The High-Velocity Edge - Chapter 5 (3)

The High-Velocity Edge に関する記事一覧は こちら

アメリカ海軍の原子力潜水艦、商用ジェットエンジン開発、ウェブ広告と、それぞれの分野に於ける High-Velocity organization について。

Pratt & Whitney: 新製品の開発のため、ハイスピード、低コストを求める

Pratt & Whitney はジェットエンジンを開発する企業である。ジェットエンジンは、物質工学、燃焼力学、航空力学、制御システムにおいて高い技術力を必要とする。

従来のマーケットでは、一つの仕事において、$1 billion の投資を 4 年費やして行っていた。これにはシンクタンク（検討や方針決定を主とする）アプローチを用いていた。一方、Pratt & Whitney が直面する新しいマーケットにおいては、$300 million の投資額かつ 30 ヶ月の期間という、従来よりも厳しい環境で成果を出す必要があった。この状況下では、シンクタンクアプローチではなく、もっと別の方法が必要であった。

最初は、Pratt & Whitney は複数の部署にまたがる横断チームを設立し、異なる訓練や異なるコンポーネントの開発に協力してあたるというアプローチをとった。しかし、これは不十分であった。既に持っているナレッジを使い続けるというのではなく、役に立つ知識を生み出したり、構築していく必要があったのだ。

これを実現するために、Pratt & Whitney は Engineering Standard Work (ESW) を推進していった。ESW は、

• 社員が仕事を始める際、組織全体が積み重ねてきた経験を上手く取り出す事ができるようにする
• 組織全体が積み重ねてきた経験に対して何か誤りがあった場合、新しい知見を直ちに反映できるようにする

という理念を根幹としている。また、具体的なアプローチのため、次のツールを用いている。

• workflow map（関係性）
  • 設計段階において、そのステップがどのシーケンスに起因して発生しているか、また独立した部分は何かを明確にする
• design criteria（仕様）
  • それぞれのステップにおいて、依存するステップを満足させる要件が何かを明確にする
• activity page（アプローチ）
  • 担当者は、案件を成功に導くため、その時点でベストな方法を公開する
  • その方法はツールや理論を用いて「どのようにな方法で」「どのような時に」「何故」を明示して説明する必要がある

これにより、知識を収集、シェアし、構築していくことができる。

一つの心配として、「もし自分の持つ知識やスキルを公開してしまうと、人々が実力を熟練させるための時間が実際のところ激減してしまうのではないか」というものが挙げられるが、これに対して ESW は、「制御された慣例の下であなたはイノベートさせるチャンスを与えられている。これによりあなたは、製造工程に余計なリスクを取り入れる心配がなくなる」と説明している。標準化は、「イノベートが必要な領域」と「イノベートさせる必要がない領域」を明確に区別する事ができるのだ。これにより、余計な領域に余計なリソースを注ぐことなく、必要なところに集中させることが出来る。

Avenue A: 混沌からしゃかりきになる

Avenue A は Web-based marketing のパイオニアである。

サービスとしては、概ね以下のようなものとなる。

• Design: インターネットベースの広告展開に関する計画や、広告欄の買い付けを行っている
• Implimentation: 広告を実現するための技術提供を行っており、自社でサーバや設備を有している
• Optimization: 広告分析に関するデータを収集し、広告の最適化を行っている

ドットコムバブル崩壊後も、Avenue A は成長を続けてきた。成長の中で社員は増えていき、それぞれのステップにおいても多くの担当者が関係するようになってきた。そういった中で、問題も起こるようになってきた。

デザインフェーズを例に見てみる。キャンペーンの展開やテーマの開発のためには、どのような広告タイプがどのようなサイトで利用できるか、また、どのようなタイプの広告が有効であるかといったサーベイを行う。これら事項が顧客に提案し承認を受けてから、出版社（広告スペースの提供者）と広告費といった詳細な交渉が行われる。

出版社や広告オプションの数が増え、複雑になるほど、これらの調整をすることは難しくなってくる。次第に、それぞれの要件について依存関係が複雑になっていき、その結果として遅延といった問題が生じてくる。

