マニュアル駆動開発を考えてみた

マニュアル駆動開発
1.目的
1−1.ユーザが理解可能な仕様書を作る。(not設計書)
まず、仕様書とは何であるのか。設計書とは何であるのかを定義したいと思います。

仕様とは、製品が満たすべき、満たされるべき、満たすことが保証されている性能・機能。
あるいはお客様が望んでいる性能・機能。それを記述した物が仕様書。

設計とは、製品をどのような材料を、どのように加工したり組み合わせて製造するかを計画すること。それを記述した物が設計書。

システム開発における仕様書と設計書とは何でしょうか。システム開発における仕様書とは、このシステムで、なにを実現するのかが解る物。システム開発における設計書とは、このシステムを、どのように構築するかを理解できる物。そういう風に言えないだろうか。なので、ユーザに見える、理解できるようにすべきものとしては、仕様書になると思います。

しかしながら、現実として、仕様書を見たことのあるユーザはいるでしょうか。ユーザとは、実際にそのシステムを使用する人であって、情報システム管理者や経営者ではない。現場の人間です。一般的にあるシステム開発における仕様書を見ても、ユーザにとって有益であるとは思いにくいです。直接システムを使用するユーザが読まない仕様書に何の意味があるのでしょうか。

直接システムを使用するユーザがシステムを使用するために読む物としては、マニュアルがあると思います。マニュアルには何が書かれているのでしょうか。あるいは、マニュアルにはどういった種類があるのでしょうか。

世の中には取扱・操作説明書(マニュアル)、リファレンスマニュアル、ユーザーズマニュアル、業務マニュアル、運用マニュアル、障害対応マニュアル等、多種多様なマニュアルが存在しますが、ここでは「業務マニュアル」と「運用マニュアル」と「操作マニュアル」について定義してみたいと思います。

「業務マニュアル」には、会社の業務を遂行するために何をするべきかというような事柄がまとめられます。たとえば、ISO9001 などの品質管理(QMS)等や、営業マニュアル、販売や在庫などを管理するための管理マニュアル、社内規定等が挙げられると思います。業務フローや業務に関する注意事項が記述されます。これは会社毎に存在するものと思われます。

「(システム)運用マニュアル」には、業務に使用するツールやシステムを運用するためにどのようなタイミングで何をしたらいいかがまとめられます。たとえば、販売管理システム運用マニュアルのような物です。システムの運用フローやシステムの運用に関する注意事項が記述されます。これはツールやシステム毎に存在するものと思われます。

「操作マニュアル」には、業務に使用するツールやシステムの何をどのように操作したらいいのか、操作方法の詳細がまとめられます。たとえば、販売管理システム操作説明書のような物です。システムのUI情報やその操作方法の詳細について記述されます。これはツールやシステムのUI毎に存在するものと思われます。

これらのマニュアルの定義と、仕様書の定義はオーバーラップする部分が多いのではないでしょうか。

そうです。ユーザに解りやすい、読んでもらえる仕様書というのはマニュアルのことなのです。逆にユーザに解りやすい、読んでもらえる仕様書を作ろうと思うと、結果的にマニュアルが作成されるのではないでしょうか。

1−2.ユーザに納品する物を中心に開発するということ。
現状、お客様にシステムを納品するシステム開発の「成果物」としてあげられるものは何でしょうか。

ユースケース図?・ユースケース記述書?画面設計書?テスト仕様書?クラス図?要求仕様書?ER図?DFD?その他いろいろあると思います。しかし、そのいろいろある成果物の中で、最も品質の精度を求められているものは何でしょうか。

それは、システム本体(プログラム・ハードウエア等、動作環境一式)とマニュアル一式ではないでしょうか。どちらが欠けても、最終的にシステムを使用していただくユーザに、システムを使ってもらうことはできません。システムとマニュアルは1セットです。切り離すことはできません。

しかしながら、実際のシステム開発は、膨大な仕様書・設計書を元に、プログラムを実装し、システムが構築されて後、最後にマニュアル類を整備していくという方法が採られていることが多くないでしょうか。それで品質の高いマニュアルが作成可能でしょうか。

また、システムを構築するための膨大な仕様書・設計書をユーザに確認してもらったにも関わらず、ユーザと開発者のシステムに対する考えの乖離は発生しないでしょうか。

仕様書・設計書に承認の印鑑をもらって実装した後、プログラムをリリースして、「そういうことではない。」「これではない。」といわれることはないでしょうか。

その乖離を防ぐ方向として、さらに詳細な仕様書・設計書を作成していくということになりがちですが、詳細に記述したら、本当にユーザと開発者との間で乖離はおこらなくなるのでしょうか。

このように、実質、直接ユーザに納品しなければならない物に掛ける工数を削減してまで、仕様書や設計書に工数を費やすことをしていたりしませんか。本当は、実際にユーザに使ってもらえるものに開発工数をたっぷり掛けたいと思いませんか。

このことについては、ウォーターフォール型開発のデメリットであるような事も言われていますが、根本的には、ユーザが要求したことが正確に仕様書に記述されているのかユーザも開発者も確認できないというところに問題があるように思います。

実際にユーザが使う、あるいは理解できる物でなければ、ユーザは本当の意味での確認・承認をすることは出来ないと思います。

ここがうまくいかない限り、UPの様な反復型開発であろうと、アジャイル開発であろうと、最終的に、ユーザのシステムに対する満足度は上がらないものと考えます。

それを実現するために「マニュアル駆動開発」という考え方が必要であると、私は考えています。

ユーザが理解できる仕様書として、マニュアルを作成し、そのマニュアルを仕様書として、開発者は設計書なりCRCカードなりを作成して、システムを構築していくことは可能なのではないかと思います。

1−3.マニュアル駆動開発の適用範囲
マニュアル駆動開発は、以下のマニュアルによって、ユーザからシステムの機能・非機能要件を引き出す事に注力します。

  • 業務マニュアルには、業務の全体像を示す業務フローを定義し、システムの境界線や他システムとのインターフェースを定義します。業務マニュアルの推敲で業務又は会社全体の最適化を考慮しなければなりません。
  • 運用マニュアルには、システム全体の運用フローを定義し、システムの流れや関わる担当ユーザ等が洗い出されます。運用マニュアルでは、システムでの運用改善や障害時の運用などの考察を入れます。
  • 操作マニュアルには、ユーザが使用するシステムのインターフェースの使用方法が定義されます。操作マニュアルでは、ユーザインターフェースのユーザビリティを中心に推敲されます。

開発プロセスについては、すべてについて網羅することはできないと考えています。各開発プロセスの各フェーズで、どのような目的で、どのようなマニュアルを作成、または参照するかを定義するに留めます。そのことにより、ウォーターフォール型開発や反復型開発、アジャイル開発にマニュアル駆動開発方法論を適用可能にしたいという考えからです。さらに言うと、開発するシステムにより、要件定義の難易度や技術的に実現可能かどうかのレベルが違いますので、そこは他の開発方法論が優れているところを使用したほうがいいかと考えています。

1−4.マニュアル駆動開発とUCDとの関係と、マニュアル駆動開発の適用場面
UCD(User-Centered Design)は文字通り、ユーザの使い勝手(ユーザビリティ)中心に開発を進めていく方法論ですが、その意味で、マニュアル駆動開発はその目的は同一なものです。が、しかし、ITシステムはユーザビリティのみならず、システム全体の運用効率や、システムが与える業務への効果なども考慮しなければなりません。そういった全体最適化の視点や、システムの可用性等の運用面に関する視点も考慮しながら、ユーザビリティを向上させたシステム開発を行っていく方法論で、その開発のトリガとしてマニュアルというドキュメントを使用していこうという考えです。マニュアルとシステムを構築するためにプロトタイピングなどを行い、実際にユーザにマニュアルとシステムを使ってもらい、反復しながらマニュアルとシステムを構築していきます。

また、主な適用場面としては、企業基幹システムの開発が想定されています。この部分に関して、UCDより範囲が狭く、特化する事になると思います。

2.マニュアル駆動開発のアクター
2−1.ユーザー
まず、マニュアル駆動開発の主人公は「ユーザー」です。さらに、システム開発に関わるユーザにもいろいろな立場があると考えます。本当にシステム本体とマニュアルを欲して止まない人はエンドユーザだと考えます。システム開発でエンドユーザを無視した開発を行った瞬間、そのシステムの価値の大部分は失われてしまう物と考えます。ですので、一番の主人公はエンドユーザだと考えます。その次に、そのシステムを保守・運用するシステム管理者もユーザだと考えます。システム管理者の使い勝手が宜しくないシステムも、その価値を大幅に下げてしまうものと考えます。最後のユーザとしては、経営者(又は部門管理者)と考えます。 システム開発のスポンサーでもありますが、システムを導入することによる費用対効果や企業戦略的なポートフォリオも考慮に入れたシステム導入に対する優先順位付け等、大局を見越した判断が必要なユーザです。

  • エンドユーザ…主に自分の担当するユーザインターフェースに関わる「操作マニュアル」の作成に関与します。次に自分の担当範囲の前後に関わるフローに関わる「運用マニュアル」に関与します。最後に業務全体におけるシステムの位置づけを認識する為に「業務マニュアル」に関与します。
  • システム管理者…主にシステムの運用に関わる「運用マニュアル」の作成に関与します。次に業務全体に置けるシステムの効果的な運用を考慮するために「業務マニュアル」とシステムの詳細が全体的に統一感あるものになっているかを確認するために「操作マニュアル」に関与します。
  • 経営者(又は部門管理者)…主にシステムの範囲を投資の視点を持って「業務マニュアル」に関与します。運用マニュアルや操作マニュアルにも優先順位の判断など、経営的視点から関与します。

以上のように、 ユーザ重視の開発は、ユーザも積極的に開発に関わり、その内容に対してコミットしなければならないと考えます。

実際にユーザが関わることのできないパッケージやプロダクト開発の場合、ペルソナを立てて開発を行うことになると思いますが、その際の難易度はかなり上がるものと思われます。

2−2.開発者
続いてのアクターは開発者です。ユーザの要求を具体的なシステムとして構築する役割です。ユーザから明確な要求を引き出す事と、その要求を可能な限り実現する事に責任を持ちます。さらにユーザとのコミュニケーションにより、ユーザにとって本当に必要な事は何であるのかを明確にする必要があります。マニュアル駆動開発は、その為のツールとして「マニュアル」を活用しようというアプローチです。さらに、そこで得られた明確な仕様を元に設計書なり、実装なりを起こしていけば良いのではないかと考えます。そこからのアプローチについては、各種開発方法論で語られているところであるので、特に言及しません。

さて、開発者のマニュアルに対する視点は3つあると考えます。

  • コンサル的な視点…主に「業務マニュアル」を中心に考察します。
    • 業務の流れから、他のシステムとの連携に関するインターフェースを考えます。
    • 無駄な業務フロー上のタスクや、ボトルネックになるクリティカルパス等を考慮し、効率的な業務フローをユーザと共に探っていきます。
    • その上で、構築対象となるシステム開発の境界線を決める事が重要です。
    • 業務フロー上のタスク間の関連線上で流れる伝票や帳票等の情報を明確にすることも必要かと思います。
    • 業務要件から導き出される非機能要件が洗い出されるものと思います。
    • 統合テストのテスト仕様書としての役割を「業務マニュアル」に持たせるため考慮をします。
  • SE的な視点…主に「運用マニュアル」を中心に考察します。
    • 開発対象システムの運用フローをユーザと共に作成し、機能要件の洗い出しや、インプット・アウトプットされる情報の流れを考察します。
    • また、外部システムやシステムを操作するエンドユーザ等の(ユースケースでいう)アクターを明確にし、そこから考察されるインプット情報、アウトプット情報を洗い出します。
    • 「業務マニュアル」の検討で出された非機能要件とも絡めたシステムのアーキテクチャーの検討も必要です。
    • UIの基本的な操作方法やデザインもシステムのアーキテクチャーとして考慮したほうが良いと考えます。
    • アーキテクチャーの検討で、運用上のリスクにどのように対応するかを考慮して、例外系の運用マニュアルとして記述しておきます。
    • アーキテクチャー検証用の、システムのプロトタイプを作成しておくことが良いかと考えます。
    • 結合テストのテスト仕様書としての役割を「運用マニュアル」に持たせる考慮をします。
  • PG的な視点…主に「操作マニュアル」を中心に考察します。
    • 「運用マニュアル」で検討された機能要件とインプットされる情報をUIやそこからもたらされる情報のアウトプットを具体的に構築します。
    • 各UIとアウトプットをユーザと繰り返し検討しながら、「操作マニュアル」とシステムを構築していきます。
    • 「運用マニュアル」や「業務マニュアル」で示された範囲を意識することが重要です。
    • UIの基本的な操作方法やデザインなどは「運用マニュアル」でアーキテクチャーとして定義されますので、この段階では、そこはできるだけ考えないようにすることが重要だと思います。
    • 単体テストのテスト仕様書としての役割を「操作マニュアル」に持たせることを考慮します。

システム開発のどのフェーズでどのような視点を持ってどのマニュアルを作成していくかは、その際適応するシステム開発方法論により変化します。

2−3.ツール
マニュアル駆動開発を行う際、使用するツールによって、効率がかなり変わってくるものと考えます。開発中のマニュアルを紙で出力して管理してしまうと、バージョン管理が大変な手間ですし、参照すべきマニュアルは最新版でなければならないにも関わらず、ユーザと開発者との間で参照しているマニュアルのバージョンが食い違うと、そこで乖離が発生します。ですので、マニュアル作成用のツールは以下の条件を満たしているものを推奨します。

  • 離れた環境でも同じマニュアルを同時に参照可能。
  • 同時に修正可能であればなおよい。
  • バージョン管理が可能。
  • ブランチができればなおよい。
  • 文章間でのハイパーリンクが可能。

お手軽なのは、Wikiのようなツールを使用することではないでしょうか。ある程度、表現力に限界はあるものの、同時に同じ最新のマニュアルを参照できる事の意義は大きいと考えます。また、TracredMineなどのプロジェクト管理も行えるWikiを使用することにより、マニュアルと開発のタスクとを結び付けることが可能になります。

3.マニュアル駆動開発のプロセス
3−1.開発プロセス

マニュアル駆動開発の開発プロセスは基本的に、他の開発プロセスのアドオン(もしくはインクルード)的な適応をします。つまり、

という風に、他のシステムシステム開発方法論と組み合わせて使用します。大まかなイメージとしては、各方法論の仕様書を作成するフェーズと仕様書を使用するフェーズにマニュアル駆動開発を適用します。

  • ウォーターフォール型開発の場合、要件分析〜外部設計までのフェーズをマニュアルを作成します。実装とテスト、納品時には、作成したマニュアルを使用します。
    • 要件分析で業務マニュアルと運用マニュアルを作成します。
    • 基本設計(外部設計)で操作マニュアルを作成します。
    • 実装では操作マニュアルをメインの仕様書として実装し、単体テスト仕様書として単体テストを行います。
    • テストで作成したマニュアルを使用します。
      • 結合テストは、運用マニュアルを使用。
      • 総合テストは、業務マニュアルを使用。
    • 納品時には、これまで作成してきたマニュアルをそのまま納品します。
    • 保守・運用時にはシステムと同様にマニュアルも保守・運用します。
  • UP型開発の場合、方向づけ〜作成フェーズでマニュアルを作成&利用します。移行フェーズで、作成したマニュアルを利用します。
    • 方向づけフェーズで業務マニュアルを作成します。業務のウォークスルーを行う為の運用マニュアルを作成し、業務・運用マニュアルを利用します。
    • 推敲フェーズで運用マニュアルを作成します。プロトタイプの操作マニュアルを作成し、単体テストに利用します。
    • 作成フェーズで操作マニュアルをインクリメンタルに、業務・運用マニュアルをイテレーティブに作成します。作成した操作マニュアルは単体テストに使用し、結合・総合テストが必要であれば、それぞれ運用・業務マニュアルを使用します。
    • 移行フェーズでは作成した運用・総合マニュアルを利用して、本番環境における結合・総合テストを行います。

ここで大事なことは、(ウォーターフォール以外では)各フェーズで作成されたマニュアルは、随時、更新されていくものであるということを認識する必要がありますが、業務〜運用〜操作と、抽象度の高いところから低い順に仕様固めを行って行くということです。

また、どの開発方法論を採用するかの基準は、以下のようになると思います。

  • 要求のブレが少ない、あるいはブレさせない、さらに開発環境が整っている案件についてはウォーターフォール+マニュアル駆動開発
  • ある程度要求のブレは少ないものの、システムのアーキテクチャーや開発環境がが開発初期段階で未確定な案件については、UP+マニュアル駆動開発
  • 要求がとても抽象的、あるいは小さな要求から将来的に拡張していくような案件については、アジャイル+マニュアル駆動開発

さらに大型案件では、アジャイル+マニュアル駆動開発からUP+マニュアル駆動開発、さらにウォーターフォール+マニュアル駆動開発へ変化していくこともあるかと思います。

4.マニュアル駆動開発の成果物
4−1.システム本体とマニュアル以外の成果物
基本的に、マニュアル駆動開発において、システム本体と各種マニュアル以外の成果物は定義しません。最小構成で開発を行うことを想定します。しかし、それでは開発できないプロジェクトやチームがあることも想定されます。たとえば、低コンテキストな環境、開発場所が分散していたり、開発チーム内での暗黙知がまだ熟成されていないような環境や、新しいアーキテクチャーに基づいた開発を行わなければならないような場合、仕様書から設計書への詳細な変換が求められるでしょう。その場合の参考になるような一定の成果物の指針を挙げます。

  • 業務マニュアル
    • 業務フロー
      • DFDかマジカ!により作成。
    • プロジェクトスコープ記述書
  • 運用マニュアル
    • 運用フロー
      • DFDかアクティビティ図により作成。
    • WBS
      • ワークパッケージ
      • WBS辞書
    • リスク登録簿
    • プロジェクトスケジュール
    • ドメインモデル
  • 操作マニュアル
    • WBSのアクティビティ
    • 外部設計書
      • 画面遷移図
      • 画面(帳票)設計書
      • 画面(帳票)項目設計書
      • 機能設計書
    • ER図or実装レベルのクラス図
    • シーケンス図等

上記のような設計書を作成するためのインプットとして、各種マニュアルを使用したらよいかと思います。逆に、上記のような設計書をマニュアルに統合する方向で考える事がマニュアル駆動開発で可能になると考えています。