コンサルタントとして提案を行い、そのまま自分で実装まで担当する。そんな経験を積む中で、「提案フェーズで見えていた世界」と「実装フェーズで見えた現実」の間には、思った以上のギャップがあることを実感してきました。この記事では、同じ案件の中で提案者と実装者を兼ねた筆者が、そのギャップをどう経験し、どう向き合ってきたかを紹介します。
提案時点では、クライアントの「内側」は見えない
提案フェーズでは、クライアントから提供される情報をもとに、システムの構成や実装の方向性を組み立てます。しかし、提案時点で見えている情報は、あくまでクライアントが「外に出せる情報」に限られます。
実際のデータがどういう状態で存在しているか、社内ドキュメントがどこまで整備されているか、現場の担当者が業務をどのように運用しているか。こうした「内側」の情報は、提案の段階では多くの場合、正確には把握できません。
そのため、提案書の中に書く実装イメージは、ある程度「想定」の上に成り立っています。実装難易度についても、「このくらいの工数でできるはず」という見立てを立てますが、その見立てがどこまで現実と一致しているかは、実際に着手してみるまでは確かめようがない部分があります。
いざ実装に入ると、見えていなかったものが出てくる
実装フェーズに入ると、提案時点では見えていなかった課題が次々と顔を出します。
最も多いのは、データやドキュメントの状態が想定より整っていないケースです。AIエージェントの開発であれば、参照させる情報源が必要になりますが、その情報がドキュメント化されていない、あるいは担当者の頭の中にしかない、という状況は珍しくありません。予測モデルの開発であれば、学習に使うデータの形式が統一されていない、欠損が多い、そもそも必要なデータが存在しないといった問題が出てくることもあります。
もう一つよくあるのは、要件の抽象度が高いままになっているケースです。「こういうことができるようにしたい」という方向性は合意されていても、具体的にどういう入力に対してどういう出力を返すべきかが詰まっていないと、実装の途中で方向性を何度も確認し直す必要が生じます。
これらは、提案書の中で「できる」と書いた内容が間違いだったわけではありません。ただ、実際にかかる時間や手間は、提案時点の見積もりより大きくなることが多い、という現実があります。
「提案する自分」と「実装する自分」で見えた景色の違い
同じ案件の中で提案も実装も担当すると、二つの視点を同時に持つことになります。
提案フェーズにいるときの自分は、「この構成であれば実現できる」という全体像を描きながら、クライアントに方向性を示すことに集中しています。一方、実装フェーズに入った自分は、「この部分のデータが足りない」「この要件はもう少し具体化しないと進めない」という細部の問題と向き合うことになります。
同じ人間が同じ案件で両方を経験すると、「提案時点で何が見えていて、何が見えていなかったか」が非常にクリアになります。提案書に書いた一文が、実装の現場ではどれだけ大きな前提を含んでいたか。後から振り返ると、提案時点の自分が持っていた「想定」の多さに気づくことがよくあります。
この経験が、次の提案にどう活きるか
提案と実装を繰り返す中で、提案フェーズでの問いの立て方が変わってきました。
以前は、「この構成で実現できるか」を中心に考えていました。今は、「このクライアントのデータ・ドキュメントの状態であれば、実装にどれくらいの準備が必要か」という視点が自然に加わるようになっています。
具体的には、提案の段階でクライアントに確認する項目が増えました。既存のドキュメントがどの程度整備されているか、データはどの形式でどこに存在するか、現場の運用ルールがどこまで明文化されているか。こうした確認を提案フェーズで行うことで、実装に入ってから「想定と違った」となるリスクをある程度下げられるようになったと感じています。
提案と実装を一人で担うことは、負荷が大きい反面、こうした「実装から逆算した提案」の精度を高める経験としては、得がたいものだったと思っています。
まとめ
コンサルタントとして提案を行い、そのまま実装も担当することで、「提案フェーズで見えていなかったもの」が実装フェーズで次々と現れる経験を積んできました。データやドキュメントの整備状況、要件の抽象度の高さ、こうした課題は提案書の段階では見えにくく、実装に入って初めてその影響の大きさが分かります。
この経験を通じて、提案の段階でクライアントの「内側」をどこまで把握できるかが、その後の実装の進め方に直結することを実感しています。提案と実装の両方を担うからこそ気づける視点を、今後の仕事にも活かしていきたいと考えています。
コメント