最初の処置としては、ボトルネックとなる業務について人材を投入するという事を行ったが、これは根本的な問題を解決するための方法にならなかった。依然として、広告の内容や出稿先が決まってから「うちではこの広告は扱えない」という事象が発覚し、それを解決するために何度も電話やメールのピンポンが発生する、といった問題が見られた。

そのため、Avenue A は、業務を完遂させるため、全ての業務をマップ化して、キャンペーンの初めから完了までをきちんと動かすようにした。また、それぞれのステップにおいて、そのステップが次のステップに対して何を提供するべきかターゲットを明確にするようにした。

Avenue A は、混沌の中で標準化と自動化に舵をきる事で、High-Velocity organization, すなわち、複雑なオペレーションを通して複雑なサービスを常に高い品質で提供することの出来る企業になったのだ。

The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition

The High-Velocity Edge - Chapter 5 (2)

The High-Velocity Edge に関する記事一覧は こちら

アメリカ海軍の原子力潜水艦、商用ジェットエンジン開発、ウェブ広告と、それぞれの分野に於ける High-Velocity organization について。

Capability 3: 組織全体に学んだことを広げていく

High-Velocity organization において、人々は自分自身だけで学ぶことはせず、むしろ彼らの同僚と共に学んでいく。個人の経験が、多くの人びとの専門性に寄与していくのだ。

アメリカ海軍では、新しい乗組員が入ると、まず次のことを学ぶ。

• 船の設計や、その船を運用する上での手順
• 問題を明確化させるトレーニング
• 問題を解決するためのルーティンに関するトレーニング

これにより、アメリカ海軍では、海軍全体に波及するような経験を生み出す事ができる。

また、改善のルーティンは、close loop になっていて、具体的なサイクルとしては

1. 現場の経験を積んでいく
2. 経験から lesson を受ける
3. 根本的な問題解決にあたり必要な技術を定義する
4. 新しい設計、スペックに反映させる
5. 運用させ、現場の経験を積んでいく

というようになっている。

Capability4: 改善のサイクルを循環させる

リーダーに求められるものは何だろうか？

通常の組織であれば、

• ゴールをセットすること
• 限られたリソースを下に決断をしていくこと
• 個々の状況において、メンバーの温度感を合わせていくこと

といったところであろう。

高いパフォーマンスを発揮できる組織では、リーダーは、「何をやったか」だけではなく「どのようにそれらをやったか」についても責任を求められる。もう少し言えば、「ゴールやリソースを設定する」だけではなく、「企業における（業務）プロセスやシステムを形作る」ことで成果を挙げる、ということになる。

NR Program では、リーダーの役割として、"learner-in-chief" を定義している。これは、自身の learning だけではなく、他人の laerning についても責任を持つということになる。

こういった機能があることにより、メンバーは常に学び続ける体質となり、その結果として最初に挙げた "discipline of engineering" が推進させる事になる。

（つづく）

The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition

The High-Velocity Edge - Chapter 5 (1)

The High-Velocity Edge に関する記事一覧は こちら

アメリカ海軍の原子力潜水艦、商用ジェットエンジン開発、ウェブ広告と、それぞれの分野に於ける High-Velocity organization について。

アメリカ海軍の Power Propulsion Program

アメリカ海軍は 200 もの原子力潜水艦、30 に近い原子炉、500 もの炉心を運用してきた。かつて、潜水艦といえばバッテリーの制限を受けていたため、航海距離はせいぜい 20 miles 程度であった。原子炉を搭載することで、これが事実上無限となった。

これを実現するためには高信頼な原子炉を搭載する必要がある。当然、原子力の技術は当時新しいものであったため、原子力を安全に制御する方法もわからない中での文字通り手探りでの発進であった。もう少し言えば、

• 新しい科学を扱う
• 新しい物質を扱う
• 新しい製造システムを構築する
• 何千人ものエンジニアやオペレータを育て上げる

といったたくさんの課題を抱えていた。

