どうせならみんなでプロジェクトマネジメントできるチームへ
ラクスが考える変化に強いチームを作る３つのポイント

入社から10年間で担当してきたプロジェクト

大塚正道氏（以下、大塚）：配配メール開発課の大塚です。よろしくお願いします。「変化の時代に活かす『みんなのプロジェクトマネジメント』」というテーマで発表いたします。私はSIerなどを経験しまして、2011年にラクスへ入社しました。

今年で入社10年目になるのですが、過去に担当してきたプロジェクトを少し紹介いたします。入社して最初に担当したプロジェクトは、弊社ではめずらしいBtoBtoCサービスでした。BtoBtoCというのは、例えば楽天さんのような一般のお客さまと店舗などのビジネスのお客さまの両方にサービスを提供するタイプのサービスです。

次に、これもまた弊社ではめずらしいアメリカ向けのサービスを担当しました。簡単に言うとSNSなどを使ったCRMとマーケティングのサービスでした。

そして2015年に今では弊社の主力サービスになっている楽楽精算も担当しました。メインの開発は当時から東京のチームで行っていましたが、この時はスマホアプリなどの周辺機能を強化するために大阪に開発チームを立ち上げて、領収書の読み取りアプリなどを開発しました。

そして2019年からは現在の配配メール・クルメルというメールマーケティングのサービスの開発を担当しています。

プロジェクトマネジメントはエンジニアのスキルの1つ

さまざまなプロジェクトに関わってきましたが、変化に対応できず失敗してしまうダメプロジェクトというのは、次のような傾向があると感じています。

忙しくて、絶対必要なこと以外に時間が割けなくて、当たり前のように改善が先送りされる。また緊急なバグ対応などの場当たり的な仕事ばかりで、がんばっても成長が実感できない。そしてなんとかプロジェクトを終わらせようとがんばってはいるものの、終わったあとの未来がイメージできない。

そこでプロジェクトマネジメントが大切になるわけです。ではプロジェクトマネジメントとは何か、その言葉の定義をみなさんご存知でしょうか？　プロジェクトマネジメントとは、「プロジェクトを成功裏に完了させることを目指して行われる活動のことである」と言われています。

マネジメントというと、なにか特殊な役割と捉えられがちですが、そのようには説明されていません。プロジェクトマネジメントは行動様式であって、簡単に言うとエンジニアのスキルの1つと言えます。

プロジェクトマネジメントはプロジェクトマネージャーだけのものかというと、そうではありません。サーバーサイドエンジニアでもフロントエンドのスキルをもつ人がたくさんいるように、エンジニアもプロジェクトマネジメントのスキルを身につけることで変化の時代に活かせると思います。

昨年末にスクラムガイドの改訂がありましたが、大きな変更点の1つが、「自己組織化」よりも「自己管理」でした。この改訂も変化の時代を生き抜くためにチームが自己管理に重点を置く、つまりみんながプロジェクトマネジメントスキルをもつことを示唆していると言えないでしょうか。

みんなでプロジェクトマネジメントできるチームは、変化の時代を生き抜くチームであるというのが今日のテーマです。

というわけで、先ほどのダメプロジェクトの兆候を反転させます。ダメプロジェクトに向かわないためにみんなで取り組むプロジェクトマネジメントの3つのポイントについて、私の過去のプロジェクトでの取り組みを踏まえてお話ししたいと思います。

改善を先送りしない

まず1つ目が、「改善を先送りしない」ことです。改善の最初のステップは何でしょうか？　改善の第一歩として「ふりかえり」を導入しているチームが多いのではないでしょうか。私たちのチームも、ふりかえりの教科書とも言える『アジャイルレトロスペクティブズ』を参考にして、毎週ふりかえりを行っています。

しかし、ふりかえりをするためにはもっと最初のステップがあります。それが「計画」です。ふりかえりでよく使われるKPTも、まずは1週間の計画を立ててからふりかえりを行い、PDCAを回していくことが説明されています。PDCAサイクルが習慣化されないすべての原因は計画のダメさにあるとも言われています。

