求人と採用支援システムの開発案件で、3週間ほどかけて、基本的な要件を定義してきた。
基本の手法は、RDRA ( リレーションシップ駆動分析 )。
モデリングツールとして、Enterprise Architect 、コミュニケーションツールとして、オンラインは、37 signals のベースキャンプ、オフラインは、もちろん、ホワイトボード。
簡単な振り返りと、今後の進め方を、ここで立ち止まって、整理しておこう。
コンテキストモデルで、アクタと外部システムを洗い出すところからスタート。
要求モデルは、ちょっと、つっこみが足りない。
総論というか、一般的な「ニーズ」で、このシステムのこだわりポイントとか、キモになるポイントの具体的な検討がもっと必要。
もっとも、「検索の軸」それと「選考業務支援の軸」について、それぞれの選択肢の中から、こだわりポイントがはっきり選べたので、方向感はでてきた。
また、サイトの運用についても、初期の段階の方針も決まったので、システム要件としては、だいぶ明確になった。
概念モデルも、この段階では、まあ、いい感じで、描けたと思う。
まあ、求人・採用ドメインで、いろいろな案件を、5年間も手を変え、品を変えやってきているので、この程度のことは、さくっとできないとまずい。
基本的な業務の流れは、比較的、単純だったので、この段階のモデリングは、さらっと、流した感じ。
ただし、「選考プロセス」が、かなりの問題。
大きな手順は、応募>書類審査>面接、なんだけど、ケースバイケースで、業務のやり方は、かなりバリエーションがでてくる。
ここは、「プロトコルモデル」と「イベントモデル」で、分析・モデリングすることで、なんとか、道筋が見えてきた。
「求職者」と「採用担当者」という、「人」と「人」との間の連絡プロトコルという視点で、モデリングをはじめて、ようやく突破口を見つけることができた。
<反省点>
この時点で、画面とか、サービスクラスやシーケンス図という、実装レベルに入りこみすぎて、2日程度、時間を浪費した感じ。
やはり、「関心事」の分離は、モデリングのやり方の鉄則。
RDRA や、ICONIX という方法論の良いところは、「このステップでは、この関心事に注力する」「この関心事は、先々、ここでやればよい」という、具体的なガイドラインがあること。
しかも、RDRA も ICONIX も、形式的ではなく、「必要なことを、必要な時、必要なだけ」やればよい、という、軽量化され、ひきしまった手法なので、実践的。 コストパフォーマンスが良い手法。
先ほどのプロトコルモデルなども参考にしながら、全体のユースケース、キモになりそうな画面などの洗い出しを、今日の午前中で、いちおう達成した。
概念モデルは、初期に洗い出したもので、この段階までは、ほぼそのままでやれた。
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週間くらいで、やれば、なんとか、なるんではないかと推測している。
そこがうまくいけば、先ほどの、携帯サイト固有技術の課題に、アーキテクトを振り向けられる。
ある程度の経験と勘で、リストを織り込んだ上で、上記の戦い方で、なんとかなるかと思っている。
ただ、いろいろ、雨の日コースも想定しておこうとは思っている。
いざという時のためには、やはり、やばそうなところを、最初に集中して叩き潰したほうが良いとは思う。
目先、まわりから、目に見える成果が少ないけど、システム開発の勘所みたいな箇所が、確立したほうが、結局は、プロジェクト全体が安定するから。
なかなか成果が見えないことに対する、説明責任、関係者に信頼してもらえるようにするもの、私の大きな責任になりそう。
また、兼任の仕事が増えた。 一人がいろいろ兼任で担当する、という計画自体、かなり問題なんだけど、この程度のやり方でやらないと、プロジェクトはまわりませんからね。
基本の手法は、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週間くらいで、やれば、なんとか、なるんではないかと推測している。
そこがうまくいけば、先ほどの、携帯サイト固有技術の課題に、アーキテクトを振り向けられる。
うまくいかない、雨の日ケースの想定と対応
ある程度の経験と勘で、リストを織り込んだ上で、上記の戦い方で、なんとかなるかと思っている。
ただ、いろいろ、雨の日コースも想定しておこうとは思っている。
いざという時のためには、やはり、やばそうなところを、最初に集中して叩き潰したほうが良いとは思う。
目先、まわりから、目に見える成果が少ないけど、システム開発の勘所みたいな箇所が、確立したほうが、結局は、プロジェクト全体が安定するから。
なかなか成果が見えないことに対する、説明責任、関係者に信頼してもらえるようにするもの、私の大きな責任になりそう。
また、兼任の仕事が増えた。 一人がいろいろ兼任で担当する、という計画自体、かなり問題なんだけど、この程度のやり方でやらないと、プロジェクトはまわりませんからね。