参考文献
具体と抽象 細谷功著
問題発見力を鍛える 細谷功著
ロジカルファシリテーション 加藤彰著
ソフトウェアアーキテクチャの基礎 マーク・リチャーズ著
変数についての用語の定義
ここで述べる変数とは、
品質特性含めた機能要求＋非機能要求や、要求指標を構成するパラメータ、
リスク対策要求、新たな価値を生むためのISO規格にもない品質特性の項目などなど
あらゆる値が一定値でない変えられるものを指す。
参考として以下にISOの2018年度版の規格を添付しておく。
※注意
ソフトウェアアーキテクチャの基礎による内容を引用すると、
この品質特性に関する確立された方法論というものは存在しておらず、
常に新しい品質特性が発見されたり、
時代の流れとともに品質副特性の中で非常に重要になってきたものは品質特性として考えるなど、
品質特性の構造自体も時代と共に移り変わっていっている。
よって、エンジニアリングで求められる活動として、
そのビジネスに見合った新しい品質特性変数の発見も求められる。
多変数関数についての考え方を取り入れた方法論
一般に数学の世界でもそうだが、一度に複数の変数を扱う多変数関数の考察は困難を極める。
そのためn個の変数を同時に扱わなければいけないときなどは、
いったんその中の１つの変数にのみ注目して、それ以外の変数は定数とみなして考察する。
例 f(x, y, z, s, t, u)みたいな6変数関数の中で、xのみ変数として扱い考察が完了してから
他の変数も同様に1つずつ変数として動かしていく。
この考察は非常にアジャイルのイテレーティブな活動や、アジャイルではない反復型のアプローチと非常に相性がいいと感じている。
問題の発見のための発散と収束
発散をさせないといけない理由
以下の内容は、問題発見力を鍛えるという書籍の思想に自分の考えを追加した内容である。
下図の左側のようにユーザーから言われた問題をそのまま解決するのでは、
表面的問題の枠が固定化されているので、そもそもの悩みが解決されない可能性が高い。
そのためにまずは問題の発見をするため考えを枠の外に向けなくてはならない。
具体的には「そもそもなぜそれをしたいと感じるのですか？」と問いかけたり、
「そもそもの前提を疑いましょう」ってすることで、今目の前にある表面的問題の外に意識が向くようにする。
すると、問題発見した結果、実は本当の問題は下図の右側の緑枠のような複雑怪奇な形をなしていることが判明する。
※実際にはこのような２次元的なものでなく３次元的なものである。
しかもこれはいまこの瞬間というごく微小な時間における問題の形のスナップショットであるため、
ここにさらに時間経過という時間軸も加わると問題領域は４次元的な形の変動をなしていくと考えられる。
だからこそ、何度も反復することでその瞬間その瞬間に応じて、
その複雑な問題の対象領域を把握するために新たな重要な変数を探す意味で現状見えてる表面的問題の枠を外すことが重要である。
発散と収束を繰り返す
まずここでいう発散とは、重要な変数を発見しに行くフェーズのこと。
収束とは見つかった変数の中で、特に重要なものに絞り込んで問題を解決することを指す。
この問題解決をしている段階では、
前提が崩れないようにするために途中で変数を追加するなどスコープが変化するようなことはしてはならない。
変数を追加するなどするのは、次のイテレーションに突入する前段階（下図の①）である。
上図をもとにまとめると、
①発散
で枠を外して「そもそもなぜ？」思想で発散させ問題の発見・変数の発見を行う。
このフェーズにおいて、問題の収束・詳細具体化するのが得意である専門家や
実現手段が気になってしまうような人は、
かえって発散すべき議論に蓋をしてしまう意見を出しやすいため、
PMなどが事前にこのフェーズの議論にそもそも参加させないなどの工夫が必要である。
逆に型に捉われない自由な発想をする者やデザイン思考が得意な人材やステークホルダーは、
このフェーズの議論に積極的に参加させるべきである。
②変数の決定
でその中でもっとも重要そうな変数にのみ絞り込む。
およびこれ以降の④で求められている目標指標に対して、
できあがった成果物がどのくらい誤差発生してるのか？を検証するための仕組みづくり。
(検証材料のためにどんなデータがなくてはならないか？などの設計)
で、これ以降は次の工程の①まで変数を追加してはならない。
この段階で「ところでそもそも～」というように議論が発散しないように、ファシリテーターは工夫しなくてはならない。
これが前述の多変数関数の考察で、
１変数のみ動かしてる最中で別の変数も同時に動かしたりはしないっていう思想そのものだと個人的に考えています。
③問題解決
その後は問題の枠を固定して収束、つまりは問題を詳細化して解決していく。
これ以降の実現手段に詳細化していく過程では、そもそも論を述べてきたり、
自由に議論を発散させることはさせず、
実現可能性などを深く理解している専門家などに積極的に参加してもらった方がよい。
④検証
あらかじめ仕込んで置いた検証用のデータを使って、
できあがった成果物の品質などが、もとの目標指標に対して許容できる範囲の誤差であるか？を検証する。
これがOKだったら、このイテレーションの工程は完了する。
あとはこの上記の①～④を繰り返すだけ。
すると、イテレーション回すたびに形がはっきりしてくる。
(参考文献 具体と抽象トレーニング)
対象とする問題でもっとも本質的な変数
ここについての詳細は別の記事で解説する。
すべての品質特性変数を扱うのは、アンチパターンであるため、
各イテレーションではステークホルダーがもっとも関心を寄せる変数だけに的を絞り込むことが重要である。