SaPIDプチBlog～プチブロ
書籍「SaPID入門」だけ読んでも何がポイントなのかイマイチわからない・・・というお話もよく耳にします。
ということで、SaPIDのことを”より適切に理解していただく”ために、書籍「SaPID入門」では書けなかったこと、触れていなかったことを中心に、さまざまな切り口でミニBlog記事を書いていきます。
随時書き足していきますので参考にしてください。（最上位が最も新しい書き込みです）
問題発見力のお話 2018.11.12
この内容は「JASPIC メルマガ 2018年10月号」に投稿し、掲載されたものです。
システム／ソフトウェア業界に携わるみなさんは、自らの力量を高めるために外部の研修やセミナー、勉強会等に参加することも多いと思います。
研修機関やセミナーセンターで主にどのような内容を実施しているのかを思い起こしてみてください。
研修機関やセミナーセンターとしては自らのビジネスを維持・継続していくために「人が集まりそうなテーマ」「ニーズがあるテーマ」を設定するはずですよね。
IT業界向けで人が集まりそうな流行のテーマ・・・現在なら例えばAI・RPA・IoTなどでしょうか。そして継続してニーズがあるベーシックなテーマとしては新入社員向けマナー研修、開発言語の習得、OSやデータベース管理システムの使いこなし方、各種技法の習得などですかね。これらで構成すると、前者は流行のキャッチアップに、後者は新入社員～中堅クラスまでの段階的な育成を支援することができます。
実際にどの研修機関・セミナーセンターのメニューを見てもそのような構成になっていることが多いです。
あくまでも個人的な感触ですが、これらが意味することは、多くの組織（人たち）が特定領域の「問題解決力」を重視している、ということなのかもしれないなぁと感じています。
これらの内容は世の中の変化を捉え、新入社員からの段階的成長を促進するものなので否定するつもりはありません。しかし一方で気になることがあります。それは、個別領域の問題解決力を身につければそれで終わりになっていないだろうか？ということです。
最近流行のRPAでもそうですが、RPAのやり方を学べば対象をRPA化することが可能になります。とはいえ、闇雲にRPAで自動化しても思うような効果は得られない、というのが現実です。人間の手作業を自動的にやってもらえるのは確かに魅力的ですが、これまで非効率なやり方や本来の目的に合わない結果しか得られていないやり方をそのまま自動化する・・・。もちろん人間が手作業でやるよりは早くできる、うっかりミスをしないという効果は得られますが、本当に解決したいこと（問題）はそのことなのでしょうか？
人手不足の解消のために“にっくき”手作業を無くすこと？
作業中に誤りを起こしてしまう厄介者の人間に委ねる領域を狭めて経営者が楽々儲けられるようにすること？
流行のRPAをうちでも活用していると周囲に言える状態にしてお偉いさんの面子を保つこと？（笑）
紙面も限られているので話を前に進めましょう。
私が今回お伝えしたいことは、実務上の目に見える個別のリスクや問題を首尾よく解決する問題解決力ももちろん重要だけれども、一方でリスクや問題の発見力、もう少し丁寧に書くと、隠れたリスクや問題をも明確化し、存在する多くのリスク、問題の中から現状で解決すべき問題を特定する能力も重要だ、つまり「問題発見なくして問題解決なし」ということです。
この“問題発見力”には、多くの人が気づいていないところで「ここにはこういうリスク・問題がある」と気づくチカラと、現状のコンテキストや方針・目標に基づいてたくさんのリスクや問題の重要度や優先度、解決した際の有効性などを評価して射抜くべきリスク・問題を特定する、または適切な優先順位を付与するチカラ、が含まれます。それができたらあとは「問題解決力」をフル活用して対象を撃ち抜くことになります。
問題発見力が重要だ、と主張するのにはもう一つ理由があります。
ソフトウェア／システム関連の実務では、毎日計画された自らのタスクを遂行するだけで目一杯、という場合が多いと思います。それでなくても計画していない横槍もたくさんやってきて日中は仕事にならない。目に見える／見えないにかかわらず多くのリスクや問題に囲まれ、毎日目先の問題を解決しながら業務やプロジェクトを進めています。
別途本質的な問題発見解決＝改善に活用できるリソース的な余裕はほとんどない。
存在する多くのリスクや問題すべてに手をつけて解決するのは無理、いや無茶な状態なのです。
というわけで、多くのリスクや問題の中から現状で解決すべき対象を特定し、自ら持ち合わせているすずめの涙ほどの余裕（涙）を集中投下して撃ち抜き、欲しい効果を獲得することが求められています。
そしてここ20数年の間にわれわれの組織運営にはある変化が起きています。
ある程度の規模を持つ組織では公的認証や実践レベルを評価するQMS・ISMSなどの事務局やSEPG、SQA、PMO、など間接的な専門組織やその役割を担う方が増えているのです。それ以前にもシステム監査人制度や安全対策実施事業所認証制度などが存在していました。しかし、ここまで多くの側面の外部認証や役割が別々に立ち上がるとは当時は誰も予想しなかったと思います。
この状況は組織の成果や結果を安定的に獲得するためにプロセスに着目することが世界的に定着した証の一つなのだとは思います。しかし一方で、プロセスにフォーカスするあまり、そして目先の効率化やスピードを求めるあまり、プロセス要求事項の形式的な適用や個別適用による部分最適な実践で全体がギクシャクしたまま放置されているケースも目立つようになっていることも事実です。
本来は組織全体、ビジネス、業務・プロジェクト、あるいはチームなどそれぞれの領域で総合的に状況把握＆評価した結果を俯瞰し、それぞれの領域で方針や中長期的な目標、あるいは現状から見てどのリスクや問題に取り組むのがよいのかを特定（問題発見）し、取り組むことが求められています。
導入当初はその側面に疎い要員も多いため、事務局や専門組織・専任者が活躍するのは致し方ないと思います。しかし、いつまでも事務局や専門組織・専任者だけがリスクや問題を俯瞰し、取り組むべきコトを指摘してやらせる／やらされる状態を続けたり、第二者・第三者の監査・審査・アセスメント結果等で客観的な事実を突きつけ、改善を促すアプローチを続ければ、チームやプロジェクトが受身になったり、萎縮・依存する状態になりえます。
「はいはい。言われたらやればいいのね。」という状態が続くことは、実務の現場から問題発見に対する当事者意識を低下させ、結果として「問題発見力を奪う」アプローチにもなりかねないのです。
製品・サービスを実際に作りこむ、そしてそのやり方を改善するのは実務者の方たちです。
主役を横において、脇役や外野が活躍する図になっているなら、それは求める姿ではないはずですよね。
品質→セキュリティ→プロジェクトマネジメント→・・・と段階的に適用されたさまざまな切り口の本当の目的は何なのか？個別バラバラに結果を出せばいいのか？組織としてどうなることを目指しているのか？現在の状態は本当に目指していた姿なのか？
実際に製品・サービスを作り上げている実務者やリーダ、管理者の「問題発見力」がどのレベルで実践できているのかを軸に、いま一度問い直す時期に来ているのでないでしょうか。
なお、以上の内容はMS事務局やSEPG、SQA、PMO、など間接的な専門組織や兼務する方の存在や必要性を否定するものではありません。
「問題発見力」を軸にして、これらのみなさんが今後、製品・サービスを作り上げている実務者の方たちとどのようにかかわるのがよいのかを是非一度考えてみてほしいと願うものです。
このあとも新たな切り口の外的介入が増えていくと予想される中、われわれはどのような未来を描いて進むのがよいのか？その実現のためにどうしていくのがよいのか？
是非一緒に考えていきましょう！
知らないことが強み 2018.11.4
現状把握や未来予想のためにヒアリングを重ね、問題や未来を構造化していきますが、検討対象（ドメイン）に対する専門性は一切なくても問題ありません。
中途半端に知っているよりむしろ何も知らないほうが、いろいろと聞いて確認しなければ理解できないため一生懸命質問して聞き出そうとします。
その結果、相手も一生懸命、わかりやすく説明しなければならなくなり、その過程で相互理解が深まっていくのです。
ということで、構造分析は”知らないことが強みになる手法”でもある、と言えます。
ドメインに対して中途半端に知っているほうがむしろ先入観や決め付けに繋がる場合もあるため要注意です。
自律と自分勝手の違い 2018.11.3
10/31に勝手にSaPIDを語る夕べが開催され、その際に「自律と自分勝手を混同している人もいる」という話題が出ましたのでちょっとだけ解説しておきます。
重要なことなのでSaPID Bootcampではこの二つの違いを解説しています。
自律と自分勝手は、能動的に自分でやる、自ら進めるという意味では似ているのですが、その「目的」が異なります。
自分勝手な方のさまざまな行動の目的は「自分だけが得をする／他者がどうなろうとも」です。
そのことが”勝手”という言葉に表れていると思います。
別の言葉で表現すると、ワガママ、になるかもしれませんね。
一方、自律した方の行動の目的は「周囲の方たち（悪意のある方を除く）との関係性を保ちつつ、自らができることで貢献し、一緒に目的を達成する」です。これは三方よしにも繋がることになります。
自律した方＝何でも自分でできる、と受け取りがちですがそうではありません。
自律した方は、自分にできること、できないことをちゃんと把握していて、自分よりも他者に任せる方がよりよいと判断してチーム内外の相手に依存することを意図的に行える、という面を持っています。
自律した方同士でこれを行える状態を「相互依存」と呼びます。
人間は万能ではありません。
失敗もするし、一人でできることは限られています。
だからこそ、関係者と相互に依存しながら協力・協調してコトを成し遂げることが重要になります。
自分も大事、それと同じように相手も大事。自分も活かし、相手も活かすことが、SaPIDで重視している「自律」です。
「三方よし」の意味 2018.11.2
10/31に勝手にSaPIDを語る夕べが開催され、その際に「なぜ三方よしを重視しているのか？」という話題が出ましたのでちょっとだけ解説しておきます。
三方よしは、実務の現場－会社－顧客がみなうれしくなるように運営（改善）しよう、というものです。
なぜこのことを重視しているのか？というと、改善を進めていくと周囲のコトは考えずに安直に改善対象や改善策を決めてしまう場合が多いと感じていたからです。周囲のコトを考えずに安直に出した答えは多くの場合考慮不足となり、Lose-Win、Win-Lose、Lose-Loseのような結果になりやすいのです。
本当に欲しいのは、誰かだけがうれしくなる第一案でも第ニ案でもなく、全体がうれしくなる第三の案なのです。
第三の案をひねり出すには、本腰を入れて塾考したり、関係者の知恵を集結・融合させる必要があります。
これまで見ていた景色ではない別の立ち位置に立ってモノゴトを捉えなおさなければならないのです。
そしてさらに、関係者がみなうれしくなることなくしてビジネスは継続しません。
ということで、三方よしは関係者の安易な思考停止を防止し、ビジネスを継続させる（そして互いに繁栄する）ゴールを目指す、という効果を狙っています。
■STEP2：事実確認・要素精査の事例 2018.2.20
17-18にSaPID+ Bootcamp2018を開催しましたが、その際に支援した受講者の方の事例です。
STEP1で困り事や問題を付箋に記載し、STEP2で事実確認と要素精査を行ったあと、時間の関係でSTEP3：関係性を分析して構造化する説明を行いました。
その結果、問題構造図っぽいもの（笑）ができるのですが、ある受講者の方の構造図っぽいものを見ると、こんな要素と構造がありました。
「仕様を作成する人のスキルが足りないので仕様に抜け漏れが多い」
↓
「企画と開発が仲が悪く企画の人が突っ走ってしまい手戻りになる」
この要素と構造を適切なものに変えるために、やらなければならないことがいろいろあります。
【原則1】1つの事項は1枚の付箋に書く（STEP1の注意事項）
「仕様を作成する人のスキルが足りないので仕様に抜け漏れが多い」には「仕様を作成する人のスキルが足りない」と「仕様に抜け漏れが多い」の2つの事項が含まれています。
同様に「企画と開発が仲が悪く企画の人が突っ走ってしまい手戻りになる」には「企画と開発が仲が悪い」と「企画の人が突っ走ってしまう」そして「手戻りになる」の3つが含まれています。
ですのでまずはこれらを分解して記載します。
「仕様を作成する人のスキルが足りない」
「仕様に抜け漏れが多い」
「企画と開発が仲が悪い」
「企画の人が突っ走ってしまう」
「手戻りになる」
【原則2】抽象的な内容は具体的な内容に書き換える（STEP2の実践事項）
例えば「仕様を作成する人のスキルが足りない」ですが、ここでいう”スキル”ってどのようなものなのでしょうか？
ITSS,ETSSなどを見ていただけるとわかると思いますが、スキルを構成する要素はとても多いです。
構成要素がありすぎる対象を漠然と指し示すと、それらすべてを相手に改善を行う必要性が発生し、結果として（長期化したり、思うように進まなくなるなど）解決できなくなる、そして効果が確認しにくくなる可能性が高まります。
よって解決策を検討しやすくし、解決する可能性を高めるために具体化する必要があるのです。
ここでは「足りない」と言っている「仕様を作成する人のスキル」とは何か？具体的にはどういうものか？を明らかにして書き換えます。
他にも上記要素では「抜け漏れ」「突っ走ってしまう」「手戻り」それぞれが、何がどうなることなのか？どんな内容なのか？を明らかにする必要があります。
【原則3】自分がそう感じている的な要素は、そう感じるきっかけとなった具体的エピソードを明らかにする（STEP2の実践事項）
「企画と開発の仲が悪い」という要素は、私はそう感じている（私にはそう見えている）的な要素になります。
この類の事例としては「～はやる気がない」「～はテストが好きではない」などの表現で登場することが多いです。
これらは原則2と同様で具体性を欠く要素であり、かつ自らの見方（他者から見るとそう見えないかもしれないもの）となりますので、そう感じるきっかけとなった具体的エピソードを明らかにしてもらいます。
※ファシリテータからの質問は「そう感じたエピソードってありますか？もしあれば教えてください。」です。
具体的なエピソードが出たらそれをそのまま書いてもらい、当初のカードの上に貼り付けます。
もしエピソードが言えなければ、記載した方の勝手な決めつけだったり、類する別の状態である（事実ではない）可能性が高くなりますのでその要素を対象から外します。
【原則4】～不足、～がない などの要素は、そのことで起きる問題や困り事を明らかにする（STEP2の実践事項）
「～不足」や「～がない」などの要素は、対策型と言われる要素です。
この要素を記述してくれた方が、～を充足させると”ある問題”が解決する、～があれば”ある問題”が解決する、という意図を持っていて、それを問題風に表現しているに過ぎないわけです。
ですので、そのことで起きる問題や困り事を（具体的に）明らかにします。（それこそがSTEP2で明確にしたいことです）
仮にもしそれが言えなければ、～を充足させる、～を作る必要はない（あればよりよいかもしれないが必ずしもなくてもよい）ものである可能性が高くなります。（事実ではないとわかった場合はその要素を対象から外します）
また「～不足」の場合は、何がどのくらい不足しているのかも明確にしておきます。
代表的な原則と対応を示しましたが、以上のような処理の過程では背景や状態などいろいろな情報が飛び交います。
これまでに表現されていない、しかし現状を把握するためには重要な事項が共有されることも多いです。
そのような情報は、付箋の中に補記したり、別の付箋として新たに書き記したりします。
このようにそれぞれの要素を具体的な内容に変換すると、STEP3の構造化は驚くほど簡単に終わります。
そして出来上がった構造体は、自分だけでなく、それを見た第三者も「現状はそういうことなんだ！」と腹落ちする、わかりやすい内容になるのです。
■問題構造図や未来予想図作成で求められること 2018.2.9
問題構造図や未来予想図を構築した結果、できなければならないことがあります。
それは図を前に置いて眺めた際に「対象の全体像と個別詳細の両方が把握できること」です。
両面を把握することで、どこを打ち抜くべきか、打ち抜く際の手段は何がよいかを導き出しやすくなります。
その実現のために注意すべきことがいろいろあります。
・構造図の構成要素数を20～30に抑えること
・それぞれの要素は具体的であること
・同類の要素は統合して1要素とする、あるいは親子関係で括るなどパッケージ化する
・1要素の文字数は概ね40文字以内で簡潔に記載すること
・1要素は丁寧に、大きな見やすい字で記載する
・余計な関係線はつけないこと
・わかりやすいように配置を工夫する
■[STEP1：問題洗い出し・引き出し]で「～不足」が出てきた場合の[STEP2：事実確認・要素精査]での対処例 2018.2.6
STEP1では、普段からその方が感じている問題や困り事をその方の言葉で素で書いてもらいます。
その際によく登場するのが「～不足」という要素。
「設計不足」「レビュー不足」「人材不足」「工数不足」「テスト不足」・・・いろいろあります。
SaPIDでは、対策の裏返し型表現を避け、可能な限り実際に発生した事象や成果物等の状態を具体化することを重視していますが、これらの表現は、抽象度が高く、対策（裏返し）型でもあるので、適切に対処しないと解決が難しくなります。
ここでは「レビュー不足」を事例として、どのように具体化するのかを説明します。
あくまでも基本的事項のみを示しますので、STEP2の状況により対処が変化することもありますので注意してください。
・何に対するレビューを指しているのか？
レビューは対象を選びません。計画書レビュー、コードレビュー、設計書レビュー、テストケースレビューなどいろいろありえますので、「レビュー不足」と記載した方が意図したレビューはどの段階（あるいはタイミング）の何に対するレビューなのかを確認します。
・不足、とはどんな状態のことか？
「不足」とは、これで十分だと言える状況よりも少なかった、という意味ですが、どのくらい足りなかったのか？数値的なものなのか？対象外となったものがあるという意味なのか？などを具体的に把握します。
過去の例では、以下のような状態をいずれも「レビュー不足」と表現していました。
15件のレビュー対象のうち（時間もないので）9件のみレビューし、6件はしなかった
すべての対象をレビューしたがそれぞれ観点が不足していた→不足していた観点とは何か？
すべての対象をレビューしたがそれぞれ時間が不足していた→どのくらい時間が不足した？
21件のレビュー対象のうち、有識者がレビューしたのが3件のみだった→有識者がレビューすべき対象は？
レビューを一度も実施していなかった
・レビューが不足したことで発生した問題事象や困り事は何？
～不足は対策（裏返し）型でもありましたね。
～不足という表現を使う場合、その結果何か問題事象や困り事が発生していた可能性が高いわけです。
その問題事象を見た（経験した）方が、「レビューやっておけばそうならなかったのに！」と頭で考えて「～不足」と表現することが多い、というのがからくりです。
よってそれ（対策：今回はレビュー）が不足したことで発生した問題事象や困り事を確認します。
以上のように、抽象的な要素や対策型の要素を具体化していくのです。
具体化することにより、誰も否定できない事実を捉えられるだけでなく、誰もがリアルに状況をイメージできます。
さらに、その後の対策検討時に対策が小さくて済む、改善工数や期間が小さくて済む、効果があるかどうかを評価（実感）しやすい、などにつながります。
■解決手段は、認識した問題･困り事の粒度、具体化度と同じレベルになる 2018.2.5
SaPIDのSTEP1～3では、メンバーが認識している問題や困り事を捉えて構造化します。
その際に共有される問題や困り事の中味が十分に具体的でなければ、解決（改善の成功）が難しくなります。
抽象度が高い状態で認識された問題や困り事に対する解決手段は、包括的な内容になるからです。
例えば、「要件明確化不足」、「設計不足」、のような粒度で問題を捉えると、その対策は「すべての要件を明確化する」、「すべての設計をしっかりやりきる」的なものになりますよ、ということです。
包括的な解決策の中にはたくさんのやるべきことが詰まっていて、その適切な実践は容易ではなくなります。
その場合、既存とのギャップが大きくなり、適切に実践するための学習時間は長くなります。
やり損ないも増えるでしょう。すべての関係者が新しい方法をスムーズに実践できるようにならないと、欲しい結果は得られない。よってその改善は長期化し、効果があったとわかりにくくなります。その改善の成功確率は当然低くなります。
SaPIDでは、"短期間の成功実感"と”継続”を重視しているため、それ（長期化）を回避するように運営します。
STEP1～2では、（まずは自ら認識している問題や困り事を出してもらった上で）問題や困り事を具体的にすることを求めます。
具体的であるほど改善策は小さく絞られ、成功しやすくなります。
■メンバーが持つセンサーを頼りにする 2018.2.1
多くのメンバーで進めるプロジェクトや業務の中で問題やリスクを捉える人は誰ですか？
よくあるのは管理者やリーダがその役割を担う、というものですが、その実態が「一人で」ということであれば恐らくうまくいかないでしょう。（スーパーマンでない限り（笑））
プロジェクトや業務の中には、それぞれのメンバーが割り当たっている作業や、顧客・協力会社などの関係者がいる場所、役割などがあり、それぞれの立ち位置から見える景色（状況）は異なっていて刻々と変化していきます。
それらの中に、問題・リスクやそのヒントが隠されているのです。
管理者、リーダの立ち位置ですべての領域をタイムリーに、いやリアルに把握するのは不可能です。
ゆえにそれぞれのメンバーや関係者に「問題・リスクはないか？」を問いかけ、（例えば進捗報告書などにより）情報を収集するわけですが、問題点の欄はいつも「空欄」または「問題なし」。
たまに問題点の欄に記載してくれる内容に対して「こんな記載じゃ何が起きているのかわからないじゃないかっ！」なんて反応しようものなら二度と報告しなくなる。（笑）
その反応が発するメッセージは「俺は間違いを許さない！ちゃんと書けないなら二度と報告するな！」ですよね。
厳しくするほどメンバーはそれに応えてくるはず・・・と考えての意図的な反応ならまだしも、多くの場合は自分の基準に従わせる身勝手さやわがままであることも多い。厳しくして伸びるメンバーは極々少数、というのが現実だと思います。
マネジメントは自らの行動や言動で、相手がどう受け取り、そのあとどのような行動になりそうかを見極めてアプローチせよ、と言われるゆえんはここにあります。
本来は「書きにくいことをちゃんと記載してくれてありがとう！ところでこの内容を詳しく教えてもらないかな？さてさて、どうしたら解決できるだろうか？一緒に考えよう！」と反応するのがよいのでしょうね。
SaPIDではSTEP1～3で関係者全員からその人の言葉で問題やリスクを収集し、それらの情報を活用して（STEP4以降で）問題を解決したり、リスクに対応したりします。
STEP1では、「問題だと思うことや困り事としてこういうのがあるな！と思ったらみなさんの言葉でそのまま書いてみてください」とアプローチします。記載内容には制約をつけません。（STEP0で設定したテーマに対して、ということくらいです）
その方が普段、自らのセンサーを通じてどのように感じているか、受け取っているかをベースに"素”で問題や困り事を書いてもらいます。その内容は（問題や困り事であれば）どのような言葉でも構いません。
普段それぞれのメンバーが持つセンサーに引っかかっている事項をそのまま出してもらうので、提供される情報は「ダイヤモンドの原石」みたいなものです。
情報を磨けばその背後に存在する問題やリスクが明らかになりますが、そのままだと問題やリスクが見えにくい状態となっています。よってSTEP2：事実確認・精査でそれを磨き、問題やリスクをみなで共有します。
とはいえ、それを先導するファシリテータが普段からメンバーとどのように接しているか、記載する際の障壁（間違うなんてとんでもない！など）度合いなどによって、本当の情報が得られるかどうかが決まりますので注意が必要です。
■モデルを見やすく、わかりやすくする(その2)：間違って書いた線を削除する 2018.1.30
モデルを見やすく、わかりやすくする方法はリファクタリングだけではありませんのでその例を示します。
問題（要因）を構造化する際に、個別に見ると間違っていない矢印が、全体像になってから確認すると誤りになっているケースがあります。よく見るのはこのような状態になっています。
この例では要素aと要素cの間に要素bが1つだけ存在しますが、複数の要素が存在する場合（例：要素a→要素b→要素d→要素e→要素c）も意味は同じです。
何の変哲もない構造のようですが、このような状態になっている場合は「要素aから矢印2・要素b・矢印3を経由して要素cに至る因果関係とは別に、要素aから直接要素cにつながる関係性は存在するのか？」を確認する必要があります。
確認した結果、関係性が存在する場合はもちろんこのままにします（下図左）が、そのような関係性は存在しないとわかれば”矢印1”は削除します。（下図右）
実際どちらの結果になった事例もあります。
仮に正解が上図右：要素a→要素b→要素cのみ、だったとしましょう。
構造化の過程でどうして最初の図ができてしまうのでしょうか？
それは、要素aから見ると（要素bを経由しなくても）要素cは因果関係として成立してしまうからなのです。
なので直感的に矢印を要素a→要素cと引いてしまうわけですね。
また、最初は要素aと要素cしかない状態で構造化し、そのあとで要素bが登場することでもこのような図になりえます。
余計な線（矢印）が多いほど構造図はわかりにくくなりますので、今回のような間違った線があるならちゃんと削除しておくことが大事です。構造図ができたらすぐに次のステップに進みたい気持ちをグッとこらえて（余計な要素や矢印がないかを今一度）確認することで、結果的に解きやすい問題構造を作ることができるのです。
■モデルを見やすく、わかりやすくする(その1)：モデルのリファクタリング 2018.1.29
問題などを構成要素としてモデル化した結果、見やすく、わかりやすくなっているほうが解きやすい、という話をしました。
見やすく、わかりやすくするための手段の一つに「リファクタリング」があります。
同じ意味を持つ別の構造に変える、という意味になりますが、文字で書いてもなかなかわかりにくいと思いますので簡単な事例でそのことを示してみます。
話を単純化するために、同じ要素に複数の線が刺さっている場合はすべて”OR条件”であると仮定します。
まずは事例1です。
STEP3：問題分析･構造化の開始時には、"STEP1・2で洗い出し（引き出し）た要素の発生順に左から右（または上から下）へやんわりと配置”します。（最左の図）
※こうすることで、構造化しやすくなることが（経験則で）わかっています。
次に、要素間の因果関係を分析して、関係している要素間を矢印でつなぎます（真ん中の図）が、たくさんの要素が絡んで発生する別要素が存在した場合は矢印線の本数が（あたりまえですが）多くなります。
線が多くなると、混在して見にくい、わかりにくい図になりえます。
そこで、その意味（関係性）はそのままで、見やすく、わかりやすくするために、見直した例が最右図です。
要素4、5、6を枠線で囲い、要素1、2からそれぞれ要素4、5、6に刺さっていた線（のべ6本）を、囲われた枠線のみに接続させることで矢印線は2本だけになりました。
※要素3から要素6の矢印線は単独で存在するものですので、直接要素6に刺さっています。
真ん中の図よりも最右図のほうが関係線が少ないため、見やすく、わかりやすい構造になっています。
もう一つの事例2を見てみましょう。
要素の発生順に左から右（または上から下）へやんわりと配置するのは先ほどと同じです。（最左図）
関係性を分析して矢印で結ぶと・・・直後ではなく、2つ向こう側の要素に刺さることがわかった、というのが真ん中の図です。
これでも関係性は示せているのですが、矢印線が長く、要素cの横から上にかけて迂回し、湾曲しているため、わかりにくい印象です。
こういう場合は、要素を移動して、線がなるべく直線的に引ける状態に整理していきます。（最右図）
なお、見直した結果、要素の発生順が逆にならないようにすることも忘れないようにしてください。
この2例だけですべてをお伝えするのは無理ですが、わかりにくい図をできるだけわかりやすくすることが、問題を解きやすくする前提条件になるということは覚えておいてください。
■問題（要因）をモデリングする 2018.1.26
SaPIDではSTEP1：問題洗い出し・引き出し、STEP2：事実確認・要素精査、STEP3：問題分析･構造化を通じて問題構造図（トラブルモデル）を構築します。
STEP1～2では問題構造図に組み込む要素（問題・困り事）を明確化し、STEP3でそれらを組み立てるのですが、これらの過程を通じて問題（要因）をモデリングすることになります。
モデリング＝モデル化すること、ですので、良いモデル、わかりやすいモデル、悪いモデル、わかりにくいモデルなどなど、いろいろ書けることになります。
最終的には「わかりやすいモデル」を構築しないと、その問題を解き明かすことが難しくなります。
そう、モデルのわかりやすさが、問題の解きやすさを決めるのです。
書き方のレベルで、わかりやすいモデルの特徴（その反対がわかりにくいモデルの特徴）を思いつくまま書いてみます。
・構成要素それぞれが具体的である
いつ、どこで、どのような状態になったのかを頭の中でリアルにイメージできるのが理想です。
要素の内容が抽象的だと、リアルな状態を捉えにくくなります。
SaPIDでは、主にSTEP2：事実確認・要素精査で要素を具体化していきます。
・構成要素数が適切である
構成する要素数が多いと、情報量が多くなり、その内容を把握することが難しくなります。
SaPIDでは、要素数が全体で20前後となるようにコントロールします。
・関係性が単純である(1)：無駄な関係線がない、あるいは最小限である
必要な関係線を引きながらモデルを構築しますが、わかりやすいモデルは関係線の数が必要最小限になります。
反面、無駄な関係線があるとモデル（の内容や流れ）は複雑でわかりにくくなります。
SaPIDでは、STEP3：問題分析・構造化で、関係線が適切に引かれているかを精査し、問題があれば訂正します。
・関係性が単純である(2)：交わる関係線がない、あるいは最小限である
わかりやすいモデルは関係線の交差がない、または必要最小限になります。
関係線が交わる、交差するとモデルが複雑になります。
反面、関係線の交差がたくさんあるモデルは、その内容や流れが複雑でわかりにくくなります。
SaPIDでは、STEP3：問題分析・構造化で、交わっている関係線ががあれば要素を移動するなどにより補正していきます。
注意：今回はモデルを「パッと見た」ときにわかりやすい、となるために必要なことを書きました。
構成要素そのもののあり方、については別スレッドで触れたいと思います。
■機能は関係から決まる 2018.1.25
SaPIDはシステムズアプローチを採用しています。
それはシステム思考により（対象をシステムと見立てて）進めることを意味します。
※システムとは？
多数の構成要素が有機的な秩序を保ち、同一目的に向かって行動するもの（JIS定義より）
構成要素は機能、構成要素間の関係性は機能と機能のつながり・連携を指します。
例えば問題構造図では、構造図自体がシステムの全体像、構造図の中に存在する個別要素が（システムの中に存在する）機能を意味します。
ここでは「機能は関係から決まる」という原理を説明します。
要因分析の前段で行う要素洗い出し（STEP1：問題洗い出し・引き出し）時には「要素一つ一つを評価しないこと」が大事です。
要素そのものがどのような意味を持つのかを確定することなく、淡々と事実（こんなことがあった、こんな状態だったなど）を置いていきます。
それぞれの要素がどのような意味を持つのかは、他の要素との関係性で決まります。
例えば「機能仕様は簡潔に書かれている」という要素があったとします。
その状態でスキルや経験、業務知識が少ない方がその内容に沿って作業を進めると「詳細がわからないため作業が進まない」とか「実装漏れ」「誤った実装」につながる可能性があります。一方、スキルも経験も業務知識も認識共有も十分な方たち（チーム）がその内容に沿って作業を進めると「余計な情報を作らずに進められた＝生産性が高い」のような結果になる可能性があります。
まったく同じ要素（機能仕様は簡潔に書かれている）でも、関係する人やコトによって評価（意味）が変わる。
SaPIDではそのことを分析過程で明らかにしながら結果を導いていきます。
■要因分析時には含めない要素(1) 2018.1.24
事実に基づき分析せよ、とよく言われますが、その実践は容易ではありません。
人間には”想い”があるため、事実情報に自分色を加えてしまうことが多いばかりか、自分ではそのことに気づきにくいのです。
例えば、先日遭遇した要素（をちょっともじっています（笑））はこんなものでした。
・当初の段階から自ら業務を理解しなければならないという認識をリーダが持たなかった
この要素を出してくれたのは上級管理者の方なのですが、「どうしてリーダはその時そう認識しなかったのか？その段階で気づくべきだろう！」という想いが聞こえてくるような内容です。
そのアツい想いは汲み取ることとしますが、要因分析時に取り扱う情報としてはふさわしくありません。
その理由は、この要素が解決手段に相当する内容だからです。
SaPIDの要因分析（STEP1～4）時に明確にしたいのは、（解決手段ではなく）解決すべき（実際に発生した）問題事項なのです。
ということで、SaPIDではまず関係者から問題点や困り事を（”想い”が付与された情報を含めて）フランクに集め、その内容（や想い）を確認してから、要因分析時に必要な情報を選択したり、変換していきます。
要因分析の過程で関係者が対話を重ね、相互理解の下で（関係者全員が）納得する結果を導いていきます。
SaPIDファシリテータは、そのことを一貫して実践することを促進する支援を行います。
※上記事例の要素が私に提示された際には「その結果発生した問題事象や困り事は何でしたか？」と質問して、要因分析に必要な情報を獲得しました。
■原因追究ではなく解決すべき問題の発見 2018.1.23
原因分析でよく聞くのは「原因を追究するのだ！」的なフレーズです。
そのこと自体は否定するつもりはありませんが、追究するがゆえに（行き過ぎて）辛辣になったり、関係者が責められる（そして嫌な思いをする）こともあるような気がしています。
例えば、なぜなぜ分析で何度も言われる「なぜ？」という言葉は、それ自体が責められていると感じてしまうものです。
たとえ問いかける側にその意図がなくても、問われる側には負担がかかることは認識しておくべきだと思います。
責められた、と感じた関係者が、その後の問題解決や原因分析に一層協力的になる・・・わけはありません。
むしろその逆になるでしょう。原因分析がなかなか根付かないのは、そんな理由があるようにも思います。
SaPIDが採用しているシステムズアプローチとその運営方法は、原因を追究するのではなく、問題（事実）をしっかり把握して自然と「ここを何とかしないとダメだよね」と関係者が納得することを目指しています。
関係者が自ら（一緒に）解き明かす、そのお手伝いをSaPIDファシリテータが行う、というものです。
■SaPIDを活用してうまくいく人といかない人 2018.1.16
これまでに多くのSaPID実践を支援していますが、問題構造を作り上げる過程で終わってしまう人、作り上げた問題構造を浮かない顔で眺めてモチベーションも上がらないまま終わってしまう人もいらっしゃいます。
共通しているのは「自分（その方）が期待している答えにならない」ということです。
SaPIDでは（誰にも否定できない）事実情報を一つひとつ明らかにし、それらの関係性を結んで構造体を作ります。
適切に進められれば驚くほどわかりやすい構造になる（もちろんわかりにくい構造をなかなか打開できない方もいますが）のですが、だからこそ、どこが解決のポイントになるのか、何を打開しないと解決できないのかが自然とわかるものになります。
自分が普段思っている「問題点」と、SaPIDで作り上げた問題構造の結果が異なるものになった場合の反応は大きく２つに分かれます。
--------------------------------------------------------------------------------------------------------------------------------------------------------------
反応1：この構造ならここが解決のポイントと考えるのが適切だよね。これまでの考えは間違っていたんだなぁ。
反応2：私の考えと違う！どこかで間違ったか、作り方がおかしいんだ。（私が間違っているはずはない！）
--------------------------------------------------------------------------------------------------------------------------------------------------------------
反応2のような方は、何度もやり直したり、自分の欲しい答えになるように曲解したりするので、無駄に時間がかかり、結果的にうまくいかないことが多いです。
もともとの見方や考え方が不適切なので、（残念ながら）いつまでもその問題が解けずに残ってしまう。
特に自己責任回避型、他者責任追及型の思考が強い方はこの傾向にあります。
（SaPIDだろうと、別の手法であろうと、このタイプの方はうまくいかないと思います）
アインシュタイン氏はこう言っています。
「我々が直面する問題は、それを作った時と同じ考えのレベルで解決することはできない。」
一度自分の立ち位置から離れ、自分やモノゴトを別の視点で客観視できるかどうか。
自分の拘り、執着を捨て、可能な限り”素”の状態になれるかどうか。
立ち位置を自在に変えながら同じ対象を眺めた場合、どのように見え方が変化するのか。
自分のこだわりや考え方、捉え方の癖、別の見方、考え方、捉え方に気づき、関係者がみな幸せになるポイントを把握することができるかどうかが重要になります。
■求められているのは問題解決力？ 2018.1.15
日々発生する問題を首尾よく解決しなければ、業務もプロジェクトも立ち行かなくなる・・・実務上で「問題解決」が重要なのは誰もが認めることだと思います。
その一方で、システム要件がなかなか固まらない、システム関連のドキュメントがわかりにくくて作業が進まない、一度決めたはずの要件や仕様の変更が多い、終わったはずの作業に難癖がついてやり直す事態が多発している、プロジェクトの生産性が悪い、見積と実績の乖離が大きい、目標としていた利益が得られない、プロジェクトの途中で離脱するメンバーが後を絶たない、、、など、目先ですぐに解決できない問題が多数存在していることも事実です。
毎日の業務をこなすだけでほとんど余裕がない状況で、山積する問題を前にどこから手をつけてよいのかわからない・・・そんな組織が多いと推察しています。
このような状況で重要になるのは「問題解決力」でしょうか？
それとも、たくさんの問題の中から、現状で取り組むべき問題を適切に特定して解決に向かうための「問題発見力」でしょうか？
もうお気づきだと思いますが、自らの問題解決力が役に立つ前提条件は、今手をつけて解決すべき問題を発見（特定）することです。取り組むべきではない問題を適切に解決したとしてもそれほど意味はない（むしろ、忙しい中で無駄に工数を使うことや、優先度を誤ることでサービスレベルを落としたりすることにもなりかねない）わけですから、重要なのは問題発見力であるといえます。
SaPIDは、組織やチーム、個人に山積する問題の中から、現状の取り組むべき問題を特定（問題発見）し、自ら実践できる手段で解決を行う、そしてそれを自律的に継続実践するための手法です。
■要因分析（の対象）にも種類がある 2018.1.12
みなさんへ”要因分析”と聞いてどのような対象を思い浮かべますか？
いろいろな切り口がありえますが、ここでは大きく3つの対象を分けて考えたいと思います。
----------------------------------------------------------------------------------------------------------------
1) リリース済み製品・サービスの一部に不備が見つかった際の原因分析
製品・サービスの欠陥や不備の作り込み、流出原因などの分析が中心となる
2)破綻したプロジェクト、ロスコン（ロストコントロール）プロジェクトの原因分析
プロジェクトの制約条件や運営のまずさ、判断ミスと結果・成果との関係性などの分析が中心となる
3)現状の課題を把握するために実施する要因分析
個人やチーム、組織が取り組むべき課題や問題を明確にするため、現在どのような状況なのかを分析する
----------------------------------------------------------------------------------------------------------------
このように、対象が変われば分析する際に収集する情報や着目すべきポイントが異なります。
一方、どの分析においても重要なことは「可能な限りバイアス、先入観（決め付け）や押し付け、 個人攻撃を排除し、事実と根拠・論拠をベースに、関係者や他者が納得する要因を特定し、適切な対策を導出する。」です。
1)を対象とした分析の事例としては「欠陥エンジニアリング／欠陥モデリング」があります。
→「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」（JaSST'13東京）
一方、SaPID/SaPID+で実践する「問題構造分析」は（もちろん1)にも活用できますが）主に2)と3)を対象とした手法です。
■「問題」の定義からわかること 2018.1.11
「問題と課題」2018.1.10で定義したとおり”問題”とはあるべき姿、基準と現状のギャップ（差異）のこと。でした。
つまり、組織やチーム、個人が持つ「あるべき姿」と現状のギャップが問題となるので、どのようなあるべき姿を描いているか、関係者で共有しているかが鍵になります。
非常に高いレベルや実現難易度が高いあるべき姿を持っている組織やチーム、個人と、誰でもできるレベルや実現難易度が低いあるべき姿を持っているそれでは、認識される問題の内容が変わります。
同じ状況を見ても、人によって問題視したり、しなかったりするのはこのためです。
また、どんなにすばらしい価値実現のあるべき姿を描いたとしても、それが関係者に伝わっていなかったり、共感していないメンバーが多いほど、問題認識がばらつき、一貫した判断や行動に結びつかなくなることは容易に理解できます。
Personal SaPIDを活用して問題構造を描くワークを行ったり、チームや組織の問題構造を構築する支援を行うと、その方（達）がどのようなあるべき姿（価値観）を持っているのかが手に取るようにわかります。
そして、そのあるべき姿（価値観）や執着心、勝手な決めつけなどが邪魔をして、問題の捉え方がゆがんでしまい、いつまでも解決できなくなっている組織、チーム、個人が多いことを実感しています。
■問題と課題 2018.1.10
問題と課題。
似ているようで異なるこの二つの言葉の意味を共有しておきましょう。
まずは、書籍やWebサイトの情報から典型的なものを並べてみます。
----------------------------------------------------------------------------------------------------------------
問題の定義：
（問題解決の分野では）あるべき姿、基準と現状のギャップ（差異）のこと。
※テストや試験に出る問題、という意味もありますが、ここでは対象外とします。
課題の定義1：
目標を達成するためにこれから成すべきこと。
問題を解決するためにどのような行動を起こしたらよいかを明確に述べたもの。
問題を解決するために、担当・期限が設定できる単位に細分化したもの。
通常１つの問題を解決するには複数の課題設定（行動）が必要である。
課題の定義2：
現状のあるべき基準ではない新しいあるべき基準を設定した際の現状とのギャップ（を埋める施策の方向性）。
問題創出とも言う。
課題の定義3：
実際に存在する多くの問題の中で、現状で取り組むべきもの。
（参考情報）
wikipedia
http://mngmnt.jp/2017/02/03/problem-issue/
「問題解決モデル」サイモン著
「問題解決入門」佐藤 允一著
----------------------------------------------------------------------------------------------------------------
問題、の定義はどこを見ても大枠同じ意味になっていましたが、課題のそれは異なっていますので注意が必要です。
１つ目は、（取り組もうと選択した）問題（目標）を解決（達成）するためになすべきこと。
これは、問題の解決策に求められることや内容を指しているようです。
２つ目は、現状で共有している基準とは別に新しく設定した基準と現状とのギャップのこと。
こちらは、現状よりもレベルアップを目指すための新しい目標と現状の差分そのものを指しています。
３つ目は、たくさんの問題の中で、解決に取り組むべき（と特定した）ものそのもの。
実際にいろいろな方に「あなたの”課題”の意味は？」と聞いてみると、それぞれ異なる意味で使っていることがわかります。
自らが「課題」をどちらの意味で使うのかは自由ですが、少なくとも同じチームや組織の中では定義を統一しておいたほうがよいですよね。（相互理解を確実にするために）
当コーナーでは（SaPIDを語る上で）問題、課題の定義を、以下のようにしたいと思います。
---------------------------------------------------------------------------------------------------------------------------------------
問題：
あるべき姿、基準と現状のギャップ（差異）のこと。
課題：
実際に存在する多くの問題の中から特定された取り組むべき問題を解決するためになすべきこと。
---------------------------------------------------------------------------------------------------------------------------------------