プロジェクトの成功率を上げるために、チームリーダーができること・やるべきこと

プロジェクトをリードする技術

吉田慶章氏（以下、吉田）：こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思います。

kakakakakkuと言いまして、Twitterではよくブログ芸人みたいな感じでやっています（笑）。一応サイバーエージェントの子会社で働いていまして、副業はテックアカデミーでRuby on Railsの講師をやっています。

ただ、仕事より自分のブログのほうが大事なので、基本的にはブログをずっと書いていて、毎週毎週ブログで眠れない日々を過ごしています。

最近、「ブロガーを世の中に増やしたい」ということで、無料でブログを続けるコツを教える取り組みをやっています。ブログメンターと呼んでいます。

さて、『プロジェクトをリードする技術』という社内勉強会の資料を、2ヶ月前に公開しました。

これ、見たことあるって方はいらっしゃいますか？

（会場挙手）

なるほど。6割くらいですね。ありがとうございます。

これは約1時間20分くらいでお話できる内容なんですが、今日20分です。かつ、これを見たことある人がいると、内容がかぶってしまうとつまらないので、ほぼ新しくして、この資料の補足版のような感じで見てもらえればいいかなと思っています。

この資料を2ヶ月前に公開してから、いろんな会社からオファーが来たり、「技術顧問に来ませんか」という問い合わせがすごく来ました。その中でおもしろかった質問が「プロジェクトリードに再現性はあるんですか？」というものです。

これはどういう意味かと言うと、「僕がその困難なプロジェクトに入れば、必ずうまくいくんですか？」という、けっこう強い質問です。

これ、けっこういろんな会社から聞かれまして、だいたい僕は「100パーセントうまくいく保証はないです」と。「でも、たぶん成功確率は高まりますよ」という回答をしています。

確かにチームの成熟度やメンバーの状況、経営陣の状況など、いろんな状況があるので100パーセントとは言えませんが、「だいたいうまくいきますよ」と回答しています。

プロジェクトの定義

では、僕がずっと「プロジェクト」と言っていることの定義をしておこうと思います。「新機能を作りましょう」とか「既存機能を改善しましょう」とか、あとは「インフラを一新しましょう」とか。みなさんだいたい、なにかプロジェクトに属していますよね。それを「プロジェクト」と言ってます。

一応言語化するのであれば、「ゴール意識を持った1名以上のチーム」という感じです。1名でもプロジェクトですよ、ということは今日持ち帰ってください。

それで、期間はだいたい3ヶ月が限界だと思っています。長くても4ヶ月くらいですね。もしみなさんが6ヶ月や1年のプロジェクトを担当していたら、たぶんそれは100パーセント失敗します。それはだいたいブレイクダウンの仕方が間違っていて、長くても3ヶ月くらいでなにかをリリースするほうが良いと思います。今日はそこが主眼ではないので、お話しませんが。

僕がここ1～2年ほどなにをやっているかと言うと、どんなプロジェクトでもだいたいプロジェクトリーダーを任されて、かつスクラムマスター、もしくはスクラムだけではないので、開発プロセスマスターというか。開発プロセスをガンガン回すというポジションをやっています。

一応、認定スクラムマスターも持っています。あとはテックリードも担当します。

あの資料を公開してから、ディレクターとかプロデューサーっぽいイメージを持たれたんですが、僕のメインはインフラです。インフラエンジニアで、AWSとかクラウドを使ったオートメーションが得意なので、ここは基本的に1人でやります。

ですが、この上3つも兼任するので、ぱっと見、兼任しすぎでしょって感じなんですがあとでお話します。うまくデリゲーションして、メンバーにぶっこんでいくやり方が重要です。

唯一僕がやらないことがあります。先ほどの田中さんの話と逆なんですが、僕はビジョンや仕様にはあまり関心がありません。いわゆるスクラムで言うPO、プロダクトオーナーみたいなことはほとんどやりません。そういう人がいる中で、それがどんなに無茶な要望であれ、それを現実にモノにする、テクニカルと開発プロセスで担保する、ということをやっています。

プロジェクトにあわせて型を変える

先ほど、スクラムが好きです、と言いましたが、基本的にスクラムの型にはまってプロジェクトを回すことはほとんどやりません。だいたいこういう関連する技術を学んできたので、そのチームの状況によって、「このチームはこれとこれとこれを取ろうかな」という感じで、毎回ピックアップしています。

そのときになにを選ぶかと言うと、チームビルディングのスキルやファシリテーション、ファシリタティブ・リーダーシップ。あとは最近はやっている、マネジメント3.0。それで、アジャイルと言ってもスクラムとかカンバンとか、XPとかありますよね。あとはリーン。

例えば3人のチーム、5人、10人、50人、100人、1,000人。いろんな組織があるので、それぞれのかたちでの組織論も、かなり学んできました。

そして育成。後輩だけでなく同僚もガンガン育成していきます。

今日、けっこう同じ話が出ていますが、結局は人間関係ですね。ドロドロの人間関係ではうまくいきません。なにが重要かと言うと、心理学や、メンタリング、メンタルヘルスとか。そのあたりも重要です。

こんなようなことを学んだ上で、「このチームはこれとこれとこれかな」という感じでピックアップをしていきますが、今日お話しする内容は「ほとんどのプロジェクトでうまくいきますよ」という、万能薬みたいなものです。

3つの粒度で計画を作る

今日は大きく2つのお話をしますが、その中でもいくつかプラクティスをポコポコと入れていきます。まずは「タスクの流れに着目しましょう」というテーマで、いくつかお話をさせてもらいます。

僕はプロジェクトを立ち上げるときに、まずはだいたい3種類の粒度の計画を作ります。まずは全体計画。3ヶ月とか4ヶ月ですね。次にスプリント計画。だいたいスクラムっぽいものを回すので、2週間ごとに計画を作ります。最後はタスク管理です。

まずは全体計画について。もしかしたら「アジャイルだから全体計画はいらないよね」と思っている方もいらっしゃると思いますが、（全体計画は）けっこう重要です。なぜかと言うと、経営層やステークホルダーにバチッと決まるからですね。

例えば3ヶ月で5人のメンバーをアサインした場合、5人で3ヶ月間、うまくやって行かなければなりません。経営側からするとけっこう大きいリソースなので、「うまくいってるよね」「うまく成功させます」というアプローチをするためには、全体計画見せればそれでいけるので、すごく重要です。

じゃあ、全体計画はメンバーにとっていらないのかと言うと、そうではありません。「あっ、この人と3ヶ月一緒にやるんだな」という思いをメンバーに持ってもらう必要があるわけです。なのでメンバーに対しても、全体計画は必要です。

次に、スプリント計画。これはアジャイルの話なので、もしかしたら「エンジニア向けで必要なんじゃないの」と思っているかも知れませんが、逆にスプリント計画は経営層に必要です。

さっきも言ったように3ヶ月で5人のリソースをもらっているとき、なんとなくうまくいってなさそうなチームだと、「ほかのチームが忙しいので1人ちょうだい」と言われるわけですね。ガンガン引き抜かれて、どんどん苦しくなってくるわけです。

なので、2週間ごとにうまくいってるかたちでリリースして、「うまくいってるんだな、人数ちょうどいいんだな」ということを見せることによって担保する。そういうかたちなので、スプリント計画も対経営層においてすごく重要です。

次に、タスク管理。ZenHubというのはあとで紹介しますが、これで管理しています。

リーダーは常に頭の中でガントチャートを描け

続いて、クリティカルパスの話をしたいと思います。クリティカルパスという言葉は、みなさんご存知ですよね。情報処理（技術者検定）でも出てきたと思いますが、要するにガントチャートがあって、ある棒線が1日でも遅れたらそのプロジェクト全体が遅れるというものですね。

リーダーはこれを常に頭の中で描けているべきです。かつそれにはすごくたくさん粒度があります。全体計画レベル、スプリントレベル、プルリクエストレベル。いろんなレイヤーで、すべてを常に3Dで頭に描けている必要があります。僕は寝る前でも明日の朝でも、常に自分のプロジェクトのガントチャートが描けています。それがすごく重要で、これはなんとも言えない、引き継げないんですが、そういうことをやったほうが良いと思います。

よく、プロデューサーやディレクターが計画を引くチームがあるかもしれませんが、基本的にそれはアンチパターンだと思っています。僕はインフラメインからフロントまでがんばって見るようにしていて、技術的な勘所があるからこそ「あっ、これはたぶんハマるな」とか「逆にこれはうまくいくよね」ということがわかります。技術的な勘所を応用したスケジューリング、クリティカルパスの意識ができるので、やはりエンジニアリングのベースの人がいいかなと思ってます。

ZenHubを使ったタスク管理

今日はあまり詳細は話せませんが、ZenHubという、GitHubをラップしたカンバンツールを使っています。実は僕、ZenHubの運用の話をするのは初めてですね。なので、あとでこの資料を公開するので見てもらえればと思います。

例えば、まずはEpicを作って、Epicに紐づくタスクを作って、それぞれがマイルストーン（スプリント）に属していて。そして、Backlogs、未来にやることについては必ずメンバーはアサインしません、とか。あとはDoing。今やっているものは6個とか4個とか数を制限して、それ以上はやらせません。

Doingに1回入ったら、どういう状況でも右に行きます。左に行くことはあり得ません。しばきます。

（会場笑）

なのでDoingにいったら、必ず右に進むことしかあり得ません。

あとは、Backlogs、Doing、Reviewing、Closed。たぶん要素はこの4つで十分です。よくDoneってありますが、マジでいらないです。この話は次でします。

これは前回の資料にもあって、けっこう「へぇー」って言われたことです。よく、スクラムでやるデイリースクラムって、「おはようございます」のあとに「昨日なにをやった」「今日なにをやる」「困っていること」という3点セットがあります。これ、いらないんです。

僕のデイリースクラムはだいたい、「おはようございます」のあとに「今日のCloseを教えてください」から始まります。要するに、Reviewingには昨日リリースしたものがあるわけです。それをClosedに、右に流していく。そこから始まります。

全員の前でガンガンガンとCloseすることによって、「それ終わったんだな」とか、「それ、実は終わってないよね」という注目ができたりとか。あとは、やっぱり「右に進む」ということ。小さなことですが、それがすごく価値なんですね。それを繰り返していくのがリリースなので、そこに達成感を感じられるチームにしたり。

あとは、1個のタスクがけっこうハマっちゃって3日くらい停留したときに、それがCloseにいったら、「おつかれさま！」っていう感じですよね。なので、そこから始まるという感じです。

雑談で「オートクライン」を引き出す

さて、ここまでがタスクの話でした。ここからは「雑談」と「スウォーミング」の話をしたいと思います。

「ミーティングとかいらないから雑談しましょう」っていう話なんですけど。みなさんミーティングをしたいと思います。「ミーティングしたいです」ってSlackに書くと、「今13時半だから、じゃあ15時半で」とか。「みなさんの予定空いてないんで、次の日の17時で」とかなるじゃないですか。そんなのいらないです。誰かが「やりたい」って言ったら、今やればいい、っていうかたちです。すごくシンプルですが、けっこうできていないと思います。

なので、プロジェクト始まるときに、僕が「集合！」って言ったらみんなが集合してくれる、という前提を作っておくのがけっこう重要です。

先ほど田中さんも似たことを言っていましたが、Slackでわーっと議論をしたり、GitHubのコメントでばーっと議論しているのを見つけると、「ストップ」ってコメントして、はい全員集合、ってやるわけです。そして、ホワイトボードの前に立たせて、ここでやりましょうと。それでばーっと議論して、ホワイトボードの写真を撮って、Slackに貼っておしまいです。文字でのやり取りとか本当にいらなくて、雑談を基点にしましょう、というのが僕のメインのやり方です。

なぜ雑談を重要視しているのかと言うと、「オートクライン」という言葉を持ち帰っていただきたいです。これは難しい言葉なだけで、みなさん知っていることです。

先輩とかに「〇〇どういう意味でしたっけ？」って聞くと、聞いた瞬間「あっ、アレだ」ってわかっちゃうことってありませんか？　あれって心理学では「オートクライン」って呼ぶんです。

これは自分の質問を口に出して、それが耳に入ることによって客観性が得られて、自分で解決してしまうことです。なのでホワイトボードの前で全員が集まってわーってディスカッションすると、オートクラインが起こるんです。なのでふつうに閃くよね、っていうことを担保しています。

先ほど田中さんが「リモートワークはあまりやらない」とお話されていましたが、基本的に雑談もできない未成熟なチームで、リモートワークはしないほうが良いです。絶対に失敗します。なので僕も、基本的にリモートワークはさせていません。オンサイトで雑談ができるようになってから言ってください、という仕切りをしています。今の流行とはちょっと逆かもしれません。

メンバーをタスクに振り分ける

そして「スウォーミング」です。これもスクラムの言葉です。「助け合い」とか「共同作業」のことです。「群れ合う」って意味ですね。ここが今日1番伝えたいことです。

タスクを分割するリーダーっていると思います。よく「この人たぶん来週空いちゃうから、この人に充てるタスクを考えなきゃな」みたいなことってありませんか？　たぶんあるんですよ。それって、最近流行りの言葉で言うと「リソース効率」というもので、「3人いるから3人の稼働率を100パーセントにするようにタスクを分割しましょう」という考え方です。

でもそうやってやってしまうと、「今はいらないんだけど、この人は得意だからこれを先にやっとこう」みたいな感じで、2週間後で必要なものを先にアサインしたりするわけです。そうじゃなくて、そもそも目の前で作りたいMVPはこれなんだから、それに対して人をアサインしましょう、と。「タスクをメンバーに」与えるんじゃなくて、「メンバーをタスクに」アサインするんです。

よくある「1タスク1人だよね」という前提を、まずはぶっ壊してください。複数人で1個のタスクをやる文化をふつうに作っちゃったほうが早いです。そうするとMVP以外のものはやらなくてもいいよね、っていう体で進められるので、リソース効率ではなくてフロー効率。フローというのは、今やりたいプロジェクトやMVP。それを Ship することにフォーカスするという意味です。

ここはけっこう重要なので、ぜひ覚えて帰ってください。「明日あの人空きそうだからこのタスクをやってもらおう」と思ったら、その人を今佳境になっているタスクにアサインしてください。

「モブプログラミング」でレビュー依頼をなくす

ということで「複数で1個のタスクをやりましょう」という提言としては、モブプログラミングもそのとおりですね。最近導入し始めていますが、1個の機能を全員で作るというやり方です。ペアプログラミングは2人ですが、モブプログラミングはデザイナー、サーバーサイドエンジニア、フロントサイドエンジニア、いろんな人が混ざって、がやがや言いながら作ります。

よくあるレビュー依頼。「開発しました」「レビュー依頼します」「突き返されました」「直しました」「レビュー依頼」「また突き返されました」というこのフローは本当にムダです。なのでその場で全員で、まさにこういうところでコーディングをして、がやがや言って、LGTMでこの場でリリースをすればいいわけです。それがスウォーミングだし、複数人でタスクを進めるということです。最近流行っていますが、うちも毎日はやっていなくて、たまにオンデマンドでやるという感じですね。

モブプログラミングをやるときに僕がちょっと気にしてるのは、「スキルマップ」っについてです。

プロジェクトで扱う技術とメンバーを、タテとヨコに並べて、だいたい僕が、〇×を付けます。〇というのはその技術・レイヤにおいて一番詳しい人です。

なので先ほど「テックリード任されてます」と言いましたが、任されてます、「表向きには」。でも実際には、僕が全部見るよりそれぞれの領域で〇の人が意思決定したほうが、どう考えてもうまくいきます。なので、そこでデリゲーションをします。僕は集約するだけですね。

基本的に、僕よりもレベルの高い人しかいません。なのでお願いして、「じゃあそれでいこう」ってOKするだけ、というかたちです。これがデリゲーション、全員テックリードというやり方です。

もう1個、すごく重要なのが△です。△というのは、「今は1人前ではできないけど、このプロジェクトを卒業したら、次のプロジェクトでは〇になってください」という人です。

どうするかと言うと、△の場合は120パーセントの時間かかってもいいので、〇に教えてもらいながら習熟度を上げたり、モブプログラミングをしたり。いろいろなかたちで△を〇にしていく、ということにフォーカスしますし、僕もそれを許容してアサインしていきます。

なぜかというと、メンバーの成長実感を大切にする。もしプロダクトが大好きだったら、プロダクトの新機能を出して「わーい」ってなると思うんですけど、僕みたいにプロダクトの成長と同様に自己成長も大切にする人間だと、プロダクトをリリースしただけじゃ満足できないんですね。自分が成長していないと、「あれ、何なんだっけ？」となってしまいます。

なので、プロジェクトを成功させるのと同時に新しい技術成長をさせます、という2重のメリットで成功すれば、△が〇になるということですね。かなり満足度が高いかたちで次のプロジェクトに入れるわけです。

ですのでリーダーとして、△を〇にするところに意識を使いつつ、プランニングをする工夫をしています。

リーダーに向いている素質は「心配性」

あと4分くらいなので、まとめます。「re:Work」っていう、「Googleが提唱してる働き方改革」みたいな資料があります。その中に、「Google Manager Behaviors」という、「こういうマネージャーは良いよね」という提唱が10個くらい並んでいます。

例えば「1番、良いコーチでありましょう」とか、「5番、うまくコミュニケーションを展開させましょう」とか、「8番、マネージャーだからこそ高い技術スキルを持っていましょう」とか。これまで僕が実践してきたことは、これを見るとほとんど合致している感じです。プロジェクトリーダーという謎のポジションですが、たぶんこれはマネージャーも兼ねてるのかな、と最近思ったりしています。

これもオファーとか技術顧問の依頼を受けたときにけっこう聞かれたことで、「プロジェクトリーダーを育成したいんです、何が素質なんでしょうか」と言われたときに、「喋りがうまい」とか「声がでかい」とか、そんなのはどうでもよくて。「心配性であるべきです」と言うと、みなさんびっくりされます。

でも心配性な人ほどうまくいきます。リスクヘッジできますし、だからこそ完璧主義だとさらに良いんですが、こういう人のほうがリーダーは案外向いてると思います。

逆に「いっちゃえ！」とか、楽観的な人ほど失敗します。なのでもしみなさん、「リーダーはできないけどこういう人なんだよね」という場合は、ぜひチャンスを掴みにいってください。

ということで、僕の発表は以上です。ぜひこの資料を見てみてください。あとで雑談しましょう。ありがとうございました。

（会場拍手）

※登壇者による補足はこちら