要件定義的思考を、ふだん使いして、色んな場面で活かしてみませんか？

機能要件（functional requirement）とは、システムに実装する機能・挙動についての要件のことです。

広範な領域で求められる仕事術（暗黙知）。

この暗黙知（個人の経験や勘に基づく、簡単に言語化できない知識。）。

クライアントの要望と言い換えられます。

その要望を、どのように叶えるのかを文章としてまとめたもの（体系化（形式知化（文章や計算式、図表などで説明できる知識のこと。）））が要件定義です。

つまり、お客さまの要望をまとめる工程である要件定義を活用して、要件定義のうち、必ず搭載すべき機能である機能要件は、以下の視点から整理可能です。

（１） 木ではなく森を見る

（２） 静的ではなく、動的である。

（３） 一方通行の因果関係ではなく、循環（フィードバック・ループ）を重視する。

（４） システムの外部からの影響ではなく、内部で起こることに焦点をあてる。

（５） 要素の羅列ではなく、実際に起こるプロセスに注目する。

（６） 「測れるもの」ではなく、「大事なもの」に注目する。

（７） 何かを証明することではなく、目標の達成に役立つことを重視する。

この思考の活用ポイントは、「ちょっと待てよ」と一歩引いて、私たちがどのように環境を認知し、行動するかを見ることにあります。

できごとを現象だけでとらえるのではなく、どのような因果関係のつながりになっているのか、どのような背景・文脈にあるのかなど、構造の全体像を「見える化」することによって、対象に対する新しい視点と洞察を得ることができます。

とりわけ、組織や業務プロセスなどの集団の文脈では、複雑なシステムの全体像を探り、共通理解を進めるためのコミュニケーションツールの役割を果たすシステム作りの観点が重要となります。

また、対象の課題解決は、次のステップをとると良いと考えます。

順番に挙げてはいますが、けして直線的なプロセスではなく、新しい発見や問い直しなどによって前に戻っては繰り返す循環的なプロセスです。

（１） 課題を設定し、だれがクライアントであるかを確認する。

（２） 時系列で３種類のパターンを描く。

（３） 「今まで」のパターンの構造の仮説を立てる。

（４） ループ図を描く

（５） 「このまま」のパターンを確認する

（６） 構造の仮説を現場で確認する

（７） 「望ましいパターン」を創る働きかけを探る

（８） システムの抵抗を予期する

（９） 働きかけ、抵抗への対策を選択する。

（１０）働きかけを実行する

【参考記事】
システム開発だけじゃない―もっと“ふだん使い”できる「要件定義」（前編）
https://joins.co.jp/ownedmedia/small-win_yokenteigi1/

システム開発だけじゃない―もっと“ふだん使い”できる「要件定義」（後編）
https://joins.co.jp/ownedmedia/small-win_yokenteigi2/

みなさんは、グランドデザインという言葉を聞いたことはありませんか？

一般的な定着の度合いは、十分ではないかもしれません。

類語は、スキーム、マスタープラン、ロードマップ、トータルデザイン、ライフプラン、キャリアデザイン。

それでも、何かを制作したりマネジメントしたりといった仕事に従事する層の間では、かなり浸透しているフレーズです。

経営のグランドデザインなど、壮大なグランドデザインを作るような機会は、一般的な勤め人にはないかもしれません。

でも、自分の人生のグランドデザインを考えることは、人生を充実させるために役立つと思います。

自分のグランドデザインを作り、理想の姿を意識しながら毎日を過ごしてみるのも良いと思いますので、次のような項目について考えていき、実現可能な範囲での理想の姿のイメージを明確に固めてみる訓練でも如何でしょうか？(^^)/

■人生（≒システム）の定義

人生（≒システム）とは、「多くの要素がモノ、エネルギー、情報の流れでつながり、相互に作用しあい、全体として特性を有する集合体」のこと。

■人生（≒システム）の特徴

人生（≒システム）は、さまざまな要素が複雑に絡み合っていて、その仕組みを理解することはしばしば通常の人の認知レベルを超えてしまう。

人生（≒システム）の理解不足のために、人やグループの変化を目指した行動が、予期せぬ結果や副作用をもたらしたり、あるいは意図する変化が抵抗を受けることがしばしば見られる。

これらの現象の多くは、人生（≒システム）のフィードバックによって起こっている。

■人生の設計図（≒デザイン）は、現場観察なくして成り立たない！

・アジャイル開発プロセスの導入

