計画変更時の再合意をブレなく簡単に行うために　プロジェクト開始時に大切な、3つの合意形成ポイント

岡崎氏の自己紹介と、DeNAの紹介

岡崎文哉氏：ではさっそくですが、1発目を始めたいと思います。「多様な事業を支援する情シス部門の合意形成」ということで、DeNAの岡崎から発表したいと思います。よろしくお願いいたします。

まずは本日の流れですが、自己紹介をしたあとに本題、最後にという流れで進めたいと思います。

自己紹介ですが、私自身の登壇者のプロフィールとともに、DeNA、所属会社の紹介も軽くしたいと思います。

あらためまして、私は岡崎文哉と申します。よろしくお願いいたします。現在株式会社ディー・エヌ・エー IT本部 IT戦略部システム基盤グループというところに所属していて、このIT戦略部が、いわゆる情報システム部門コーポレートエンジニアの部門になります。このIT戦略部にはだいたい約50名ぐらいが所属していて、私は気づいたらそのIT戦略部の中でPjMやPdMの役割をしがちな人です。

もともとインフラエンジニアではありますが、前職の関西の企業でスクラムのパイロットチームの立ち上げの支援などをやっていたような略歴を持っています。最近登山がマイブームです。

次にDeNAの簡単な紹介ですが、「DeNAの名前は聞いたことがあるよ」という方も多くいるかなと思ってはいるんですが、やはりゲームの会社であったり、横浜DeNAベイスターズ、野球の会社というイメージが強いかなと思っています。

他にも多様な事業をやっていて、ライブストリーミングであったり、オートモーティブ、ヘルスケア、メディカルですね。そういった領域にも今は力を入れていて、本当に多様な領域をやっています。

私が所属しているIT戦略、情シスの部署ですが、ポリシー、MVVを独自に展開しています。（スライドを示して）いろいろ書いてあるんですが、「グループ全体の社内ITを統括」すると3点目に書いてあるんですが、書いてあるとおり、いろいろな多様な事業があるんですけが、それ全部を担っているような情シス部門になっています。

情シスのプロジェクトってどういうものがあるの？

では、ちょっと本題に入っていきたいと思います。事例と合意形成のコツですが、「まず情シスのプロジェクトってどういうものがあるの？」ということを共有させてもらい、そのあとに私の経験から合意形成に関わる3つのポイントというコツをお伝えします。

情シスのプロジェクトってどういうものがあるの？　（スライドを示して）これは関わったプロジェクトの列挙であって、これだけじゃないんですが。例えばネットワークのVLANの統合であったり、オンプレミスセンターを使っていたのをパブリッククラウドにお引越ししたりとか。グループウェアのパッケージ版、サーバー版からSaaS版に引越ししたりとかしました。

あとは、事業のM&AのとかPMIとかが発生した時の事業のお引越しですね。あとは拠点の追加とか撤退とか、本社の引越しみたいなのがあった時とか。あとは情シス内のサブチームの立ち上げとか。ヘルプデスク二次請けチームとか、そういったもののプロジェクトが進んだりします。

いろいろありますが、全グループとか全事業規模を巻き込んだ引越しとかエトセトラみたいなところがけっこう多いですね。

合意形成のポイント1　本質的な価値提供に対する合意形成を行う

こういったプロジェクトがいろいろある中で、合意形成の3つのポイントを伝えたいと思います。

先に結論から伝えることになるんですが、1番の本質的な価値提供に対する合意形成。2番は優先順位の設定。3番は理想のチーム状態と現状のギャップ。この3点について合意形成しておくのがコツであったりとか、おすすめだなと思っています。

まず各3点を補足していくんですが、本質的な価値提供って何？　という話です。「我々はなぜここにいるんだろう？　集められたんだろう？」ですね。「我々が提供すべき本質的な価値って何だろう？」というところについて合意形成をしていくことになります。

方法としては、プロジェクトの始まりのキックオフですね。デザインスプリントとかチームビルディングの機会で合意形成を広くやっておくというのが方法としてはけっこうありで、インセプションデッキとか、ユーザーストーリーマッピングみたいないろいろな手法があると思うんですが、個人的なおすすめとしては、会社や部署のMVVとかです。先ほどもチラッと触れましたが、そういったものと連動したもので、インセプションデッキとかを整理しておくのがけっこうおすすめです。

例えばDeNAの場合は、DeNA Qualityという、DeNAで働くすべての人の共有価値観みたいな5点とか、けっこう浸透しているものがあります。こういったものと絡めてインセプションデッキを作っていくことがけっこうおすすめだったりします。

「部署のMVVとしても何をするの？」ということでいろいろ書いてあるんですが、安心できる環境の提供とか、効果的なユーザー支援とか。改善提案と変革を広い、事業横断的な全社最適で適用していくようなところが書いてあるものがあるので、こういったものを拠りどころにしていったり。

また隣の部にはなるんですが、IT基盤部という、よくやり取りするカウンターパートになるような部では「QCD全てで世界最高の水準を達成する」みたいなところを掲げていて、QCDのクオリティと、コストと、デリバリーって、基本的にはバランス、トレードオフだったりはするので。

全部をマックスにするというのは非常に難しいというところも書いてあるんですが、「そういったところで最高レベルを目指すんだ」みたいなところが書いてあるので、こういうところと絡めて意思決定というか合意形成していくのがおすすめです。

合意形成のポイント2　優先順位を設定する

2点目、優先順位の設定ですね。先ほど出たように、QCDすべてで最高の水準を達成するというところはあるんですが、そこにも書かれているように、その時のフェーズに合わせた優先順位の合意形成をしていく必要がある。バランスを取っていく必要があるということが書かれています。

常に最新の優先順位で整理されたバックログに対して合意ができていることが理想ではあると思います。

しかし、現実問題として、ステークホルダー全員が確認されたタスクレベルで合意したような状態を生成するのはなかなか難しいかなとは思っていて。少なくともQCDのどれを優先するべきと考えているのか合意形成をしておくのがおすすめです。

ただ、ステークホルダーの方とかに「これってQCDのどれを優先するべきですか？」みたいなところを投げかけても、なかなか解が出てこなかったりするので、デリバリー、柔軟な調整が難しい外部、社外との条件とかから明確にして逆算していって、次にクオリティとかコストとかの社内調整をしていくのがおすすめだったりします。

合意形成のポイント2　理想のチーム状態と現状のギャップに対して工夫する

次に3点目ですね。理想のチーム状態と現状のギャップです。よく「人、モノ、金」と言われたりすると思いますが、「人材はもっとも重要なチームのリソースであり能力だ」みたいなことは、ITILとか、そういったところとかでも言われたりするかなと思います。理想としては、高いスキルレベルのメンバーがプロジェクトに専任でコミットしてくれることだとは思うんです。

だけれど、なかなかそういうのも難しくて、現実としては兼務とか、既存業務＋αで参画することが多いかなと思っています。そういった場合に、あるべき兼務割合とかを可視化して、例えばAさんがプロジェクトにジョインしたら「このプロジェクトに2割の割合で参画してくださいね」というところをまずは可視化しておく。

あとは、そのチームで必要となるところをスキルマップに落としておくことがおすすめです。最初にインセプションデッキについて伝えました。インセプションデッキが何個かあると思うんですが、「ご近所さんを探せ」みたいなところもあるので。すでに作成済みであれば、調整先のプロジェクトとかがこの時にはもう明確になっているかもしれないですね。

合意形成の3つを押さえることでどんなメリットがあるのか

駆け足で3点伝えましたが、この3点を押さえることでどういうメリットがあるの？　というところですが、想定外が発生した場合のエスケープルートとして使えると思っています。

例えばQCDの鼎立、バランスに想定外が発生しました。もちろんデリバリーを間に合わせるところは大切ですが、今のリソース状況でどう考えてもデリバリーが遅れちゃいそうな想定外の状況が起こった時に、「これは絶対にデリバリーの優先度が高いんだ」というところをもともと合意できていれば、ゼロから議論することなく、「Aさんの稼働の2割では足りないから、再合意の交渉としては（デリバリーを遅らせるのではなく）4割などに（リソースの追加）が妥当だよね」みたいなところで、意思決定の再合意が取りやすくなります。

次に、QCDのそもそもの順位に想定外が発生した。例えばデリバリーが優先だと言っていたけれど、「さすがにもう少しクオリティを上げてリリースしたいよ」みたいな意見が内部から上がってきたことですね。そういった時には、「俺たちが提供する本質的な価値提供っていったい何だっけ？」みたいなところが議論済みであれば、そこに立ち返った時に「確かにね」みたいな話で、再合意のところでブレなくコミュニケーションができるかなと思っています。

PjMのコツは登山と同じ

最後に、これは私の趣味も絡めて最後のまとめです。PjMのコツは登山と同じだなと思っています。同行者とかと一緒に登山に行くのであれば、山に登る目的を合意しておくとか、優先順位を合意しておくとか。それに基づいて緻密な計画を立てて、装備を整えて、環境の変化に合わせて計画を変更することが大切かなと思っています。

登山といっても、良い景色を見に行く登山もあればロッククライミングみたいなところもあるので。「そんなつもりじゃなかった」みたいなことも往々にして発生するので、「そういった目的意識のコミュニケーションって大切ですよね」と思っています。

PjMとかの活動で難しいのが、こういう事前準備って万端にしなくても結局どうにかなっちゃうことも多いのかな、と。このあたりも登山に似ているのかなとは思うんです。

ただ、我々DeNAのIT戦略のプロジェクトとかをやるにあたって、安心できる環境の提供とか、効果的なユーザー支援とか改善提案の変革とかを世界最高の水準で達成するためのプロとして活動していくんだというところは心に留めているので、やはりプロとしては総合的に考慮し、優先順位を付けながら最適な解を出していくところが必要になっているし、コツとして心がけているところでもあります。