はじめに

ソフトウェア設計では、「抽象化」が重要だと言われます。

重複した処理を共通化したり、具体的な実装から本質的な概念を取り出したりすることで、変更に強く、再利用しやすい設計を作ることができます。

私自身、これまで設計について学ぶ中で、具体的な事例から共通する本質を見つけ出し、より抽象的な概念として捉えることを意識してきました。

しかし最近、別の重要なことに気づきました。

抽象化は、必ずしも最後まで行えばよいわけではない。

抽象化を進めすぎると、今度は意味が伝わりにくくなることがあります。

今回は、転職活動での企業選びを通して、このことに気づいたので整理してみます。

1. 「裁量がある会社」を探していた

これまで私は、転職先を選ぶ際の基準として、

裁量があること

をかなり重視していました。

例えば、

  • 設計に関われる
  • 技術選定に関われる
  • 仕様について提案できる
  • スケジュールについて意見を言える

といったことです。

しかし、改めて「なぜ裁量が欲しいのか？」を考えてみると、裁量そのものが目的ではないことに気づきました。

例えば、技術的負債によって実装が非常に難しくなっている状況を考えます。

現場のエンジニアが、

「このままでは予定通りに実装するのが難しい」

と判断したとします。

このとき重要なのは、必ずしもそのエンジニア自身が、

「では私の判断でスケジュールを変更します」

と決められることではありません。

むしろ、

「このままでは難しいので、スケジュールを見直したほうがよい」

という現場の判断を、上司やマネージャーが受け止め、必要ならさらに上の意思決定者に伝え、組織として判断できることのほうが重要です。

つまり、私が本当に求めていたのは「裁量」そのものではありませんでした。

現場で行われた合理的な判断が、組織の意思決定に反映されること

だったのです。

2. さらに抽象化してみた

そこで、もう一段階抽象化してみました。

「現場の判断が尊重される」ということをさらに抽象化すると、

チームとして適切な意思決定が行われていること

と言えそうです。

または、

適切な意思決定プロセスがあること

とも表現できます。

確かに、これは概念としては間違っていません。

抽象化したことで、より本質的な意味を表しているようにも思えます。

しかし、ここで問題が起きました。

分かりにくいのです。

自分の企業選びの基準として考えてみても、

「チームとして適切な意思決定が行われている会社がいい」

と言われたとき、具体的に何を確認すればいいのかが分かりにくい。

面接官に説明するとしても、

「適切な意思決定プロセスとは何ですか？」

という話になり、かえって説明が必要になります。

一方、すこし具体的にして

「現場の判断が尊重されること」

なら、かなりイメージしやすい。

例えば、

  • 技術的に難しい問題があれば相談できる
  • 無理なスケジュールなら調整を検討してもらえる
  • より良い設計案があれば検討してもらえる
  • 技術的負債の解消が必要なら、リファクタリングの時間を確保してもらえる

といった具体例にすぐ落とし込めます。

ここで私は、

「抽象度が高いほど良い」というわけではない

ことに気づきました。

3. 抽象化には「ちょうどいい地点」がある

抽象化には、少なくとも二つの目的があります。

一つは、

複数の具体的な事例に共通する本質を見つけること

です。

もう一つは、

その本質を、他の人にも理解・利用できる形で表現すること

です。

この二つは、必ずしも一致しません。

抽象化を進めることで、

裁量 ↓ 現場の判断が尊重される ↓ チームとして適切な意思決定が行われる ↓ 適切な意思決定プロセス

と、より上位の概念にたどり着くことができます。

しかし、上位概念になればなるほど、必ずしも使いやすくなるわけではありません。

例えば「現場の判断が尊重される」という言葉には、ある程度の具体性があります。

だから、

「この会社では、現場のエンジニアが技術的な問題を発見したとき、スケジュールや仕様について相談できますか？」

という具体的な質問に変換できます。

一方、

「御社では適切な意思決定プロセスがありますか？」

では、抽象的すぎて、何を聞いているのか分かりにくくなります。

つまり、

抽象化の目的は、可能な限り抽象度を高めることではない。

目的に対して、最も扱いやすい抽象度まで上げること。

これが今回の気づきです。

4. これはソフトウェア設計にも応用できる

この考え方は、企業選びだけではなく、ソフトウェア設計にもそのまま応用できると思います。

例えば、設計を考えるとき、

「この処理は共通化できそうだから、共通化しよう」

という発想があります。

さらに抽象化して、

「これは○○という概念だから、○○という抽象にしよう」

と考えることもできます。

しかし、抽象化しすぎると、

  • 何のための抽象なのか分からない
  • コードを読む人に意図が伝わらない
  • 変更したいときにどこを変更すればいいのか分からない
  • 抽象が増えすぎて、かえって理解が難しくなる

ということがあります。

つまり、

良い設計とは、最も抽象度の高い設計ではない。

その問題を解決するために、適切な抽象度で表現された設計である。

と考えることができます。

5. 「本質を見抜く」と「抽象化しすぎない」は両立する

ここは少し面白いところです。

一見すると、

「本質を考えるなら、できるだけ抽象化したほうがいい」

ように思えます。

しかし、実際にはそうではありません。

本質を見抜いた結果、

「ここから先は抽象化しないほうがいい」

と判断することもあります。

つまり、

具体的な事例 ↓ 共通点を見つける ↓ 抽象化する ↓ より本質的な概念を見つける ↓ 目的に対して十分なところで止める

という判断もまた、設計の一部です。

これは、以前から私が考えていた

設計とは、パターンを当てはめることではなく、その状況に対して適切な判断をすること

という考え方ともつながります。

「抽象化する」という技術そのものを目的にしてはいけない。

抽象化することによって何を得たいのかを考え、その目的に対して適切なところで止める必要がある。

まとめ

今回、企業選びについて考えている中で、

「裁量があること」

から始まり、

「現場の判断が尊重されること」

さらに、

「チームとして適切な意思決定が行われていること」

「適切な意思決定プロセスがあること」

と抽象化していきました。

しかし、最終的に企業選びの基準として採用したのは、

「現場の判断が尊重されること」

でした。

より抽象的な表現が間違っているわけではありません。

ただ、目的に対して抽象化しすぎていたのです。

この経験から、私は次のことを学びました。

抽象化は、すればするほど良いわけではない。

目的に対して、最も理解しやすく、扱いやすい抽象度で止めることも重要な設計判断である。

これから設計を考えるときも、

「もっと抽象化できないか？」

だけではなく、

「ここから先まで抽象化する必要があるのか？」

「この抽象化によって、誰かにとって分かりやすくなるのか？」

「抽象化したことで、かえって扱いにくくなっていないか？」

という視点を持っておきたいと思います。

抽象化する能力だけでなく、抽象化を止める判断力も、良い設計には必要なのだと思います。