データモデルを上流設計で決めてしまう方がよいという考え


システム開発方法論とテラーリング
プロジェクト管理手法の上に載せるシステム開発方法論は王道のウォーターフォールから新興勢力から着実に支持を広めているアジャイルなどから、それらをベースにした各種の亜流、傍流が試行錯誤しながら拡散と収斂を繰り返している。それでもやはり、ウォーターフォールは王道であって、成功も失敗も実績が多いことからその信頼は厚い。
特に労働集約的な生産性を求める金融再構築プロジェクトなどの場合は、そのプロジェクトに召集するエンジニアの質がアジャイルで求めるような自己組織化できる自律したエンジニアというフィルタがかかると必要な人数を集めきれないから、標準化という規律を適用しやすいウォーターフォールが採用され続ける。
プロジェクト管理手法は、PMBOKを見てもわかるがプロジェクトを管理するフレームワークであって、乱暴に言えば単なる器でしかない。具体的なシステムの設計や開発の“やり方”はそこにはない。同じようにシステム開発方法論についても、プロジェクト管理の上でのプロセスを定義するにとどまり、システム開発の現場で即実践できるまで踏み込んだhow toまでは言及しない。あくまでも、

「こんなやり方があるよ。こんな風に使うよ。」

程度のものだ。なぜなら、プロジェクトは唯一無二であって、押し付けられないからであり、採用する側が“考えて”、何をどのように取り入れて、具体的に箸の上げ下ろしまでの運用をテラーリングする必要があるからだ。


データモデルを上流工程で終えられない副作用
プロジェクトマネージメントの考え方はさまざまあるだろうが、プロジェクト管理手法は器であって、システム開発方法論は、器に盛る料理の作る技術であるとも言える。料理に使う素材は、そのプロジェクトの調達の文化により何をどのように仕入れるか、レシピで示された素材が入手できないときに何で代替するかも含め、個々のプロジェクトに強く依存するから必然とアレンジすることになる。和食に喩えるなら、料理の骨格となる出汁をデータモデルと位置づけるなら、料理を良くも悪くも変えてしまうのが出汁であって、最初の段階でその料理の特性を決めてしまう。
システム開発もフィーチャーの設計や実装の裏には、データモデルなどもあって、システムを支える柱がいくつかある。データは、その生成から破棄までがライフサイクルで成り立つので一貫したモデル設計が必要であることは多くを語る必要なないと思う。そのデータを業務のフィーチャーと整合性を持って概念化し、データモデルとするがそのモデル化する時期については上流設計と言う“要件定義”と“基本設計”の二つのフェーズを跨ぐような形で進めることが多いのが現状だろうと思う。どちらかと言うと、実質は、上流設計の中の“基本設計”でほぼ吸収していることが多く、データモデルの設計が追いつかない場合、詳細設計までなし崩し的に突入し、データモデルの変更を製造フェーズにまで引き込んでしまっている事実が顧客にもわかるようになってしまっていると、データモデルに変更をかけてしまう業務仕様を変更を安易に引き起こしてしまう原因をシステム開発を担うSIer自身が生じさせてしまっていることに気付かないことも少なくない。


ほぼ確定、すこしは柔軟に
業務仕様が変わるということは、データモデルにも手が入ることの可能性を意味しており、更には関連するすべてのフィーチャーの設計からプログラムまで横並びで影響の有無を点検するような無駄な作業を生じかねさせない。それを防ぐには、上流工程でデータモデルをfixさせることであり、それをできるようなシステム開発方法論を取らなくてはならない。システム開発をする側がデータモデルをする時期をシステム開発のプロセスとして組み立て、実行する必要があり、それに沿ってプロジェクトを進めることを顧客に提案し採用させる必要がある。つまり、契約で謳う提案仕様の中でプロジェクトのキャリーの仕方を見積もり仕様として組み込み、そのやり方で顧客から対価を受け取るということになる。
合意されたシステム開発プロセスで、実際にデータモデルを上流で設計するときには、それができるようなシステム要件の聞き方や、何がデータモデルとして必要なのか、具体的な段取りを確立しておく必要がある。それが出来なければ上流工程でのデータモデルの確定は多難を極めるだろう。
データモデルに必要なコアなデータ属性はあらかじめ決めておく。その上で顧客の業務を載せ、システム運用と業務運用が回るようにする必要がある。そのためにもコアなモデルはプロジェクトを始める前には必要であって、もし、都度、一からコアなデータ属性を作り上げるのであれば、その業務精通したデータモデルのプロフェッショナルが必要になるだろう。
データモデルをどのフェーズでどのくらいの工数の割合でやればよいだろうか。実際にある業務システムで実践していたケースでは、業務モデルから利用者が生成してから破棄するまでのモデル化から必要なデータのCRUDを導き、データモデルを仕様として確定するまでを次のようにしていた。データモデルの全体の枠の設計から個々のデータの取りうる値まで、ほぼ80-90%を要件定義で決めるようにプロジェクトをファシリテートしていた。基本設計では、実装に係る実現仕様とより具体的な業務フローの整合性からの手直し程度にとどめるように顧客と意識をあわせながら進めた。要件定義でほぼデータモデルを決めてしまうと、顧客はより現実的に新しい業務プロセスを意識することができ、現実的な業務フローを妄想する時間をプロジェクトが開始したばかりの1-2ヶ月の時点で経験することになる。顧客がプロジェクトを開始して早い時期にリリースしたシステムの業務を意識すると言うことは、受け入れ試験から移行、システム利用を早い段階で意識できる良い面の効果も伴う。さらに、要件定義でデータモデルを顧客と同意することで、データモデルの変更には、顧客自身がその変更の必要性について慎重になる。





  • 道具室(アプリとか)

ストーリーポイントと理想日の違いが、中々腹に落ちず。頭でわかっているつもりでも、胸がすっきりしない感じ。自分の言葉でうまく言い替えられなければ本質的に理解しているといえないとわかっているから、ちょっと歯がゆい日を何日か過ごした後、ふと「あぁ、それでいいじゃん」と思うときが間々あるもので。大げさに言えばブレークスルーした、みたいな。実際適用するなら経験のないチームには理想日のほうがWBSの展開で経験をしているから取っ付きやすいだろう。理想日でボトムアップで積み上げるか、仮定か一般的な画面などチームで作業のプロセスとボリュームの共通認識を作ってそれを基軸にほかの作業を計るか。積み上げは抜け漏れの恐れや仔細な仕様の有無に無駄な時間をとられるから、短時間に“大体の”見積もりをするというプライオリティなら必然とストーリーポイントになるだろう。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)
  • 視聴覚室
  • 調達室