TOP
＞
プロジェクト管理
＞ DOAを現場で展開する上での留意点
DOAとは何か！〜開発現場から見るDOA〜
第１回：DOAを採用した現場の実態とは
著者：
システムズ・デザイン DOA推進ワークショップ
2007/2/15
前のページ
1
2
3
DOAを現場で展開する上での留意点
さて、ここまでの説明で、DOAを使った現場のプロジェクトの流れを理解していただけたのではないかと思います。開発プロセスやプロジェクトメンバーの構成などは、一般的なプロジェクトに同じような例を見出すことができるほど、何の変哲もありません。
DOAの特徴的な部分は以下のようになります。
情報システム部門が組織全体でシステム開発の品質維持を目的としてデータモデリングを中心にした開発体制と制度を敷いていること
成果物の中で業務フローとER図が特に重用されること
開発プロセスの中に計画・実行・結果の振り返りを行う「PDSサイクル」がしっかりと組み込まれていること
表7：DOAを採用した現場の特徴
それでは、以上の点を踏まえ、次にあげる課題について解説します。
情報システムベンダーとしての問題
ユーザとの関係
業務フローの共通認識
開発スピードと品質の妥協点
理想を追い求めるDAとの葛藤
表8：DOAを採用した現場の課題
情報システムベンダーとしての問題
情報システム業界を見渡してみると、いわゆる偽装請負的な人材派遣型のビジネスモデルに遭遇します。受注した仕事に対して人をあてがい、後は本人任せという案件が後を絶ちません。
昨今特に感じられるのは、高い製造技術を持ちながら、設計技術が伴わない技術者の存在です。これに対しては、各工程の目標や達成基準を把握してから仕事に取り掛かる姿勢が技術者に求められます。
配属されたプロジェクトで、指示をされないと仕事ができない技術者が僅かに混ざるだけでも、プロジェクトを軌道に乗せるまでに手間がかかってしまいます。
データモデルの基本的な思想は
「現場の事実をデータに語らせて業務を認識・可視化する技術」
と定義することができます。DOAで作るモデルは、意味論モデルといわれています。意味論は、言葉の関係を扱う「統語論」と言葉の使用を研究する「語用論」に大別できますが、DOAはこの２つを使って巧みに言葉（メタデータ）を分析します。
この「意味の分析」とは「解釈して伝えるという」作業です。このことから、DOAではエンティティやアトリビュートといったメタデータを「業務」や「管理」「運用」などの視点で「解釈する技術（解析表現）」と「伝える技術（仕様化）」を定義しています。
この2つの技術について基本的な見識がない技術者は、DOAの現場で仕事していくのは困難といわざるを得ません。ただし、この技術は多少の訓練と経験によって修得できるため、ぜひチャレンジしていただきたいと思います。
ユーザとの関係
ユーザ部門と開発側がプロジェクトの対象となる物事を見るときに、1つの見方で理解しあえる方法があればコミュニケーションは円滑になり、相互の意思を疎通させることが容易になります。
一般にモデリングの世界では、表やダイアグラムを用いて事物の分析を一定の方式で表現します。モデル言語といわれるこの表現方法は、特定の物事について、立場の違う人間が相互に理解するもっとも有効な方法と考えられています。
時間を有効に使用して、高い品質でプロジェクトを推し進めるためにも、モデル言語をユーザ部門と開発部門で共有しておくことは、不可欠であるといえるでしょう。
業務フローの共通認識
筆者は、ビジネス分析〜要件定義工程段階で描かれる新業務フローが、ユーザと開発者の共有できる具体的な完成イメージだと考えています。しかしこの業務フローがあまりにも大雑把であると、お互いに誤解を招く引き金となってしまいます。
開発者が描いてしまうとシステムフローになりがちで、実際にシステムを切り替えると業務が回らないケースも見受けられます。また、業務フローにすべてのケースが考慮されておらず、特定のケースだけは従来通り手作業で行ったり旧システムを使用するといった、お粗末な話も耳にします。
このような結果を招かないためにも、要件定義工程では開発者がユーザと一緒に業務フローを考えて、イメージを合わることが重要だと考えています。
また、ユーザの代表者（実務担当者ではなく）は実務担当者の窓口的業務を担っている人物である場合がほとんどです。業務全体を1番良く知っている人物ではあっても、いくつかの業務領域ごとに存在する実務担当者の業務を知り尽くしているわけではありません。
SEはむろんのこと、ユーザですら、恐らくはビジネスルールを隅々まで知り尽くしている人物はいないのです。この点からも、なおさら時間の使い方に留意して業務フローの認識を共有することが重要だといえます。
最近では渡辺幸三氏の三要素分析法を取り入れて成果をあげています。しかし、コミュニケーションの部分で改善しなければならない余地は少なくありません。DOAに限ったことではありませんが、こうした努力を惜しまずに、日々改善していくことが、よいシステムを生み出す源にもなるのです。
開発スピードと品質の妥協点
要件分析に時間がかかってしまい、立ち上げ時期を変更せざるを得なくなったとき、ユーザを納得させる説明をするのは、簡単なことではありません。結果的に開発期間が短くなって品質に影響がでたり、前工程を急いだため後工程で手戻りが発生したりするケースは少なくないと感じています。
開発期間と品質のトレードオフにさいなまれないためにも、現場ではしっかりとした管理が必要となります。データモデリングは業務分析手法なので、管理については明確な規定があるわけではありません。したがって、何らかの管理手法を用意して、プロジェクトを進める必要があります。
理想を追い求めるDAとの葛藤
DAは企業のデータを管理する立場にあり、その役割に真摯であればあるほど妥協を許しません。一方、開発プロジェクトは、納期やコストの上にもなりたっています。DAの理想が高ければ高いほど、開発期間が圧迫されてしまうケースがしばしば見受けられます。
DAはプロジェクト専任の立場ではないため、なおさらプロジェクト側は理想論と開発期間に対するプレッシャーを感じることになります。現場の実力やユーザの仕様にあったマチュリティレベルを見極めて実現すべき事柄を検討し、期間やコスト、スコープの最良のミートポイントを開発関係者全員が共有することが、もっとも望ましいプロジェクトのあり方といえます。
改善の指標
どんなによい環境を提供しても、それを運用する側の意識や目的を達成するために何を妥協するかといったジャッジを行う管理者が不可欠です。SEの育成には、部下の設計したシステムを品質面で正確にジャッジできる上級SEを多く抱える企業が有利であることに間違いはありません。
そのためにも、モデル図などを共通言語として扱い、DOAの観点から設計の良し悪しを慎重にレビューすべきであると考えます。
次回はDOAによるWebアプリケーション開発について、その課題について解説します。
前のページ
1
2
3
著者プロフィール
システムズ・デザイン株式会社 DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。
INDEX
第1回：DOAを採用した現場の実態とは
DOAとPOAという2つの流れ
プロジェクト体制
DOAを現場で展開する上での留意点
