2015.01.06

アジャイル開発のアウトプット最大化の為に〜如何に上手く伝えるか

Agile&DevOps担当の川上です。今回は今までとは少し違う視点で、開発における要件定義の成果物について書きたいと思います。今更な話もあると思いますが、お付き合い頂ければと思います。要件定義とは、一般的に以下のように定義されています。

図1

要件定義で気をつけること

要求が有り、それを実現する為に、時にはソフトウェアを開発し、時には業務を変更したりしていると思います。そして要件定義の出来次第で、ソフトウェアの品質が大きく変わってくるということに反論される方は少ないのではないかと思います。品質を左右する要件定義で、どのようなアウトプット(成果物≒要件定義書)が出来ると良いのでしょうか?
私が考えるに、良い要件定義のアウトプットとは、「読み手の業務知識に依存しないこと」であると考えます。
ソフトウェア開発において、開発者の業務経験は様々で、必ずしも該当サービスの業務知識を保有している者ばかりとは限りません。東急ハンズのシステム開発をされているハンズラボのように、業務経験者が、ソフトウェア開発を行っている会社も勿論ありますが、ビジネスのバックボーンが異なる人間が読んでも、意味が通じること、それが要件定義書に求められる要素だと考えます。

木をみて森は分からない

図3

スクラムのプラクティスでは「ストーリー」という形で、要求をエンジニアへ伝えます。このストーリーの情報をまとめる事が、小さな要件定義となります。このストーリーはスプリント(短い開発サイクル)の中で実装から、試験までを完了する必要があるので、適切な粒度に分割する必要があります(適切な分割の仕方については、別の機会にお話したいと思います)。小さく分割されているということは、全体を見渡すことが難しくなるということでもあります。また、細かな議論に終止し、木を見て森を見ずという状況になることもしばしば見かけられます。ストーリーの内容を説明する前に、該当するストーリーが全体のどこに位置する内容なのかという事を明示する必要があります。

問題突破の鍵は・・・・

KDDI Business IDの開発においても、内製化に取り組んでいますが、申し込み業務や、問い合わせ対応、請求など幅広い業務分野の知識を必要とする中で、様々な業務経験者が集まり、開発をスタートする為には、やはり共通認識をもつ必要が有りました。そこで開発をスタートした段階で、開発メンバー全員を集めて、要件定義として作成したユースケースマップとドメインデータモデルのレビューを最初に実施しています。

ユースケースマップでは下記の二点を最初に意識合わせします。

  • 誰が何を行うのか?
  • どのようなデータを扱い、そのデータはビジネス上どのような意味を持つのか?

以下の図は、KDDI Business IDのユースケースマップの抜粋です。

図5

『アクターには、利用者と管理者と、KDDI運用部門が居るようだ』
『利用者と管理者は汎化の関係にあって、それぞれ別の事が出来るみたいだ』
『認証方式は複数設定出来るようだ』
『利用者/管理者と、KDDI運用部門は色が違うのは何か意味が有るのかもしれない』ということが“なんとなく”理解出来るかと思います。

これを自然言語で表現してみましょう。
『本システムを利用するユーザには、“利用者”と“管理者”存在し、管理者は特権ユーザとして、認証設定が行える。認証設定に、社内IPアドレスの設定機能と、認証方式の設定機能が含まれ、認証方式にはベーシック認証と、着信認証を選択する事が出来る・・・・』
まぁ、多少わざとらしさがある表現になっていますが、絵を一枚見せるのと、言葉を連ねるのでは、どちらが全体像を把握しやすいでしょうか?「百聞は一見に如かず」の言葉通りかと思います。勿論実際のプロジェクトのユースケースマップではこれに比べ物にならないくらいの要素が出てきます。それらを言葉だけで表現することは勿論出来ますが、同じ姿を思い描く事は難しいというのは、誰しも納得頂けることかと思います。

なんとなく分かるというメリット

図4

この「何となく理解出来る」という事がとても重要だと考えます。勿論このユースケースマップだけでソフトウェアが作れる訳では有りません。詳細な業務フローや、ビジネスロジックを定義した資料、画面の項目定義書やデザインシートなど様々な物が必要です。ただ言える事は、全体のどこの部分を開発していて、開発している機能は誰が利用する機能なのかという事が、頭の中でイメージ出来ているかどうかで、出来上がったソフトウェアの完成度は段違いだという事です。私はオフショア開発でベトナムのエンジニアと仕様の議論をするのですが、議論をしている対象が何かということが、まず理解出来ているというのは非常に大きなアドバンテージになっています。相対しているベトナムのエンジニアチームは、別の日本のプロジェクトがスタートした際に、日本語(場合によって英語)で書かれた大量のドキュメントを熟読するところから始めたそうです。時間をかけてドキュメントを精査しても、言語の壁や、一般に言われる“行間仕様”で相当悩まされたという話を聞いています。

昨今ITシステムに対するビジネスの要求の幅が広がる中、国籍も違う人たちと同じゴールを共有する為にも、標準言語としてのUML(Unified Modeling Language)を活用しています。ゴールを共有する為に、情報を共有するという行為は必要不可欠です。効率が全てでは有りませんが、効率を無視する訳にもいきません。UMLなどの汎用的なツールを、円滑なコミュニケーションのきっかけにしてはいかがでしょうか。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
アジャイル開発センター

川上 誠司

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP