- Published on
ソフトウェアエンジニアとしてプロジェクトをデザインする
はじめに
チームリーダーというロールで仕事をするようになってから、プロジェクトマネジメントについて考える時間が増えました。
チームとして事業を前に進めるためには、エンジニアだけではなくそれ以外のステークホルダーも含めて課題を解決するためにプロジェクトを推進する必要があります。
とはいえ自分は専任のプロジェクトマネージャーではなく、あくまでソフトウェアエンジニアです。
この記事では、手を動かすエンジニアでありながらプロジェクトを前に進める役割も担うために、自分がどんなことを考えて何をしているのかを書いてみます。
リーダーの仕事は物事を前に進めること
エンジニアチームのリーダーの仕事は色々ありますが、突き詰めると「物事を前に進めること」だと思っています。
技術的な意思決定もメンバーのサポートも、最終的にはチームとして成果を出し、物事を前に進めるためにやっていることです。
そして物事を前に進めようとすると、プロジェクトマネジメントのような仕事が必ず必要になってきます。
- 今プロジェクトがどういう状況なのかを把握する
- 関係者に状況を共有し、認識を揃える
- 必要な情報や意思決定の記録を残す
- 課題やリスクを見つけて手を打つ
一方で、物事を前に進めるには自分自身が先頭に立って手を動かすことも必要です。
難しい設計判断や、誰も手をつけていない曖昧なタスクに真っ先に飛び込むのもリーダーの大事な役割だと思っています。
しかし、手を動かしながらプロジェクトの全体を把握して、必要な部分にアクションして...という動きは想像以上に難しいものです。
だからこそ、プロジェクトマネジメント的な仕事はできるだけ仕組みで解決したいと考えています。
プロジェクトデザインという考え方
自分はプロジェクトを仕組みで前に進むように整えることを勝手に「プロジェクトデザイン」と呼んでいます。
この考え方の土台になっているのが『Design it!』です。
以前読書感想を書いたこともありますが、いつ読み返しても新しい学びがある最高の本だと思っています。
Design it!ではステークホルダーを「プロジェクトに関わるあらゆる人々」として扱い、ステークホルダーと共にアーキテクチャをデザインしていく方法が説明されています。
これをもう一歩広げて、事業も人もシステムもすべてステークホルダーだと捉えると、プロジェクトの進め方そのものもデザインの対象になります。
具体的な例を紹介します。
プロジェクトの状況を正確に把握する
情報は更新されない
プロジェクトの状況を正確に把握するのは、思っている以上に難しいです。
例えば、もしやっていることやその進捗の共有をメンバーに任せた場合、思った通りに情報が更新されないといったことがあると思います。
みんな忙しいので、プロジェクト管理のためだけの作業はどうしても後回しになります。
例えば、エンジニアは普段GitHubのIssueやPull Requestで仕事をしているのに、プロジェクトの進捗は別のツールやスプレッドシートで管理されている、という状況はよくあると思います。
これではそもそもの情報を集める部分に時間を使うことになってしまいます。
普段の営みがそのまま状況を表すようにする
このような状況は、例えばプロジェクト管理の仕組みをGitHub Projectsに載せると解決するかもしれません。
エンジニアが普段から使っているIssueやPull Requestをベースにプロジェクトの全体像が見えるように設計しておけば、そこを見れば大体のことがわかるようになります。
例えば、具体的な運用はGitHub Projectsをチームタスク管理に利用して3Q経ったのでプラクティスをまとめるに書いたりしています。
チームに合うようにステータスを作成し、Issueに仕事を切り出し完了したらCloseするという普段の営みがワークフローで整備されるようにしておけば、エンジニアの負担は格段に減ります。
ビジネス側の人にとってはどうか
しかし、エンジニアにとって便利な仕組みが、ビジネス側の人にとって使いやすいとは限りません。
例えば、ガントチャートをスプレッドシートで管理する運用を好む人もいます。
エンジニアの都合だけで「今日からGitHub Projectsで見てください」と押し付けても、きっと使ってもらえません。
だからこそ、ビジネス上のメリットも含めてステークホルダーに説明し、納得してもらった上で仕組みを作るのがリーダーの仕事だと考えています。
- 情報が常に最新なので、状況確認のための問い合わせや会議が減る
- 進捗の遅れやリスクに早く気づける
そして「なんか良さそう」と思ってもらえたら、一緒に使ってみて運用に乗るまで助けるところまでやるのが良いと思っています。
ビッグバンにならないように、まずは一緒に見ながら口頭で共有する会を設けるなども良いと思います。
そして最近は、プロジェクトの「怪しい匂い」をどう検知するか？を考えています。
AI時代の難しい部分で、今まで「タスクの遅れ」などといった明確な部分に表れていたものが「認知負荷」や「理解不足」といったパッと見でわかりづらい部分に現れるようになっている気がしています。
このような「なんとなくうまくいってなさそうだな？」を検知することも仕組みで解決できるようにする必要があると感じています。
情報の置き場所を作る
資料についても考え方は同じです。
プロジェクトに関する情報がSlackのスレッドや個人のメモ、あちこちのドキュメントに散らばっていると、最新の情報を探すだけで時間が溶けていきます。
まとまっている場所がなければ場所を作り、「ここを見れば最新情報がわかる」という状態にします。
よく言われるDesign Docもその一つですが、自分はDesign Docをもう少し広く捉えているイメージです。
なぜその設計にしたのか、どんな選択肢を検討したのかを一箇所に残しておくことで、後から参加した人も同じ前提に立って議論できます。
また、リーダーの仕事として「叩き台を作る」ことはかなり大事だと思っています。
Design Docは叩き台としてとても優秀で、議論を前に進める推進力になります。
意図のない定例ミーティングはしない
定例ミーティングは、状況共有や認識合わせのための便利な仕組みです。
一方で、一度始めると目的が曖昧なまま惰性で続いてしまいがちな仕組みでもあります。
自分は、意図のない定例ミーティングは実施しないようにしています。
定例を始めるときは何のためにやるのかを明確にし、それが状況把握の仕組みや情報の置き場所で代替できるなら、そもそもやりません。
また、なあなあになってきていると感じたら、改めて意図を何度でも伝えます。
それでも意図が果たされていない、あるいは別の手段で代替できるようになったのであれば、その定例は無くします。
定期的に見直す仕組みもセットにデザインしておくととても良いです。
自分の仕事をスケールさせる
ここまで書いてきたような仕組みづくりは、最初は自分が先頭に立ってやることが多いです。
ただ、それをずっと自分だけでやっていては、チームとしてスケールしません。
自分がボトルネックになってしまえば、結局物事は前に進まなくなります。
そこで、自分が先頭に立ってやっていた仕事を他の人にもやってもらえるようにすることを意識しています。
進め方としては次の3段階です。
- やっているところを見てもらう：まずは自分がやっているところを見てもらい、何をなぜやっているのかを伝える
- 伴走する：次は相手にやってもらい、自分は横でサポートする
- 任せる：最後は完全に任せる
普段からどうしてこの運用をしたいと考えているかなどの意図を積極的に伝えたり、いつでも参照できるようにまとめておくことを心がけています。
1on1などより密なFBのタイミングが必要（求められている）であれば定期的に実施するのも良いと思います。
まだまだこの辺りはチャレンジの途中という感じですが、自分がより新しい領域で先頭に立って手を動かせるように取り組む価値のあることだと思っています。
仕組みで解決することと、人に任せられるようにすることは、どちらも自分の手を空けて物事を前に進めるための手段です。
おわりに
エンジニアチームのリーダーとして物事を前に進めるために、プロジェクトマネジメント的な仕事をできるだけ仕組みで解決する、という考え方について書きました。
- リーダーの仕事は物事を前に進めること
- 手を動かす時間を確保するために、プロジェクトマネジメント的な仕事は仕組みで解決する
- 事業も人もシステムもステークホルダーとして捉え、プロジェクトの進め方そのものをデザインする
- 仕組みは押し付けず、メリットを説明し、運用に乗るまで伴走する
- 作った仕組みは評価し、意図を失ったものは無くす
- 自分の仕事は人に任せられるようにしてスケールさせる
同じように手を動かしながらプロジェクトを進める立場にいる方の参考になれば嬉しいです。