一般記事

日本のDevOps変革を促進するバリューストリームマッピング

この記事を読むのに必要な時間:およそ 4 分

「自分たちでもできる!」と思う心がリードタイムを短縮する

バリューストリームマッピングのセッションを日本で実施する場合は,まず1つのプロジェクト/サービスに的を絞って,そのプロジェクトのDev,Ops,QA,UCD,プロダクトオーナー,マネージャーなどの関係者に参加してもらう。できれば全員に。そして,重要なことは,開発プロセスを変更できる権限を持っている人(つまり偉い人)に参加してもらうことである。

図2 バリューストリームマッピングに参加する人たち

図2

なぜ,⁠開発のプロセスを変更できる権限を持っている人」に参加してもらうのだろうか。

バリューストリームマッピングを実施して,プロセスやリードタイムを見える化していると,誰の目にも「無駄」が明らかになってくる。しかし,現場のメンバーだけでは,無駄だとわかっていても「会社で決まってしまっていることだから……」と考えてしまい,改善につながらない場合が多い。ところが,そこに,開発プロセスを変える権限を持った人がいたら,その人に対して発言を促して聞いてみればよい。

たとえば,⁠〇〇さん,この承認って明らかに無駄ですよね。これって削除できないですか?」と聞くと,今のところほぼ100%次のような答えが返ってくる。⁠削除しちゃいましょう。リードタイムが短くなるなら大歓迎だよ」⁠

偉い人からすると,新しいことを導入して,リードタイムが短くなるなら方法などどうでもよいのである。しかも,追加でお金がかかるわけでもない。単に「やり方」を変えるだけなのだから。そういう発言を聞いていると,現場のメンバーも「あ,プロセス変えちゃっていいんだ」と認識してくるので,どんどん議論が活発になって,自ら「無駄」を指摘して,みんなと共有できるようになってくる。

このプロセスが日本で効果的な理由は他にもある。単に数字だけで「効率化」されることを言われても誰も納得しないが,自分が自らやってみて,⁠無駄」を発見・共有する。そして,次にその無駄を削除したり,自動化したりして,解決策を一緒に考えることによって自分たちでも無理なく改善するだけで,リードタイムが劇的に短くなるという効果が明らかになるからだ。つまり「自分でできる!」と思えるのである。これは大変重要なことだ。

ミドルマネジメントにも安心を与えること

バリューストリームマッピングがもたらす効果として,重要なことは「わかりやすさ」だ。その場にいなかった人,たとえばCEOクラスの人にとっても,成果が説明しやすい。バリューストリームマッピングを実施すると,各プロセスのリードタイムがわかるので,それを合計すると,現在のリードタイムが明確になる。そして,無駄を省いて,新しいプロセスを考えて,自動化をどうしていくかを考えていくと,実現可能なリードタイムが簡単に算出できる。たとえば筆者が実際に行った例では,バリューストリームマッピングを実施することによって,現在のリードタイムが8.5ヵ月であったが,それが1週間まで無理なく短縮できるとわかった。

DevOpsの変革を実施することで,リードタイムが8.5ヵ月から1週間になったらそれはとてつもないビジネスバリューだ。たとえば,CXXの役職の人に「DevOps を導入すると,現在のリードタイムが8.5ヵ月なんですが,これが1週間になる見込みなんです。やってもいいですね?」と言って誰が反対するのだろうか。

つまり,圧倒的にわかりやすいのだ。

すると,かなり上位まで改善プロジェクトのコミットを得られるようになる。そうなったときに,しっかりトップを巻き込んで,この改善活動にチャレンジしたミドルマネジメントは,たとえ失敗しても高い評価を与えるというコミットを得ておくとよい。そうすれば,ミドルマネジ メントのほうも安心してこの改善活動に参加できる。

よく,ミドルマネジメントが石頭で反対ばかりする,と言う人がいるが,重要なことはその人を否定することではなく,理解することだ。そこには絶対的にその人にとって重要な理屈が存在する。それはたいていは「恐れ」だ。だから,その「恐れ」を取り除いてあげればよいだけなのだ。

たった4時間のワークショップがデリバリーを劇的に改善する

バリューストリームマッピングは,1つのプロジェクトにつき4時間程度で実施できる。もちろん,このワークショップを実施した後に,実際にプロセスを変更したり,自動化を実施したりする必要がある。しかし,プロセスを変えるにしろ,自動化するにしろ,ここで作られたマップがあればその後がとても明確で,簡単になる。そして,チーム全員を巻き込んでいることで,共通認識,自分たちでもできるという思いがあるため,ムードもかなり良くなるのだ。

筆者はバリューストリームマッピングを実施した後には,⁠ハックフェスト」という活動をお勧めしている。エキスパートとともに,バリューストリームマッピングで発見した「無駄」のうち,自動化できる部分を実際にハッカソンで自動化してしまうのだ。だいたい3日から5日程度で実施している。そうすると,実際にリードタイムが劇的に短縮される。

その後,定期的に改善の様子をモニタリングしていくと,どんどんリードタイムが短くなってくる。筆者が実施した他の例でも,13日だったリードタイムが数ヵ月で2日になった。他の例ではなんと8.5カ月が実際に1週間に短縮された。劇的な効果だ。ただし,この場合も,無理にあわててリードタイムを短くしないことだ。チームの改善にはチームのペースがある。ただ,定期的にモニターして,どの程度リードタイムが短くなったかの計測とデモを共有するようにして,自分たちのペースで改善する。

すると,あわてなくてもすぐにリードタイムは短くなるのだ。ただし,バリューストリームマッピングは,2時間以内にデリバリーできるほど自動化できているチームには,あまり有効でない場合もある。そのケースでは,Gene KimのThree Waysに従って,本番からのフィードバックの速度を速める方向に注力してくとよいだろう。

表2 無駄のリスト

無駄の種類 マーク 定義
欠陥の無駄(Defects) D 誤った,抜けのある,不透明な情報や成果物。システムを破壊し,解決するのに時間と労力が必要 壊れたビルド,不正確な設定,不正確な要求
マニュアル/モーション(Manual/Motion,Handoffs) M オーバーヘッド,コーディネーション,作業引き渡し,またはセットアップや仕事の実行に関する非効率性 ミーティング,手動デプロイ,チーム間の作業引き渡し
待ちの無駄(Waiting) W 次の価値のあるステップを開始,または終了することの遅れ 承認待ち,リソースの待ち,予定されたミーティング待ち
未完了の作業(Partially Done) PD 未完了の作業,何らかの操作。他者からの入力やアクションが必要となる。欠陥とタスク切り替え,待ちを招く デプロイされていないコード,不完全な環境設定,実行中バッチ
タスクの切り替え(Task Switching) TS タスクの切り替えは,高価なコンテキストスイッチを招き,エラーが発生しやすくなる 進捗上限による無駄作業,障害による中断,アドホックなリクエスト
余分なプロセス(Extra Process) EP 価値のないステップやプロセス。たいていは,公式,非公式な標準作業に含まれる 不要な承認,不要なドキュメント,無駄なレビュー
余分な機能(Extra Feature) EF 機能,たいていは実装フェーズで追加されたもの。リクエストされていない,ビジネスに沿っていない,顧客価値がない “次に必要かもしれない”,不要なアップデートや要求,望んでいない
ヒーローまたはヒロイン(Heroics) H 仕事を完了させる,または顧客を満足させるために,ある人に大変な負荷がかかっている状態。ボトルネック 数日必要なデプロイ,長年の知識が必要,極端な調整が必要

まとめ

バリューストリームマッピングは,リードタイムの短縮だけではなく,日本では変革の効果を劇的に高める効果があり,大変お勧めの技法だ。興味のある人は次のプレゼンテーションの資料を公開しているので参照されたい。

著者プロフィール

牛尾剛(うしおつよし)

マイクロソフトコーポレーション テクニカルエバンジェリスト - DevOps米マイクロソフトのDevOpsワーキンググループ所属。大手SIerを経てアジャイルやDevOpsの実践者/コンサルタントとして15年以上のキャリアを誇る。国内だけでなく,Agile Conference等の国際カンファレンスでの講演も多数。ベトナムのDevDay 2015では2nd Speaker prizeを受賞。

バックナンバー

DevOps

  • 日本のDevOps変革を促進するバリューストリームマッピング

コメント

  • プロセスを変更する権限を持った人

    アジャイル導入の難易度の国別の一覧は、確かに日本の開発組織の特性を表していると思いました。

    この特性に対して、バリューストリームマッピングが有効である理由は今ひとつ分かりませんでした。改善点を可視化し、共有するという点では、どのような組織に対しても有用であると思うからです。
    そこで、バリューストリームマッピングを行う際の参加者が関係者全員であるというのが「全員合意」を尊重する日本の特徴に適合するのではと考えました。その意味で、DevOpsではプロセス変更を行うので、プロセスを変更する権限を持った人を入れることが重要になると理解しました。さらに、DevOpsはプロセスを変更する作業であるため、むしろプロセス策定者がリードするというのが自然であると考えたのですが、いかがでしょうか。

    Commented : #1  天羽正道 (2017/06/23, 00:54)

コメントの記入