これもちょっと前に実際にあった話。
Windowsアプリを作成する（ベースソースはある）タスクに取りかかったのですが、
上から仕様がなかなか降りてこなかったのです。
この時点で資料としてあるのは、「こんな感じのアプリ」というイメージを書き残したスライド資料。
そして、残念なことに、先輩フリーランスのメンバーは家庭の事情で長期にわたって不在。
残されたメンバーで完成するのか？
UIに関しては、すでにイメージがあり、ベースソースもあるので、それを改修して、で、あとでその画面を実際に見てもらって、これに関しては解決。
が、実際にデータを受け取って、あれこれ処理して応答を返す処理。
このアプリの核をなす重要な部分。
この情報が情報が出てきたのも開発の終盤。
そして、クラウドサーバ（試験用）に接続するための認証処理にかんしては本当の最後の最後にようやく完成。
それまでどのように開発していたかというと、
ローカル環境に疑似サーバを作成し、その中のやりとりもある程度想像で作ってました。
てな感じで最初の開発は何とか終わりましたが、
この状況を見た、現場復帰した先輩フリーランスからの厳しいお言葉。
今後、二次開発があるのが確実なので、そのときはやり方を変えよう、という話になりました。
具体的にどうしたのか。
仕様に関しては、まだ不明点ではあるところもQA形式でこちら側で仕様を考え、「これで問題無いか」というやり方にしました。
仕様が降ってくるのを待つのでは無く、提案する形で仕様を固めていきました。
そして、毎日ミーティングを実施しました。
これによって認識のすりあわせ、進捗状況の共有、まだ決定されていない仕様の情報を少しずつ引き出す、そして、開発スケジュールの再確認。
これを実施することで、一次開発よりも二次開発の方が、こころにゆとりを持って開発できました。
やっぱりマネージャークラスのスキルを持っている人は、考えることが違うなぁ。
というか、ミーティングのセッティングや仕様のQAの整理とかは社員メンバーに全部任せて、
自分はほぼほぼコーディングのみを行っていましたけどね。
まぁ、うちの現場ではこんなことあったよ、と言うことで、参考になれば。