この記事は Akerun Advent Calendar 2024 - Qiita の25日目の記事です。

こんにちは。Esperna - Qiita です。ファームウェアの開発をしています。今年の私は一開発者であると同時に一PjMとしてプロジェクトを回す立場でした。自身の業務を振り返りつつ、心がけたことと改善したいことを書きたいと思います。

心がけたこと

(1)プロジェクトの開始時に、開発の内容だけでなくリリースのスコープ及びその後の段取りに関してステークホルダーと合意した

リリースのスコープ及びその後の段取りに関して複数案を用意し、顧客、物流、製造の観点でメリット・デメリットを整理しました。そのうえで、個別に複数のステークホルダーに対して自分が推す案が各部署にとってデメリットになりませんよという旨を説明し、リリースのスコープ及びその後の段取りを決めました。これは一から十まで自分で全部やったのではなく、自身の知識やスキルの足りないところに関しては都度同僚や上司、他部署のステークホルダーに助けてもらって進めることができました。いわゆる根回しなのですが、プロジェクトを円滑に進めるうえで事前に話を通しておくことで、開発後半や開発終了後にちゃぶ台返しが起こることなく、開発に集中することができました。なお、根回しについては自由に働くための仕事のルールという書籍を読む機会があり、そちらを参考に業務に取り入れました。

(2)開発内容、リリーススコープのMust/Wantをコントロールした

開発をしていると、追加の要求がない場合でも改善事項が見えてきたり、割り込みがあるなどして、スケジュールが遅延することがありますよね。遅延が発生した時は早めにアラートを上げつつ、下記の対応をすることでスケジュールを維持しました。

開発内容に対して、梅をMust、それ以外をWantとする松竹梅を設けてMustから対応していき、スケジュールに収まらない場合Wantを別スコープとした
リリースのスコープを一部小さくした

開発内容、リリーススコープのMust/Wantをコントロールする方法はデスマーチに記載されている、「トリアージ」という考え方に着想を得ています。書籍では「トリアージ」というのは乏しい必需品（私の場合時間）から最大の効果を引き出すやり方と書いており、デスマーチでは開発システムの要求項目を下記３つに分類していますが、図らずも梅竹松となってました。

やらねばならぬ。must-do
やった方が良い。should-do
やれればやる。could-do

また、実際の業務においてはリリースするかどうかに焦点を当てがちで、上記の３分類ではなくMust/Wantで判断してしまっていました。次のプロジェクトでは３分類をもっと意識してみようと思います。

(3)QAリリースのマイルストンを守るのに中盤でスパートをかけた

なんとなくプロジェクトの最後にラストスパートをかけるプロジェクトが多い気がするのですが、今回はプロジェクトが遅れていた中盤くらいに前述の開発内容、リリーススコープのトリアージを行いつつスパートをかけました。理由は開発後半で不具合が何か出るかもしれないので早めにQAリリースをして不具合が出た時の対策時間を十分に取っておきたかったからです。なぜ、あなたの仕事は終わらないのかという書籍にラストスパート志向の一番の欠点は最後の最後までその問題の難易度が分からないことだと書いてあり、なるべく早い段階でリスクを潰しておこうと考えました。また、大前提としてこのプロジェクトを遅らせず世にリリースすることは顧客にとって価値があると思っていたことと、ここで開発が遅れると、チーム全体が開発が遅れてるのだし仕方ないみたいな空気になりかねないと思ったこともスパートをかけた理由でした。

(4)発生頻度、修正コスト、デグレリスク、顧客への影響範囲を考慮して、不具合対応を取捨選択した

不具合が発生した時に発生頻度、修正コスト、デグレリスク、顧客への影響範囲を考慮し、対応を決めること自体は当たり前のことです。が、私自身すごく悩んだことなので書くことにしました。 QA評価フェーズでは不具合がいくつか出ました。影響範囲・発生メカニズムは把握し、修正案まで思い至ったので、一開発者としては修正したい思いがありました。一方、一PjMとしては修正には追加工数とデグレリスクがあり、修正しないことによるリスクもあり、修正すべきか相当悩みました。これらの内容については事前にステークホルダーに共有し、最終的に発生頻度、修正コスト、デグレリスク、顧客への影響範囲を考慮して取捨選択を行いました。

改善したいこと

開発内容やリリーススコープにMust/Want、松竹梅を設けるなどコントロールできるバッファを設けたつもりでしたが、それでも、実際のところはいっぱいいっぱいでした。病院のベッドに空きがあった方が効率がよくなる話は耳タコすぎてしたくもないのですが、いっぱいいっぱいにならなければ、他のこと・新しいこともできて、結果として生産性や効率を上げていくことにつながると思います。なぜ、あなたの仕事は終わらないのかには「10日の仕事に対して最初の2日で仕事の8割を終わらせて締め切りが近づいたら流せ」という旨が書かれています。これは余裕がある時に健康だけには気をつけながら全力疾走で仕事と向き合い、残りの8割で「仕事の完成度」を高めるというものです。今の私にはできていないことです。実際10日の仕事を2日で終わらせるには無理があるかもしれませんが、余裕のあるうちに集中して取り組み、間に合わなさそうなら早めにアラートを上げて調整をし、間に合いそうなら後半は完成度を高めようと思います。決して前倒しで仕事を終わらせてはいけないと思っています。前倒しで、終わらせて次の仕事に取り掛かってしまうと、改善する時間が取れず技術的負債が増えるからです。