DMM.comのプロダクトオーナー・石垣氏によるLTがスタート
石垣雅人氏（以下、石垣）：プロダクトをリリースするまでを見える化することで、組織体質を変えた話ということで、石垣が話します。
自己紹介ですが、私は2015年に新卒でDMMへ入社しました。今はプラットフォームの開発を進めていて、Account（ID）、Auth、Personal Info、個人情報やバックエンド基盤を担当し、現在、そこでプロダクトオーナーをしています。
今日は、リリースするまでを見える化することで悪い組織体質を変えて、リリースまでのリードタイムを268.5時間から54時間に短縮したケーススタディをお話ししたいと思います。スライドについてはTwitterでも流してあるので、見えにくかったらそちらでお願いします。
組織の「ムダ」を定量的な数値で可視化する
（スライドを指して）こちらアジェンダになります。まず会社の組織の話をします。
DMMは40種類以上の幅広いサービスを展開しています。DMMの有名なところで言うと動画、証券、バヌーシー、電子書籍といったさまざまなサービスがあります。
そこで自分は、事業サービスが使うプラットフォーム基盤を提供しています。個人情報を取得、登録するようなAPIを用意したり、そういったかたちでやっています。
自分が当時抱えていた組織体質の問題として以下のようなことがありました。悪い組織体質の例として、ある開発者が自動化をもうちょっと進めていきたいということです。
今まで手動でリリースしているから、もっとCI（継続的インテグレーション）とかCD（継続的デリバリー）を導入して、テストも自動で回したいという話をしたときに、どうしても「今のやり方でも困っていないから」「新しいツールへの学習コストがかかる」「1度チームで決めたことだから」という課題が出てくるかと思います。
この組織体質を変えるには、普通にテストを作ってしまってデモを見せるとか、いろいろあるんですが。スライドのタイトルでもある「改善の1歩」というところで言うと、そういった組織のムダを定量的に数値として可視化してしまうことです。
VSMとSIPOC分析、2つの事例
方法論としてはいろいろあるんですが、VSMとSIPOC分析の2つを使った事例を説明していきたいと思います。
VSMは、Ideaを要求や要件に置き換えて、要件定義からValueとしてユーザーに届けるまでという開発プロセスを可視化するツールです。
実物としては（スライドを指して）こんなかたちになっていて。これはホワイトボードですが紙とかでもいいです。左から右に開発のプロセスを書いていきます。
書き方について、厳密に定まっているわけではないですが、4つの工程に分けて説明していきます。
（スライドを指して）こういった例を軸にお話ししていきます。1番始めにプロセスのタイトルを書いていきます。
この例だと会員登録機能を作成したあとに、上の人たちが見て「リリースオッケーだよね」というリリース判定ミーティングがあったとします。その下にそのプロセスにかかった時間を記載していきます。
例えば会員登録機能作成だったらProcess Timeが10時間かかっていて、Wasting Timeには、レビューを待っている時間を書いていきます。承認ミーティング自体は1時間で終わっています。
今やっているプロセスが前のプロセスにどのくらい出戻ったかというのが3つ目の完成と正確性です。例で言うと、会員登録機能を作成しました。それを承認ミーティングに持っていきました。ダメ出しをくらって7割の機能を作り直しというように、割合を書いています。
理想に近づけるために大事なのは、改善ポイントを見つけること
最後に、プロセス間のリードタイムを書いています。会員登録機能については12時間かかっていて、それを84時間経過したあとに承認ミーティングを開いている。承認ミーティング自体は1時間で終わっている。
これだけ見ても、おそらくその84時間ってムダだというのが見えてくるかと思います。それこそ承認ミーティングをなくしてしまえば、85時間の削減につながるというのが見えてきます。
プロセスに関してもう1個言うと、今のようなVSMを書いたときに、もう1つ理想というか、仮説のVSMを書いていただきたくて。これは現状のVSMを書いた人間と同じメンバーで「こう削減したらこのくらい減るよね」という、会話のように理想の開発プロセスを書いていきます。
3の改善プロセスでその差分をどんどん改善していけば、理想のVSMに近づきます。大事なのは改善ポイントを見つけるということです。どう改善するかというのは別のレイヤーの話です。
（スライドを指して）SIPOCの分析です。これはプロセスの工程を可視化するもので、真ん中にプロセスを書いて、それに対して必要なインプット、供給者、右側にいってプロセスをやったことでのアウトプット、顧客を書いていきます。
VSMの親和性で言うと、真ん中のプロセス欄にはVSMのプロセスをそのまま書いてしまえば大丈夫です。例で言うと会員登録機能作成、承認ミーティング、リリース作業です。
それに対して1つ例を出すと、スクラムでやっているならインプットはDoneの定義になる。それを供給する人はPOである。POか開発チームですね。
可視化してみてわかった、ステークホルダーとの調整時間の多さ
右側にいくと、この時点ではソースコード。まだ市場に出ていないのでソースコードがアウトプットになる。顧客はまだユーザーではなくチームであると書いて可視化していきます。
さらに、この2つを掛け合わせた改善事例を出します。VSMもいろいろ書いていて、だいたい省略するとグループとして3つに分けられます。
ステークホルダーとの調整と、開発作業と、リリース準備・作業の3つです。
1つ例を出すと、リードタイムがある案件で268.5時間かかっていました。1営業日で6時間計算なので、だいたい1ヶ月から2ヶ月の間くらい。
割合としては、ステークホルダーとの調整にだいたい85パーセントかかっています。開発自体は実は5パーセントで、リリース準備や作業自体は10パーセントです。
ほぼすべてのVSM、どんなパターンの開発プロセスでもこの比率になったというところで。この時点で、例えばプロジェクトが遅いからといって開発力を上げてもムダだということが判断できます。
「実際の削減率」を見せることの重要性
なので、コミットするのはこの2つであると。SIPOCの観点でステークホルダーとの調整を見てみると、プロセス数が2。承認ミーティングがあって、出戻ってまた承認ミーティングをしたからプロセス数が2であると。
それに対するインプットとアウトプットの量に注目をしていて、承認をするために説明用のドキュメントを準備するのもそうだし、アウトプットとして7つのドキュメント、いわゆるソースコードを文章に起こしてそれをマネジメント層に説明するための資料が、蓋を開けてみたらこのくらいになっていましたと。
リードタイムの例なんですが、実際にはステークホルダーとの調整は、理想のVSMで言うと40時間に短縮。リリースの準備とか作業自体は26時間から5分に短縮されます。
実際に短縮したんですが、はじめの1歩目としては「こんなに改善できますよ」という定量的な削減率を見せることが大事です。
「CI入れたらこんなに便利になります」と口で言っても、さっきのように「今のやり方で困ってないから」などと言われてしまうので、こういった削減率を見せるのが大事になります。
最後に、僕も新卒で入って、はじめはチームではなく、自分1人で作って上司に見せて、では改善しましょうと進みました。1枚の紙があれば明日からでもすぐ書けるものなので、VSMや、今回の例に出たSIPOC分析を作ろうという話になります。
ご静聴ありがとうございました。
（会場拍手）
