失敗談

未経験入社後1年5ヶ月経過したタイミングでありがたい事に、ある予約システムのプロジェクトリーダー（PL）を経験させてもらえる事になり、約6ヶ月の開発期間を経て、先日リリースを迎えました。

しかし、度重なる仕様追加・メンバーのコロナ感染による不在期間があったとはいえ、当初計画していた開発期間3~4ヶ月に比べて大幅に期間オーバーし、納品した形となります。

我々の担当範囲ではない別プロジェクトの納期が大幅に遅延していたため、我々の担当範囲であるプロジェクトの納期調整が効いたのと、終盤の約1ヶ月間は先輩社員にアサインしてもらえたおかげで何とかリリースできた形となります。これに関しては力不足を感じざるを得ません。

技術力が不足していたのは言うまでもないのですが、それ以外の要因で失敗だったと感じる部分はあります。それをこれから記述していきます。

開発について

アジャイル開発
4~5人のチーム体制
タスク管理ツールを使用(今回はbacklogを使用）

失敗の内容

失敗と考えている点は以下です

仕様変更の可能性が大いにある段階で、backlogにそれぞれのタスクの詳細を厳密に書いてタスク起票した

これはプロジェクトがどの段階なのか？によると思うのですが、仕様があまり決まっていない・納期にまだ余裕がある段階では、クライアントからやっぱりああしたいこうしたいという要望が出てくる可能性は高いと感じました。（実際に要望が出てきました）

タスク起票にはかなり時間を使いましたが、変更が入ると都度メンテをする必要が出てくるので、タスクの数が多いほど精神的にも工数的にも辛いです。メンテ専任がいるなら別ですが、仕様変更が起こり得る状況ではタスク起票の内容は最低限の構成にとどめて、早く動くものを見せてクライアントFBをもらう方がよっぽど効率が良いと感じました。

1個1個のタスクについて厳密に工数を定義してしまった

あるタスクは0.5h、あるタスクは1h、あるタスクは2hといった形で登録しました。
(これもかなり時間がかかる作業でした）

結果として、実際にかかった工数はズレました。

別の仕事の差し込みや作業員の力量不足など、様々な要因が発生し得るので、
大体2時間くらいで終わるであろうタスクを1タスク2時間で設定し、
1日で3〜4タスク消化する事を目標として計画を立てる方が良いと感じました。

プロジェクト全体の開発進捗の遅れを自分で挽回しようとした

結局挽回できませんでした。（挽回できているようで品質が悪かった）
自分はジョーカーのような最強キャラではありません。
挽回できているようで品質に問題が出てきたり、体を壊したりする可能性があるため、
プロジェクト全体として開発進捗の遅れが生じた時は、早くレスキューを挙げるべきと感じました。
これについては後ほど改善策で記載をしますが、「タスク工数のバッファだけでなく、人員にもバッファを持たせる」という話に繋がります。

ガントチャートでタスクの実施日時を動かし、遅延分の埋め合わせを図った

他のタスクに被る形で、社内テスト・クライアントテストの実施期間をずらしました。
結果的にはこの期間内にテストを実施しなかったのですが、よくなかったと感じる部分があります。

これらの行いは、ガントチャートの見た目上うまくいくよう調整しただけであって、
あるステップを疎かにしよう、できた事にしよう、と言う気持ちが働いてしまうため、
何か必要な機能が抜ける・必要なテストが漏れる、などの現象に陥る可能性が高いと感じています。

結果として偽った報告をしてしまった

クライアントとの納期調整も行えているし、ガントチャート通りいけば問題ないと考えていました。
プロジェクトが危険な状況だという事の判断基準を自分の中で明確に持ち合わせていなかったので、レスキューを挙げることができませんでした。
結果として、テストが十分に実施できておらず、品質に問題があった訳です。

レスキューを挙げる事は本当に難しいと感じました。

もしかしたらプロジェクトがうまくいくかもしれないと言う気持ち
やりきるという信念
負けたくないというプライド

これら全てを捨てる訳なので難しいのですが、プロジェクトを管理する立場の人は、
気持ちなど隅の方に置いておいて、客観的に見れるようにならないといけない。
よっぽどな実力が無いと挽回などできない、という教訓を得ました。

テストアップ前に品質の担保ができなかった

リリース前に何回かに分けてテストアップがある訳ですが、
バグが発覚するケースが多かったです。
これに関しては理由はシンプルで、開発の段階でテストケースを洗い出し、
テストコードを書いていなかったためです。
テストファーストで開発を進めていく必要があると感じました。

プロジェクトが終盤になるに連れて、テスト工数がバカにならなくなってきた

これも上記と同様です。
後でリグレッションテストにかかる工数を考えると、
開発時にテストコードを書くことに工数をかけた方が、品質・全体工数としてメリットがあると感じました。

開発メンバーそれぞれの得意・不得意が違ったため、得意な人に得意なタスクを振ってしまっていたため、作業負荷が偏ってしまった

これを続けていると、どうしても作業負荷が偏ってしまうと感じました。
持っているタスク的に余裕があるな、というメンバーが出てきてしまいました。

タスクができない人をできるようにする事で、
タスクの割り振りも柔軟に行えるため、比較的暇な人が減り、タスク消化率が上がります。
また、1人のメンバーしかできない・知らないという状況は、単純にリスクです。

改善策

失敗を色々と記述しましたが、それぞれの改善策を考えました。
自分の中での次のプロジェクトの大まかな方針としつつ、状況に応じて軌道修正していければと思います。

どの機能がいつまでにできている必要があるかというマイルストーンを設け、それが間に合うかどうかだけ管理する

仕様変更の可能性が大いにある段階で、backlogにそれぞれのタスクの詳細を厳密に書いてタスク起票した

個々の作業者がその機能を細かく分解し、タスクとして管理するのはやるべきと思いますが、PLとしては、マイルストーンの管理だけを行い、それが達成できそうかどうかは動くソースコードで判断するのが良いと感じました。この判断能力はこれから鍛えていく必要があります。

工数はざっくり1タスク2時間で設定する

1個1個のタスクについて厳密に工数を定義してしまった

これについては失敗の内容で記載した通りです。
別の仕事の差し込みや作業員の力量不足など、様々な要因が発生し得るので、厳密な工数を計画してもズレが発生すると感じました。
なので大体2時間くらいで終わるであろうタスクを1タスク2時間で設定し、
1日で3〜4タスク消化する事を目標として計画を立てる方が良いと感じました。
そしてPLとしては、機能単位でのマイルストーンを管理し、個々の作業者が2時間単位でタスク管理する形が良いと考えています。

PLがタスクを持ちすぎないようにする事で、スケジュールだけでなく人員にもバッファを持たせる

プロジェクト全体の開発進捗の遅れを自分で挽回しようとした

基本的にメンバーに全タスクを割り振り、PLはそれぞれのメンバーの状況を管理・レビューする。溢れた分のタスクをPLが受け持つようにするのが良いと考えます。

しかし大体はそこまで余裕が無いパターンもあると思いますので、PLが少しのタスクを持つのはアリだと思いますが、PLがメンバーと均等にタスクを積み、その計画で進めるのは危険と考えます。

誰かの開発状況に遅れが生じている、という状況になった時に人員にバッファが無いため、プロジェクト全体として余裕を持てなくなってしまい、いきなり赤信号になってしまうためです。

ガントチャートは有っても良いが、大まかなマイルストーンを表すだけに留めて、タスク１個１個のスケジュールをガントチャートで管理しないようにする

ガントチャートでタスクの実施日時を動かし、遅延分の埋め合わせを図った
結果として偽った報告をしてしまった

親タスクを作成し、PLはそのマイルストーンだけを管理する形です。
親タスクに紐づく子タスクは個々の担当者に管理してもらえれば良いと考えますが、
PLは、マイルストーン内の機能開発の実現可否は、動くソースコードを見て判断する必要があると考えます。
遅延分が発生すれば人員バッファであるPLが他タスクを担当します。
PLがタスクを担当しても、スケジュールに遅れが生じる場合は、赤信号でレスキューを挙げます。
納期調整・人員調整・稼働調整などの調整が必要な段階と考えます。
決してガントチャートのタスクを動かして、遅延分の埋め合わせを図るのはやらない方が良いと考えます。

テストファーストで開発を進める

テストアップ前に品質の担保ができなかった
プロジェクトが終盤になるに連れて、テスト工数がバカにならなくなってきた

失敗の内容で述べた通り、後でリグレッションテストにかかる工数を考えると、
開発時にテストコードを書くことに工数をかけた方が、品質・全体工数としてメリットがあると感じました。
自動テストでどこまで担保するかはプロジェクトによって異なるかもしれませんが、
以下を基本のスタイルとしてやっていきたい所存です。

backend・frontendの単体テスト・結合テストに関しては必要パターンを網羅したテストを書く
E2Eテストに関しては、画面操作が必要な部分に関しては必要パターンを網羅したテストを書く
画面レイアウト形のテストは仕様変更が多く、壊れやすいテストとなるため、表示されているかどうか、という最低限の担保ができる形でテストを書く
何らかの原因で自動テストが行えない部分は、手動テストを実施する

リグレッションテストを早急に行えるようにする事で必ず幸せになると信じます。

開発初期の段階から、そのタスクの開発ができるであろう人に振るのではなく、まだやったことがない人にタスクを振り、できるようにする

開発メンバーそれぞれの得意・不得意が違ったため、得意な人に得意なタスクを振ってしまっていたため、作業負荷が偏ってしまった

最初は進捗が出せずに辛いと思います。
それを見積もったマイルストーンでの工数管理は必要ですし、遅れが生じた場合のPLのカバーが必要ですが、プロジェクトをうまく進めるためには、ここは頑張りどころだと考えます。

まとめ

PLなど全く経験したことが無かった事もあり、振り返ると失敗ばかりだったなと思うのですが、せっかく失敗したので、次に活かせるようまとめてみました。

書籍とかwebとかで色々議論があると思いますが、実際の案件内容とか会社の体制・考え方とかチームのメンバーのスキルとか、取り巻く状況が異なるので、今の環境で経験した事について振り返るというのは大いに意味があると感じます。

考えてみると、プロジェクトの最初が一番辛いなー辛くあるべきだなーというのがよくわかります。この上、要件定義も載っかってくるんですからね。。
自分自身とチームを守るため、これからも頑張っていきます〜!