BT

企業のマインドフルネスと状況把握

| 作者: Ben Linders フォローする 23 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2014年12月7日. 推定読書時間: 4 分 |

原文(投稿日:2014/11/12)へのリンク

プロセスから無駄を排除するには、ジャストインタイムで提供できる流れが必要だ。そして、人間の知性によって構築されたプロセスの問題に対処するための、企業でのマインドフルネスや状況把握が必要になる。ますます多くの企業が流通の概念を導入して必要なときに必要なものを開発し、在庫を抱えるのを回避しようとしている。このような企業に必要なのは“自動化”、つまりマインドフルネスと状況把握だ。

Mary Poppendieck氏はLean Kanban Central Europe 2014 Conferenceにて気付きのある企業について話した。氏は安全で信頼ができる世界レベルの組織になる上でマインドフルネスがいかに役に立つかを説明している。

氏が引き合いに出したのは軍隊の展開だ。軍の展開にはふたつの重要な点がある。まず、分隊長が命令の意図を理解する必要がある。つまり、作戦の目的を理解し、望ましい結果を達成するためにチームがやるべきことを理解する。そして、状況を把握し、他の部隊の進捗を確認して、彼らが目的を達成するために、今どこにいるのか、どのように貢献しているのかを理解する。

そして氏は、高い信頼性を持つ企業の協力モデルについて話をする。

氏によれば、マインドフルネスには5つの要素が貢献する。

  • 運用に対する繊細さ
  • 単純化に対する抵抗
  • 専門性に対する敬意
  • 失敗に対する執心
  • 弾力性に対するコミットメント

運用に対する繊細さとは、実施する運用プロセス全体を把握するということだ。なぜそれを実施するのか、それはどのようにして全体に嵌るのかを理解する必要がある。

労力を削減する、ということをテスト自動化の理由にするのは、間違っている、と氏は言う。その理由では、正しい理由で自動テストをすることを妨げてしまうのだ。テストは回帰テストで利用できる実行可能な仕様になっていなければならない。テストの自動化は、常に高い品質を確保するために実施するのだ。

プロセスは視覚化することで理解できるようになる。進捗やボトルネックもわかるようになる。氏はFordのAlan Mulally氏の例を挙げる。Alan Mulally氏によれば、成功するには、数値上の目的に対して幹部に責任を負わせるのではなくて、チームで働くことが重要だ。氏はFordのビジョンを決め、経営幹部が気付きを得られるようにした。情報センターを設置し、チェートが表示される大きな部屋を作り、週次で幹部ミーティングを行い、チームとして問題を議論し対処するようにした。大きな絵を見ることができるようになったので、幹部たちは効果的なアクションを素早く実行するようになった。

単純化に対しては抵抗するべきだ、とMary氏は言う。全世代のソフトウエア開発では、ウォーターフォールやVモデルというような開発ライフサイクルが使われたが、過度に単純化をしすぎて、何か起きているのか理解できない。現在のアジャイルやリーンの手法でも同じだ。氏は次世代のソフトウエア開発は継続的デリバリに基づくだろうと考えている。

Mary氏によれば、継続的デリバリは受け入れテスト駆動のプロセスであり、ビジネスチームと機能横断デリバリチームが一緒に働く。開発は継続的統合のメインラインとして実行される。ソフトウエアは常に運用環境に配置可能で、リリースは常にビジネスの要請に結びついている。

また、専門性に対する敬意として、最も知識がある人々に意思決定を求める。幹部は組織の最下層で問題が解決されるということを認めるべきだ、とMary氏は言う。問題が階層を渡ってくるのを待つのは時間がかかりすぎる。

弾力性のある開発は失敗に執心し、失敗を受け止めることを学ぶのに役に立つ。Mary氏はAmazonがGameDayを使って、失敗への対処方法を学んでいることを例示する。氏は、“つつく”ことを薦める。つまり、小さな変更を行って、そこから学ぶことだ。

弾力性に対するコミットメントは、失敗から学びたいと考えることだ。仮説を定義して、プロセスの問題を学び、テストする必要がある。リーンスタートアップの手法を使って、プロダクトのどの失敗が必要なのかを学ぶことができる。つまり、最初のプロダクトを開発し、仮説を検証して、デプロイをし、顧客が何を欲しがっているを学ぶ。

アイディアを簡単に検証する環境が必要だ。デリバリをする企業はうまくいかない、とMaryは言う。そのような企業は問題解決型の組織に変わる必要がある。インパクト駆動の開発をすることで、製品開発のための意図的なインパクトから逆算して作業することができる。目的に対する優れた理解と解決するべき課題から始める必要がある。

自分自身に問いかけることで望ましいインパクトを理解する必要がある。

a. 潜在的な課題解決のインパクトは誰に影響するか
b. その人たちはどのようにしてインパクトを計測するか
c. そのようなけんかがメトリクスを正しい方向で動かすような結果をもたらすか

変化をプロトタイピングし影響を計測することで実験することをインパクトを生み出すために反復するのがいいだろう。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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でリプライする

ディスカッション

特集コンテンツ一覧

.NETの派生を理解する

Wayne Citrin 2018年7月18日 午前3時44分

ASP.NET Core - シンプルの力

Chris Klug 2018年6月4日 午前3時26分

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT