「ソフトウェアを開発する」を生業に、40年もの間コードを書いてきました。
会社員のころ開発を始めるとき、必ずといってよい作業があります。
それは、どれくらいで作れるかを見積もる事です。

当たり前のように行うこの作業、何を根拠に見積っていたのでしょう？

よくわからないシステムだったり、プログラムでも、必ず聞かれます。
当たりもつけていない段階でも、「ざっくりでいいから」とか上司、営業やお客様に聞かれます。

今まで作ったものを参考にできるようなものだったり、修正案件だったりすれば、それも可能かもしれません。

しかし、作ったこともないものを、どうやって見積ればよいのでしょう？

コストを見積もらないと、話が先に進まないということも理解できますが、一度公言した開発規模を後で変更できないというのも、現実なのです。

計画と現実のギャップを誰が埋めるのか

実現方法が明確でないソフトウェア開発を開始してみたところ、色々な壁にぶつかるというのは、よくある話です。
本来なら、そこがリーダーの出番なのです。リーダーとは、プロジェクトのリーダーだったり、その上位の部門マネージャーだったりします。

とにかく、実際にコードを作っている人をマネージメントしている人が、計画と現実の課題のギャップを埋めることや、埋めるために何が必要かを整理することが役割なはずです。
しかし、なぜか、コードを作っている人に「何とかしろ！」的だったり、「いつ頃できる？」だったり、「それを聞かれましても、返答に困ります。」の質問をよくしてきます。

「そんなリーダーに遭ったことがない」という人は、ある意味、幸せな世界で生きていると思っていいですね。

結局は、課題を乗り越える方法は、コードを作っている人が乗り越えていかなければならないか、スーパーマンが助けに来てくれる事を待つしかないのです。

でも、よく考えてみてください。「実現方法が明確でない」ところから始まったことなので、壁にぶち当たっても、「やっぱりね！」ってことなのです。

問題は、「実現方法をどれだけ明確にしてから、開発に入るか」ということなのです。

40年の開発から一つの答え…

「実現方法をどれだけ明確にしてから、開発に入るか」の答えは、作ろうとする対象を２つのカテゴリに分け、検討することです。

• 論理的構造（やればできるので、そのボリュームを検討）
• 技術的課題（H/Wや実装方法の不透明度合を検討）

論理的構造は、システムや、プログラムの論理的動作の流れと、処理の流れを各種図にて整理します。
この部分は、どんな言語や環境でも、時間さえあれば作れる部分です。
作れないとか、？？？な点があれば、それは、要件が不明確として具体化をすればよいレベルで、論理破綻がなければ、必ず実現できます。
最数的には、どれくらいで作れるかを見積もる話で、これは経験値で算出することでできます。

技術的課題、これが、開発計画にたいするズレを起こす根源です。
H/W的な問題だったり、実装できそうであっても、コードを作る人が、実装の方法をどれくらい理解しているのか？経験しているのか？
私の経験としては、ここは実証試作（部分的なもので十分）を行うということです。
自分にとって、未知のターゲットであれば、これを行うまで、時間稼ぎをして計画策定を遅らすことです。

実証試作とは、実際のターゲットを作るわけではなく、サンプルコードで、仕組みの理解を行うことでも十分な場合もあります。
H/W制御が関係する場合、H/Wを実際に使ってみたり、そのH/W相当の動作をエミュレートできるものを探し実際のプログラムとの関係を実現するか、中間層を入れた設計にすることです。

「技術的課題」をどれだけ周囲に理解してもらい、その課題の解決手段を具体化するか？
これに尽きます。
そのために、40年くらい前なら、「書籍」に頼っていましたが、そのうち「ネットでググル」れば情報が見つかったりしました。
今では、「Colilot」や「ChatGPTなどのLLM」は強力なツールです。
これらのツールを駆使することで、「技術課題」の検討で行う「実装試作」は各段にスピードアップできます。
実際のコード作成時にも利用できますが、調査段階での利用は、本当に有益です。

みなさんも、新しいツールを使い、計画と現実のギャップの少ないソフトウェア開発を是非行ってください。