モデリング・DDD＃１　「エコな開発を」

システム開発地図 第1回

はじめに

業務システムの開発・保守において、発注側と受注側が互いの立場を超えた共通認識を持てないことは大きな障害となります。伝言ゲームによる間違いや認識のずれによる手戻りは、開発の遅延や経営的な損失を招きます。

本記事では、このような課題に対する指針となる「システム開発地図」をご紹介します。この地図を使って、業務分析から要件定義、設計・実装に至るまで、発注者と受注者が共通の認識を持ち、成果物のトレーサビリティーを確保してエコな開発を行うための考え方・視点を提案します。

エコじゃない開発

業務システムを再開発するときに、現行システムのドキュメントが存在しない、存在したとしてもメンテナンスされていないということがよくあります。システムの発注側は、現行システムとソースコードがあれば大丈夫だろうと思うかもしれませんが、「現行システム通りの仕様でやってくれ」などとベンダーに言って、要件定義や設計の確認を省略してしまうと、受け入れ時に仕様の解釈の相違などによるトラブルが必ず発生します。開発側には、仕様変更に近い要求がリリース直前に大量に突きつけられ、デスマーチに突入し突貫工事をするはめになります。プロジェクトメンバーは疲弊しプロジェクトは赤字に、リリースが延期されるなど発注者の被害が発生する場合もあります。

再開発でなくても、ドキュメントが十分でない場合、システム保守フェーズでトラブルが発生する可能性が高くなります。開発時には大勢のメンバーで作成したプログラムを少人数の保守担当者がメンテナンスするのですが、各開発担当者の頭の中だけにあった手がかりは失われてしまっています。保守担当者は、他の担当者が作成したソースコードを初めて読みながら必死で修正ポイントを探し回り、こわごわ修正を施します。回帰テストが自動的に実行できれば、修正が他の機能に影響を与えてないかが確認できます。しかし、ドキュメントが十分でないようなシステムでは回帰テストが自動化されていることもほとんどなく、確認できないままリリースせざるを得ません。リリース後に別の機能が使えなくなっていること(デグレード)が発覚し、ユーザーからクレームが出て、徹夜で復旧したりすることになります。業務要件で頻繁にシステムに手を入れなければならない場合、毎回このような綱渡りのメンテナンス作業をしていかなければならないのです。保守フェーズではドキュメントを新たに書き起こしたり、回帰テストを整備したりというのは、とても採算に合わないため、何年も不安定なままシステムを運用することになります。

このようにしてシステム開発への多額の投資が無駄になったり、システムが経営の足かせになったりする状態をまねいてしまうことになります。筆者らが支援した開発現場でもこのようなケースはけっして珍しいことではありません。ドキュメントレスな開発はとてもスマートとは言えません。人件費や光熱費の観点からもとてもエコとは言えません。

システム開発における成果物のトレーサビリティーの重要性

システム開発では、発注者側の要求がヌケ・モレなく、システムの要件として反映され、システム設計・実装に繋げられる必要があります。このため、要求が設計に反映されているか、設計がシステムの機能としてちゃんと実装されているか、トレーサビリティー(追跡可能性)を確保する必要があります。こう考えてみると、ソースコードしかない状態というのはいかに危険かがわかります。ソースコードは業務を遂行する人の言葉で書かれていません。いくら可読性が良く保守性の高いコードでも、システムの要件や業務の流れ、業務データやデータに対する処理などが直感的に理解できる形で表現されてはいないのです。これらを表現するには別の表記方法が必要です。

複雑な業務は、業務フローや概念モデル、ユースケース、画面・帳票定義など様々な表現で可視化します。可視化された各種モデルや文章、図表などの間には、論理的な整合性・一貫性を保つ必要があり、成果物の要素レベルのトレーサビリティーが必要です。これらの成果物で使われている言葉は、用語集などにより厳密に管理されなければなりません。

これらの成果物は、様々な記法、様式を持ち、発注者、開発者など立場の違う人間が大勢で集まって作成するため、整合性やトレーサビリティーを確保するのは口で言うほどたやすいことではありません。成果物を作成する各担当者が、「何をやったらいいか分からない」、「何を元に何を作り出せばいいか分からない」などということになりがちです。開発に参加するメンバーが、開発の目的と自分の役割を理解し、自分の作成する成果物が他の担当の成果物とどうつながっていくのか理解する必要があります。

システム開発地図の概要

システム開発地図はこのような背景から生まれました。システム開発は、たくさんの人が交代しながら、長く複雑な旅をするようなものです。前の人がどこまで行ったのか、自分はどこまで行くべきなのか。システム開発地図に照らし合わせながら、確認することができます。

旅全体を大まかに見渡したり、時には詳細に調べたりする利用方法は、本物の地図にそっくりです。目的地と現在地を確認し、旅をともにする人と共通の認識を持つことができます。

システム開発地図の全体図は下図のようなものです。

