IT企業管理：理論を実践から破る

練習は、すべてが機能するときですが、誰もその方法を理解していません。 理論は何も機能しないときですが、誰もがその理由を正確に知っています。 しかし、私たちは理論と実践の組み合わせに到達しました。何も機能せず、誰も理由を理解していません。



ITだけでなく、他の分野でも成長しているビジネスの機能において、遠い隅に捨てられ、すでに高貴な緑青に覆われている問題を無視することが不可能な時が来ます。 その結果は、最も予期しない状況で感じられます。 問題に対処してビジネスを機能させるには、12を超える手法がありますが、常に同じことから始める必要があります。これらの同じ問題の根本原因の分析です。 そして今日、Robotsはこれについて話します-アジャイル、スクラム、およびカンバンHenrik KnibergのITビジネスコーチおよびスペシャリストの根本原因を見つけることに関する記事を翻訳するだけでなく、Robotsが自身の失敗のいくつかを修正する方法についても。











ヘンリック・ニバーグ。 記事の目的



原因結果図は、根本原因分析を実行するためのシンプルで便利な方法です。 私はこれらのチャートを長年使用しており、企業が技術的および組織的な幅広い問題を認識して解決するのを支援しています。 この記事の目的は、因果関係図がどのように機能するかを示し、読者に必要に応じてそれらを作成する方法を教えることです。



症状ではなく問題のトラブルシューティング



効果的な問題解決の鍵は、何よりもまず、解決しようとしている問題を理解することです。 なぜ解決策が必要なのか、いつ解決されるのかを判断する方法、およびこの問題の根本原因は何か。

多くの場合、「症状」は1つの場所に表示されますが、問題の本当の原因はまったく別の場所にあります。 状況をより深く評価しようとせずに単純に症状に対処する場合、問題は後で明らかになりますが、別の形で起こります。



問題：寝室の煙。

悪い決断：窓を開けて、再び寝ます。

良い解決策：煙の発生源を見つけて対処してください。 おっと！ そして、地下に火があります！ さらなるアクション-火を消します。 それが現れた理由を理解するために; 火災警報器を設定して、次回問題を早期に学習できるようにします。



問題：おでこ、疲労。

悪い決断：額に氷を入れて冷やします。 エネルギーのために砂糖を食べる。 仕事を続けます。

適切なソリューション：温度を測定します。 はい、熱があります！ さらなる行動は、家に帰って休むことです。



問題：サーバーのメモリリーク。

悪い決断：メモリを購入する。

良い解決策：メモリリークの原因を見つけて修復します。 将来のリークを避けるためにテストしてください。



...など。



組織の問題のほとんどは体系的です。 システム（ビジネス）に障害が発生したため、障害を修正する必要があります。 この失敗の根本原因が明らかになるまで、問題に対処するほとんどの試みは効果がなく、逆効果にさえなります。



A3形式での思考と問題解決への無駄のないアプローチ



無駄のない思考の基本原則の1つは、改善-継続的なプロセス改善です。 世界で最も成功している企業の1つであるトヨタは、成功のかなりの部分を、問題解決へのアプローチにおける高い規律と関連付けています。 このアプローチは「A3形式で考える」と呼ばれることもあります（問題解決に関する各「セッション」で得られた知識はシートA3に記録されます）。



以下に例とテンプレートを示します。

www.crisp.se/gratis-material-och-guider/a3-template





「A3アプローチ」では、時間の大部分（シートの左側）が問題の根本原因の分析の分析と視覚化に費やされ、 ソリューションの開発に先行します 。 根本原因分析の方法は、原因図と結果図だけではありません。 他にもあります。たとえば、 バリューストリームマッピングの体系化と 石川図、または魚骨の図とも呼ばれる図の作成です。 上記のサンプルA3には、値ストリームマップ（左上）と因果チャート（左下）が含まれています。

原因図と結果図は、直感的に理解でき、追加の説明が不要なため（特に魚骨図と比較して）優れています。 別の利点は、繰り返される悪質なサイクルを説明できることです。これは、体系的思考の観点から非常に便利です。 次に、このような図を効果的に作成および使用する方法について説明します。



原因図と結果図の使用方法



基本的なプロセスは次のとおりです。

1. 問題（あなたを悩ますもの）を選んで、それを書き留めてください。
2. 「上方への動き」を追跡して、ビジネスへの影響、問題が引き起こしている「明らかな損害」を評価します。
3. 彼女の「下向きの動き」を追跡して、根本原因（または根本原因）を特定します。
4. 悪循環を定義し、強調します。
5. 上記の手順を数回繰り返して、チャートを調整します。
6. どの根本原因を決定するか、どの方法を実行するか（どのような対策をとるか）を決定します。

次のステップはフォローアップです。 対策が機能する場合、おめでとうございます！ そうでない場合は、絶望しないでください。 それらが機能しなかった理由を分析し、知識に合わせて調整されたチャートを更新し、他の対策を試してください。

本質的に、対策は解決策ではなく、実験です。 あなたの仮説は、対策が問題を解決（または最小化）するということですが、完全に確信することはできません。 実際、システムに「鋭利な棒を刺して」、反応を確認します。 したがって、フォローアップが重要です。

実際、ミスとは、システムがあなたに耳を傾ける価値のある信号を送信することを意味します。 唯一の本当の間違いは、間違いから学ぶことができないことです！



例1：ペアプログラミングの欠如



あるクライアントは、彼のビジネスがペアプログラミングとテストによる開発（TDD）のようなXPのトリックを使用していない理由を見つけるのを手伝うように頼みました。 「私たちはこれをしなければならないことを知っていますが、しません」とクライアントは言いました。







TDDとペアプログラミングの欠如は本当の問題ですか？ いつものように、しばしば私たちが問題と呼ぶものはそうではなく、単に症状です。



Q：ペアプログラミングとTDDを無視すると、どのような結果になりますか？

A：これらのプラクティスを使用すると、コードの品質が向上すると考えています。

Q：コードの品質が悪いとどうなりますか？ 品質の低いコードが原因で実際​​に問題が発生しましたか？

A：はい、デモが飛び出しました。 デモはビジネスの重要な要素であるため、これは本当の問題です。







さて、要素の1つを検討し、「基盤」とのつながりを構築できるかどうかを確認してください。



Q：ペアプログラミングを練習してみませんか？

A：多くの人がそれが機能しないことを恐れており、時間を無駄にしているからです。 動作するという証拠はありません。

Q：どのような証拠が必要ですか？

A：まあ、私たちはそれが効果的であることを示す研究を見てきました。 しかし、当社では実際にそのようなプラクティスを実装しようとした人はいないため、成功するかどうかはわかりません。



最初のループは次のとおりです。







彼らはうまくいくかどうかわからないので、彼らは新しいプラクティスを導入したくありません。 そして、彼らはそれらを実装しようとしなかったので、彼らが働くかどうかわからない...



Q：なぜペアプログラミングを実験として使用しようとしなかったのですか？

A：実験の時間はありません。

Q：なぜですか？

A：一時的な準備金がないためです。 1時間ごとに責任があります。 そして、顧客は私たちに仕事を殺到させ続けています。

Q：なぜ顧客は自分の時間を独立して管理する機会をあなたに与えず、いつでも都合の良いときに仕事であなたを積み重ねることができると考えていますか？

A：彼らは私たちに独立して時間を割り当てることを信頼していません。



信頼の欠如は、一般に失敗の恐れにもつながります。これは、もちろん、動作することを保証することなく、ペアプログラミングなどの新しい手法を実験的に使用する可能性を減らします。







2つのグローバルな根本原因があることがわかります。信頼の欠如と、1時間ごとの会計処理に対する経営者の態度です。 全体像に戻りましょう。







クライアントと顧客の間の信頼の欠如が、TDDやペアプログラミングなどのXPプラクティスが実装されなかった主な理由でした。 これは、デモが飛び出すために品質が低下します。 そして、あなたは推測することはありません：飛行デモは相互信頼をさらに低下させます。 これは悪循環です！



興味深いことに、この分析は約25人の2日間のワークショップで実施しました。 最初は、主に技術的なこと-TDDとペアプログラミングの開始方法について話しました。 このアプローチは特に効果的ではありませんでしたが、代わりにグループに分割し、各グループが独自の問題を選択し、因果関係図を作成し、シートA3で問題の解決策を策定することを決定しました。 興味深いことに、さまざまな問題を一見して分析したいくつかのグループは、同じ根本原因である信頼の欠如に至りました。 上記のチャートは、これを示す一例です。



したがって、マスタークラスの終わりまでには、クライアントと開発者の間の信頼度をどのように高めるかについての会話が既に行われていました。 予期せぬワークショップターンでした。 そもそも、次回は「彼ら」（顧客）をワークショップに招待することで合意しました。これにより、反対派「私たち」と「彼ら」の頻度が減るはずです。



例2：長いリリースサイクル



問題があるとしましょう：期限を常に守っています。 より正確には、私たちのリリースは常に計画よりも遅れてリリースされます。







問題は、目標を達成できない場合にのみ問題になります。 したがって、まず、目標を決定し、目標のコンテキストで直接問題の結果を考える価値があります。 これは、「だから何？」という質問に役立ちます。明らかな損傷を特定できるようになるまで、これを尋ねなければなりません。

目標は、顧客を満足させ、最大の収入を得ることです。 ダイアログは次のようになります。



Q：「リリースが遅れると、どのような悪影響がありますか？ 結果はどうなるのでしょうか？」

A：「遅延によりリリースサイクルが長くなります」

Q：「だから何？」

A：「これは収入の受け取りを遅らせ、会社のお金の速度に悪影響を及ぼします。 また、これが原因で顧客がいらいらしているため、顧客を失います。」



対話プロセスでは、セルと因果矢印をチャートに追加します。 通常、最初に述べた問題から「上流」に移動し、その結果を「マッピング」しようとします。 しかし、これは厳密な規則ではありません。







つまり、リリースの遅延は実際には問題ではないことがわかります。 本当の問題は、収益の遅れと顧客の損失です。 この段階では、次の3つの点を考慮する必要があります。



顧客の損失と収益の遅延につながる他の要因はありますか？ もしそうなら、すべての解放が責任であると仮定することは可能ですか、それとも何か他のものに注意を向けるべきですか？ 問題を定量化できますか？ どれくらいのお金を失いましたか？ 何人の顧客がかかりましたか？ これらのデータは、示された問題を解決する上で正当な努力の量を評価するのに役立ちます。

問題を解決したことをどのように理解しますか？ 幸せなコンサルタントがオフィスに飛び込み、誇らしげに「問題を解決した！」と宣言したとします。 これがブラフではないと判断する方法は？

問題の結果を分析した後、根本的な原因を深く掘り下げます。

そして、「なぜ」という質問が助けになります。 はい、リーン思考を勉強している場合に聞くことができる「5つの理由」テクニックがあります。



Q：「なぜリリースが遅れるのですか？」

A：「作業量が増えているためです。」

Q：「なぜ？」

A：「顧客はますます多くの機能を発明しており、現在のリリースに追加する必要があると主張しているため、優先度の低い機能を除外することを拒否しています。」

Q：「なぜ？ 新機能への新機能の追加を延期しないのはなぜですか？」

A：「リリースサイクルが非常に長いため、次のリリースまでに新しい要件が発生するため」



これまでのところ、「理由」は3つしかありません。 しかし、あなたは原理を理解しました。 このダイアログでは、次の図を作成できます。







悪循環は赤い矢印でマークされています。 繰り返し発生する問題には、ほとんどの場合、このような「ループ」が含まれますが、それらを特定するには時間がかかります。 このようなループが見つかった場合、問題を解決でき、取り消せない解決策が見つかる可能性が大幅に高まります。

私たちの目標は、最小限の労力で最大の効果を達成できるように、この問題の根本原因を特定することです。 最初の段階では、重要な理由を簡単に見落とす可能性があるため、戻っていくつかの質問をしてみましょう。



Q：「なぜリリースサイクルが長いのですか？ リリースの遅延が唯一の理由ですか？」

A：「実は、遅滞なく、計画されたリリースサイクルは十分に長いです。」

Q：「計画されているリリースサイクルはどれくらいですか？」

A：「四半期に一度」。

Q.「しかし、なぜそんなに長いのですか？」

A：「リリースは高価で複雑だからです。」

Q：「なぜ？」

A：「すべてのリリースには多くの詳細が含まれているため、また手作業であるためです。」







左側には、別の悪循環（赤い矢印）があります！ リリース間隔が長いということは、新しいバージョンごとに多数の更新が含まれるため、製品のリリースが複雑で費用のかかるプロセスになることを意味します。 このため、リリースを頻繁に行いたくありません。

お気づきのように、ここで2つの根本原因に注目することにしました。 そして今-対策：



根本原因

リリース準備中の自動化の欠如

対策

リリース準備の自動化



根本原因

低優先度機能はリリースから除外されません

対策

同じ数の優先度の低い機能がリリースから除外された場合にのみ、新しい機能をリリースに追加できることにクライアントに同意します。



どのような理由が根本原因であるかを示す厳密な規則はありませんが、いくつかの兆候があります。

