こんにちは。
ライジングサン・システム・コンサルティングの岩佐です。
今回は、アジャイルソフトウェア開発におけるドキュメントの重要性について解説します。
あなたはアジャイルソフトウェア開発…にかぎらず、ソフトウェアの開発プロジェクトにおいて、ドキュメントをどの様にとらえていますか？
もしかしたら「誰も読まないのに儀式的に書かなければならない面倒くさいもの」という印象を持たれているかもしれません。
私も過去、ドキュメントに対してそのような印象を持っていました。
特にウォーターフォール手法で開発していた頃は、元請け企業から提示されたドキュメントを、意味も変わらず、役割も分からず、ただただ「決まりだから」と言われて書いてたので、そういった思いを強く持っていた記憶があります。
一方、アジャイルソフトウェア開発では、あまりドキュメントを書かない、もしくは全く書かないという、行き過ぎた印象を持たれています。
もしかしたら、ドキュメントを軽視するスタイルでプロジェクトを運営しても成功する有能なチームもあるのかもしれませんが…
私はアジャイルソフトウェア開発だからこそ、ウォーターフォール手法とは別の文脈でドキュメントを非常に大切だと思うようになりました。
確かに私自身が過去経験してきたウォーターフォール手法を用いたプロジェクトと比較すると、記述するドキュメントの「量」は圧倒的に少ないです。
しかし、特に「質」的な意味合いにおいては、ドキュメントの重要性がより上がったと感じています。
この記事では、私がアジャイル開発においてもドキュメントを重視する理由を、次の４つの視点から解説してみたいと思います。
1.対話の質を上げるためのドキュメント
私は技術者同士での対話もさることながら、お客様との対話の質を上げるために、ドキュメントは非常に重要だと考えています。
ここで言う「対話の質」とは、ある抽象的な概念において、情報を伝えたいと思っている側と、その情報を受け取りたいと思っている両者が、より高い臨場感でその情報を理解し合えることができるという意味での質です。
ソフトウェア開発では抽象的な概念が話題になることが多々ありますよね。
業務フロー然り、ビジネスモデル然り、データモデリング然り…
直接見ることができない、触ることができない、感じることができない抽象的な概念に対しての理解度は、その概念との接触頻度や過去の経験によって人それぞれ異なります。
しかし、この抽象的な概念を、プロジェクトの利害関係者が、高い臨場感を持って理解できないと、なかなか開発作業というのはうまく進みません。
特に弊社では、お客様のソフトウェア開発の内製化を支援する「共同開発」というサービスをご提供していることもあり、お客様の会社に所属されるプログラマと私が一緒になってひとつのソリューションを開発します。
この共同開発をスムーズに進めるためには、私達とお客様の双方が、ビジネスとソフトウェアというそれぞれの抽象的な概念をお互いに高い臨場感で理解を深めることが成功の鍵になります。
そしてお互いの理解を深めるためには、お客様との豊富な、そして質の高い対話が最も重要だと考えます。
ここで交わされる対話は、お客様が理想とされている業務フローや業務ルールや中長期的なビジネスプランといったビジネス側の話題から、拡張性の高いデータベース設計のコツや、高度な技術要求を実現するための開発テクニックといった技術的な話題まで多岐にわたります。
これらの対話を、より質の高いものにするためにドキュメントを用いることが有効だと判断した場合、私は積極的にドキュメントを記述します。
この時のドキュメントの位置付けは、新しい発想を促し、アイデアへの理解度を深め、そしてより素早いアクションを生み出す原動力になるよう心がけます。
何も可視化されたドキュメントがない状態でお客様とダイヤログを重ねた場合と、ある一定のレベルで可視化されたドキュメントがある状態でお客様と対話を重ねた場合、私自身の個人的な経験では、やはり後者のほうが圧倒的に質の高い対話ができます。
ここで重要な事は、ウォーターフォール手法でのドキュメンテーションのように、「言った・言わない」を防ぐであったり、設計仕様を正確に記述することが目的では無いということです。
重要なのは、お客様と私達がそれぞれで考えていること、思っていることを、それぞれが高い臨場感をもって理解し合える「橋渡し」的なツールとしてドキュメントを使うということです。
2.抽象度を上げるためのドキュメント
私達が手掛けるプロジェクトは、ある特定の部門や機能を実現する「ツール」の開発プロジェクトではなく、企業活動全体を包括的にサポートするような「システム」を構築するプロジェクトがほとんどです。
一般的には、こちらにあるバリューチェーンで表現される「主活動」を包括的にサポートするソフトウェアの開発が対象となります。
このように、部門横断的なシステム開発をサポートさせていただくことがほとんどなので、その全体構造は非常に複雑で変化の激しいものになります。
このレベルのソフトウェアを開発する際に、全くドキュメントなしで開発する場合と、一定レベルのドキュメントを記述するのとでは、どちらがより質の高いソフトウェアを、より速く開発することができるでしょうか。
私は後者だと思います。
もちろん、小規模なソリューションや特定業務だけに特化されたツール型のソフトウェアであれば、ドキュメントの重要性はそれ程高くないかもしれません。
しかし、部分最適も実現しつつ、全体最適も同時に求められるような包括的ソリューションでは、やはりその全体像が可視化されていないと、どうしても開発作業が進めづらくなります。
そして結果が、低品質なソフトウェアと、開発スピードの鈍化につながります。
私達がドキュメントを書く上で重視しているのは、「抽象度を上げる」ということです。
つまり「木を見て森を見ず」の状態に陥ることを防ぎ、「木を見て森も見る」状態を創りだすことです。
その為には、ソリューション全体のER図やビジネスフローチャートは、欠かすことができない重要なドキュメントです。
もちろん、ソフトウェアの仕様を確認するという文脈において「最も信頼できるドキュメント」は、今この瞬間、実際の商用環境で動いているプログラムコードです。
人間が記述したドキュメントは、この実際に動いているプログラムと差異がある可能性があるので信頼できません。
この見方はある意味正しく、私もそのとおりだと思います。
しかし、私がソフトウェアの設計情報をドキュメント化する目的は、あくまでも設計の抽象度を上げて全体を俯瞰し、ソリューション構造の最適化を図ることです。
今動いているソフトウェアの内部構造を、プログラマ以外の「非専門家」でも理解できるような表現方法や抽象度で記述することが目的ではありません。
完成しているソフトウェアの内部構造を確認することが目的であれば、やはりソースコードを直接確認するのが一番です。
実際、私が用いるFileMakerプラットフォームであれば、DataBase Design Report（DDR）機能を使って、今この瞬間動いているソフトウェアの内部構造を自動解析し、ドキュメントを自動生成することが可能です。
DDRを用いれば、例えばあるテーブルのあるフィールドが、どこで、どのような役割で使われているのか、どのプログラムからどのようなタイミングで参照・更新、あるいはクリアされるのかをメカ的に調査することが可能です。
もちろん、メカ的に解析した結果がドキュメントになっているので、人間が手作業で調査し、それをドキュメント化したものよりも、よほど正確ですし、ドキュメント作成の手間もいりません。
ドキュメント化の目的は、あくまでも抽象度を上げることです。
ソフトウェアの内部構造を正確に把握するためのドキュメント化は、「抽象度を上げる」という目的とは相反するものなので、そのようなドキュメントは作成しません。
そもそもこれだけソフトウェア開発ツールが進化した現在、そのような目的でドキュメントを記述するのは「ムダの極み」だと思います。
しかし、ソリューション全体の構造が本当により最適なのか、拡張性は担保されているのか、保守性は高い状態を保てているのか、サブシステム間のデータの流れ欠落は無いかといったことまでは、メカ的に解析することができません。
そしてもし解析できたとしても、それを開発ツール自身が、自律的に拡張性の高い状態、保守性の高い状態に、自動的にソリューション全体を最適化できるものでもありません。
そこはどうしても「人間の意思決定」を介入させる必要があります。
そしてこの「意思決定」の質を上げるためには、ある一定のレベルで抽象化された全体構造を可視化したドキュメントが重要だと思います。
3.利害関係を調整するためのドキュメント
先述のとおり、私が手掛けるソフトウェア開発プロジェクトは、企業のビジネス活動全体を包括的にサポートするソリューションです。
このようなプロジェクトではやはり、「部門間の利害の対立」が発生します。
特に部門横断的なプロジェクトであれば、それぞれの部門から見た「正義」があり、当然その「正義」を実現するための機能実装を、それぞれの担当者が求めてくるので、時にはその「正義」が対立することがあります。
例えば典型的な対立は、事業部門と管理部門の対立でしょう。
一般的に事業部門はある程度の不確実性を受け入れながら、正確性以上にスピード重視の傾向があります。
一方経理等の管理部門は、不確実性を可能なかぎり排除し、スピード以上に正確性を重視する傾向にあります。
このお互いの「正義」の対立が、部門横断的なソフトウェア開発プロジェクトでは良く発生します。
この利害の対立が発生してしまうことは、現在のように高度に専門家された部門間の連携によって成り立っているビジネスではしかたのないことです。
それに、「より良いソリューションを開発する」という文脈においては、一定レベルの対立や摩擦は歓迎すべきものです。
もちろん、ソフトウェア開発ベンダーの立場からすると、「社内調整はお客様自身でやってください」という考え方もあると思います。
しかし、お客様内部だけで調整した結果が本当にベストな結果なのかどうかは一考の余地があると思います。
特に、２項対立の罠にはまった議論は、両者の利害にあまり関係のない我々のような第３者が適切に介入することで、お互いの「納得解」を導き出せるケースは多々あります。
さらにこの２項対立で最も避けたいのは、属人的な意見の対立です。
同じ意見の対立でも、意見に意見するような建設的な対立であればよいのですが、「あいつが言うから気に入らない」といった坊主憎けりゃ袈裟まで憎いのような対立は避けるべきです。
そしてこのような第３者として私達が介入させていただく時に、ドキュメントは大きな効果を発揮します。
ドキュメントは、人と人との間に立って、対立の緩衝材になってくることがあります。
また、意見Aと意見Bの共通項が可視化できれば、よりお互いが納得できる意見Cを発見する手がかりも提供してくれます。
利害の対立で重要なことは、より抽象度の高い全体像の中で議論を行うということです。
そしてやはり「抽象度を上げる」という文脈において、ドキュメントは非常に有効な道具となります。
4.計画を可視化するためのドキュメント
私達は、共同開発サービスを最低でも半年から、長期の場合は１年の契約でご提供させていただきます。
当然、長期の契約で多額のお金をいただくわけですから、当然予算決裁権をもつクライアント企業の意思決定に関わる皆様には、ある一定レベルで、「何がいつまでに実現できる予定か」を説明する義務があります。
ここで重要なのは、最初に立てた計画は変わることを十分に説明することです。
そもそも私達がご提供しているサービスは「つくって終わり」「完成すれば必ず見込んだ効果が出ることを担保」できるようなサービスではありません。
そもそも、お客様のビジネスにおける内部環境・外部環境の変化に柔軟に対応できることがアジャイルソフトウェア開発や、ソフトウェア内製化の良いところです。
例えば当初の計画では、機能A・機能B・機能Cを「A→B→C」の順番でリリースする計画を立てており、その計画をプロジェクトの利害関係者で共有していたとします。
そして実際に「機能A」をプロジェクト開始の１ヶ月後にリリースしたとします。
ここで実際に「機能A」使ってみた結果、計画では次にリリースするのは「機能B」ですが、実は「機能C」を先にリリースしたほうが、より早期に投資回収できると判断したとします。
このような場合、最初に立てた計画を忠実に守るのではなく、確実に「利」を取ることができる新しい計画に更新すべきです。
しかし、プロジェクトの利害関係者は「A→B→C」の順番でリリースすることを前提に、様々な準備や内部調整を進めている可能性があります。
このように、一度合意したスケジュールを、「IT投資の成功」という文脈における合理的な判断として変更する場合、それを利害関係者に説明する責任があります。
さらに、プロジェクトのスポンサーである経営トップには、このことをしっかりと説明し、納得してもらう義務があると私は思います。
なぜなら経営トップとは「お金の使い方に責任を持つ」ポジションにいるからです。
また、計画が変更になることで、特に部門横断的なシステムの場合には、予定していた人員計画や業務ルールの変更計画に影響が出ることもあります。
そんな時に、ただ口頭のみで説明するよりも、口頭に合わせてドキュメント化された変更理由、そして変更したほうが、会社全体としてより高い利益を得ることができる旨がドキュメントとして示されてている方が、よりお互いの納得感を得られるのではないかと思います。
ここで重要なのは、計画を守るために計画を可視化するのではなく、計画を柔軟に変更するために計画を可視化するという概念です。
計画が何も可視化されていない状態での計画の変更は、ある意味「変更」とは言えないかもしれません。
なぜなら、それは組織活動という文脈において「合意」しているとは到底思えないからです。
変更が合意されているならが、当然「変更前」と「変更後」が可視化されており、変更されたことによる利害関係者への影響が分かる状態にしておくことが、プロジェクト全体をよりスムーズに動かすためには非常に重要なのです。
ドキュメントの記述を端折ることで、確かにドキュメント製作時間を削ることはできるかもしれません。
しかし、その代償として、別の部分…
特に組織の利害関係の調整に時間がかかるようであれば、それは本末転倒です。
重要な事は、プロジェクトの全体スピードを落とさないという、より抽象度の高い視点なのです。
まとめ
この記事では、アジャイルソフトウェア開発におけるドキュメントの重要性について記述してきました。
お気づきのかたもいらっしゃるかもしれませんが、記事のシナリオに関しては、アジャイルソフトウェア開発宣言をもとに構成しました。
アジャイルソフトウェア開発宣言には、４つの価値基準が述べられています。
- プロセスやツールよりも個人との対話に価値を置く
- 包括的なドキュメントよりも動くソフトウェアに価値を置く
- 契約交渉よりも顧客との協調に価値を置く
- 計画に従うことよりも変化への対応に価値を置く
この４つの価値基準において、ドキュメントに関する言及は、上から２番め「包括的なドキュメントよりも動くソフトウェアに価値を置く」という部分でしょう。
私には「包括的なドキュメント」の具体的な定義がよくわかりません。
しかし、私が作っているドキュメントは、私自身がウォーターフォール手法で作ってきた、もしくは見てきたドキュメントよりも「包括的」ではありません。
私自身が、大切にしている価値基準は次のとおりです。
- 対話をより高い質にするために有用であればドキュメントを書く
- 動くソフトウェアを素早くつくるために有用であればドキュメントを書く
- 利害関係者とのよい協調関係を構築するために有用であればドキュメントを書く
- 変化に対して俊敏に対応するために有用であればドキュメントを書く
このような価値基準でドキュメントを書いています。
無料動画プレゼント
FileMakerプラットフォームとアジャイルソフトウェア開発手法で大成功を収めたプロジェクトの解説動画をプレゼントいたします。
この動画では、アジャイルソフトウェア開発手法だけではなく、事例としてあまり聞くことの少ないFileMakerプラットフォームでのチーム開発についても、多くを学べる動画になっております。
今回ご紹介させていただくプロジェクトのお客様は、東証１部上場企業のサービス業です。
こちらのお客様が、新たに新規顧客獲得の増加、そして成約率の向上を目的としたコールセンターを立ち上げるということで、そちらのコールセンターで使用する顧客管理システムの構築事例となります。
プロジェクト立ち上げ当初は、具体的なコールセンターの業務フロー、メンバーも決まっていないという状況から、納品期日の３週間前にはすべての開発を終えて納品させていただくという、絵に描いたような成功プロジェクトとなりました。
また、この時にプロジェクトに参画したプログラマのプロジェクト中の残業時間はゼロ時間。
今すぐ、以下のコンタクトフォームから動画URLをご請求してください。
