<< オブジェクト指向とは、モノ指向であり、目的指向である | main | 「仕事」を探す、URI 設計。 qeury 文字列方式は使わないぞ! >>

RDRA リレーションシップ駆動分析から、いよいよ実装へ

求人と採用支援システムの開発案件で、3週間ほどかけて、基本的な要件を定義してきた。

基本の手法は、RDRA ( リレーションシップ駆動分析 )。
モデリングツールとして、Enterprise Architect 、コミュニケーションツールとして、オンラインは、37 signals のベースキャンプ、オフラインは、もちろん、ホワイトボード。

簡単な振り返りと、今後の進め方を、ここで立ち止まって、整理しておこう。

(1) RDRA:システム価値を明らかにする


コンテキストモデルで、アクタと外部システムを洗い出すところからスタート。
要求モデルは、ちょっと、つっこみが足りない。

総論というか、一般的な「ニーズ」で、このシステムのこだわりポイントとか、キモになるポイントの具体的な検討がもっと必要。

もっとも、「検索の軸」それと「選考業務支援の軸」について、それぞれの選択肢の中から、こだわりポイントがはっきり選べたので、方向感はでてきた。

また、サイトの運用についても、初期の段階の方針も決まったので、システム要件としては、だいぶ明確になった。

概念モデルも、この段階では、まあ、いい感じで、描けたと思う。

まあ、求人・採用ドメインで、いろいろな案件を、5年間も手を変え、品を変えやってきているので、この程度のことは、さくっとできないとまずい。

(2) RDRA:システムの外部環境の確認する


基本的な業務の流れは、比較的、単純だったので、この段階のモデリングは、さらっと、流した感じ。

ただし、「選考プロセス」が、かなりの問題。
大きな手順は、応募>書類審査>面接、なんだけど、ケースバイケースで、業務のやり方は、かなりバリエーションがでてくる。

ここは、「プロトコルモデル」と「イベントモデル」で、分析・モデリングすることで、なんとか、道筋が見えてきた。

「求職者」と「採用担当者」という、「人」と「人」との間の連絡プロトコルという視点で、モデリングをはじめて、ようやく突破口を見つけることができた。

<反省点>
この時点で、画面とか、サービスクラスやシーケンス図という、実装レベルに入りこみすぎて、2日程度、時間を浪費した感じ。

やはり、「関心事」の分離は、モデリングのやり方の鉄則。

RDRA や、ICONIX という方法論の良いところは、「このステップでは、この関心事に注力する」「この関心事は、先々、ここでやればよい」という、具体的なガイドラインがあること。

しかも、RDRA も ICONIX も、形式的ではなく、「必要なことを、必要な時、必要なだけ」やればよい、という、軽量化され、ひきしまった手法なので、実践的。 コストパフォーマンスが良い手法。

(3) RDRA:システム境界


先ほどのプロトコルモデルなども参考にしながら、全体のユースケース、キモになりそうな画面などの洗い出しを、今日の午前中で、いちおう達成した。

概念モデルは、初期に洗い出したもので、この段階までは、ほぼそのままでやれた。


A4の1枚に収めた、ユースケースモデルの全体図(パッケージ図)をみると、「選考業務の支援」だけが、突出して、ユースケースが多いのが一目了然。

この部分の概念クラスモデルは、かなり、検討の余地がある。

いずれにしても、今後の開発の主要課題のひとつが、この「選考業務の支援機能」のモデリング、設計・実装にあることは明確。

ユースケースモデルでは、仕事を探すためのユースケースパッケージは、現時点では、シンプル。これは、「軸になる検索・ナビゲーション」だけに、絞ってあるから。

プロジェクト全体では「検索・ナビゲーション」については、いろいろ、要望があとからでてくることを想定している。

この、「検索・ナビゲーション」の「後から要望」に、どう対応していくかも、プロジェクトのまわし方としては、大きなポイントだと思っている。

技術課題


携帯サイトおよびそのSEO対策に関する、要求と実装技術が、技術面では、大きな課題。
キャリアや端末ごとの端末特性の違い、セッション管理や文字コードなど、PCブラウザとは、ことなる世界。

ここは、テスト環境やテスト方法の問題もあり、経験者にサポートしてもらえる体制にはしているが、見えていないことが多く、かなりのリスクポイントだと思っている。

チームビルディング


携帯サイト固有の問題以外は、基本的なアーキテクチャや、モデリングの考え方は、ある程度、実績があるもの、その延長上のものを使う。

Spring 2.5 系から、 3.0 系に移行するところ、特に、 JSR-303 対応の アノテーション方式の Bean Validation と、Spring 3 MVC を使った、REST スタイルの Web MVC の実装は、このプロジェクトで、初めて、実戦配備する。

この点は、いままでも、いろいろ相談にのってもらっていた、Spring のエキスパートを確保できたので、まあ、リスクは小さいと思っている。

一番のリストは、開発チームが、今回はじめて、召集した、寄せ集めチームである点。