アジャイル開発（「プロジェクトに変化はつきもの」という前提で進められるので仕様変更に強く、プロダクトの価値を最大化することに重点を置いた開発手法）の考えを人生設計に応用してみる。

＜リリース計画＞
アジャイル開発では、ソフトウェアの計画段階で厳密な仕様を決めずに、だいたいの仕様と要求だけを決めます。

これは、「開発途中に仕様や業務内容の変更があることは当たり前」という前提があるからです。

おおまかな計画のみでは、その後の実装フェーズで問題が起こりそうですが、仕様が決まっていないと途中で変更があっても臨機応変に対応できるため、顧客のニーズに最大限応えることが可能です。

この考えって、人生にも十分当てはめて活用できますよね(^^)/

＜イテレーション＞
だいたいの仕様と要求を決めたら、イテレーション（iteration）と呼ばれるサイクルを繰り返して開発を進めます。

イテレーションとは「反復」という意味で、小さな単位に分けられた開発を「計画」→「設計」→「実装」→「テスト」と行いながら、機能のリリースを繰り返します。

人生も、よく見てみると、実に多くの小さな出来事から大きな出来事迄、多種多様ですよね。

であれば、アジャイル開発の流れであるイテレーションを参考にして、自分の人生を小さい単位に細分化して、できるところから、前述の「計画」→「設計」→「実装」→「テスト」と行いながら、スキルをリリースしてみると、過程が可視化されて面白いですよ(^^)/

・変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求。

・技術スキルではなく行動の仕方で、アジャイルに向く向かないが変わる。

・ＰＤＣＡサイクルとＫＰＴ（反省会）を使った振り返りが重要。
Ｐ：Ｐｌａｎ（計画）
Ｄ：Ｄｏ（実行）
Ｃ：Ｃｈｅｃｋ（検証）
Ａ：Ａｃｔｉｏｎ（改善）

・Ｋｅｅｐ、Ｐｒｏｂｌｅｍ、Ｔｒｙのエリアに分ける

■システム・ダイナミクスの基本的な考え方

システム・ダイナミクスの基本的な考え方は、しばしば氷山モデルによって説明される。

すなわち、私たちの関心を集めるできごとや結果は、より長い時間的文脈の中で時系列での「パターン」として理解する必要があること、上昇、下降、安定、不安定、繰り返し起こるなどのパターンは「構造」から起こること、そして構造は私たちがどのようにものごとを見ているかの「意識・無意識の前提（メンタルモデル）」が基盤になって生じている。

■勝てる勝負を探して（作って）、勝ちに行く。

どこで戦うかを選択して、そこにリソースを集中して、勝ちに行く。

特に、組織の能力は、無能力の決定要因になるので、注意が必要である。

■基本精神（マーケティング）

・品質は自分（顧客）が決めるものであり、メーカーが決めるものではない。

・自分（顧客）は買える価格で、期待する品質を決める。それ以上の品質は不要。

・価格を最優先して、品質を合わせこむ。

・技術の供給は市場の需要と等しいとは限らない

・現場で求められる機能を探り出す。

・必要条件：自分の人選も、例えば、１５％のソリューションを、５０％の価格（自分の行いに対する時間単価のミニマム化）で作ること。（リバース・イノベーション）

■人生戦略を寝言にするな！

＜誰でも言える寝言＞

確かに正しい発言だが・・・

・・・の推進：・・・

・・・の必達：ウトウト

・・・の活性化：グーグー

・・・の強化：スースー

・・・の充実：ズォォォ

・・・の（組織）変更：ピクッ！

＜必要なのは行動に繋げること＞

何故？：最も大切

誰が？：次に大切

どのくらい？

いつまでに？

どうやって？：具体的に

できなかったら？：忘れがち・・・

⇒人生戦略で最も大切なのは具体性（重要な所は細部まで徹底的に具体化する！）

⇒理由を頭で理解した上で納得し、かつ腑に落ちないと、人（組織）は変化に頑強に抵抗する。

⇒具体的な指針がないと、人（組織）は絶対に動かない。

⇒主流人（組織）の資源の一部だけを利用し、プロセスや価値基準を共有しないようにする。

⇒分析して成功するよりも、失敗に備えて犠牲を小さくし、試行錯誤から学ぶ。

■リソースをシフトしろ！

目標を実現するには、リソースのシフトが不可欠。

・年収（売り上げ）を倍増するなら、相応の営業活動が必要。

・業務時間を半減するなら、相応の合理化が必要。

・手元にリソース（人員・時間・投資資源）を、どこに突っ込むか？（ＷＨＯ）こそ、戦略の基本。

