プロジェクトリーダーってなんだ

2023年12月2日 00:00

ブックサンタという企画で、ジュール・ヴェルヌの『十五少年漂流記』を寄付してきました。年末ですね。

スターフェスティバル Advent Calendar 2023 の2日目の記事です。よろしくお願いします。

スターフェスティバルに入社して4年が経とうとしています。昨年まではソフトウェアエンジニアとして開発に従事しておりましたが、今年からはロールが替わって Kitchen Success プロジェクトのプロジェクトリーダーとなりました。経験の枯渇しないことでお馴染みのスタフェスです。大変ありがたいことです。それにしても、プロジェクトリーダーってなんだ。

勢い込んでアドベントカレンダーの枠をいただいたものの、ネタがなにも浮かびません。二年間の休暇でも貰うことができるなら、なにかいい感じのトピックを捻り出せそうなものなんですが。あいにくそんな時間はありません。

だから今回はふりかえり記事のようなものを書きます。私がこの1年で失敗してきたことや学んだことを、時系列順に吐き出していこうと思います。

偽エンジニア期

サッカーにおける戦術上の役割に、偽○○というものがあります。○○の部分には、ポジションを表す言葉が入ります。偽9番、偽サイドバックといったような使い方ですね。偽○○というロールを担う選手は、本来のポジションから離れて局所的に人数を増やすことで数的優位を得る、あるいは意図的なアンバランスを生み出すことによって周囲の味方やボールの流動性を増すような役割を果たします。

2022年秋からの私は、まさしく偽エンジニアと呼べる存在でした。この時期から、私は Kitchen Success というプロジェクトにおいてプロダクトマネジメント（この時期は主にプロジェクトマネジメント）を担当することになりました。肩書はエンジニアのままでしたが、コードを書きつつ、かたわらで要件定義や開発スケジュールの管理をこなします。その比率は 5:5 から 4:6 へと徐々に移行してゆき、気づけばすっかり偽エンジニアとして振る舞うことになりました。

Kitchen Success というプロジェクトは、スタフェスのプラットフォームにおける製造パートナーのビジネス上の成功を追求しています。おもに製造パートナー向けの管理画面 Kitchen Manager を開発しています。当時の Kitchen Success チームは、大きな機能開発を進めているところでした。そのリリースまであと2ヶ月ほど。まずはこのドデカいリリースを成し遂げることが最初のミッションでした。

粒度

一つ心に誓ったことは、こんな開発は二度とごめんだということです。"こんな開発" というのは、"こんなドデカい粒度の開発" という意味です。これは私の偽エンジニア期における大きな学びの一つです。

開発の粒度を小さくしようなんていうことは、いろんな人が言ってます。みんな知ってるし、当たり前のことですよね。しかし防げなかったのです。最初は適切な粒度に切って開発できている、とそう思っていました。しかし開発を進めていくうちに、新たに発覚する事実や考慮漏れによって、みるみるうちに工数が膨れ上がっていったのです。

その都度チームで振り返って、なにが原因だったのかを話し合いました。その結果、不確実な要素を多く残したまま要件定義や開発を進めてきたことが原因なのではないかという結論に至りました。すべてのコンテキストをここに記載するわけにはいかないのですが、そのとき取り組んでいた開発というのは、私にとってはかなり難易度の高いものでした。メンバーの誰もが経験したことのないアーキテクチャに挑戦していました。それ以外にも多くの不確実な要素を含んだ開発でした。そういった多くの不確実な要素を、その他の勝手知ったる課題と同じように扱ってはいけないのだということを、痛みとともに学びました。この学びはその先のプロジェクトで大いに役立っています。

Box to Box のジレンマ

偽エンジニアになってから、エンジニア以外のステークホルダーと話す機会がとても多くなりました。もちろんそれまで一切話すことがなかったというわけではありませんが。この時期の私は、細かな意思決定を担当するようになっていました。それに伴って要件定義や内部調整に時間を使うことも増え、次第に人と話す時間が増えていくことになりました。