こちらは、今まで積み重ねてきた、手法や方式の延長上で、やっているけど、今回、初めて参加するメンバーたちに、その内容をキャッチアップしてもらうのが、目先では、かなり重要なリスク要因だと思っている。

キャッチアップにてこずるようだと、スケジュール面と、たぶん、品質面、それも、「変更容易性」に、だいぶインパクトがありそう。

リスクとの戦い方の方針


RDRA で、要件をある程度、固めたことで、ようやく明らかになった、上記の4つのリスク課題について、基本的な方針。

選考業務のモデリング、設計・実装


RDRA レベルの要件定義がいちおうできた。
ここから、先は、ICONIX の手法で、詳細を詰めていけば、なんとかなりそう。
担当者が私になるのが、リスクといえばリスク。(いろいろ兼任しちゃっていて、ここに集中できなそうだから)

RDRA の成果で、ユースケースモデルは、だいたい固まった。
それをさらに詳細化した、画面の紙芝居(画面・帳票モデル)と、要求事項を情報源にして、初期のドメインモデルと、ロバストネス分析から入る。

シーケンス図に進めためには、ドメインモデルやサービス層のクラスの設計パターンを、もうちょっと、詰める必要がある。

ここは、マーチン・ファウラーの Event Sourcing パターンと、エヴァンスの DDD ( Domain-Driven Desing ) のパターンを参考にして、アーキテクチャを固める必要がある。

とくに、「イベントオブジェクトの生成」「イベントのハンドリングサービス」「イベントに付随するデータの扱い(イベントデータ)」あたりの設計が、キモになりそう。

仕事の検索・ナビゲーション


ここは、要求事項をひっぱりだしながら、個別に、対応していくしかないと思っている。

手法としては、基本的には、データモデリングに、振り切ってしまおうかと思っている。
検索やナビゲーションの要求の実現手段としては、結局、

・検索キーの特定
・検索の高速化手法(アプリケーションレベルでのインデックスの設計・実装)
・多対多関係の解決(交差エンティティの設計・実装)

という、データベース系の、設計・実装が中心になるから。

ドメインモデルの観点では、「 Repository インタフェースの設計 」が関連するくらい。

ドメインモデルの実装オブジェクトのメモリー上での操作よりも、データアクセスレベルの SQL での解決が基本になると思っている。

ここは、いろいろノウハウもあるので、要求がいろいろでてきても、対処はできそう。
(開発パワーの余力が問題)

携帯サイト固有の技術課題


これは、基本的には、課題は、列挙できている。
というか、携帯サイト用のフレームワーク mobylet の仕様を理解して、使いこなすことが、唯一の解決策、とみている。(個別の調査・開発していては、まにあわないので、フレームワークのサポート範囲で、最大限の効果を狙う)

mobylet の機能リストの中ら、要求の重要度と、技術的な難易度(自分たちの不安の度合い)を、にらみながら、やばいネタ順に、やっていくしかないと思っている。

問題は、ここの担当メンバー。 かなり、レベルの高いメンバーをアサインすべきだが、ここにいつから、どの程度、集中できるかが、現時点では、明確でないのが、いちばんの不安。

逆にいえば、携帯の領域以外の、他の技術方式のスキルを、他のメンバーに、いかに、はやくスキルトランスファーできるかという、次の課題と密接に関連している。

スキルトランスファーとチームビルディング


現在、ドメインモデルと、データモデル、データアクセス(O-Rマッピング)という基本部分のスキルトランスファーを進めているところ。

モデリングのパターンや考え方と、Spring / MyBatis / JUnit DBUnit の実装技術と、両面から、実際にやってもらっている最中。

経験は豊富だし、発想も柔らかいメンバーなので、キャッチアップは、まずまず順調。

問題は、Spring MVC と、Spring Web Flow という、UI レベルの技術方式のトランスファーがこれからの点。

ここらへんは、全体モデルの一部をうまく取りだして、シンプルな構造と仕様にした、習得重視にミニプロジェクトを、8月の2週間くらいで、やれば、なんとか、なるんではないかと推測している。

そこがうまくいけば、先ほどの、携帯サイト固有技術の課題に、アーキテクトを振り向けられる。

うまくいかない、雨の日ケースの想定と対応


ある程度の経験と勘で、リストを織り込んだ上で、上記の戦い方で、なんとかなるかと思っている。

ただ、いろいろ、雨の日コースも想定しておこうとは思っている。

いざという時のためには、やはり、やばそうなところを、最初に集中して叩き潰したほうが良いとは思う。
目先、まわりから、目に見える成果が少ないけど、システム開発の勘所みたいな箇所が、確立したほうが、結局は、プロジェクト全体が安定するから。

なかなか成果が見えないことに対する、説明責任、関係者に信頼してもらえるようにするもの、私の大きな責任になりそう。

また、兼任の仕事が増えた。 一人がいろいろ兼任で担当する、という計画自体、かなり問題なんだけど、この程度のやり方でやらないと、プロジェクトはまわりませんからね。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM