サマリ
ある SharePoint 2007 を利用した、社内ポータルの導入でのお話です。
基本設計書の位置づけとはどうあるべきなのでしょうか？
パッケージ システムの導入とスクラッチ開発とでは設計および製造というものは大きく異なりますが、要件-設計-製造で変わらない関係があります。
大企業の社内ポータル構築プロジェクトにて、入れ替わりで入ってきた女 PM と取り巻きメンバー 2 名によるトンチンカンな認識で、てんやわんやになった失敗談です。
「設計書は実装者が考えなくてもいいレベルで 詳細に書くべきだ」と思っている人は必見です。
基本設計書の方針作成を八部合意
今回のプロジェクトは、社内ポータルを SharePoint 2007 で構築する、という案件でした。
私は要件定義の段階から基本設計まで、技術補助として参加しておりました。
SharePoint をほとんどわかっていないお客様に、やや強引ながら、こちら側が提案する形で進めていたため、後で細かい要件が修正されることは予想できます。そのため、お客様も
「基本設計書は、ざっくりした形体にしてくれ。イメージがつかめる程度でいい。」
と言っておりました。
パッケージ CMS の導入では、このような要件の「八部決め」はよくあります。基本設計書フェーズでは、大まかな方針と実装方式を決定し、レイアウトやカラーリング、権限名（例：「トップページ管理者」「広報記事編集者」等）のような細かい事を詳細設計のフェーズに移る直前にこちら側で決めて提案するのです。
暴走 PM とメンバーが登場
ここで、プロジェクトに大きな変化が起こりました。
急遽リーダーが変わることになり、女性のリーダーが指揮を執ることになったのです。同時に彼女はメンバーも彼女の配下である、忠誠を誓ったような若いエンジニア２名に入れ替えてきました。この新リーダーと新メンバーは、あまりエンジニアスキルに長けた人たちでもありませんでした。これが後々、大きな弊害を引き起こすことになりました。
社内レビューで暴理がまかり通る
私が仕上げた基本設計書を社内レビューでプロジェクトメンバーに見せました。
お客様との合意である「八部要件」も頭に入れながら、設計には詳細なパラメーターを記述しておりません。
基本設計 (外部設計) とは、実装ではなくお客レビューを意識した設計なので、作業員しか知らなくてよい細かいシステム パラメーターを書くのは不適切です。
レビューを初めて間もなく、ドロンジョ様、もとい、女性プロジェクトリーダーとその配下メンバー２名が次々にかみつきます。
ドロンジョ「ここのパラメーターはどうなってますか？」
私『今時点では記述はしてません。細かいのはあとでこちらから提案してパラメーターシートに書きますよね？』
（※ パラメーターシートは詳細設計書にあたります）
ドロンジョ「パラメーターシートも作りますよ。」
私『じゃあ、これはパラメーターシートの直前の段階で決めることですよね？』
ドロンジョ「いえ、これ（基本設計書）をもとに構築をします。構築者が困らないように詳細なパラメータまで書いてください。ほかのプロジェクト同様に」
私『構築はパラメーターシートをもとに作るはずですよ。また、お客様との合意もあり、基本設計は具体名などの細かい設定値を省いて記載しています。今決めても必ず後で修正になりますよ？』
ドロンジョ「でも作るのが普通なので作ってくださいよ」
この新プロジェクト リーダーのもとでは、お客との相談の結果決めた、抽象レベルの高い設計書を作る、という話はなかったことになりました。お客様との内容が引き継がれていなかったわけではありません。単にこの女性リーダーは、他の SharePoint プロジェクトでそうした様に、さっさとウォーターフォール式にすすめてしまおうと思っていたようです。
さらに、この女性リーダーの後押しをするように、ドロンジョ様配下の男が食いつきました。
ボヤッキー「グループ (SharePoint Group) の記述がここにあります。グループ作ってから下位サイトを作るのですか？サイトを作る時点でグループは同時に作成できますよ。」
彼は、設計書で SharePointグループの設計と下位サイトの設計を分離していた事にかみつきました。
言わずもがなですが、設計書というのは、要件を実現するためのシステムの設計を書くものであって、構築手順を書くものではありません。
実際に SharePoint で構築操作をすると、確かにサイトを作成し終わった直後にグループ作成画面に自動的に遷移します。ただし、それは画面上それが見えるだけで、そこで設定するものではありません。どちらにしてもパラメーターシートと構築手順書こそが、構築作業を定義するモノです。今回の基本設計書も当然のようにSharePoint グループとサイトの設計は分離して書きます。
重ねて言いますが、基本設計 (外部設計) とは顧客によるレビューを意識したものでもあり、構築を意識したものは「内部設計 (パラメーターシート)」です。
そのため、私は答えました。
私『設計ではこう書いてます。手順を書いてるわけではありません。実装上それが簡単なら実装者の判断でそうします。』
ボヤッキー「基本設計でも実装者が実装するように (手順どおり) 書かないとわからないじゃないですか！」
私『構築手順書とパラメーターシートは？』
トンズラー「それも必要です」
私は、実装を考慮した過度の具体性を持たせることに抵抗しましたが、なにせ今回のメンバーは、エンジニアとしての技量が乏しいうえ、女性リーダーと鉄の結束意識を持っています。私もSharePoint の専門家として協力しておりましたが、その専門家の意見なんて通してくれません。
ここで私はもっと強く出るべきでした。しかし、それをしなかったことは、のちの実装フェーズで大きな負担となりました。
構築作業で地獄が始まる
私が作った「実装のための基本設計書」はお客様のレビューも通り、お客様のところで常駐しての実装作業のフェーズへと移りました。
今回のプロジェクトの進め方では、パラメーター レベルの変更を後で決めることになっています。
作業が後半に進むにつれて、お客様の SharePoint の理解も進み、修正の要望を出してきます。私も専門家なのでこのくらいは予想済みです。
実装の修正は簡単なものです。しかし、今回は同時に詳細設計だけでなく基本設計書も整合性をもって修正しなければならなくなりました。当然、納品フェーズを終えた基本設計書ですから、修正するたびに納品後修正ということで、毎回レビューと承認が必要になります。
さらにやっかいなのは、設計を修正するのは一人でも実装を修正する者は一人ではないので、当然ながら不整合が生じやすく、数千～数万もあるパラメーターシートの項目を一つ一つ確認しながら整合性を検査する作業が度々必要になり、それに加えて基本設計の再レビューも発生し、作業コストがとてもかさむようになりました。
そんな中でも、名称や動作の細部変更依頼は次々にやってきます。
基本設計書は、もはや最初のものからは原形をとどめないくらいの修正がなされていました。
ボヤッキーは、その状況にて
「もっと要件定義をしっかりしないからこうなったんだ」
と言っていました。
違います。要件の大枠は決まってます。進め方に合わせた外部設計/内部設計を構えるべきなのです。それが設計士です。
要件 – 設計 – 実装の汎化・洗練関係とは？
さて、社内レビュー時の話に戻ります。一般論として、今回のプロジェクト新リーダー＆新メンバーが設計書に関して口に出したことは、別に間違っているわけではありません。
しかし、今回に限れば間違いである点が一つありました。それは、基本設計書の抽象レベルの認識です。
通常の開発現場でも、「詳細設計書は実装者が考えなくてもいいレベルで 詳細に書くべきだ」と、勘違いする人がいますが、それは大きな間違いです。
ソフトウェアファクトリーの理論 (Microsoft PnP 04) によれば、要件・基本設計・詳細設計・実装などの各フェーズは、「凡化」と「洗練」（特化）の関係にあると言えます。
各フェーズとも、下位フェーズから見た上位フェーズは「仕様」として映り、上位フェーズから見た下位フェーズは「実装」に見えます。
そして、一つの「仕様」に対して、複数の「実装」が存在する、１対Ｎの関係がそこには存在します。
今回の女性 PM & メンバーのやり方では、以下のようになります。
※ 最後の「詳細設計書 ＝ 実装」の部分でパラメーターシート（詳細設計）の作成コストが実装を上回るという逆転現象は起きますが、パッケージソフトの導入なので、そうなります。性質上、これは実装からジェネレータを使ってジェネレートすべきものですので、当然かもしれません。それはまた別の機会にお話ししましょう。
さて、今回のように「凡化」と「洗練」の関係が正しく守られなかった場合は、上位フェーズのコストが下位フェーズに限りなく近づく（場合によっては上回る）ことを意味します。
上の図で、もし、下位の３つの抽象レベルが等しかったら、下位フェーズの変更がそのまま上位フェーズにのしかかることがわかると思います。
そして、ヒューマンリソースの観点では、上流フェーズで「特化した専門家」の役目が終わり、
以降のフェーズでは単純な機械的作業者（タイプライター）のみが必要と言うことになります。
たとえるなら、設計書のレベルがプログラム コーディングに限りなく近づくわけです。そして、コーディングを行う者は特に専門性を必要とせず、マシンのようなコーディング作業のみをすることになります。
通常の、下位フェーズに行くにしたがって特化した作業知識が必要になる、という構図には反しますし、なにより設計士をコーダー並みに揃えたらコストも大きくなります。
今回の彼女らの要求は「実装が１つになるように仕様書を作れ」ということでした。
今回のように要件定義レベルでお客の理解が足りない場合、きっちりした定義がなされることはありません。特にデータではなく「コンテンツ」を扱うCMS ではよくあることです。
よって、設計書のほうも多々修正が発生することは肝に銘じなくてはなりません。
それゆえに、お客との間に「ざっくりとした設計書を作ってくれ」との要求が出てくるのです。
現時点のお客の理解度 (＝事後変更の可能性) も見抜かなければなりません。
先に若いエンジニアが言った言葉「もっと要件定義をしっかりしないからこうなったんだ」は、的を外していることがわかると思います。
ポータル作成のような UI とコンテンツ中心のシステム導入では、ウォーターフォール式に事が進むわけはないので、構築結果を見ながらの修正は当たり前です。
そうなると、必要なのは基本設計書をいかに揺らぎを持たせて作るか、ということです。
プロジェクトマネージャーも、ウォーターフォール型の常識を捨てて、プロトタイプ型寄りのプロジェクト体制を敷き、基本設計書のあり方をとらえるべきでした。
経験と偏見を分かつものはありません。これまでの経験だけに頼らず判断する。これが プロジェクトの専門家としての腕だと思います。
学習しないエンジニア
いままでこの方法だったから、これからもそうだ、と主張するのは、技術者としては愚の骨頂です。
専門性とは都合のいい状況を前提にした行動力のことではありません。知識に裏打ちされ、状況に合わせた適切な解決力です。
今回の若いメンバーも、思考停止に陥って何も考えずに着々と「作業」を進めていました。
しかし、地図を見ずに道を歩いてきたツケは、どこかで出てくるものです。
今はいいかもしれませんが、技術的応用力を試されたときにはさすがに困ってしまうことになります。
私はこういったことを教えることなくプロジェクトを離れてしまったことは、今でも心残りです。