不確実さが増す世界のプロジェクトマネジメントとはとういうものか
倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。
（スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。
これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。
（会場笑）
なぜ（失敗するか）というと、そもそも僕らがやっているクリエイティブな仕事は、不確実なものに対してどうすればいいのか（です）。完成しても終わりではないですよね。家を建てたら終わりみたいな、完成して終わりのつもりでやっていますが、いやいや、我々のやっているプロジェクトはそういうものじゃないですよね。人を増やしても速く作れるわけでもない。たくさん作っても生産性が高いとは言えない。人に依存せずに同じ品質で作ることはできない。そして、プレッシャーをかけても生産性は上がらないですよね。
クリエイティブな仕事はアイデアを出す仕事に近いです。アイデアを出す仕事や、アイデアを出す仕事をしている人に対してプレッシャーをかけて、速く出せますか？ みなさん絶対に無理なことじゃないですか。なのにマネージャはプレッシャーをかけようとするんですよ。それじゃダメだと思っています。
見積もりを求めたら絶望感は増します。正解がないプロジェクトはやってみるしかないので、「じゃあ精緻な見積もりを出せ」と言われると、実際にやってみるしかなくなります。
でもやったら、逆に見積もりにめちゃくちゃコストがかかる。なので、「やらずに守れる見積もりを出せ」と言ったら何が起きるかというと、バッファを積むんですよね。なるべくバッファを積んだ見積もりがどうなるかというと……。人間は誰でもバッファを食い潰すんですよね。なので、正確な見積もりを求めようとすると、そこは結局うまくいきません。
一度に大きく作ろうとすると得に見えて損をするとか、工程を分業しても効率化につながらないというのがソフトウェア開発やデザインです。マーケティング、人事……。先ほどの再現性の少ない仕事のプロジェクトは、もしかしたらこれに全部当てはまるんじゃないかなと思っています。
ということを書いたのがこの本で、2023年に発売されたものになります。
（会場笑）
何回説明するんだという話ですけど、買って読んでもらえたらと思います。
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと
さらに言いたいこととしては、これまでの常識が通用しないということです。これからのプロジェクトマネジメントは何が大事なのかなと僕が考え（て辿り着い）たのは、これかなと。結果にコミットしないことです。結果にコミットしないプロジェクトマネジメントがうまくいくんじゃないかと思っています。
1つ例を紹介しようかなと思います。「北欧、暮らしの道具店」というECサイトがあります。もしかしたら使ったことがあったり、知っている方もいるかもしれませんが、エンゲージメントアカウント数が686万人ぐらい。アプリを2020年ぐらいに出して300万ダウンロードぐらいということで、けっこうたくさんの人に使ってもらっているサービスです。
それを運営しているのがクラシコムという会社ですね。私はこちらの社外取締役として2018年に参画しています。内製のエンジニアが今は9名いますが、私が参画した時には1人、2人ぐらいの状態でした。2022年に上場を果たすことができましたが、当時は上場に向けて内製のエンジニアチームを作っていく、いわゆるショップやモールを使うのではなくて、内製で自分たちでシステムを作ってユーザーさんに提供できるプラットフォームを作っていこうということで、そこの支援をしました。
その中でずっと取り組んできたことは、経営サイド、いわゆる事業の経営をしている人たちと、テクノロジーの人たちが、一緒の方向を向いて同じチームとして成果を出していくにはどうすればいいかということです。そこのコミュニケーションを取った結果が、先（に話した「結果にコミットしない」という話）のほうになってくる感じですね。
「結果にコミットしない」プロジェクトマネジメントで取り組んだ3つのこと
そこで取り組んだことは、今思うと本当にすごく良かったです。経営陣もプロジェクトを理解し、テクノロジー側も経営のことを理解しながら同じチームとして進められています。
その中で取り組んだことが3つあるんですね。1つは社外取締役としてやるようにしたのが、経営者と開発チームを、定期ミーティングとか……。定例ミーティングはどうせあるんですが、それまでは（中身が）進捗報告だったんですね。
隔週とか月1とかで「進んでません」「まだ進んでいないんですか？」「今だいぶ進んでますけど遅れていますよね」と（話をするものでした）。
不確実なプロジェクトで進捗管理をすると、毎回「遅れている」としか言えなくなるんですよ。それはそうなんですよね。結果にコミットしているものに対しての進捗なんですが、毎回「遅れている」報告しかできなくなります。
経営陣も「また遅れているのか。リスケか？」と。開発チームも、とはいっても想定どおり作れないことはザラにあるし、思っていなかったことが起きることもあるし、他のトラブルで時間がないこともあるので、やはり「このプロジェクトは遅れています」としか言えないことが多いです。なので、お互い不幸だよねということで、進捗管理を止めましょうと。
進捗管理をやっているから進捗報告になるので、僕らはロードマップミーティングというものをして、ロードマップを確認しましょうということをしています。このロードマップも、経営陣と開発陣で同じものを見ています。
それまでは開発チームが見ているタスク管理があって、そして（それとは別に）経営陣は経営陣に見せるタスク管理でやっていたのですが、そうすると結局チームが分断されるんですよね。
同じものを見るということがポイントになるので、同じものを見ましょうと。同じものを見るロードマップという時に、「スケジュール」と言うのを止めましょうと。「スケジュール」とは言わないで、「ロードマップ」と呼んでいるんですね。
「ツールはいろいろなものを使う」と書いてあるのですが、中身の本質的には何をしているかというと、いわゆるプロジェクトが時系列に並んでいます。時間軸として、短い時間軸のものは精緻に見積もりしたりする、ちょっと先のものはふんわりとした見積もりをして、だいぶ先のものはだいぶふんわりとした見積もりをします。
時系列に時間軸に重要なプロジェクトを並べていきます。これがロードマップですね。1チームの時には1ラインしかない。2チームあったら2ライン。ということで、このロードマップを見ていって、後ろの時間は固定しません。ロードマップミーティングは今は隔週、一時は毎週にしたり変えたりするのですが、経営陣が入っているロードマッピングで、プロジェクトの順番を毎回更新していきます。毎週、隔週更新をしていく。そうすると、リスケしないので、ただのアップデートになるんですね。
絶対に何か進んでいるはずなので、進んでいるものを確認した上で……。（そうすることで）未来のことが少し確実になったので、それに関してはアップデートしてわかりやすくしようとしています。
それを続けていくことをやってきました。経営陣からすると、決めた機能を、決めたリリースを絶対に守ってほしいとは思っていないんですよ。できれば守ってほしいけれど、それよりも今あるリソースで最大限のパフォーマンスを発揮して、うまくやってくれることが良いですよね。
あとは「こういうことをやってみた？」「やったほうがいいよね」といことのは、「いつかちゃんとできたらいいよね」と言うのですが、いつできるのかわからないことのほうが怖いです。
ロードマップで計画して（あげることで）、わかっているかの話ができるんですよね。テクノロジー側もベストを尽くせば、今ベストを尽くしてやっていけば前に進んでいくよねといえるので、同じ方向を向けるプロジェクトマネジメントができるようになるのかなと思っています。
そのためのロードマップは、制御できるサイズまでスコープを小さくしようということですね。1本のプロジェクトが3ヶ月とか4ヶ月とか半年とかかかって、結局ウォーターフォールの「進捗30パーセントです」みたなことが起きちゃうので、プロジェクトはなるべく小さくして終わらせていくということをやっています。
そういうことをしていくことで、経営陣とテクノロジーサイドで同じ目線でプロジェクトをマネジメントしていければなと思っています。
これは「アジャイル」という言葉を使わずに説明していますが、おそらくこれが本物のアジャイルということなんじゃないかなと思っています。
「アジャイルである」とはどういうことか
これをもうちょっと抽象化して、アジャイルであるとはどういうことか。経営陣も含めて、アジャイルとはどういうことなのかなと考えた時に、3つあるかなと思います。
1つは結果を約束しない。だけど、今のフォーム、今の自分たちのやり方でベストを尽くす。「こういうやり方が良い」ということに集中するということです。
弓道の世界で「正射必中」という言葉があるらしいです。「正射必中」という言葉は「必中正射」の逆です。必中正射は、当たれば「いい投げ方だったね」となるのですが、それでは再現性がないので、「良いフォームで投げたらきっと結果が出てくるよね」というものが、正射必中の考え方なんですよね。
それに近いもので、「ベストは尽くすけれども、どうやるかわからない」。どうやるかわからない不確実なものに対しては、ふりかえりをしましょうということです。ふりかえりをすることで改善できるし、３ヶ月、半年のプロジェクトで自分たちの成長を見越さない計画を立てるよりは、ふりかえりをしながらチームのアップデートをしていくことが大事だと思います。
その先にあるのが、良いことも悪いことも両方拾って、「まぁ、どうなっても大丈夫だろう」と思えるだけの強さを身につけることが、本当のアジャイルなのかなと思っています。
ウォーターフォールやアジャイルの対比をする時に僕がいつも思うのは、ウォーターフォールは結果が決まっていて、結果どおりにやれば成功なので、間に合うかドキドキはしますが、ワクワクはあまりしないんですね。
アジャイルだと、うまくいかないかもしれないけれど、思った以上にアップサイドのリスクというか、アップサイドの良いところも当然あると考えると、前に進んでいくプロジェクトとしてはすごく希望があると思っています。
（スライドを示して）これもまた（後で）見てもらったら良いかなと思います。従来の予測型の事業計画を立てて、決めて結果にコミットするようなマインドセットか、変化に適用していくアジャイル的なマインドセットかという違いです。
ということで、この変化の激しい不確実な世界をどうマネジメントしていくのかというところで、「Backlog」とアジャイル思考で成果が上がるんだという、サービス名を掲げて終わります。
（会場笑）
私の話は以上になります。ありがとうございました。