■目標設定の枠組み「ＳＭＡＲＴの法則」で考える

Specific（具体的であること）

Measurable（測定できること）

Achievable（達成可能であること）

Related（上位目標と関連していること）

Time－bound（期限が決められていること）

■捨てる目標の提示

今までの目標を捨てられないなら、新しい目標は立てるな。

■人生（≒システム）における個別性と普遍性

『経験をいくら集めても理論は生まれない』とアインシュタインは言っている。

観察によってデータをいくらたくさん集めても、既存の理論の検証が進むだけである。

従来的帰納法からは斬新な新理論、イノベーション（あらたな価値の創造）は生まれない。

論証を行うだけである演繹法からももちろん、新しいアイデアや新しい理論は生まれてこない。

つまり、個別の経験や事実を別の視点から総括するアブダクションが必要だ。

記号論の王様、チャールズ・パースは、人間の推論には演繹と推論とアブダクションの３つの形式があると指摘した。

アブダクションとは、説明すべき事実に対してたくさんの仮説を立てて、その中からもっともらしい仮説を選び出す拡張的な推論プロセスである。

パースは分析的推論として【演繹】があり、拡張的推論として【帰納】と【アブダクション】があると整理した。

アイデアや新しい仮説はどうやって生まれるのか。

そのあたらしい考え方がアブダクションである。

ウィキペディアによると、帰納（きのう、Induction）法とは、個別的・特殊的な事例から一般的・普遍的な規則を見出そうとする推論方法のことで、対義語には演繹法がある。

演繹法においては前提が真であれば結論も必然的に真であるが、帰納においては前提が真であるからといって結論が真であることは保証されない。

アブダクションは帰納に含まれるものであるが、帰納のなかで創造性の高い拡張的推論であり過謬性の高い、論証力の弱い推論でもある。

だが、パースによると既存の枠組みを超えるイノベーション（あらたな価値の創造）を生み出すために不可欠な、もっとも優れた推論だと高く評価した。

ここで、思考のプロセスである代表的な演繹と帰納を整理しておく。

●演繹（deduction）

<前提1>　ＡならばＢである。

<前提2>　Ａである。

<結論>　Ｂである。

●演繹ではない推論（広い意味での帰納 induction）

１．枚挙的帰納法（狭義の帰納）

<前提1>　ａ1はＰである。

<前提2>　ａ２もＰである。

<結論>
（たぶん）全てのａはＰである。

２．アナロジー(類推)

<前提1>　ａはＰである。

<前提2>　ｂはａと似ている。

<結論>
（たぶん）ｂはＰである。

３．アブダクション

<前提1>
ａである。

<前提2>
Ｈと仮定すると、ａがうまく説明される。

<結論>
（たぶん）Ｈである。

「アブダクションは最初にいくつかの仮説を思いつくままにブレストするように提起する示唆的な段階と、それらの仮説のなかからもっとも正しいと思われる仮説を選ぶ熟慮的な推論の段階から成り立っている」

仮説はどこから生まれるのか？

仮説は頭の中から自然と涌いてくるものだ。

そこには何の法則も根拠も見えない。

そこには、ただただ思いがけない創造的な飛躍がある。

なぜヒトは「ひらめく」ことができるのか？

なぜ人間は創造性を持っているのか？

それは進化生物学的に説明がつくとアブダクション研究者は考えた。

生きていくための問題をとくためには発想力が必要だ。

アブダクションは人類進化の過程で自然に適応するために人間精神に備わった「自然についての正しく推測する本能的能力」であると考えた。

アブダクションでは、そうした「示唆的段階」で生み出したたくさんの仮説（アイデア）の中から、

１　もっともらしさ　もっともらしい理にかなった仮説

２　検証可能性　実験的に検証可能な仮説

３　単純性　より単純な仮説

４　経済性　実験に経費、時間、思考、エネルギーが節約できる仮説

という基準で、もっとも正しいと思われる仮説を選ぶ熟考的段階に進んでいく。

アブダクションという厳密でない推論こそ人類の叡智の中核をなす能力と言える。

人間には創造性が進化の過程でビルトインされている。

何をシステム（≒人生）化するか？

大切なことは、「何をシステム（≒人生）化するか」ということを確定することである。

<参考事例>
面白かったのは、占いはアブダクションだとする「占いの力」著者である鈴木淳史さんの考え。

演繹法では、

（ルール）赤いものを持っていると幸せになる

（実例）赤いものを身につけていた

（結果）幸せになった

