BETA

大炎上した案件にアサインしてわかったプロジェクトを運用する上で大切なこと

投稿日:2020-04-09
最終更新:2020-04-09

大炎上後のアサイン

約半年前、私は会社の歴史史上とんでもない大炎上を起こした案件を引くことになりました。
アサインした当初、クライアントも今までのことがあったのでピリピリしたオーラを醸し出していました。
案件ガチャのむごさを痛感しましたが、また炎上して火の粉を浴びたくないのでどうにかして安定的に案件を運用できないかずっと考えてました。

なぜ炎上するのか

案件が炎上する原因は、スケジュールが遅れる要因にあります。
例えば、チームの技術力不足、プロジェクト進捗への認識の欠如、情報共有の欠如、仕様理解への甘さ、課題の放置などがあります。
私のいる会社ではたびたび情報共有の欠如とプロジェクト進捗への認識の欠如、課題の放置が問題になり案件が炎上するということがあったので、まずはこの3点をしっかり改善し、チームの体制から変えていくように動きました。

プロジェクトを見直す機会を作る

情報共有や課題の放置については、2週に1度、チーム全体で振り返る時間を作り、プロジェクトで出た課題や実践していい効果がでたこと、今後も続けられたらいいことなどを話し合い、改善案を実行に移していくことで少しずつプロジェクトの問題点を解消していきました。

振り返りは面倒なものと思いがちな人が多いかもしれませんが、着実に問題に向き合い解決していくためには必要不可欠なものです。
また、チーム全体で話し合う場を設けることでプロジェクトへの現状認識を深める場ともなります。

振り返りのタイミング

振り返りを行うタイミングも重要で、過剰な話し合いは無駄と怠惰を生み出しますが、2週に1度などほどほどに控えた振り返りは、ある程度課題が溜まっきて、前回の振り返りで出た改善案も実行フェーズに移っている頃合いなのでベストなタイミングだと思います。
もし課題が溜まっていないのであれば2週に1度やる必要がないか、プロジェクト進行が完璧かのどちらかです。
改善案が実行フェーズに移されてない場合は、改善案そのものに問題があるか、プロジェクトに与えられたリソースが欠如していることが考えられます。

振り返りには、KPTというメソッドが有効なので振り返りがうまく回っていないチームには是非検討していただきたいです。

【徹底解説】正しい「KPT」が仕事の成果を生み出す!進め方のコツ、現場の事例を紹介

スケジュールの徹底管理

タスクの抜け漏れがないようにスケジュール通り進めることは意外と難しいもので、最も気を配っておかなくてはなりません。
例え、バッファが数日合っても1日遅れたとしたらそれは、まごうことなき1日遅れであり当初のスケジュールから1日遅れているということになります。
遅れたとしても遅れた負債をバッファで補うという考えはしてはいけません。
バッファは案件に関わる人すべての精神衛生上の担保であり、予測できない事態に対するバッファでもあります。
私が今まで入った案件ではバッファがあるので遅れた分は巻き返せる、という考えが蔓延しており、何度も失敗しています。

ガントチャートの導入

私はまず、プロジェクトをもっとわかりやすい形で可視化するべくガントチャートというものを使ってチームで進捗を管理するようにしました。
ガントチャートを使うと、いつどのタスクを始めていつ終わらせるのかを決められるのと、進捗がひと目でわかるのでプロジェクトがどういった状態に合って残りのタスクがどのくらい残されているのかなどひと目で理解することができます。

ここで注意が必要なのは、ガントチャートは作って満足してはいけないということです。
プロジェクトを進める中で新たなタスクが発生することや、進捗が早まる、もしくは遅れることもあるので、定期的に見直す必要があります。
これはかなり重要なことで、私自身、見直す時間が十分に確保できなかったことと見直すことの重要性への理解が乏しくスケジュールがうまくコントロールできず失敗した経験があります。
失敗後は週に1度チームでガントチャートと新しく発生したタスクの見直しをする時間を作るようにしました。
おかげで残されたすべてのタスクとそれにかかる時間、優先度などを短いスパンで確認することができ、以前よりもプロジェクトの運用がスムーズになりました。

他プロジェクトを巻き込む

大炎上後の案件に入って数カ月、現行で動いているシステムをReactに移行するリプレイス作業が始まりました。
Reactを社内で経験した人は僅かにいましたが、その人たちがReactに触れたのは遠い過去の話で、すでにHooksの時代に入っていたことや新しいプラグインが続々と出現していたので本当にReactをできる人はゼロの状態でした。

最近はReactやVueといったJSフレームワーク全盛期の時代でもあるので徐々に社内の案件でもReactが導入されていく流れになっていました。
そこで私は思いました。
チームのReactに対する技術力不足で各案件で火を吹き出すのではないかと。
以前社内でReactを触っていた人たちが必死になって実装していたので、おそらく各案件で火を吹き出すのは時間の問題だと思っていました。
とにかく火に対して恐怖心がある私は、早い段階でこの起こり得る状況を、万が一起こったとしても軽い火傷程度ですむようにReactの勉強会を定期的に開くことにしました。
今でも社内のReact案件に携わるメンバーの協力もあり継続的に開催ができています。

React勉強会では単に誰かが資料を用意して話すのではなく、React実装に関することで課題になっていることや知っておいたほうがいいことなどを議論、共有する場として機能しています。

また、社内のSlackチャンネルにReactのナレッジを共有、議論する場を設けることで常にReactについて話せるようにしました。

私の入っているプロジェクトはReactを実装する開発者の人数が2人なので、他のプロジェクトメンバーとReactのナレッジ共有や議論できるようになったことはお互いに非常にいい効果をもたらしました。

これまでやってきた炎上対策は何も難しいことではなく、2週に1回の振り返りに30分程度の時間と、1週に1度のスケジュールの確認に10~20分程度の時間を割くだけです。
振り返りについてはKPTを使えば決められた形式に沿って話を進めるだけなので何も難しいことはありません。
絶賛炎上しているエンジニアの方は一度試してみてはいかがでしょうか。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@uichiの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう