手段を目的化しないこと

これまでの経験で、手段にフォーカスを当てすぎて誤った意思決定をしそうになるケースを何度か見てきた。自戒も込めて、整理しておきたい。

エンジニアリングにおいて、手段は目的を達成するための一つの方法論にすぎない。手段そのものが目的になってよいのは、「この技術の習得自体を目的とする」と意図的に宣言した検証や学習投資くらいのもので、プロダクト開発の意思決定の場面では極めて少ない。

具体的なシナリオを交えて紹介する。

kubernetes を採用してスケーラブルな構成にしたい

このようなシナリオ、意外とありませんか？

そもそもスケーラブルとはなんなのか？トラフィックやキュー、メッセージの量によってインスタンスを手軽にスケールさせたいことの意なのか？

どういった課題があるのか、ちゃんと言語化して明確化しような。それによって kubernetes なのか、別のソリューションなのか選択肢も変わる。

さらに、事業優位性と組織のケイパビリティも考慮した上で意思決定しないと後で苦しむことになるぞ。

• 事業優位性: kubernetes を運用することが、その事業の成長に貢献すると予見されるか
• 組織のケイパビリティ: kubernetes を運用する体制・スキルがチームに整っているか

kubernetes の運用に手一杯になり、feature 開発に支障が出るようでは、その選択が正しかったとは言えないよな？

オープンウェイトLLMを運用したい

この手のシナリオもありませんか？

オープンウェイトLLMを運用することで何を解決したいのか？コストなのか、セキュリティなのか、精度の向上なのかでアプローチが変わるよね。

コストの場合、オープンウェイトLLMをGPUインスタンスでホスティングしたとして、トータルコスト（ランニングコストやメンテナンスコスト）は本当に削減できるのか？また、オープンウェイトLLMにも得意不得意があるので、ちゃんと理解した上で技術選定しているか？一つのLLMに固執するなよ？

精度の向上が目的なら、ファインチューニングやRAGなどいくつか手法があるので、検証した上で提案しような？

共通するチェックポイント

2つのシナリオに共通する問いは、結局これに尽きる。

1. 解決したい課題は言語化されているか？ 「スケーラブルにしたい」「LLMを自前運用したい」は課題ではなく手段の話
2. 代替手段と比較したか？ その手段が唯一の選択肢であることは稀
3. トータルコストを見積もったか？ 導入コストだけでなく、ランニング・メンテナンス・学習コストまで含めて
4. 組織のケイパビリティはあるか？ 運用に手一杯になって本来の開発が止まるなら本末転倒
5. 事業の成長に寄与するか？ 技術的に面白いかどうかと、事業に効くかどうかは別の話

書籍

手段の目的化に話が流れがちな方は、ひとまずこの本を10回読んでくれ。読んだ後には思考が変わると思うので。

システム開発と「具体と抽象」〜問題発見と問題解決を往復する「思考のメタ化」を身につける〜

https://www.amazon.co.jp/dp/429715790X

あなたの職場では、手段を目的化して誤った意思決定はしてないか？