BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

Kevin Behr氏に聞く,継続的改善の技術(Kung-Fu)

| 作者: João Miranda フォローする 2 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2013年12月5日. 推定読書時間: 6 分 |

原文(投稿日:2013/11/17)へのリンク

先頃ニューヨークで開催されたDevOps Daysで,"The Visible Ops Handbook""The Phoenix Project"の著者のひとりであるKevin Behr氏は,Jesse Palmer氏とともに,常態的にオーバーワークにある運用チームに継続的改善の文化をいかに浸透させるか,というテーマで講演を行った。

両氏によると,この継続的改善のプロセスを通じて,チームの仕事の方法は劇的に変わった – 開発(Dev)と運用(Ops)が緊密な関係で作業し,不要な作業ややり直しは着実に減少しているというのだ。さらにこのプロセスは,チームが自分たちの仕事,つまりミッションの進むべき方向や一貫性のあるストーリを見失ったという結論に達したときにも,ブレークスルーを実現する上で重要な役割を果たしたという。

氏らはまず,現状の分析から始めた。この分析ではTOC(theory of constraints, 制約理論)Cynefinなど,いくつかのフレームワークを指針として使用している。Cynefinは,複合系の進化的性質と内在する不確実性を論理的に検証するためのフレームワークだ。次にCRT(current reality tree, 現状構造ツリー)を使って,組織の問題を生み出す根源となっている最上位の問題を描き出した。

さらにMike Rother氏が著書 "Toyota Kata" で推奨しているテクニックである 改善のカタを使った実験も,期間を短く制限して始めている。改善のカタとは,科学的手法を組織の日々の活動に適用することによって,問題やその根本原因を解決する方法である。今回使用された改善のカタは,毎日のスタンドアップミーティングで次の5つの質問に答える,いうものだ:

  • 目標条件は何か?
  • 現在の状況はどうか?
  • 目標条件を達成する上で,もっとも大きな障害は何か?
  • あなたは今日,どの障害を試すのか?
  • あなたの試みは何か,その結果はどうすれば確認できるのか?

例えば,もっとも一般的な不満は "十分な時間がない" というものだ。しかしチームは,それをもっと深く掘り下げることで,ひとつの結論に達した。それは皆がいつもその時点で,もっとも有効な手段を探しだそうとはしているが,全体的な視点が欠落している,というものだった。そこで彼らはカンバンを採用することにした。それによってチームは,バリューストリーム(value stream)の可視化やフロー管理,試行や進捗の状況を測定するためのステージ設定などが可能になった。

改善プロセスでは,"技術的負債の返済"や"計画外作業の管理"など,いくつかの目標条件を特定した。これらを達成する過程において,クリティカルな技術的負債プロジェクトの定義や,上位アクティビティを見失わないためのシンプルなプロジェクトプランの作成など,いくつかの実験が行われた。結果は具体的な形で現れた。根本原因の解析にってマーモットの日(Groundhog Day)効果が回避できたこともその一例だ。運用チームはさらに,デプロイメントプロセスの改善などといった,開発チームと共同で行う改善作業にも着手した。これが実現できたのは,何よりもチーム間にフィードバックループが形成されたからだ。

InfoQではKevinに,講演で取り上げた技術と実践について話を聞くことにした。

講演で紹介した組織の改善事例では,改善のカタを利用したいう説明がありましたが,これとような方法をいつも採用しているのでしょうか,あるいは今回の状況に合わせて改善のカタを選択したのですか?

形としてはさまざまですが,Mike Rother氏が著書 "The Toyota Kata" で説明したものと同じような改善のカタは頻繁に使用しています。私たちが使うのは,Opsflowと呼んでいる,より広範な形式のアプローチの中の一部としてです。組織学習の7つの面に合う,さまざまなメソッドやアセンブリを採用します。価値提供のサイクルとリードタイムを削減すると同時に,共適応的なイノベーション能力を開発し,潜在的才能を育成,発展させることが目標です。

目標条件は単なるゴール(Goal)やKPIではないという点について,詳しく説明して頂けますか?ここで言う目標条件とは何なのでしょう?

ゴールは遠すぎますので,その時々の作業判断による影響をほとんど見ることができません。課題(Challenge)はゴールよりも小さい達成の単位です (ゴールにほとんど近い課題もあり得ますが) 。ゴールよりもっと作業者に近くて小さなものが目標条件,すなわち作業者の隠喩的なワークステーションないしワークセンタにおける測定基準,あるいはその集合です。プロセスレベルでの測定基準(1日当たりのウィジェット開発のように)といったような,知的作業を測定する数値なのです。課題を達成するためには,デスクで何をしなければならないのか,目標条件の達成度を測るにはどうすればよいか。最初はそのようなことを広範囲に指導すればよいでしょう。習うより慣れる,ということですね。

目標条件を見つけ出すのには,どのような仕組みを使うのですか?

多くのテクニックを利用しています。もっとも有効なのは,組織のゴール/ミッション/戦略/計画/開拓といった,ミッション定義に対する管理的なアプローチですね。目標条件はすべて,管理の確立した領域内にあることが必要です - 目標条件の示す課題が,確実にゴールに近づくことのできるものであるように管理しなければならないのです。

ターゲットとする目標条件は,どのように決めているのでしょう?

現状構造ツリーや未来構造ツリー,移行ツリー,ゴールマッピングなど,Eli Golddatt氏の制約理論を基にした思考ツールを使っています。フューチャーバックワード(future backward)や儀礼的異議(ritual dissent)など,認知バイアスの回避と変更すべき根本条件の特定を支援するためにDavid Snowden氏のデザインしたメソッドやアセンブルも使っています。

継続的な学習あるいは継続的適応でもっとも難しいのは,その"継続"という部分だと思います。勢いに乗って始めるのは簡単ですが,自然消滅することも少なくありません。長期に渡って継続的な適用を維持するためのヒントやテクニックといったものはありますか?

ありますよ! まずは形式を正確に,深く習得することです。科学的手法を学習して科学者の文化を確立し,育成することが重要なのです。その文化を守る姿勢を確立するためには,コーチングや第2コーチングなどのプログラムも必要になります。失敗を語り合い,成功を祝うために,振り返りを毎週実施してください。努力を継続する上で最大の障害は,課題が次から次へと現れるために,あたかもランニングマシンの上にいる(同じ場所にいるだけで,大きな変化が何もない)ように感じられる点でしょう。改善の失敗率は低いので,かえって落胆を感じてしまうかも知れません。チームが定期的に自らの成功と教訓を振り返れば,そこで得た達成感を使って,さらなる改良へのモチベーションを高めることができるでしょう。それが鍵なのです。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT