なぜなぜ分析は「それは問題か？」で視点を切り替える
■よく出会うなぜなぜ分析の結果
大企業でプロセス改善のサポートをしていると
ふりかえりの効果を感じない。
Ploblemに対するTryは出てくるが、やることが増えているだけで、改善していない気がする。
と相談を受けることがあります。
効果が大きそうなProblemに絞って、なぜなぜ分析をしている。
と言うので見せてもらうと、こんなパターンが多い印象です。
●1システムを担当する部署内で実施した なぜなぜ分析の例
Problem: リリースまでに時間がかかった
1 資材の差分確認に時間がかかるから
1.1 差分が多かったから
1.1-OK: 案件の規模に応じた差分は発生する
1.2 開発チームとの問い合わせに時間がかかったから
1.2.1 差分リストをつくり忘れたから
1.2.1-対策: 手順化してチェックリストで確認する
1.2.1.1 複数案件を並行開発しているから
1.2.1.1-OK: ビジネスの状況に応じて複数の施策は並走する
2 ファイルの持ち込みに時間がかかるから
2.1 ファイル転送に時間がかかるから
2.1.1 資材のファイルサイズが大きいから
2.1.1-OK: 大きなシステムだから資材も大きい
2.2 ウイルススキャンに時間がかかるから
2.2-対策: 持ち込み(リリース)する回数を減らす
2.2.1 資材のファイルサイズが大きいから
※前述
2.2-OK: セキュリティ部門のルールで義務付けられている
この対応では
・リリースする頻度を下げる -> 変化を避ける
・チェックリストで確認する -> 価値を生まない作業を増やす
ことで、自分たちの首を絞める結果になっています。
■「それは問題か？」で視点を切り替えるきっかけをつくる
なぜなぜ分析で原因を掘り下げる流れは、虫の目で鮮明にプロセスを捉えなおすものです。この工程は大切ですが、虫の目だけで分析を続けると、真因にたどり着くことも、対応案を発想することもできません。なぜ？を繰り返し、次の原因を考えるときには、鳥の目でどこを掘り下げるのか判断する必要があります。
今の視点が、虫の目か鳥の目かを、意識し続けながら原因を考えることは難しいですね。そんな場合、原因ごとに「それは問題か？」を問いかけることで鳥の目を取り戻すきっかけをつくることができます。
●それは問題か？を適用したなぜなぜ分析の例
Problem:リリースまでに時間がかかった
◯それは問題か？
同規模の案件でもかかる時間が増えてきている
-> 以前の実績との比較からきづいた問題
1 資材の差分確認に時間がかかったから
◯それは問題か？
案件の規模に比例して時間がかかっている
-> 規模に比例しているので、優先度は低い
1.1 差分が多かったから
◯それは問題か？
案件の規模に応じた差分は発生するので、問題ではない
差分抽出はツール化しているが、比較は手動で実施している
1.1.1 なぜ手動で実施しているのか？
1.1.1-傾向: ツール化する時間が取れないから
1.1.1.1 開発チームから渡されるリストのフォーマットが変わるから
1.1.1.1-傾向: 管轄外だから
1.2 問い合わせに時間がかかったから
◯それは問題か？
別チーム、別の場所で作業しているので
問い合わせのやり取りには時間がかかる
1.2.1 なぜ問い合わせる必要があるのか？
1.2.1.1 開発チームしか期待値がわからないから
1.2.1.1-傾向: 管轄外だから
1.2.2 開発チームが用意する差分リストに不足があったから
◯それは問題か？
リリース可否を判定するときの資料なので、誤りは許されない
リリースしたい対応ごとに、担当者が、差分リストを記入している
1.2.2.1 なぜ手動で作成しているのか？
1.2.2.1-傾向: ツール化する時間が取れないから
1.2.2.2 開発チームがつくり忘れたから
◯それは問題か？
リリースしたい対応ごとに、担当者が、差分リストを記入している
※前述
1.2.2.2 複数案件を並行開発しているから
◯それは問題か？
開発チームでのテスト後に、QAチームがテストを行う
QAチームのテストサイクルが長いので、開発チームは先行開発している
1.2.2.2.1 なぜ先行開発しているのか？
1.2.2.2.1-傾向: 管轄外に作業が移ったから、次に備えるため
2 セグメントを越えたファイルの持ち込みに時間がかかるから
◯それは問題か？
リリース作業のボトルネックはここの待ち時間
-> ボトルネックなので、優先度は高い
2.1 ファイル転送に時間がかかるから
◯それは問題か？
セグメントが、開発 / 作業 / 本番で分かれているので必要な作業
開発 -> 作業、作業 -> 本番 に、2回ファイル転送している
2.1.1 作業セグメントを経由する必要があるのか？
2.1.1.1 わからない
2.1.1.1-傾向: 管轄外だから
2.1.1.1-対応: 問い合わせてみたら、不要だった
2.1.2 資材のファイルサイズが大きいから
◯それは問題か？
既存のデプロイツールが、すべてのファイルを含める必要がある
デプロイを簡単にするために、サブシステムをまとめた資材にしている
2.1.2.1 なぜまとめているのか？
2.1.2.1.1 デプロイツールのメンテナンスにコストをかけたくないから
2.1.2.1.1.1 開発チームは機能をつくることが担当だから
2.1.2.1.1.1-傾向: 管轄外だから
2.2 ウィルススキャンに時間が掛かるから
◯それは問題か？
外部から本番環境にウィルスを持ち込まないために必要な作業
QA環境と同じウィルススキャンを、持ち込み時に実施している
2.2.1 QA後の資材に同じウィルススキャンをかける必要があるのか？
2.2.1.1 わからない
2.2.1.1-傾向: 管轄外だから
2.2.1.1-対策: 問い合わせてみたら、不要だった
2.2.2 資材のファイルサイズが大きいから
※前述
「それは問題か？」の回答は、原因の状況に沿って、やりたかったことの目的を軸に、視点を切り替える必要があります。
問題である場合
どこが重要なのかを説明する
問題をうまく表せていない場合
より具体的に、切り分けて説明する
問題でない場合
「では何が問題なのか？」とリフレームを促す
視点を切り替えて問題を分析していくと、自分たちが気にしていないこと、分からないことに気づくきっかけに出会うことがあります。分からないで実施している作業の中には、実は不要だったということもよくあります。
■サイロ化した組織が陥る 時間がないスパイラル
原因を分析していくと、よく行き着く傾向があります。
・自分たちの管轄外だから、分からない
・自分たちの管轄外に作業が渡ったから、次に備えて在庫をつくる
・対策を実施する時間がない
この傾向が出ている場合、時間がないスパイラルに陥っている事が多いようです。
●時間がないスパイラル
・管轄外だから、分からない
-> 分からないから、不要な作業を続けてしまう
-> 不要な作業で時間を使う
・作業が管轄外に渡ったから、次に備えて在庫をつくる
-> 在庫が増えることで、メンテナンス作業が増える
-> 在庫のメンテナンス作業で時間を使う
・時間がないから、変化を避ける
-> 変化を避けることで、対応していない間に状況が悪化
-> 悪化した状況に対応するために、時間を使う
・時間がないから、作業ミスが増える
-> ミスの対策で、価値を生まない作業を増やす
-> 価値を生まない作業のために、時間を使う
・時間がないから、周りの部署にかまっていられない
時間がないスパイラルを抜け出すカギは、なぜなぜ分析で気づいた「不要な作業」と「価値を生まない対策」を廃止することだと考えています。
こんなにシンプルには進みませんが、ボトムアップでのカイゼンサイクルを回していく場合、少しできた時間を使って、こんな進め方もできるのではないでしょうか？
1. 不要な作業と価値を生まない対策を廃止して、時間をつくる
2. つくった時間で、前後の作業を担当する組織の状況を知る
3. 広がった状況の分かる範囲で、協調作業で対策を実施する
4. 協調作業の輪を広げる
●1. 不要な作業と価値を生まない対策を廃止して、時間をつくる
日々こなしている多数の作業に比べると、インパクトは小さいですが、ここで生まれた少しの時間を使ってカイゼンのサイクルにつなげていきます。
●2. つくった時間で、前後の作業を担当する組織の状況を知る
少しできた時間を使って、前後の作業を担当している、隣の部署を知り、状況を共有していきます。隣の部署の状況が分かるようになると、より長いスパンで案件の進行状況を捉えられるので、抱える在庫の考え方を変えることができます。
仕掛中の案件をメンテナンスする作業は、並走数に応じて膨らんでいきます。ファイル内の差分を自力で判断する必要があるSVNや、gitを利用していてもgitflowなどの重いブランチ戦略を採用している場合、その膨らみ方は顕著です。
価値を生まない在庫のメンテナンスと、今後の開発プロセスをスムーズにする対策。次の案件開発が遅れるかもしれないリスクと、そのリスクの軽減策のどちらを優先するかのトレードオフになりそうです。
●3. 広がった状況の分かる範囲で、協調作業で対策を実施する
隣の部署の状況を理解して、協調作業ができるようになってくると、作業を統合したり、順番を入れ替えたり、コミュニケーションに必要な情報を整理したり、さらに作業をブラッシュアップできます。生まれた時間を使って、手をつけられていなかった根本対策を実施していきます。
一時的だったはずの運用でカバーしている作業や、既知のバグのために実施している定期メンテナンス作業、受け入れテストの自動化やアプリケーションアーキテクチャの見直しもできるかもしれません。
●4. 協調作業の輪を広げる
協調作業ができる部署が増えるほどに、価値を生む作業に集中できる状況が進んでいきます。価値を提供するまでに関わる全ての部署の状況が把握できれば、マインドセットを「管轄外」から「価値を届けるチーム」に切り替えることもできるかもしれません。
1チームのなぜなぜ分析から生まれた対策が、組織全体の改善につながっていったらすてきですね。
■まとめ
・なぜなぜ分析は、鳥の目と虫の目を切り替えて進める
・「それは問題か？」の問いかけが切り替えのきっかけになる
・時間がないスパイラルに陥っていませんか？
・抜け出すきっかけは、不要な作業と価値を生まない対策を廃止すること
・できた少しの時間で、前後工程の状況を知ることからはじめる
いいなと思ったら応援しよう！