当然、これらの課題の中で原子力潜水艦を製造・運用していくため、怪我や事故死といったリスクの中で計画を進めていく事になる。

こうした中で、"Navy's Nuclear Power Propulsion Program" (NR Program) が Hyman Rickover の下でスタートした。

この計画において "discipline of engineering" という考え方が重要となる。これは、

• グループは十分な知識を有していない
• コンスタントに、素早く、経験則だけではなく実験的裏付けに則して知識を習得していく

という基本的な考え方が根底となっている。この考え方の下では、「成功」と「失敗」ではなく、「成功」と「成功のための学び」しかない。すなわち、失敗というものはなく、そこから何かを学び取って成功に繋げるという事が求められている。

Capability 1: ナレッジの収集と問題の可視化

NR Program では「完全ではない、または正確ではない理解の下でプロセスが遂行された」状況をインシデントとみなす。そのため、例えば下記のような事象も「インシデント」とみなされる。

• step 1, 2, 3 は順番に遂行されなければならない
• step 2 の終了を確認するまでに step3 を開始してしまった
• 結果的には問題には発展しなかった

インシデントの分析において重要視されるのは、

• 何が起こったか？
  • 状況、検討、技術面、議論などに誤解がなかったか
• 何故起こったか？
  • 経緯に誤解がなかったか
• どのように改善するか？
  • 誤解を解消するために何をするべきか

であり、特に複雑な状況において、知っていることと起こっていることとの間に大きなギャップがないかどうか、という観点が重要になる。

具体的な例を挙げて考えてみる。防壁の性能が悪かった場合、十分な性能に引き上げるための必要な補充（投資）が必要であり、加えて、付随する工学的なアプローチが求められる。これは、すごく当たり前の事である。では、防壁の性能が想定ないしは要求されているものよりも高かったらどうか。実運用上で考えれば、求められる性能を上回っているのだから問題ないように見える。しかし、設計者が想定している状況と現状が乖離しているという点は事実である。これは、過剰投資という観点でも望ましくないし、「エンジニアが想定しきれていない」すなわち、「何か設計上見落としがある」とも考えられる。すなわち、これらはいずれも「ギャップがある」という観点からインシデントであるとみなされる。

多くの試験を通じて、「悪いところ」から「良いところ」を区別させる、「理解できていないところ」から「理解できたところ」を区別させる。この繰り返しを通じて、ギャップを埋めていく事になる。

Capability2: 知識を構築していき、問題を解決する

High-Velocity organization の特徴として、問題に対して「頻繁に」「深刻に」「訓練的に」取り組むという点が挙げられる。普通の企業では、報告書は求められるものの、それは単純にファイルに閉じられるか、無視されるシロモノである。

キーとなるプロセスは、組織の中で「健全なセルフアセスメントが機能しているか」というところだ。紙ベースに終始するのではなく、単純に士官や徴兵された人たちを苦しめるためのものではなく、各自が能動的にかつ組織に対して効果的な活動とならなければいけない。

この活動のために士官は、船が評価されたタイミングや、全てのカテゴリではないにせよいくつかが上手くいったタイミングで「失敗した部分」や「取るべき適切なアクション」を特記として提出する事が求められてる。単純に「より良くする」であるとか「一所懸命に頑張る」では不十分なのだ。

組織というものは、技術に向かって適合していく必要がある。決して、組織に技術が適合していくということはあり得ないのである。だから、不明な技術があれば、それに寄り添うように組織は歩み寄って行かなければならない。また、より先の発展のためには、「データは決して完全にはならない」という事を肝に命じておく必要がある。特に、複雑な技術によって成立している製品を高い水準で運用するためにはこの考え方が必要不可欠になる。

（つづく）

The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition

考えの変化

今年で twitter を始めて 6 年になる。

twitter は会社入った時に同期がやっていたので、便乗したのが動機だったと思う。最初の何年かは（特に福岡で働いている頃は）些細なコミュニケーションを取るのに便利だったものの、今ではほとんど使っていない。自分の tweet を読み返そうとも思わないし、読み返したところであまり響いてくるものはなさそうだ。そもそも 14000 post もの中からマトモなものを探す気すら起きない。

