フロントエンド開発を担当し、最近はマネジメント業務についても学んでいるT.C.です。
ソフトウェア開発では、日々様々な課題に直面し、その解決のために小さな意思決定を積み重ねていくことになります。
本記事では、私が3年ほどのソフトウェア開発経験を通じて感じた、この「選択」の難しさと面白さ、そしてその「共有」のあり方について、私なりの考えを共有させていただきたいと思います。
業務で開発を始めたばかりの頃のイメージと実際の乖離
開発業務に携わり始めた頃は、スキルが向上すれば、 数学の問題を解くように明確な「正解」の開発手法が見つかり、開発速度も飛躍的に上がっていくものと想像していました。 もちろん、スキル向上による開発効率の向上は実感できましたが、同時にどれだけ経験を積んでも、100%の「正解」に到達することが難しいということも痛感しました。
絶対的な正解はない
業務で開発を始めたばかりの頃は、次のような考え方を無意識に持っていたように思います。
- ライブラリがあるなら、それを利用するのが良い
- 共通化できる箇所は、積極的に共通化すべきだ
- リファクタリングできる箇所は、改善した方が良い
- 新しい技術やツールがあるなら、積極的に採用すべきだ
これらは一面では正しいと言えるでしょう。しかし、別の視点から見ると、必ずしも万能ではないことに気づきました。例えば、
- ライブラリの導入は、その制約によって柔軟性が損なわれ、結果として機能追加が困難になったり、予期せぬ工数増加や設計の複雑化を招くことがあります。
- 過度な共通化は、特定のケースへの対応を複雑にし、かえってメンテナンス性を低下させる可能性があります。
- リファクタリングは、貴重な開発リソースを消費します。その結果、新機能開発の遅延に繋がることも考慮しなければなりません。
- 新しい技術の採用は、バグや未知の問題に遭遇するリスク、知見不足による学習コストの発生など、かえって開発効率を低下させる要因もはらんでいます。
これらはほんの一例ですが、どのような意思決定においても、絶対的な「正解」は存在しないのだと痛感するようになりました。そして、それぞれの状況に応じた「より良い解」を見つけ出すことこそが、ソフトウェア開発の難しさであり、同時に大きな魅力でもあると感じています。
最終的には、メリット・デメリットを多角的に比較検討し、「この状況と目的に鑑みて、現時点ではこの選択が最も合理的である」という判断を下していく必要があるのではないでしょうか。
じゃあどうするか
選択までの大切なプロセス
では、絶対的な「正解」がない中で、どのように意思決定を行っていけば良いのでしょうか。私なりに重要だと感じているのは、「情報収集」「思考」「選択」という一連のプロセスです。
例えば、テーブルコンポーネントを新たに作成する場面を想像してみましょう。「情報収集」の段階では、一般的なテーブルコンポーネントの実装方法を調査したり、利用可能なライブラリを探したり、現在のアプリケーションの特性や制約を把握します。「思考」の段階では、これらの情報を基に、ライブラリを利用するメリット・デメリット、あるいは自作する場合の設計方針などを検討します。このプロセスを経て、最終的に「～という情報を基に、～と考えた結果、今回はこのような方針で進めます」といった形で、自身の判断の根拠を明確にできるようになることを目指しています。 このプロセスを意識するようになったのは、これを怠った場合に起こりうる失敗を過去の経験や見聞から学んだためです。
もちろん、どのような情報を収集し、それを基にどのような結論を導き出すかは、個人の経験や知識によって異なります。この部分に絶対的な「正解」はなく、それぞれの知見や価値観が反映される余地があり、多様なアプローチが生まれる源泉でもあると考えています。
情報共有のバランス感
チームで開発を進める上では、各メンバーが担当業務に集中するため、全ての情報を全員が詳細に把握し続けるのは、現実的に難しい面もあるでしょう。しかしその一方で、より良いプロダクトをチーム一丸となって作り上げていくためには、意思決定の背景や根拠を含め、多くの情報をメンバー間で共有することが非常に重要だと感じています。 ここで言う「多くの情報」とは、最終的な「情報収集 ↔ 思考 → 選択」の結果だけでなく、そこに至った経緯や判断材料なども含みます。
理由の共有が大事
そこで、効率的な情報共有の一つの形として、「結論」だけでなく、その結論に至った「理由」を簡潔に添えて共有することが、良いバランスではないかと考えています。
あくまで私個人の感覚的なものですが、共有する情報の内容と、それによって相手に伝わる情報量のイメージを数値で表すと、以下のようになるかもしれません。
| 伝えるもの | 伝える情報量 | 伝わる情報量 |
|---|---|---|
| 結論だけ | 10 | 50 |
| 結論 + 理由 | 20 | 80 |
| 全ての情報 | 100 | 100 |
もちろん結論は最も重要な要素です。しかし、「結論だけ」を伝えるよりも、「結論＋理由」を伝える方が、受け手にとってはより多くの文脈が伝わり、結果としてコミュニケーションの質が高まるのではないでしょうか。このアプローチは、効率性と伝達される情報量のバランスが良いと考えています。 また、理由を共有することは、単に効率的であるだけでなく、受け手に解釈の余地を程よく残すことにも繋がります。これにより、多様な視点が生まれ、チームとして局所的な最適解に留まらず、より本質的な解決策に近づける可能性を高めると感じています。 どこまで情報を共有するか、その具体的な線引きは、チームの状況や文化によって異なり、それぞれのチームの工夫が活かされる部分でしょう。
まとめ
本記事では、意思決定における「情報収集 ↔ 思考 → 選択」というプロセスの重要性と、その結果を「結論と理由」として共有することの意義について、私なりの考えを述べさせていただきました。
AI技術が目覚ましい発展を遂げる現代において、私たち人間が自ら考え、判断する能力の重要性はますます高まっているように感じます。AIのそれらしい情報や、有名な技術者から得た情報は収集すべき大切な情報であると同時に鵜吞みにしてしまいがちなものですが、目の前の課題と照らし合わせて、自分で「思考」して「選択」することも忘れないようにしたいですね。
私自身、日々の業務では思考に偏りがちな面もあるため、改めて情報収集の重要性を意識し、その理由の共有を、より一層心がけていきたいと考えています。
あとがき
以前、後輩から「どのような人が『賢い』と思いますか？」と尋ねられた際、「情報収集と思考、その両方のバランスが取れている人ではないでしょうか」と答えた経験があります。すると後輩が、イマヌエル・カントの「内容なき思考は空虚であり、概念なき直観は盲目である」という言葉を教えてくれました。
カントの言う「内容がない」が情報収集の不足を、「概念がない」が思考の不足を指すのだとすれば、選択までのプロセスで大切にしていることと通じるものがあるように感じます。どちらか一方に偏るのではなく、両者をバランス良く行うことの重要性を示唆しているのでしょうか。
恥ずかしながら、カントという名前は高校時代の記憶にかろうじて残っている程度で、その思想については深く理解していませんでした。そのような言葉を的確に引用できる後輩の知識には、素直に感心させられました。
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp
