API 開発における要件分析 – C++ のための API デザイン 
ライブラリ API の設計手法を学ぼうシリーズの第3弾です。前回の記事はこちら。以下の教材を利用しています。
今回から第4章に入ります。4章は C++ での実装の話はなく、設計に入るまでの情報の収集や整理 (要するに要件分析)、および様々なレイヤーでの設計に関する議論となっています。プログラミング実習をするような内容でもないので、要点をまとめながら解釈したり考えたりしたことをレポートしたいと思います。
今回はその中でも、 4.1～4.3節の、要件分析までの内容について見ていきます。
大原則
最初のセクションに入る前の書き出しで、以下のように書かれています。これはもう、大原則ですよね… (強調は拙引用者によるものです)。
…こうしたさまざまな分析テクニックは個別に使っても組み合わせて使っても有用である。とはいえ、「自分で理解できないことは設計できない」という原則を常に頭に入れて設計してもらいたい。
このことは、この後に説明されるさまざまな場面において重要な事柄です。システムの構成をうまく分解・整理できない、クラスや関数に適切な名前を付けられない、などといったことは、当該事項に対する理解が不足している証拠であり、そのために情報の収集や議論を重ね、要件を整理するということの繰り返しが必要不可欠になるわけなんですね。(あーしんどい)
優れた設計の必要性
4.1節では、優れた設計がなぜ必要なのかを、怖い話を交えて説いています。
…ちょっとだけ愚痴を (強調は拙引用者による)。
この問題にはもう1つの側面がある。コードの品質を高く保っていかないと、コードの進展とともに当初の設計がしだいに退化していくことだ。デッドラインに間に合わせるための手抜きは、後で戻って修正する限り許される。とにかく、自分の技術的な負債は必ず後で支払わされることを肝に銘じることだ。コードというものは、当初開発者が思ったより長く存続するものだ。APIを弱体化するときはこの事実を思い出して欲しい。このつけを長期的にサポートするはめになるのは本人だ。だからこそ、API設計に対する新規要件のインパクトをしっかりと把握し、(…以下略)
…このツケを踏み倒していく技術者のなんと多いことか＿|￣|…………◎ (←お前が言うな)
機能要件の収集
4.2節は機能要件について書かれています。まず、ソフトウェア業界における要件の種類を以下の 3つに整理しています (強調は原文ママ)。
- ビジネス要件: 事業という意味でのソフトウェアの価値。会社のニーズにどう応えられるか。
- 機能要件: ソフトウェアの動作や振る舞い。ソフトウェアが遂行すべき内容。
- 非機能要件: ソフトウェアが達成すべき質的水準。ユーザにとってうまく機能する度合い。
そのうえで、 API 開発に際して、上記のうちの機能要件、および (ついでに) 非機能要件について、 API のターゲットユーザーや専門家などからどういった要点で質問し、情報を引き出すべきか、そしてそれらについてどのように整理してまとめ、保守してゆくべきかが説かれています。
ちょっとショッキングな (だけど実感として納得できてしまう) 記述を以下に引用します…。
平均すると、あるプロジェクトで開発期間中に変更する機能要件は 25% あり、そのために書き換えるコードは 70～85% に上るという[52]。クライアントの変化するニーズをしっかり受け止めることは大事なことだが、要件の変更に伴うコストを関係者全員に理解させることも重要である。(…以下略)
(参考文献)
[52] S. McConnell, Code Complete: A Practical Handbook of Software Construction, second ed., Microsoft Press, 2004. ISBN 0735619670. (『Code Complete 第2版〈上〉〈下〉— 完全なプログラミングを目指して』、スティーブ・マコネル著、クイープ訳、日経BPソフトプレス、2005年)
…この場合、書き換えが発生すると予想できる分だけ余裕を持って見積もるべきなのか、要件の管理を徹底した上で、要件の変更が発生する度に追加の見積もりを計上すべきなのか、どっちなんでしょうかね…。アジャイルなやり方を採用している現場ならもう少し融通も利くのでしょうが、そもそもエンドが動かせないプロジェクトの場合、開発側代表者 (多くの場合、PM?) の交渉手腕、企業の人的リソース配分なども意味を持ってくることに… (考えたくない)
# マコネル読め>ヲレ
ユースケースの作成
4.3節はユースケースについて書かれています。ユースケースの様式 (フォーマットであったり、 UML であったり) よりも、概念や存在意義を始め、書くべき内容やボリューム感、粒度、使うべき言葉、それから向き合い方や取り扱いなどといった実践的な部分について書かれています。
4章で書かれていること全般的に言えることですが、ユースケースについてもあくまで概要レベルで触れられています。ここに書いてあることを読んだだけでも割といい感じで書けそうですが (それだけ要点よくまとまっています)、より深く学びたい人はアリスター・コーバーン著「ユースケース実践ガイド」がお勧めです。
それから、関連する事柄として、 4.3.4 でアジャイル開発での要件の取り扱いとユーザーストーリーについて論じられています。ユーザーストーリーについては以下の部分の引用が端的で分かりやすいのではないでしょうか。
(…前略)マイク・コーンはユーザーストーリーについてシンプルな形式を提案している[19]。
私は、 [役割] として [利点] のために [目的物] がほしい。
(参考文献)
[19] M.Cohn, User Stories Applied: For Agile Software Development, Addison-Wesley Professional, 2004. ISBN 0321205685.
私は、プログラマーとして Unicode を内部表現として安全に取り扱える C++ コンパイラと正規表現ライブラリが欲しいです…。
膨大な量の正式な要件文書を維持管理することは迅速《アジャイル》ではない
要件分析について述べられた内容は以上で終わりです。結局本書では、要件を分析する方法論として、機能要件の収集、ユースケース、ユーザーストーリーの 3種類しか挙げていません。しかも、必ずしもそれらをすべて揃えろという話ではなく、プロジェクトの性質に応じて、ユースケースのみを作成する、ユースケースから機能要件を引き出す (もしくはその逆)、ユースケースよりも迅速かつ簡潔な方法としてユーザーストーリーを用いる、などの選択肢がありうることを示唆しています。
要件定義の文書に盛り込むべき内容としてはさまざまなものが要求されることが多いです。入出力要求であるとか、業務フローであるとか…。そして、割と多くの企業や現場で、主に Excel や Excel、それから Excel などを使ってきっちりとした体裁の文書を作成し (悪意が滲み出てるって? きっと気のせいですよ…)、用語の解釈に誤りがないかとか、誤字・脱字はないかとかいったことで延々とレビューを繰り返すという光景が繰り広げられているのではないでしょうか。
もちろん、要件として残すべき資料がこの程度しか考えられないのは開発対象があくまで C++ で実装するような API の開発であり、それは開発者が使うためにリリースされるものであるからそんなもんで充分なんだろうという考え方もできると思います。なにはともあれ、振る舞い要求を分析する方法であるユースケースの説明を行う節の最後にアジャイル手法とユーザーストーリーの説明を交えてくる点も含めて、著者であるマーティン・レディが要件分析に対してどちらを志向しているのかが垣間見れるようにも思えます…。
当然のことながら、ウォーターフォールモデルを悪しき風習であると断じるつもりは (少なくとも私には) 毛頭ありません。それよりは、どんな手法や枠組みを用いるにせよ、形式に従うこと自体を目的にして費やされるコストに、もう少し懐疑的であっても良いのではないか、ということなのだと思います。箇条書きで済む内容だったら Wiki を使うんだっていいわけですし、図だって手書きのものをスキャンしたものを共有とかでもいいわけですし、履歴管理を重視したいなら図も GraphViz で書くという手だってあるわけですし、納品物という形を得たいなら印刷しなくても CD に焼いて納品という手だってあるわけですし…。
最後もなんだか愚痴っぽくなっちゃいましたね (^_^;。次回は 4.4節以降、設計の部分についてレポートする予定です。それではまた…。
2014 年 8 月 10 日 by 村山 俊之