どんなプロジェクトも計画なしには進められません。そのため、私たちもふりかえりを導入する前に、まず1週間単位の計画をしっかり立てることから始めました。従来型のプロジェクトのスケジュールをもとに1週間分のタスクを計画し、チームでレビューをしています。プロジェクトにおいては計画があってこそふりかえりが効果的になるということです。

そして私たちは現在、ふりかえりをみんなのものにしていくことに取り組んでいます。最近ではファシリテーターをチーム内で交代制にし、思考整理のフレームワークとしてマインドマップを使うなどの取り組みを行なっています。

みんなのプロジェクトマネジメントの1つ目のポイントについてまとめます。改善を先送りしないために継続的に振り返ることが大切です。継続的に振り返るためにはまずみんなで計画を立てて、それからみんなで振り返る。この2つを繰り返します。

成長を実感できることに取り組む

次に2つ目のポイント、「成長を実感できることに取り組む」についてお話をします。そもそも成長を実感するということは我々にとって大切なことなのでしょうか？　成長実感というのは過去と現在の差分によって得られます。つまり差分を得るための成長とは、変化への対応そのものと言えます。

そして変化への対応と言えばアジャイル開発です。アジャイルマニフェストに書かれている4つの価値の1つが変化への対応です。つまりアジャイルマニフェストの右側の価値を今よりも高めて、差分を作ることが成長を実感する取り組みと言えます。今よりもアジャイルにすると差分が生まれて成長が実感できます。

私たちも、今よりもアジャイルになるために、みんなでできる取り組みを段階的に進めました。まずはチームの対話を強化して、動くソフトウェアを作ることに注力する取り組み。そしてその後、顧客と協調するための視点の強化に取り組んでいます。

順番に説明します。先ほどご紹介した継続的なふりかえりを導入した次のステップとして、スクラム開発を参考にしてスプリント制度を導入しました。この時点ではスクラム自体の導入ではなくて、反復開発というかたちでスプリントの枠組みを取り入れることに注力しました。

そして次のステップではサブチーム体制に移行しました。経験の浅いメンバーが多いチームの状況を踏まえて、開発リードとオペレーションリードというリード役を配置する取り組みです。リード役を配置する取り組みは『チーム・ジャーニー』で紹介されているチーム状況に応じたフォーメーションを取るという手法を参考にしました。

そして現在はチームでドッグフーディングの実施に取り組んでいます。私たちが扱うメール配信は自分たちが仕事で使う機会が少ないので、当番制で会社の開発者ブログの更新をメール配信するという運用ルールを作りました。

みんなのプロジェクトマネジメントの2つ目のポイントについてまとめます。今よりもアジャイルにすることを考えて、成長を実感できることに取り組むことが大切です。アジャイルマニフェストの右側の価値を高めることを考えて、みんなで段階的に少しずつ取り組んでいきます。

未来のイメージを描く

3つ目のポイント、「未来のイメージを描く」についてお話しします。ところで、未来のイメージというのはプロジェクトの成功に必要でしょうか？　私たちはここまでにご紹介した改善やアジャイルの取り組みを進めてきて、その場その場で一定の成果も得られました。

一方で、改善に終わりはなく、アジャイルもスクラムも、まだ自信をもってできていると言える状態には至っていません。改善やアジャイルはそれ自体が自己目的化する危険があるということに気づきました。アジャイルを取り入れること自体が目的になってしまうというのが、つまり自己目的化です。

本来の目的を見失ったままだと、ヤクの毛刈りになる危険があります。ヤクの毛を刈るように改善やアジャイルに取り組むことだけを続けても、プロジェクトの成果に辿り着かなければ意味がありません。

『みんなでアジャイル』という本には、「アジャイルの旅を成功させる第一歩はそもそもなぜ仕事のやり方を変えたいのかを理解することだ」と書かれています。変化に対応するためには、「なぜ？」に向き合う必要があります。

そこで私たちは、会社の掲げる「中小企業を楽にする」という理念に目を向けました。そして考えたビジョンが、私たち自身が中小企業のエンジニアチームを楽にするような存在になって、そのモデルを作るということです。

このビジョンに向けて改善とアジャイルを進めていくロードマップを作りました。アウトプットの安定化、リリース速度アップ、プロダクトのアウトカム強化、チームのスケールアップというふうに順番に取り組んで、取り組みをモデル化するというロードマップです。

