こんにちは！ブロックチェーンチームでエンジニアをしている 
id:dorapon2000 です。寒暖ある中でインフルも流行っているようで、私も咳がなかなか収まらず困っています。皆様におかれましても体調にはお気をつけください。
今回はタイトルの通り「緊急度が低く重要度が高く、そして重いプロジェクト」を私が担当した際に感じたことや学んだことをまとめた記事になります。前半で私の担当したプロジェクトの経過について感じたことをお話して、後半で学びをまとめます。
第二領域
「緊急度が低いが重要度が高いタスク」では記述にあたり少し長いので、ここでは第二領域1のタスクと呼ぶことにします。今すぐではないがいつかは必ずやらねばならないタスク。例えば OS やライブラリのアップデート、開発負債の解消などが第二領域のタスクとして考えられます。緊急度が低いこともあって後回しにされがちという傾向があり、みなさんも心当たりが大いにありますよね。
では、どうやって第二領域のタスクに着手するのか。第二領域のタスクは必ず実施しないとプロダクトに致命的な影響を与えます。重要度が高いとはそういうことです。そのため、後回しになりすぎないように、全体のスケジュールに合わせて事前に期日を決めるという対策は定番です。
重い第二領域の問題
軽い第二領域のタスクは着手が一番の問題で、着手したあとは完了を待つのみです。一方で、重い第二領域のタスク(プロジェクト)は着手してからも問題がおきます。自分が考える問題をここにあげておきましょう。
- 単純に重いタスクであるため、重いタスクにまつわる問題を引き継ぐ
- 学習時間、調査、検証、動作確認、反映をする時間を見積もりに含め忘れる
- 単純に見積もりが難しい
- もうお手上げだと思われる状況に何度もあたるとメンタルがすり減る
- 長期に渡るプロジェクトだと、モチベーションを保ち続けられないことがある
- 属人化
- 長期に渡る第二領域のプロジェクトは、差し込まれる緊急度の高いタスクに優先度を何度も譲らなくてはいけない
- スケジュールが立てづらい
- 再着手するときに過去のことを忘れている
これらを踏まえて私の担当したプロジェクトについてお聞きください。
私の場合
私が前のチームにいたときの話です。プロダクトで運用しているサーバの OS のアップデートをするというプロジェクト担当になりました。というよりも、自分がやってみたいと手をあげました。これがまさに重い第二領域のプロジェクトになります。主な担当は自分で、サブで当時の上司にサポートをしていただきました。自分は難しくてもチャレンジさせてもらえるならチャレンジしたい性格なので、大変だとはわかりつつ、楽しみにもしていました。
初期
ほかチームでも OS のアップデートプロジェクトはすでに進行しており、知見を共有してもらいながらの進行でした。まず自分のチームではどのような作業が必要か洗い出し、誰と協力しなくてはいけないのか、どれくらい工数がかかりそうか、計画を立てました。この計画は今振り返るとまったく未熟で、全体の作業の 2 割程度しか網羅できていなかった気がします。計画を考えるために必要な AWS の知識が足りていなかったため、サーバを安全にアップデートするための具体的な手順と OS アップデートに伴う広い影響範囲をイメージできていませんでした。
不十分な計画ながらも、とりあえず最初にすべき検証や準備を少しずつ進めていました。 しかし、途中でサポート担当の上司がチーム異動をすることになりました。もちろん他チームのヘルプは借りつつも、これ以降はチーム内で自分だけがプロジェクト担当になります。1 人での対応に不安はありつつ、ヘルプを出すのは得意な方なので、とにかく自分がやり切るしかないという気持ちでした。
中期
自分以外のチームメンバーもそれぞれ異なるプロジェクトを持っており、それらは OS のアップデートよりも優先度が高かったです。そのため、ユーザーさんからのお問い合わせ調査やバグの修正など突発的なタスクは、第二領域のプロジェクトを進行していた自分がよく持っていました。また、ほかプロジェクトが遅延していたときに、自分がよくヘルプに向かいました。その度に自分のタスクは中断しています。数ヶ月中断せざるを得なかったことも数回ありました。
中断した数だけ自分のプロジェクトの完了は遅れるので、バッファありのガントチャートを組んでプロジェクトによりコミットできるよう工夫しました。しかし、これは結果的に自分のメンタルを責める原因になってしまいました。ただでさえ自分にとって未知の領域で見積もり通りにいかない、差し込みが多数発生する、その度にガントチャートを引き直す必要がありました。タスク単体の見積もりの曖昧さはバッファが吸収しますが、いつくるかわからない差し込みタスクをバッファは吸収しきれません。引き直すたびに完了予定が後ろ倒しになり、申し訳ない気持ちになりました。
ガントチャートは長期な第二領域のプロジェクトと相性がよくないのだと学びました。
それ以外に、このあたりから OS アップデートで更新したインフラ周りの知識が自分に属人化していることに気づき始めました。ですが、今からほかメンバーに参加してもらうにも逆に工数が膨らみそうであったため、作業ログを大量に残しつつ自分ひとりで進行を続けました。大量の作業ログは中断後の再開で記憶を取り戻すのにとても役に立ちました。
このあたりから気持ちは淀んできます。
後期
前述の件があったため、ガントチャートでの計画はやめて、各タスクに掛かった日数や工数の管理だけはちゃんと記録するようにしました。のちに振り返りの材料になります。
自分で調べたり周りに聞いたりしてもなかなか解決できない問題に何度も遭遇して、技術力不足なのかメンタルが淀んでいるのかわからなかったりしました。もしプロジェクトにほかメンバーがいれば、実は進め方に問題がある、あるいは今からでもプロジェクトメンバーを 1 人追加したほうがいい、などというような指摘を貰えるかもしれません。しかし、担当が自分だけであるので、それを自問自答しなくてはいけないことも辛かったです。このような場合、基本に立ち返ってほうれんそうが大事だと思いました。
初めてのカナリアリリースもうまくいき、いざ本番リリースと臨んだところでリリース手順中のスクリプトがうまく動かず延期ということもありましたが、最後は無事 OS アップデートすることができました。
憑き物が取れたような気持ちでした。プロジェクト開始から 1 年 8 ヶ月経っていました。
重い第二領域プロジェクトを通しての学び
プロジェクトでは自分自身の経験不足なところが多くありました。その中で学んだことをあげます。
- ビッグバンリリースを避ける
- ビッグバンリリースは避けるべきとわかっていても、細かいリリースに分けるだけの知識と経験がなかった
- そのために周りをもっと頼ることができたかもしれない
- 重い第二領域プロジェクトはガントチャートと相性が悪い
- 他のプロジェクトと兼任せず差し込み対応をしなくてよいならガントチャートは強力なツール
- ガントチャートを組まないにしても、各タスクに掛かった時間は記録して振り返りの材料にする
- 重い第二領域プロジェクトは 1 人で進行しない
- 一緒にコミットして助け合う仲間が必要
- 属人化させない
- 振り返りは短いスパンと長いスパンの両方でする
- ガントチャート周りは短いスパンの振り返りで気づいた
- 再計画とは別に再見積もりもする
- 手を動かしながら解像度が上がることで、より見積もり精度を高めることができる
- 初期の見積もりの精度を高めるより、その後に再見積もりが必要だと気づくことのほうが大切
特にガントチャートとの相性がよくなかったことは自分にとって印象的な発見でした。もちろん、常に相性が悪いわけではなく、今回は差し込みが多分に起きる状況だったため相性がよくなかったと思います。差し込みが多いというチームの状況がよくなかったという見方もできるかもしれません。よりよいプロジェクト管理のために、日々考え抜かなくてはいけません。
まとめ
記事を読んでいただきありがとうございます。緊急度が低いが重要度が高いそして重いタスクには特有の問題があることを学びました。1 年 8 ヶ月という期間はあまりに長く（もちろん途中で他のプロジェクトにスイッチすることもありつつ）、今の自分ならもっとスマートに完了できるのだろうかと空想するところです。
私の学びが他の方の学びになればと思います。
- 『7 つの習慣』という本で分類される呼び方を拝借しています。↩