の順序であるが、これでは説得力に欠ける。

赤いものを持っても良いことがなければ、信用度が落ちる。

帰納法では、

（実例）赤いものを身につけていた

（結果）幸せになった

（ルール）赤いものを持っていると幸せになれる

となる。

が、これでは、実例と結果の間の推論がどう考えても不自然に思われる。

だが、あらかじめルールを暗示しておいた場合、

アブダクションでは、

（ルール）赤いものを持っていると幸せになる

（結果）幸せになった

（実例）赤いものを身につけていた

という構造になる。

たまたま、幸せになった人たちが、予め暗示されたルールを、因果関係として推論することで、納得してしまうという説。

後だしジャンケンみたいなものだが、これが占いの本質であるとする。

【参考記事】
投資家や父としての顔も持つ起業家が語る「人生をシステム化して上手く生きる方法」とは？
https://gigazine.net/news/20191005-quest-be-good-at-everything/

■人生（≒システム）検討時の注意点

・「あるべき人生モデル」とそれを実現するための人生（≒システム）機能が、運用可能なものであるか、本当に期待する効果を挙げることができるか検証する。

・今回の人生のイベント（プロジェクト）では、どこまでの範囲をシステム（≒人生）化するのか確定する。

・知識を得ただけで、自分たちの状況や立場を一気に改善できる人生（経営）戦略がつくれるわけではない。

・当然ながら完成型は無く、正解を探し続ける必要がある。

・いろんな問題があり、試行錯誤を繰り返した結果、当事者にとっての価値というものができていくものであるから、そのプロセスで生まれる下支えするベースこそが強みであり、目に見えない資産となる。

・簡単に答が出ることに価値はない。

・どんな”知識”も”経験”が伴わないと”知恵”にはならない。

・出来事（人生（設計）プロセス）は言語化されたときに、その本質的な他者性（客観的な視点）を失って、既知の、無害で、なじみ深く、馴致された経験に縮減されることから、どのようにして人生（設計）プロセスのエンジニアリング（開発と改善）内容を毀損することなしに、それを言説のうちにもたらしきたすことができるのかの配慮が必要。

・自分の思考の道筋（ロジック）を見ただけでは、その自己の人生設計の思想が十分には伝わらない。

結局、言語によってしか出来事を伝えることができないため、人生の設計書の充実が必要となる。

・自身（設計）の暗黙知及び形式知というのは、何を知っているかではなく、何を知らないか、問いを持っているか、といことである。

自分が間違っているのではないかと疑うことが大切である。

・人生の設計書に対して、自分が誤り得ることについての査定能力に基づいて判断することができない。

平たくいえば、自分のバカさ加減についてどれくらいリアルでクールな自己評価ができるかの基準が自身にも、必要な条件（自分が間違っている可能性を吟味する機能など）となる。

・自身が選択した各種の思考ツールは、そのツールの正しさを主張するのみである。

したがって、様々な人生設計的不合理を改め、人生設計のプロセスを少しでも効率よく進めてくれるのは、自分は間違っているかもしれないと考えることのできる他視点の機能を、自分自身の中に要求定義する必要がある。

正しいことを論証できる機能要件の対象範囲として、標準データ（例えば、本とか論文）のみに限定する。

・人生（≒システム）は、正しいと思われる人生設計の結果を近似しているに過ぎない。

次元を下げれば下げる程、その対象の本質的な意味合いは失われていく。

■人生に対する個人要求の持つ三つの性質

・人生設計するユーザーは、自分の真の要求を正しく伝えられない。

・要求は時間の関数である。

・すべての機能（要求）には理由がある。

■人生に対する個人要求（機能要件・非機能要件）の漏れをなくすための確認項目

・Functionality（機能）：機能要求、セキュリティ、汎用性、将来性。

・Usability（操作性）：使いやすさ等の分かりやすさの人間的要素、整合性、見栄え、利用マニュアル。

・Reliability（信頼性）：可用性、故障頻度と深刻さ、復旧性、正確さ、予見性。

・Performance（自身の性能）：実行速度、スループット（一定時間内に処理できる情報量）、応答時間、リソース（貯蓄・知識・知恵等）の消費量。

・Supportability（自身の保守性）：テスト（試行錯誤）のしやすさ、拡張性、適応性、保守性、運用性、構成のしやすさ、ローカライズのしやすさ。

・＋（Plus=その他）：アーキテクチャ、開発言語、ミドルウェア、パッケージソフト、ハードウェアの種類、ネットワーク構成、関係する法律。