令和初の炎上プロジェクトでの学びと改善
昨年会社を立ち上げて、初めてきつい思いをして乗り切った某案件。試行錯誤の末に現在はなんとか安定稼働しているけれど、年末年始は懸念していたリスクの浮上で1人炎上・・・。
今回は、その時の反省点と、改善したその後の振り返りを書いてみたいと思います。
※セキュリティの都合上、ところどころ内容をデフォルメしています。
Contents
はじめに
簡単に当該プロジェクトの概要をご紹介します。
- 稼働中システムの追加開発（システム自体は別ベンダーが開発したもの）
- PM、技術者全員リモート
- クライアントとのMTGも基本リモート
- 1段階大きなリニューアル改善を見据え、その後は月次リリースに
- 費用・契約は月額制
ステークホルダー含め、少し複雑な関わりがありますが、開発本体はいたってシンプルな構成です。
見えていたはずの潜在リスクの数々
先に結論を言ってしまえば、この案件が炎上した元々の発端原因は私の甘えであり、何より自分の首を締めていたのは自分でした。
「これはマズそうだな〜」と思っていながらも、他業務の忙しさなどを理由にあまり当該プロジェクトにきちんとした整備の時間を割けず、間違ったスコープ制定や権限移譲をしてしまったように思います。
自分の専門外技術のマネジメント
元はと言えば、本件は開発自体を依頼されたわけではなく、上流工程のサポートとして私1人がアサインされたまででした。
しかし、MTGを重ねるうちに、クライアント側には開発体制の目処がないことが発覚。そこで私のほうで要員調整含め担当することとなったわけですが、そのシステムの使用技術が自分の専門外でした。
とはいえ、PMが必ずしも技術を知っていなければいけないとは思いません。今回も特に問題ではないと判断したからこそ承諾しましたが、他の要因も重なり、これが後に大きく影響してきます。
現にこの時も、
- いざという時にタスクを巻き取れない（見守るしかできない！）
- 仕様レビューはできるがコード品質を担保できない
といったことが後半に起こってしまいました。
ウォーターフォールでもスクラムでもない中途半端な方針
色々と複雑な事情もあり、「とりあえず走りながら進めていこう」という空気が強かった当該プロジェクト。
完璧に上流工程を固めて仕様に落とせるわけでもなく、かといって対応メンバーの稼働時間も固定でないために活動がバラバラでスクラムのように体系化もできず、なんとなくなぁなぁにその場しのぎの開発を進めてしまっていました。
上流工程で仕様が決まったり、変わったり、その都度の連携で開発を進めることになったため、手戻りの発生や混乱を避けることが難しくなっていたのです。
体制の構築不足による品質低下
普段、私はフリーランスのエンジニアさんと直接やりとりさせていただくことが多いのですが、この時は自分の専門外の技術だったことと、そもそも手が足りなかったこともあり知人の開発会社に必要なメンバー調整も含めまるっとお願いしました。
最終的に、まだ経験の浅いメンバーが参画することとなりましたが、その知人の技術は信頼していたので、アサインされたメンバーのスキルチェックも怠ってしまったのです。それが後になって見積もりの甘さに繋がります。
今日終わると思っていたタスクが明日に、明日と思っていたものが明後日に、と開発にかかる工数が自分が一般的に認知していた経験者工数に比べて倍以上かかってしまう結果に。
さらにはコードレビューもパートナーに任せっきりとしていた末、時間不足によりレビュー品質が下がっていくなどの別の問題にまで発展してしまいました。
後回しにしたベンダーコントロール
他にも難関はありました。
元々、当該システムは別ベンダーが開発したものであり、今もなお運用保守としては別ベンダーが絡んでいます。
今後の開発に際しての取り組み方や、リリース作業の分担など、調整が疎かになっていたために、双方で別管理のソースコードをいじってデグレを出してしまうなどの問題も起きてきました。
そうこうしているうちに、予定していたリリースは気がつけば来週、再来週、来月・・・と伸びていってしまったのです。
表面化したリスクの乗り越え方
この時点で、クライアントには何度も延期調整をお願いしており、「時すでに遅し」な状態だった進捗状況。悠長に反省会なんてしている暇もなく、今はとにかくこの場を収めてリリースを間に合わせなければもう後がない！といった緊迫感でした。
CTOレベルの技術力でなんとかカバー
本来は会社の持ち出し予算で赤字になるだけなので、絶対にこんなことはしませんが、ここは技術力で持ち直すしかない、と役員陣にヘルプ。
弊社役員2名も当該システムの技術はメインではありませんが、非常にキャッチアップが早く、どの技術にも精通しているメンバーなので本当に助かりました。（手前味噌ですみませんw）
私が巻き取っていたら数時間かかりそうだった修正も数十分でプルリクしてくれて、なんとか少しずつ火が消えていくことになります。
ついにPMもコードを触る
全く専門領域でない上に、数ヶ月ぶりとなる開発でしたが、それでもやるしかない、というこの状況。調査しながら私もせっせと深夜まで手を動かし続けました。
無論効率は悪かったような気がしますし、良いコードとは言いがたいものだったかもしれませんが（後にリファクタした）、当時はユーザーの利用も迫っていたためとにかくリリースファーストでした。
このように、もはや付け焼き刃でしかない方法でなんとかリリースを乗り切ったのです・・・。
仕切り直して、再出発
その後、さすがにこのままの体制ではマズいな、と反省した私は、翌月からメンバーの刷新とともにプロジェクトの進行ルールを明確化することにします。
チーム体制の見直し
これまで経験の浅いメンバーに広範囲を担ってもらっていたことを反省し、フルジョインする必要がないプロジェクトであることを利用して、スキルの高い副業メンバーを中心に体制を構築しなおしました。
また、専任がいるべきところには専任を配置し、品質と生産性の両方をあげることができました。
レビュー方針の明確化
誰がどこまで品質担保すべきなのか、曖昧になっていた問題を解消すべく、レビューに関するレギュレーションも用意しました。
- プルリクを出す前のチェックリストを作成し、最低レベルを底上げ
- レビューを通すための条件や確認フローを明文化（コードレビュー完了後にPMの仕様レビュー等）
- チーム内レビューを強化しつつ一部レビューは専任化（デザインレビューはデザイナーが対応等）
開発スコープの見直し
これまで、いきあたりばったりの仕様追加などが発生していた状況から、毎月の工数上限を決めて、さらにスコープを制限する方針に切り替えました。
- 月に1度の決まったリリース日を策定
- リリース日をターゲットに3-4件の仕様が確定した要件のみ対応
- リリースを延期する条件やタイミングも明確化
こうして年末年始の反省を生かし、新たな体制とルールで開発を進めていくことにしたのです。
そして現在
ありがたいことに、その後もずっと関わらせていただいているプロジェクト。現在は落ち着いた状況で安定的に進められています。
ただ、それはそれで今度は別の課題も出てきたりしているので、定期的に振り返りの余地はありそうです。
- 開発スコープを絞り過ぎて温度感が停滞する
- メンバー数に比べて開発課題が少なく、うまくタスクを割り振れない
- 副業メンバーが多いと夜間や土日にコミュニケーションが発生する
副業メンバーの採用は、こういった可変的な開発タスクでうまく機能する反面、コミュニケーションコストがかかってしまうのも事実。
この辺りは仕組みで改善していけるかなと思っているので、また実践したらご報告させていだきます！
何はともあれ、何事も初心を忘れて気を緩めると、必ずどこかで崩れてしまうもの。
今後は、今回の反省を生かし、整備した体制やレビューフローを横展開して他プロジェクトでも整備して使っていきたいと思います。
なお、私のように複数案件を担当したり自分のパフォーマンスを分散しつつも発揮する、という手法については以下も参考にしてみてください。
武蔵野音楽大学卒業後、ヤマハ特約楽器店にて音楽教室の運営企画に従事。2014年にSIer企業への転職でエンジニアへ転向し、証券システム、IoT事業など複数プロジェクトの開発を経験。その後、自社サービス立ち上げや法人向けJava研修サポート講師を経て同社のマーケティングマネージャーを歴任。
データ分析・マーケティングの知見を活かしたITサービスの企画・要件整理支援のほか、プロジェクトチーム構築や情報整理を得意とする。
現在は合同会社PeerQuest代表兼PMアドバイザーとしてプロダクト開発組織の内製化を支援している。認定スクラムプロダクトオーナー（CSPO）取得。