実際にはロードマップを進めてからすぐに見直しを行なっています。チームの課題感を踏まえて、先ほどご紹介したドッグフーディングのように顧客視点の強化を優先させるべきと考えて、プロダクトのアウトカム強化を2番目に入れ替えました。

そしてロードマップをより具体化するために月に1回チーム戦略会議を行なっています。これはチームの中軸メンバーを推進者として、次の年度のチームの戦略を議論して、道筋を立てていく取り組みです。

自分たちの取り組みをモデルにするというビジョンを作ったことで、私たちはみんなでそれぞれの取り組み事例を整理し、事例として紹介しています。弊社のエンジニアブログでもメール配信のノウハウを共有しました。社外の大きなイベントにも応募し、発信いたしました。それらの一部をご紹介します。

みんなのプロジェクトマネジメント3つ目のポイントについてまとめます。これまでにご紹介した2つのポイントである改善やアジャイルを自己目的化して、「ヤクの毛刈り」をしてしまわないように、未来のイメージに向けてみんなで取り組むことが大切です。

そのためにはまず、みんなで取り組みの道筋を作り、それを随時見直します。そしてみんなでそれぞれの取り組みをアウトプットし、次の戦略を考えて未来のイメージに向かっていきます。

変化の時代に活かす

最後に変化の時代に活かす「みんなのプロジェクトマネジメント」についてまとめたいと思います。ダメプロジェクトに向かわないための「みんなのプロジェクトマネジメント」の3つのポイントは、継続的に振り返って改善を先送りにしない、今よりもアジャイルを考えて成長を実感できることに取り組む、未来のイメージを描いてみんなで取り組む、この3つです。

では、プロジェクトマネージャーという役割は不要なのでしょうか？　Googleの研究結果では、マネージャーが重要ではないことを証明しようと試みたのですが、やはり重要な役割であるということがわかったとされています。プロジェクトにおいても同じだと考えます。

「みんなのプロジェクトマネジメント」を推し進める役割はやはり大切です。経営学者のピーター・ドラッカーによるとマネジメントの役割は次の3つと言われています。自らの組織に特有の使命を果たす。仕事を通じて働く人たちを生かす。社会の問題に貢献する。

これにならうと、変化の時代のプロジェクトマネージャーの役割は、プロジェクトを成功させる仕組みを作り、そこに参加するメンバー一人ひとりの自己実現と成長を支援し、プロジェクトの取り組みのノウハウを社内外へ共有することだと思います。

私が考えるこれらの役割を支える大切な要素を少しご紹介します。ビジョン作りを先導するリーダーシップは大切です。ビジョン作りは継続的なプロセスであり、リーダーシップがビジョンの実現を支えます。

アジャイルもリーダーシップの実践が大切です。お伝えしてきたようにアジャイルを自己目的化しないためにも、アジャイルプラクティスを用いてプロジェクトを成功させるためのリーダーシップが重要です。

経験から学ぶチームのモデル

HRTをチームに根付かせることも大切です。一人ひとりの自己実現とチームとしての成果を両立させるには謙虚、尊敬、信頼は欠かせません。

そして一人ひとりの成長のために経験学習をベースにします。経験学習モデルは思いとつながりを中心にしたリフレクション、エンジョイメント、ストレッチの3つの経験から学ぶモデルです。

私はこの経験学習モデルをベースにチームのモデルを作ってマネジメントしています。すでにお気づきかもしれませんが、今日ご紹介した「みんなのプロジェクトマネジメント」もこのモデルがベースになっています。

そしてチームで取り組んだことを共有することで社会の問題に貢献できます。弊社でも毎週さまざまなイベントを開催しています。プロジェクトマネジメントに取り組むみなさんと一緒にノウハウを共有しあえると幸いです。

今日は紹介していませんが、プロジェクトマネジメントの基礎を押さえることも、もちろん大切です。プロジェクトマネジメントの知識体系のガイドであるPMBOKはプロジェクトをマネジメントするための知識を5つのプロセスと10の知識エリアに分類して体系化されています。

しかし、このPMBOKも第6版から変化への対応を重視してアジャイルを取り入れています。つまりプロジェクトマネジメントの体系的な知識をベースにして、変化の時代に対応するためにアジャイルや改善を取り入れることが示されています。

最も大切なことはゴールへ導き成果につなげること

このように「みんなのプロジェクトマネジメント」のスキルを身につけたうえで、それを役割として推進する「みんなのプロジェクトマネージャー」へもチャレンジしてみてはいかがでしょうか？

忘れてはいけないのは、プロジェクトマネジメントに最も大切なことは「プロジェクトをゴールへ導き成果につなげること」だということです。しかし、どうせならチームのみんなでプロジェクトマネジメントできる変化に強いチームで働きたくないでしょうか？　

みんなでプロジェクトをゴールへ導く変化に強いチームは、先送りせずに改善できて、成長を実感できることに取り組める、未来のイメージを描けるチームです。みんなのプロジェクトマネジメントにみんなで取り組んで変化に強いチームになるよう、今日の発表がお役に立てれば幸いです。

最後に、私たちのチームはみんなのプロジェクトマネジメントを推進していただけるプロジェクトマネージャーを絶賛募集中です。よろしければぜひご連絡ください。以上で発表を終わります。ありがとうございました。

藤澤貴之氏（以下、藤澤）：ありがとうございました。個々人が自律してプロジェクトマネジメントできるチームを作るチームビルドみたいな。そういう文脈のお話ですね。ありがとうございました。

池田智裕氏（以下、池田）：最後のやつは、それでもプロジェクトマネージャーが必要だっていう文脈から、どちらを募集されていたのかなっていうのをちょっと思ったんですけど（笑）。

大塚：マネージャーですね。プロジェクトマネージャーですね。

池田：いわゆるプロジェクトマネージャーを募集していますということですね。なるほど。わかりました。

ふりかえりで「エンジョイ」を出す

藤澤：では池田さん、みなさんのリアクション等々を見ていっていただいていいですか？

池田：「わかりみ」みたいなところではありますが、プロジェクトマネジメントは行動様式でエンジニアのスキルの1つっていうところで、そういうことなんだなっていうTwitterの投稿があります。エンジニアのスキルの1つだというのは私も今日初めて知りましたね。

発表内容とは関係ないかもしれませんが、オペレーションリードというのはどういったポジションなんでしょうね？　というご質問です。途中で開発リードとオペレーションリードという文脈の図があったので、たぶんそこの話だと思うんですけれども。

大塚：運用・サポート・オフショア支援ですね。オペレーションというのはシステムの運用とかです。

池田：ここの仕様ってどうなっているんですか？　とか、ちょっとバグで動かないんですけどみたいな質問が来る運用ですかね。

大塚：そうですね。あとは、リリースとかインフラチーム寄りの調整ですね。顧客サポートやインフラ保守の調整などをメインで担当するのがオペレーション側のチームで、純粋に開発に注力するのが開発側のチーム。それぞれリードする役割が違うということですね。

藤澤：SRE的なポジションと言ったらちょっと近いんですかね？

大塚：そうですね。

藤澤：成長を実感した生の声とか知れるとうれしいということなんですが、大塚さんの配下のメンバーでこの取り組みを通じてこういうところはありますか？　成長を実感した生の声。

大塚：いろいろあると思います。例えば、我々は毎週ふりかえりをやっていますが、その中では必ずProbremだけじゃなくてKeepとかよかったこともたくさん出てくるんですよね。我々のチームはKeepとProbremとTry以外に、Enjoyっていうのを出すようにしています。

池田：エンジョイ！　ほう。

大塚：こういうことができるようになったとか、そういう意見がけっこう出てくるんですよね。今日もちょうどふりかえりの日だったんですけれども、今年の新卒で入った子がある業務をできるようになったというコメントをふりかえりの1つとして挙げてくれましたね。

藤澤：なるほど。ありがとうございます。

いきなりスクラムの全部はできなくても、変化のために少しずつ取り入れる

池田：ちょっとドキッとするようなコメントがきていますが（笑）。プロジェクトマネジメントは落ち着いた進め方よりももっと泥臭い、熱い感情の出るお話が聞きたかったなぁと。実際はそういう進め方だったと思うのですが、どうでしょうかと。

藤澤：大塚さん、どれくらいの期間、継続してこういった取り組みを続けられているんですかね？

大塚：今日ご紹介した内容はだいたい1年半くらいですかね。2019年に今のチームになってからの話が中心になっています。もちろんそれ以前のさまざまなプロジェクトの経験を踏まえて、そういった取り組みを取り入れているということなんですけれども。

藤澤：進められるにあたって苦労された点はありますか？

大塚：泥臭さというのは、例えば本当のスクラムとかアジャイルについて世の中にたくさん発信されている方と比べていただければ、わかると思います。すでに今日の私の発表の内容ってすごく泥臭いんですよね。ちゃんとしたスクラムをやっていない話なので。

じゃあ僕らにはスクラムできないんだとか、アジャイルなんてよそでやっている話だよってなってしまうと、なにも変わらなくて変化に対応できません。だからそれをこうやってちょっとずつやっているよっていうのが、すでに裏にはすごく泥臭さがあってですね。

いきなりは全部できないので、とりあえずスクラムの中のスプリントの枠組みだけ取り入れてみようとか、そういったことを少しずつ試していると捉えていただければと思いますね。確かにそれをちょっときれいにまとめすぎたので、泥臭さの部分はあまりお伝えできていないかもしれません（笑）。

藤澤：以前のチームはビジネスサイドとも暗黙の了解でゴリゴリのウォーターフォールモデルで開発を進めていて、変化になかなか追従できないところがあるけれどもいきなり変えることもできず、折衷案として今日発表していただいたようなスタイルが確立されていったというような感じですかね。

大塚：そうですね。そこはまさに変化に対応するためのっていうところですね。

藤澤：今日1番目に発表した西原が大塚のチームなのですが、私が在籍していた時にはリファクタリングとかなかなか推し進められなかったところがあって。それはいろいろな背景があるんですけれども。

こういった取り組みの結果、リファクタリングとかの改善も推し進められるようになってきたっていうのは成果として出ているという感じですかね。

大塚：そうですね。1週間でふりかえりとかPDCAを回していると、そういうリファクタリングとかも取り入れるべきだという意見が毎週のように課題の中から出てきます。そういった意味でチームの中でも議論しやすいというのはあると思いますね。

最終的には成果が何かというのを判断しないといけない

藤澤：なるほどですね。いわゆるリーダーシップという言い方で言うとサーバントリーダーみたいな立ち位置になるんですか？

大塚：プロジェクトマネージャーの話ですかね？

藤澤：そうです、そうです。

大塚：そういったリーダーシップも大切だと思います。

藤澤：理想どおり進めたいのに、とはいえプロダクトとしてのアウトプットを出していかないといけない締め切りがあったりすると思います。その中でどうしてもある程度強権的にというか、トップダウン的にやらざるを得ないシーンとかもあったりすると思うんですけど。そのへんで苦労されたポイントはありますか？

大塚：やっぱりプロジェクトマネジメントで一番大事なのはプロジェクトの成果なので、そこは最終的には成果が何かというのを判断しないといけないと思うんですよね。みんなで考えて成果につながらなければ意味がないので。そこがリーダーシップの発揮のしどころなんじゃないかなと思いますね。

藤澤：そういう局面においても全員の納得感とかを調整しながら進めていったと。

大塚：我々もアジャイルをなかなか取り入れられなかったと言いましたけど、別に取り入れたくなかったわけじゃなくて、こういうのもやりたいっていう理想は常にもっていて、やろうとしています。

そこで、ここまででやめておこう、スプリントの枠組みだけまずやろうよ、という判断をしないといけないのはやっぱりプロジェクトマネージャーとかリーダーシップを発揮する人であり、ある意味サーバントという支援もしつつ、あるところではビジネスサイドや経営サイドの要求をくみ取ってトップダウンで発言してしまったりとか、決断してしまうというような動きをしないといけないだろうなと思います。

藤澤：なるほどですね。理想どおりにはなかなか進まないというところをうまく進められたというところが、ある種泥臭いという言い方をしていいのかわからないですけれども（笑）。泥臭さのポイントの1つというような感じですかね。

大塚：そうですね。

藤澤：大塚さん、どうもありがとうございました。

池田：ありがとうございました。

大塚：ありがとうございました。