https://www.itmedia.co.jp/im/articles/0208/16/news001.html
エンジニア2年目の頃、上記案件へ参入。
小さなSirから請負でTCS経由から富士通へ。
TCSのメンバーとして参画した。
案件初日、席に着くと隣に頭を抱え下を向く人が座っていた。
彼はそのチームのリーダーだったのだが、設計書を書きコードを書き、
表示したときにエラーが出てなんとかエラーを直したが良く解らない画面でどん底の状態だった。
私も設計書を初めて体験し、まだ経験も薄い為、この状態に危険は感じた。
すぐさま考えたのが、チームメンバーに聞きに行くことだったが、7人もいるのにだれ一人解らないとの回答。
じゃあそれでは、コードと設計書を同じ状態にしてみようと、設計書を読みながらコードを修正していく。2，3日で良い形になっていった。
これで一旦良いかなと思いPMに確認に行くと、違うと言われるのだが、
何度も何度もPMへ足を運び、どこがどう違うのか？などの話をしながら作っていく。
私は海上だったが、その後陸上のチームが来て私個所を担当するとのこと。
「これ結構大変だったよ」というと彼は
「大丈夫です、あなたが作ったのをコピーして直すだけなので」
だってさ。
結局1週間で片付いてしまったのだが。私が終わらせたタイミングで、7人チーム撤収し、
TCS本社で残りの3週間待機所で待機して終わり。
ポイントとしては、まず設計書があるのであれば、設計書とコードを一致させる必要がある。
そして何よりも、理解できていない人に確認をする必要はなく、理解をしている人に直接聞くのが大事である。
この場合、私はPM3人組の一人と密に相談をしていた。
仕様を把握している人との会話が一番大事な事である。ただしかし、仕様を把握しきれてない人でもあったので、思いだして貰うのに手間取ったし、「この資料みて」で済まそうとしたタイミングもあったのでそこは一歩も引かなかった。
案件を早く終わらしたいならば、全員本気を出さなければダメという教訓でもある。