Knowledge Crunching【P13】 †
要約 †
- 素材は、業務の専門家、既存システムのユーザや似たようなシステムに関わっている（いた）技術者から提供される。
一方、知識の咀嚼は、設計チーム者が主導となるが、業務の専門家も参画する。
- 素材の受領→知識の咀嚼→整理、単純化のサイクルを試みる事で、プロジェクトの中で使われるドキュメントへと変わっていく。
- 何度も何度も話し合い、プロトタイプを作成することでチームは情報を共有し、より有効な設計ができるようになる。
- WaterFall?の大きな問題は、プログラマーの意見が知識の咀嚼作業時に反映できていない事である。
プログラマーが咀嚼作業に参画することは、拡張性を高める為、顧客の本来の要件を満たす機能の実装の為にも重要である。
- 反復される知識の咀嚼による要件の精錬作業は、参加者を変えて、全ての開発メンバーが参加するべき。
こうする事で、実装される処理が何の為に存在しているのか？という事への理解が強制的される。
担当者のつぶやき †
要件定義、基本設計の段階から業務知識に強い者だけでなく、技術に強い者も参加させる事には大賛成だが、コーディングする人、全てをこのフェーズで参加させる事はプロジェクトの規模によっては無理だと思う。
インフラ、DB、アプリケーションのスペシャリストで十分ではないか？
各スペシャリストは可能であれば複数集めた方が良いと思う。
みんなの突っ込み †
- 「ドメイン設計」って言葉出てきます？ knowlegde crunching がドメイン設計になってる気もするけど，それはちょっとおかしいような．DDD はドメインで設計を駆動するということでドメイン自体を設計するというわけではないし，ドメインは元々そこにあるもので設計するものじゃないのではないかと (ビジネスエンジニアリング的にはビジネスも設計対象だろうけど)．knowledge crunching は分かりにくいけど，知識を咀嚼する→理解するって感じでいいんじゃないかなぁ． -- 小林 (koichik)?
- ちなみに，「その数学が戦略を決める」の原題が「Super Crunchers」で，super crunching の訳語が「絶対計算」ですが，賛否あるみたいですね． -- 小林 (koichik)?
- 小林さんありがとうございます。「ドメイン設計」＝「要件定義」という印象だったのですが、ドメインは元々そこにあるもので設計するものじゃないというご指摘で認識を改める事ができました。業務プロセスの整理、スコープの決定などは、咀嚼作業であるとともに、ドメインからの設計作業ではあると思いますが、ドメイン自体の設計ではないですね。修正させていただきます。 -- 池田?