• セルには外向きの矢印しかありませんが、外向きの矢印はありません
• これからは、掘り下げて（「なぜ？」を追加して）意味がないと感じる
• セルは「解決策を持っている」ため、問題に大きなプラスの影響を与える可能性があります。

「5つの理由」のテクニックはそう呼ばれます。なぜなら、通常5つの質問が根本原因から私たちを分離するからです。 途中で停止する傾向があります。 これをする必要はありません。掘り続けてください！

最初に提起された問題-リリースの遅延-は、実際には問題ではなく、根本原因ではないことを考慮する必要があります。 それは単なる症状でした。 昇順で因果関係を構築して真の問題を特定し、降順で根本原因を特定するための言い訳として使用しました。 これにより、問題に関するすべての知識を備えた効果的な対策を開発できます。

このタイプの分析がなければ、性急な結論に達し、非効率的で非生産的な変更を加えるリスクがあります。 たとえば、追加の従業員を雇用することにより、問題の本質は労働量にあるわけではありません。 または、インセンティブシステムを変更することによって（時間通りに仕事をするように人々を奨励し、後の仕事を罰することによって）、既存のインセンティブシステムは問題とは何の関係もありませんでした。



例3：生産サイクルの欠陥



実稼働環境で実行される欠陥コードに問題があると想像してください。







Q：そして何？

A：欠陥が原因でお客様は怒ります







Q：本番環境で欠陥がトリガーされるのはなぜですか？

A：リリース前に必要なテストに合格しなかったためです。

Q：なぜテストがなかったのですか？

等



そして、ここに私たちが得るものがあります：







2つの悪循環！ 赤い矢印を見てください。

ループ1（内部ループ）：製品の欠陥により、緊急の変更が必要になり、チームの作業が妨げられます。 従業員は大部分のタスクから解放されないため、ストレスがかかり、新しいリリースを適切にテストする時間がありません。 もちろん、これは生産全体のレベルでさらに多くの欠陥をもたらします。

ループ2（外部ループ）：従業員はストレスを受けているため、自動テストスクリプトを作成する時間もありません。 その結果、テストの自動化が全般的に不足し、新しいリリースの回帰テストがますます複雑になります。 これは、もちろん、生産上の欠陥と緊急の変更を行う必要性につながります。 そして結果として-さらにストレスに。



しかし、それだけではありません！



チームは気が散ることを嫌います。 作業のプロセスは動機を混乱させ、最終的にはやる気をなくします。 これは、高い離職率の説明かもしれません！ したがって、根本的な問題（生産の欠陥）を解決すると、スタッフの離職を減らすという形で追加のボーナスが得られます。







これは、原因と結果の分析のもう1つの利点です。 通常、根本原因は複数の問題の原因です（これが「ルート」と呼ばれる理由です-メインまたはルート）。



因果分析：ロボットエクスペリエンス



プロジェクトマネージャー、Boris Ryabchikov氏：

私の仕事は、会社に存在する問題を追跡することでした。 主な生産上の問題を事前に概説しました。 仮説は次のとおりでした。私たちはプロジェクトを期日通りに納品せず、その結果、会社は低金利です。 当初はいくつかの理由も除外されていました。計画が正しく実行され、問題が他のどこかにあると想定しました。 残りの問題はこのプリズムを通じて検討され、トピックに関係のないものはすべて捨てられました。 主な問題に対処したいと考え、これに基づいてマップを作成しました。

生産プロセスはグラフィカルに示されました。つまり、私たちはどこにいて、どこで時間とお金を失うのか。

まず、情報源を選択する必要がありました。 実際には、最も効果的な方法は、各従業員に個別に問題を収集することであることが判明しました。 レトロスペクティブおよび標準レポートでは、通常、従業員はすでにチーム全体-上司との総会で発言しているように見えます。 会社に複数の部門がある場合、それらはしばしば互いに競合し、互いに問題を「投げる」。 すべての従業員が集まると、通常、品位は優勢になり、誰も顔を非難しません。 つまり、問題を静めることができます。 個別のインタビューで、彼らは表面に現れます。

私は非公式の環境で人々と通信しなければなりませんでした-喫煙室で、地下鉄のために高価です。 そのような会話では、いくつかの問題が正確に定式化されました。 結局のところ、「ファイブホワイメソッド」は実際には必ずしもうまく機能するとは限りません。 多くの場合、人々は多数の「理由」に神経質になり、一部の人々はすぐに保護を取り入れます。 つまり、それぞれの場合に、個別のアプローチが必要です。