Facebook もほとんど投稿しなくなったし、最近では他の人の投稿もほとんど読まない。友人が押した「いいね！」のお陰で、見ず知らずの人の投稿がどんどんタイムラインに飛び込んでくるのが非常に辛い。友達の友達は友達ではなく、どうでもいい人だということを再認識させられる。私のような人には　Facebook は合わないのだろう。Facebook も twitter と同じく自分の投稿を読み返す感じにはならない。記事のどうでも良さという意味では、twitter よりもどうでも良いといえる。

6 年変わって何が変わったのかと考えてみると、Web に承認欲求を求めなくなったというのと、Web に関してほとんど見切りをつけたということなのかもしれない。前者は、おそらく仕事を通して人と関わる中でもうお腹いっぱいになっているのだろう。後者も、結局 Web というのは媒体に過ぎず、それを通して何をやったとしても緩くやっている限りは何も生み出さないという事を悟ったのだろう。これも、「それだったらきちんと働いて成果を出した方がまだ世の中の為になる」という考えが元になっている。

振り返ってみると、仕事というのは自分の価値観形成に大きく影響を与えているのではないかとちょっと恐ろしくなってきた。まぁ、月に 20 日以上は会社で働いているのだから、どうあがいても自分の人生の軸に仕事というものが刺さってくるのは避けようがない。

ちなみに、blog についてはその時期の自分の考えを記録しておくという意味で役に立っている。これは、誰かに見てもらいたいというのも少なからずあるけれど、未来の自分に見てもらいたいというところが大きい。だったら公開しなくても良いじゃんっていう矛盾もあるけれど。

何のために勉強をするかと考える事自体が間違いなのではないか

今の部署に異動してからの大体 2 年半で、資格の勉強を細々と続けている。

内容としては、応用情報処理技術者、ネットワークスペシャリスト、セキュリティスペシャリストと、いわゆる情報処理技術者試験。あとは TOEIC. コツコツやれば案外合格できるし、TOEIC もなんだかんだでピークの時より 100 点ほど伸びたのでそれなりに進歩しているのではないかと思う。

元々は、業務分掌が大きく変わったというところがあって、乏しい知識を埋めるという目的で始めたが、ネットワークスペシャリストを取った辺りでもうあまり目的というものは無くなってきている。セキュリティスペシャリストで勉強した知識が業務に直結するかというとそういうわけでもないし、そもそもの話として応用情報やネットワークスペシャリストの知識が無くても仕事はできたりする。英語も全く使わないし。

しかし、よくよく考えてみると、「＊＊のために勉強する」というのは合理的なようであるけれど、動機としては低俗なようにも思える。「社会で役に立たないのに数学をやるんですか？」というのとレベルとしては同じだ。仕事をしていると自由な時間も限られてくるので、なるべくフォーカスしている分野を外れないように効果的に物事を積み上げていくというのは一理ある。ただ、高い山は麓が広いように、広い知識や考え方があってこそ、高次な技術が養われる（と、大学の時に先生から何度も言われた）。

最近は別に高次な技術を養うためとかそういう目的もなく、ただ勉強するだけという事もある。「モテたくて楽器を始めたけれど、実際にはモテなかったし、音を出している瞬間が楽しいから続けていられる」という状況に近い。

新入社員

一週間ほど前に新入社員が配属されたので、今日は 2 時間ほどアラーム対応のトレーニングを行った。

「まずアラームが出たら何する？」と聞いてみたら「アラームに紐づくマニュアルを確認します」という回答が来たので、これはまずいと思い、切り分けのトレーニングをすることにした。

内容は、80 件くらいのアラームのどさっと提示して、何が原因でアラームが出ているか切り分けをしてもらうというもの。前提として、一つの障害が原因でこれだけのアラームが出ているということだけは伝えて、トレーニングスタート。

