JaSST'15東北の前夜(2015.5.28）、東北デベロッパーズコミュニティ（TDC）さんの勉強会（ソフトウェアテスト勉強会～東北×東京×北海道×関西～）で「問題モデリング」の発表をしてきました。
翌日のイベント（JaSST'15東北）に参加するさまざまな地域のみなさんが集まり、持ちネタを披露する場だったのです。
http://tohoku-dev.jp/modules/eguide/?prev=1
----------------------------------------------------------------------------
トップバッターは、地元東北代表「うめつさん」（仙台ソフトウェアテスト勉強会）の「めんどくさいレビューをぷち改善してみた」。
次がJaSST'15東北でも発表された東京代表、クックパッド「松尾さん」の「モバイルアプリ開発体制の継続的改善」。
3番目が北海道代表の私「問題モデリング」。
そして最後は大阪代表、関西SWテスト勉強会(WARAI)「みずのりさん」の「20分でわかる”考える力”を高めるためのTOC（制約理論）」。
----------------------------------------------------------------------------
テストじゃないじゃん、というご指摘もあろうかと思いますが（笑）、それぞれの個性が発揮された内容で楽しい時間を過ごすことができました。
さて、私が発表した内容についてです。
問題モデリング（広義）とは、チームや組織に存在するたくさんの問題と、それらがどのように関連して何が起きているのか（因果関係）をわかりやすく表現し、関係者全員が問題を（最終的には全体構造と、個別詳細の両面で）把握・理解し、納得することで関係者全員に“問題発見・解決・改善の当事者”になってもらうことを目指す過程と結果の総称です。
その過程を「問題モデリングプロセス」、問題の表現方法を「問題モデリング（狭義）」と呼びます。
※補足：本来「モデリング」とは、対象の主な特徴を的確に捉え、主な要素を構造化し、枝葉情報は除外して表現するまでの試行錯誤の過程と結果を指す。（と思っています）
どうして問題モデリングなのか？というと、チーム内で問題を早期に発見して解決する、必要な改善を切り出してとっとと解決するなど関係者が当事者意識を持って自律的に運営するためには不可欠な内容だからです。
また、システム開発対象の領域（例えば、組織活動）に存在する問題点や課題となっている事項を特定する際にも問題モデリングは威力を発揮します。対象領域の関係者を巻き込んで問題や課題を明確化し、重要度レベルを付与したり、その解決方法を導出し、合意を形成する方法論でもあるからです。
つまり、問題モデリングの用途は
①システム企画・提案・要求定義
②プロジェクトマネジメント
③プロセス改善
のすべてとなります。
そんな問題モデリングの実践と実現は簡単ではありません。
例えば、用途の②③で自律運営を実現させるには「チームとしての価値観と考え方」を変える必要があります。
いや、変えるというよりは「チームの成果を上げるために必要なこと、大事なこと」を認識して、それに沿って動いてもらう、というのが正しいかもしれません。
価値観と考え方の事例として「担当する作業は責任を持ってやり遂げる。わからないことを安易に周囲に聞くのは無責任だ。」という考え方があります。
これは一般的に否定されるようなことではありませんし、むしろその通りだ！と言われることが多い内容だと思います。
しかし、これが行き過ぎるとチームとしてどうなるか。ちょっと考えてみましょう。
→問題が起きても（周囲も忙しいから）自分で抱え込む。→個別作業の進捗遅延になりやすい。
→大きな問題に発展しやすくなり、結果的にチーム全体に大きな迷惑がかかる可能性がある。
このように、個人が持つ価値観・考え方、そして行動が、チームとしての結果や成果に影響を与える可能性があるのです。
実際に、ある新任の担当者が、作業で使用する機器の使い方（パラメータの設定方法）がわからず、数日進捗が止まっていました。周囲のメンバーも忙しそう、新任なので何でも聞いていたら周囲に迷惑をかける。
自ら作業ストップ状態を抱えたまま何時間も、何日もあれこれやってみるがダメ。時間だけがムダに経過していく。
そんな矢先にたまたま全メンバーに”現在の困り事”を聞いてみる機会があり、その人に尋ねたところ「使用する機器が思うように動かず、作業が進められません。困っています。」と。その場で別のメンバーが「あ、それね。みんなはまるんだよね。こうやって設定すればいいんだよ。」と詳細な設定情報を提供してくれてすぐに解決。
こんなことなら早く聞いてみればよかった、なんて事例もあります。
そう、プロジェクトの進捗は、このような些細な遅延が毎日重なって大きな遅れ（そして全員が不幸に）に繋がるのです。
こんなことにならないように「問題は一人で抱えず、できるだけ早く共有し、解決する」のがチームにとってもよいことである、とメンバー全員が認識することが必要になります。
※そうはいっても、自分で調べる方法を知っていることまで何でも人に聞くのがよいわけではありません。
状況による使い分けが必要です。
では、各メンバーが問題を提供し、チームで共有すれば解決するよね！と思うかもしれませんが、そう簡単にはいきません。
例えば「問題がある」ということを言いにくい場（「なに！原因は誰だ！」など魔女狩りになるなど）になっている場合があります。その状況を解消しない限り、もし問題があってもみなに言う人はいないでしょう。
また「問題」とは何か？をメンバー全員で共有しておかないとグチや悪口、自分のことを棚に上げた戯言など余計な情報ばかりになったり、提示された抽象的な内容を具体的に確認する手間ばかりになりえます。
さらに、先ほどの機器設定の例は問題発見解決であって改善ではありません。
チームに存在するたくさんの問題事項の中から改善すべき事項を特定し、首尾よく解決できるようになるためには別視点での取り組みが必要になります。
以上のようなことをすべて考慮し、どのような段階を経て自律したチームを作っていけばよいのか、関係者に問題解決・改善の当事者になってもらうにはどうしたらよいのかをまとめたものが「問題モデリング（広義）」です。
これを書き込んでいる現在も、私は2チームの自律化を支援している最中です。
チームの状況やメンバーの特性も異なるため、都度、そしてチームごとにアプローチを変えて支援しています。
支援の過程で、当初曇っていたメンバーの顔が徐々に明るくなり、みんなで協力して問題を解決していくのが楽しくなっていく・・・そのさまをみることができるのは（支援はいろいろ大変なのですがｗｗ）本当に幸せです。
【参考情報1】
問題モデリングの簡単な解説PDFを「SaPID」コーナーの「問題モデリング」に置きました。
TDC勉強会での発表内容の多くを格納してありますので参考にしてください。
【参考情報2】
2015年度内に”SaPID Advanced Course”の一つとして「問題モデリング」のワークショップを開催する予定です。
それに先立って”SWEST17”にてSaPID解説＆問題モデリングワークを実施することが決まりました。
詳細は追ってお知らせします。
コメントをお書きください