得られたデータは徐々に収集され、ダイアグラムに入力されましたが、非常に大きいことが判明しました。 分析の結果に基づいて、4つの根本原因と1つの主な問題が特定された短いレポートを作成しました。 それらはすべて、会社のコンピテンスセンターによってグループ化されました。

彼らは同時にいくつかの根本的な原因で働き始めました。 このアプローチでは、どの根本原因が主な原因であるかを理解できないリスクがあります。 しかし、この場合、彼は正当化されます。

根本原因を除去するための対策が開発され、それらの除去の成功の基準が特定されました。 次のステップは、中間結果の分析と新しい調整済みレポートの準備です。 多くの場合、問題の最終的な解決策はかなり長いプロセスになります。

例4：たくさんの問題



そして、これはより大きな例です。 組織はスクラム方法論を使用しましたが、いくつかの問題に遭遇しました。 いくつかのインタビューとワークショップの結果として、チームが実際にスクラムを誤って使用し、問題を引き起こしたことを示す因果図が生まれました。







スクラムを正しく使用することで、多くの根本原因を排除できることが誰にでも明らかになりました（たとえば、機能横断型チームへの再編成、各チームには製品所有者がいるという信念）。 これは組織変更の推進力となり、最終的に多くの根本原因（緑の星）を排除しました。 次のステップは、テストの自動化を改善することでした。



もちろん、スクラムは万能薬ではありません。 実際、スクラム自体が問題である場合があり、解決するにはカンバンなどの他の手法が必要です。



実用的な問題-チャートを作成および管理する方法



一人で働く

単独で図を作成する場合、最も便利なツールはVisioまたはPowerpointのようです。 画像の操作中に、アイテムをすばやく移動したり、セルのサイズを変更したり、すばやくバックアップしたりできます。



小グループ（2〜8人）で作業する

ボードまたはフリップチャートの周りに集まります。 セルの代わりに、ステッカーを使用して、手描きの矢印で接続します。 ステッカーが移動すると、ボード上の矢印を消去して再描画できるため、ボードが望ましいです。 1人だけでなく、グループのすべてのメンバーが参加できるようにします。 何が起こったのか明確な写真を撮ることを忘れず、会議後にすべての参加者に送信することが重要です。



大きなグループ（9〜30人）で作業する

グループのメンバーを小さなチームに分けて、それぞれが特定の問題に焦点を当てるようにします。 同じ問題について複数のチームと協力することは有用です。同じ結論または異なる結論に達することができ、両方の結果が興味深いものになります。 各チームは、別々のフリップチャート/ボードとステッカーを使用します。 定期的に、短い共同討論のためにチームが集まり、経験を共有する必要があります。



パースペクティブでチャートを操作する

チャートは、使用したプログラム（VisioまたはPowerpoint）のままにしておきます。 ワークショップの一環として再びそれに戻ることに決めた場合、その目的を決定します：チャートの実演または更新。 これが更新である場合、ワークショップの参加者がチャートで効果的に協力できるように、ステッカーと矢印の助けを借りてボード/フリップチャートで繰り返します。 会議後、結果を電子ツールと「同期」します。

このタイプの同期には時間がかかりますが、それだけの価値がある場合がよくあります。 コラボレーションの場合、実際のツールを超えるものはありません。ボードとステッカーです。



危険



矢印とセルが多すぎる

ダイアグラムが非常に混becomesになり、作成することが不可能になることがあります。 次に、単純化する必要があります。 ここにいくつかのテクニックがあります：

• (, ).
• “ ” “ ”. , , .
• . . “ , ”, .
• , : .
• , 3 .

シンプルさ

これは、単純化されたタイプの因果関係図です。これは、特に意図されたものです。個人的なやり取りに代わるものではありません。より高度なまたは形式化された手法が必要な場合は、システム思考に関する文献を参照してください。たとえば、Peter Sengeの「The Fifth Discipline」。しかし、留意してください。「完璧な」図であっても、理学博士だけが理解できるのであれば特別な価値はありません。



パーソナリティへの切り替え

このタイプの個人的な告発は避けてください。







問題は、すべて体系的であるという事実に基づいて、最も効果的な方法で解決されます。もちろん、不器用な人もいます。しかし、これが私たちに大きな不便を与えたとしても、問題はまだ体系的です性格：不器用な人がそのように見なされないシステム、または内部にひどく不器用な人を入れるシステムがありますが、不器用になるのを助けません。強調する必要があります：すべての問題を全身として扱います。