システム開発地図(955.54 KB)

システム開発地図は、システム要件定義の成果物を中心として、業務分析および設計・実装における成果物をどのようにつなぐのかを俯瞰した地図です。地図に描かれた成果物は、企業の在庫管理業務をモデル化し実装するまでの、実際のモデルや文書・図表などが詳細に描き込まれて、成果物の要素レベルまでを詳細にトレース可能です。

具体例で成果物のつながりや変換の様子を追うことができますので、直観的に捉えやすくなっています。抽象的なプロセスや分厚い設計ガイドなども必要ですが、このような例示によるガイドは想像以上に効果があります。具体例があれば、状況や使われ方が理解しやすく、自分の作業に適用するのが簡単です。細かい規則に関してはガイドを参照すればよいのです。

システム開発地図の見方

システム開発地図で表現されている成果物は、メンバーの教育コストを考えて、なるべく標準の書式であるUMLを利用するようにしています。UMLと同等の表現力がある別の記法を採用しても構いません。現場のルールによってカスタマイズするといいでしょう。

作業工程は、次のようなマークに大まかな粒度で書かれています。

作業の成果物は、作業からの黄色い矢印で示されています。

成果物同士の関連は、水色の矢印で示されています。矢印の方向は、作成する順番を示しています。

成果物の中に現れる要素同士の関連は、紫の点線矢印で示されています。矢印の方向は、変換する方向を示しています。

システム開発地図は、A1の紙に印刷するとようやく詳細が見えるぐらいの情報量です。

システム開発地図の効果

システム開発地図では、プロジェクトの進捗のような動的な情報は表現していません。プロセスと成果物の静的な関係を表現しています。本物の地図が特定の地域の具体情報を描くのと同様、システム開発地図も特定の業務(在庫管理)の具体的なシステム化の道のりを示しています。システム開発地図の活用シーンとして

• プロジェクトスタート時のオリエンテーションやワークショップでメンバーがこれからやることのイメージを共有するのに利用する
• プロジェクトメンバーが、担当役割を遂行するためのガイドへのポインター (「この作業ではこのガイドを参照せよ」)として利用する
• 各フェーズの終わりに振り返りで利用する

などがあげられます。

システム開発地図を活用することにより、システム開発に次のような効果がもたらされます。

• 属人性の排除成果物をどの程度の完成度(後続作業が開始できる程度)にすればよいか、どのような入力を求めればよいかがわかる
  経験の有無によらず成果物の粒度をそろえることができる
  直前・直後の作業と成果物の関連を理解できる
  課題がどの設計・要求に影響するのか追跡しやすい
  
• 品質の担保重複・漏れを防ぐことができる
  分析・設計・実装の一貫性を保つことができる
  成果物間の整合性を保つことができる
  
• わかりやすさ作業と成果物の位置づけを容易に把握できる
  作業の詳細を学ぶ前に、その作業の全体の中での位置づけ・意義がわかる
  組織に合わせたカスタマイズが容易となる
  

システムの発注者にとっても利点があります。発注者はベンダーに業務上の要求をちゃんと伝えられているか、受け入れ段階までわからないことが多いものです。システム開発地図は、ベンダーが伝えられた要求からシステム要件・設計をきちんと導き出せているかを確認するためのガイドとしても活用できます。発注側と受注側が同じ地図を見て、共通認識を持ち、互いの役割を明確にして、成果物について議論することが可能になるのです。

おわりに

本記事では、システム開発における、中間成果物およびそれらのトレーサビリティーの確保によるエコなシステム開発を提唱し、システム開発地図の紹介と活用を提案しました。企業システムの開発では、保守期間を視野に入れたドキュメント整備、組織役割の整備が必要となります。

企業で使う業務システムは、開発して5年10年かけて運用・保守し、償却していく資産です。変化する業務に適合させ、経営をサポートするために、システムの開発・保守プロセスを見直していきましょう。ベンダー任せではダメです。発注者側の情報システム部門で要件定義ができない場合は、ベンダーや外部のITコンサルタントの協力を得ながら実施します。システムの企画から始まって要件定義、設計、開発、保守というライフサイクルをカバーするエコシステムを構築していきましょう（注1）。そして、システムの発注者とベンダーがエコシステムにどのように関わり、どのような役割・責務を果たしていくのか、決めておかなければなりません。

次回は、モデリングツールやプロジェクト管理ツールに焦点をあてます。エコなシステム開発を行うための、ツール活用ポイント、システム開発地図におけるツールのカバー範囲などを見ていきます。

（注1） ここでいうエコシステムは、「業務システムに関連する人(利用者、発注者、開発者)、開発プロセス、運用プロセスなどが、業務システムのライフサイクル全般にわたりその保全、進化に有機的に作用する体系」をイメージしています。

システム開発地図
第1回 エコな開発を
第2回 関係者の役割分担をマッピング

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。