概要

今年度かなり大きな案件にリーダー的な立ち位置で携わったのですが、
順調に進んでいるとは言えない案件でした。。。

この案件を通じて感じたことを同じような境遇のエンジニアの人への助言になればとまとめてみます。

実際に手を動かす役割というよりも「複数人のエンジニアを束ねる役割」の人向けです。

予定通りに進むなんてことはない

よくタスクを実行する前に工数を見積もっておおよその計画を立てると思います。
人月の神話という言葉がある通り、工数が大きくなればなるほどその工数通りには進みません。

ただ、ずらせないリリーススケジュールとかはあると思うので、どうしたらスケジュールを守りやすいか感じたことを上げておきます

予定している機能を最初から全部一気に作り切ろうとするのは無謀です。
作り始めて遅延が大きくなったころには遅延しながら進む以外に手が打てなくなります。
（かけたコストを無駄にしたくない心理が働くので、少し戻ってやり直すような調整は至難の業です）

優先度をつけて 「リリース可能な最小単位」から開発 しましょう。

※パーセンテージは目安です

進捗率10%ではなく（作業中なのでアウトプットがない）、全体のアウトプットのうち10%を完成させてもらい、方向性を確認しましょう。

全部作ってもらってから認識のズレが発覚して全部やり直しなんで笑えないですからね。。。

数人に同じ作業をしてもらうようなケースでは 先行して1人 その作業をやってみてもらいましょう。

作業してみないと分からない課題が出てくるはずで、事前に課題の潰し込みを行うことでその後の作業をスムーズに行うことができます。

万が一作業にクリティカルな問題があるときも最小のコストで方針転換をすることができます

案件は当然一人ではなく複数人で進めます。
そんなとき課題にぶち当たると「誰かがいつか対応してくれるだろう」って思うことはないでしょうか？

その課題が解決することは絶対にありません。
なぜなら 全員あなたと同じく誰かがやるだろうと思っています。

そもそもその課題はあなたの周りにしか顕在化していないものかもしれません。

あなたに降りかかった課題を解決したければ、あなたが行動しましょう。

タスクが遅延したとき、バグが見つかったとき、リリースに失敗したとき、、、
何かと犯人捜しをしていませんか？（人間の心理上したことない人はいないはず）

失敗の要因は犯人と思える「その人」だけではありません。
むしろ 「当時の状況」 や 「その人を取り巻く環境」 から原因を探るべきです。

既存のコードが汚すぎてバグが入りやすい状況であればリファクタするとか、
認識齟齬があってうまく進んでないのであればコミュニケーションを変えるとかが必要です。

コミュニケーションは伝えられる側ではなく、伝える側の改善が必要と思う派です。「分からなければ聞いて」と積極性を求めるのは危なくて「分からないことが分からない」部分は確実に抜け落ちます。

「実装が終わりました」と報告を受けたある機能について、実際はモックだらけでまだまだ実装はたくさん残っているということがありました。

この例は極端ですが、「人は良いように報告したくなる」 傾向があります。

かならず定量的なものや実際のアウトプットを確認する等で、「実態を把握」するようにしましょう。

定量的に数値を出す場合、最初だけでも数値の出し方を把握しましょう。
都合のいいように数値を出すなんていくらでもできるし、
それを許容すると現場がごまかしきれなくなった時にリカバリ仕切れないほどの遅延がいきなり現れます。