一つ一つ指示を出すのではなく、どうやったら正解（被疑箇所）にたどり着くことが出来るか、大まかな方針を立ててもらいつつ進めてもらう事にした。すると彼らは、複数のサーバから同じ種類のアラーム（ネットワークインタフェースのダウン）が多数出ている事に目をつけ、切り分けを開始していった。根拠としては、「一つの障害が起因となってたくさんのアラームが出ているのであれば、たくさん出ているアラームは被疑箇所に近いのではないか？」「仮に被疑箇所ではなかったとしても、そこからたどる事で特定するための糸口がつかめるのではないか？」という事だった。ちなみに、それらが「（ネットワーク機器ではなくて）サーバ」であると判断した理由は「アラーム文字列の中に kernel という単語が含まれているから」だそうだ。

実際には複数のサーバは被疑ではなかった（正常性の確認をとると、異常は見られない）ものの、これでサーバについては異常がないという切り分けができた。

まだ被疑箇所は特定できていないので、次のアクションを考えてもらうと「サーバのネットワークインタフェースに繋がっている先のスイッチが被疑ではないか？」という仮説が出た。ではそれをどのように確認したらよいか聞くと「ネットワークの構成図を見れば良い」との回答。

ネットワーク構成図を見ると、確かに複数のサーバと、それが持つインタフェースカードの識別子、そして繋がっている先のレイヤ 2 スイッチのノード名が確認できる。そして、アラームとして出ているインタフェースカードの識別子の先は、全て同じレイヤ 2 スイッチであった。これで、被疑のスイッチが特定できたことになる。

次に何をするか聞いたところ「被疑のスイッチから何かアラームが出ていないか確認する」とのこと。確かに、アラームが出ていなければ被疑箇所としての論拠は薄い。実際にアラームを確認してみると、被疑箇所からきちんとアラームが出ている。2 件ほど。

しかし、今までの切り分けで、それら 2 件のアラームが本質であるという確信が新入社員の中には確かに出ていた。

ということで、新入社員には「やり方を教える」のではなく、「調べる事や考える事を習慣づけさせる」事を徹底した方が良いのではないかという結論に至った。だって考えればできちゃうんだもの。もちろん、調べ方や考え方について適切な助言は必要だと思う。

新入社員すごいなーと思ったけど、よくよく考えたらこれくらい普通に出来てもらわないと困るというか、普段から当たり前の事を普通に出来る人と接する機会が少ないというか、ちょっと複雑な気分である。

あまり関係ない人のはなしも聞いてみよう

先日、同じ部署の他グループから立て続けに些末な依頼（お願い）がやってきた時があった。

声を掛けやすいとか、過去もあまり断ったりしてないとか、いろいろと背景はあるのだろう。が、一つとしては普段から仕事の話を雑談レベルでしているというのもあったのかなとふと思った。

Web のどこかでみた記事によると（出典忘れた）、初めて会った人から受注をもらうには、自分の出来ることを提案するというのはダメだと。まずは相手の話を聞いて、その人がどういう状況にあるか、どんな問題を抱えているかを把握する。そして、把握している（ないしはしようとしている）のを相手に認識してもらうのが大切とのこと。

これは要するに、依頼する側からしたら、自分たちの状況をキチンと把握できていない人には、お願いなんてリスクがあって出来ない、という習慣だろう。

リスクをとりたくない人は、何故やる必要があるか、どのようにやればよいと考えているか、場合によっては何故その人にお願いしているかを説明する。それは、案外時間もかかるし労力もかかる。

逆に、そういうことを既に断片でも、頭だけでも知っている人がいるなら、その人にお願いした方が効率的だし確実かもしれない。概ね、そういう思考パターンは誰しもあるのではないか。

断片でも頭でも触りでも何でもよいから、まずは相手が何をやっているか、やりたいかを把握しようとするのは凄く重要なのかもしれない。仕事は、誰かにアウトプットするものだから、誰かの益にならないと意味がない。それはすなわち、益を与えたい人のバックグラウンドを理解できないと高いレベルて遂行できない。

ともすれば、アウトプットを出すためには、自分が相手の役に立つかどうかに関わらず、まずは相手の考えにアンテナを日頃から立てておくべきだ。