決めることは私にとって大変な作業でした。最初のうちは一つの小さなことを決めるのにもフルパワーで望んでいましたが、それはとてつもないカロリーを消費します。実際には消費していないと思いますが、消費したような気分になります。腹が減ります。しかしそれだけ力を注いでも、たった一つの小さなことを決めただけです。なんかコスパ悪いんじゃないか。なんかやり方間違えてるよな。そういう認識だけはありました。ただそれをどう是正したらいいものかを考えることすらなく、ただひたすら目の前の開発を進めることに必死でした。

もっと効率よくやる方法はないか、というこの課題は、結局この時期に解決されることはありませんでした。ハードワークだけが正解なのか。ドデカい開発のリリースを終えた達成感がそれを忘れさせてしまったのかもしれません。

偽エンジニア期のインプット

偽エンジニアとなってすぐに、私はこの本を読みました。なにか新しいインプットをしなきゃいけないんじゃないかという強い衝動に駆られていたのでしょう。

この本は細かいノウハウというよりは、マインドセットに焦点を当てているものでした。偽エンジニアが最初に読む本として適していたのかどうかはわかりませんが、ソリューションに飛び付かずに問題と向き合う、という意識が重要なのだということを再確認しました。

脳死ホワイマン期

先述のドデカい開発のリリースを成し遂げ、私は偽エンジニア期から徐々に脳死ホワイマン期に移行していきました。ホワイマンというのは、Dr.ストーンに出てくる黒幕です。まだ読んでない方、ネタバレしてすみません。こいつがラスボスです。けっこう序盤で出てくるんで許してください。こいつが一番悪いやつです。

この時期から、私は正式にプロジェクトリーダーとなりました。同時に私はこのホワイマンのように、脳死でWHYと叫び続けるようになりました。これはソフトウェア開発の文脈でよく用いられる「ドリルと穴の話」や「速い馬の話」に影響を受けた行動です。ユーザーの本質的なニーズに目を向けるため、WHYと唱えることが正義だと思っていました。WHYこそがプロジェクトを正しい方向へ導くのだと。

WHY

新しい機能の要件定義や運用フロー整備をするにあたって、無数の検討すべき課題が目の前にありました。既存の複雑なフローをどう改善するか。ユーザーからの要望にどう向き合うか。社内の運用工数をどう考えるか。考えることが無限にありましたが、そのすべてに私はWHYと唱え続けていました。

無数にある課題のすべてに対し、WHYと唱えて本質的な価値に辿り着く作業は疲れます。時間がいくらあっても足りません。一つの課題に答えを出すだけでも、私には大変な時間がかかります。一つだけ解決すればいいのなら、それでいいのかもしれません。WHYと連呼して、時間をかけて価値を見つけて、解決方法を決めて、やれやれ本質的価値に目を向けてやったぞと満足して終わりです。気持ちいいもんです。一つならそれでいいんでしょう。しかしその数が増えれば増えるほど、それは私の心も体も圧迫していきます。検討材料を集めるためのMTGも増えていきます。やがて業務時間はびっしりとMTGで埋め尽くされてしまいます。エネルギーも尽き果てます。もうドリル付きの速い馬でも作っちゃえよ、と思うこともしばしばありました。作ってませんが。

実際には「それは本当に検討すべき課題かどうか」ということを検討するべきでした。私が時間とエネルギーを費やして検討したもののなかには、検討する価値がそこまで高くないものもあったかもしれません。私はその検討を怠っていました。必要なのは、そこだったのです。そういうことが『イシューからはじめよ』みたな本に書いてありそうです。私は読んでいないのですが、世間の書評を読むかぎりだと書いてありそうな気がします。

それに、WHYと唱えることが重要なのは理解しているのですが、WHYからスタートして本質的な価値に辿り着くのはなんだか疲れます。シーソーでいうと、支点の真横に力点を置いているような感覚です。より効率のいい力点がありそうな気がします。優秀なひとは、もっと瞬時に本質的な価値にたどり着いていると思います。どうやってるんでしょうね。

最近の話になりますが、ユーザーインタビューの結果の分析をどういった手法でやろうかなと調べていたときに、KA法というものに出会いしました。この手法で使用するKAカードというものを見ると、とある事実・出来事からスタートして、そこからたったの2ステップで価値にたどり着いています。

目から鱗です。いろんなフレームワークを試してみるのがいいかもしれません。

脳死ホワイマン期のインプット

この時期のインプットは、プロダクトマネジメントに関するものがほとんどです。名著ですね。

エンジニア出身の私には、デザイン領域やビジネス領域の知見が圧倒的に不足しています。そして足場となるエンジニアとしての知見も、周囲の超人たちに比すると赤ん坊のようなものです。これらの書籍を読むと、必要なスキルが膨大にあるんだぞということがわかります。なぜそれが必要なのかもわかります。なにも持っていない自分を発見することができて、落ち込みます。落ち込みたいときにおすすめです。

UIデザインについて、デザイナーと議論する機会も増えました。デザイナーにどういったフィードバックを返したらいいのかさっぱりわからなかったので、こういう本も読みました。この本はのちにチームで輪読会を開催して、みんなで読みました。

逃亡期

複雑な要件の整理や、社内外からの要望のヒアリング。私が検討しなければならないと自分に課していたものから、私は逃げ出そうとしていました。

物腰は優雅に、行動は力強く

まずは考えることと考えないことのラインを引きました。いつだったか、新卒の頃に受けたセミナーで緊急度と重要度のマトリクスを使え、というようなことを誰かが言っていたのを思い出し、それを実践することにしました。あとで聞いた話によると、これはアイゼンハワーマトリクスという名前がついているそうです。

これを使って、向き合う課題の総数を減らしました。つまりこの段階で "考えない" という決断をした課題たちがいます。声をあげてくれた人に対して、大変申し訳ない気持ちになりました。迷惑をかけてしまうんじゃないか、という気持ちが拭い切れません。人に迷惑をかけないように生きていくんだよ、と教えられて育ってきました。まさかこんな決断をしなきゃならないなんて。それでも言うしかありません。ごめん、それは考えないんだと。

それにともなって、会議の数を激減させることに成功しました。もちろん必要な会議は継続していますし、必要な議論はアドホックでMTGを設定することにしています。No 会議 Day を作ることもできるようになりました。その日はもくもくと思考に耽る日にしています。徐々にではありますが、プロダクトロードマップやプロダクトコンセプトを考えることに多くの時間を使えるようになってきました。

逃亡期のインプット

逃亡期には、有効な議論をするためにはプロジェクト内ではっきりとした "ユーザー像" の共有が必要だ、という意識を強く持つようになりました。逃亡期に至るまでの議論の連続のなかで、ユーザー像がバラバラのまま議論を展開することの効率の悪さを痛感したのです。

そして最近

考える時間を確保した私は、ようやく大事なことを考えることができるようになってきました。プロダクトビジョンや戦略を見直したり、ロードマップを書いたり、プロダクト要件を考えたりといったことです。ただし先述したように全方面のスキルが不足しているので、時間があるからといって満足にシャープな構想を展開するなんてことはできません。修行が足りません。ここはこれから。

ユーザー像を追い求めて、最近はユーザーインタビューを実施しています。これはこの記事を書いている段階で、まさに進行中のものです。リサーチ自体が私にとっては初めての活動です。初めてですが、待望の活動でありました。プロジェクトとして常にユーザー目線であるために、リサーチを習慣としていけるようにしたいと思っています。

漂流記

プロジェクトリーダーとしての業務に取り組んでいるこの時間は、一種のながい漂流に似た心地がします。もっと上手くやれたんだろうなという思いがもちろんあります。しかし、少しずつ目を向けるべきところに向けられているような気がしています。できるものなら劇的に成長していきたいところですが。

それにしても、いまだにすべてを理解できていないことを恥じるばかりです。模索はつづきます。プロジェクトリーダーってなんだ。

この記事が気に入ったらサポートをしてみませんか？