サイト内検索

閉じる閉じる

サイト内検索

閉じる

ITアーキテクトコラム

  1. コラム
  2. ITアーキテクトコラム
  3. アジャイル開発にドキュメントは不要か?

アジャイル開発にドキュメントは不要か?

2018/10/26

友野 敬大友野 敬大

  • Facebook
  • Twitter
  • google+
  • はてなブックマーク
  • アジャイル開発

価値のあるドキュメント

アジャイル開発手法(※1)が現場に取り入れられるようになって久しくなり、
既に採用済みあるいは、採用するべくまい進されている読者の方もいらっしゃる
と思います。ご存知のとおり、アジャイル開発手法にはその考え方の根幹を成す
アジャイルソフトウェア開発宣言(アジャイルマニフェスト)」があります。
その一節に「包括的なドキュメントよりも動くソフトウェアを価値とする」とあ
るとおり、動くソフトウェアに注力する価値基準ですが、ドキュメントに価値が
ないといっているわけではありません。今回は、このドキュメントについて、プ
ラクティスを交えながら話をしようと思います。

ウォーターフォール手法を採用した開発現場(プロジェクト)では、あらゆるフ
ェーズでドキュメントを作成します。上流工程の成果物である業務フローや要件
定義書をはじめ、下流工程の成果物である外部(基本)/内部(詳細)設計書や
テスト計画書まで、目的や内容は多岐に渡ります。フェーズごとの品質や進捗状
況を評価するためには必須なものであり、これが包括的なドキュメントです。 一
方で、動くソフトウェア=プロダクトに必要なドキュメントは何かと考えると、
その目的は少し異なってきます。究極的に言えば、「何を実現するものなのか」
と「どのように振舞うものなのか」の2点に集約されます。前者は要求を整理し
たものであり、後者は仕様を取りまとめたものになります。

両手法を比較すると違いが見えてきます。
どのように実現するのか、つまり"HowTo"のドキュメントの有無です。 これは
動くソフトウェアを欲するビジネスサイドから考えると至極当然で、どのように
動いているかよりも、何("What")を実現できるかどうかに関心があるためと
言えます。言い換えると、これらの"What"のドキュメントは価値があるという
ことです。

代表的なものとして、概念モデルやシステムアーキテクチャなどが、"What"のド
キュメントとして挙げられます。ちなみに、"HowTo"ドキュメントが一切不要と
いうわけではなく、説明責任を果たす上で必要なドキュメントは中間成果物とし
て作るべきです。案件や顧客属性によって、作成するドキュメントの種類やボリ
ュームを変えていく必要があります。

 

Model as Code - コードでUMLモデルを書く

さて、皆様はドキュメントを、どのようなツールを使って作成していらっしゃい
ますか。MS WordやExcelが多いでしょうか。もちろんこれも1つの解だと思い
ます。アジャイル開発の中では、Wikiに書くというのも選択肢の1つです。チー
ム内で共有することを考えると、Wikiは非常に便利です。本コラムでは、さらに
コードで表現する」ことを提案します。

参画している案件では、AsciiDoc(※2)とPlantUML(※3)というツールを利
用してドキュメントを作成しています。AsciiDocは軽量なマークアップのひとつ
で、あらかじめ定義された構造表現を利用して文書を作成することができます。
PlantUMLは独自のDSL(ドメイン特化言語)を利用してUML図を作成すること
ができます。いずれも共通点はテキストであることで、以下の点で優れています。

●バイナリと比較して軽量、かつ差分の比較が可能
●バージョン管理することでチームでの共同開発が容易
●レイアウトは自動で行われるので開発者毎の表記ブレが少ない
●ツールを組合せてリアルタイムで編集可能

専用ツールと比較して表現力が劣るなどの欠点(短所)もありますが、それを補っ
て余りあると思います。どうしても表現できない場合は、別途画像を用意するな
どして対処します。 その他、利用しているツール群は下記の通りです。

ドキュメントのための開発ツール群

上記構成では、Visual Studio Codeで編集したものが即座にプレビューされ、確
認しながら作業可能なのでスピーディかつ効率的にドキュメント作業を進めるこ
とができます。

リアルタイムプレビューでドキュメントを作る

 

常に共有することをセットで考える

ドキュメントは一度作って終わりではありません。ビジネスの変化に伴いシステ
ムが変化していくように、ドキュメントも日々更新されるものです。特に"What"
のドキュメントはそれが顕著です。情報共有がうまくできていない現場では、思
い込みや誤解が錯綜し、結果的にシステムの品質にまで影響します。

Wikiでドキュメントを作成する利点の1つに、チーム内での共有しやすさが挙げ
られます。同じ時間に同じ情報にアクセスしていることを、仕組みとして担保で
きます。前項でご紹介したツール構成では、作成したドキュメントをHTMLへ変
換・出力することができます。これをCIツールに組み込んでWebサーバーへ配
置すれば、同様の効果を期待できます。AWSをはじめとしたパブリッククラウド
サービスを利用すれば、自前でサーバーを管理せずに(=サーバーレス)、ドキ
ュメントCIを実現することが可能です。以前のコラムでご紹介したOSS、RedPen
と組合せればさらに強力な環境を手に入れることができます。参画している案件
では、AWS CodeBuild + Amazon S3(Webホスティング)を利用しています。

 

まとめ

アジャイル開発手法を採用したからといって、ドキュメントが無くなることはあ
りません。むしろ、その重要性はさらに増すばかりです。作ったきりで形骸化さ
せないためにも、自動化やメンバーの負荷を軽減する施策を導入し、ソフトウェ
アと同様に環境変化に合わせてドキュメントを進化させていくことができれば、
その真価を以ってチーム開発に寄与することでしょう。

 

  • ※1 ここではスクラムを代表とする、いくつかのプラクティスを総称してアジャイル開発手法としています
  • ※2 http://asciidoc.org/
  • ※3 http://plantuml.com/
  •  
  • 本文中に記載されている製品名などは、各社の登録商標または商標です

著者プロフィール

友野 敬大

友野 敬大

法人事業本部 ビジネスソリューション第3部
プラットフォームソリューション第1グループ リーダー

当社のクラウドサービス「寄付金クラウド」をはじめ、金融機関向け・エネルギー企業向けの複数のクラウドサービス案件に参画し、基盤構築からアプリケーション開発(Java)まで幅広く従事してきました。これらの経験から、プロダクト(ひいては組織)の全体最適化に興味を持ち、その一つであるDevOpsを推進し、お客様に提案しています。先日、娘が生まれ、溺愛しています。

資料請求・お問い合わせはこちら

インターネットからの資料請求

インターネットでのお問い合わせ

お電話でのお問い合わせ

営業代表03-6757-7211

受付時間 9:00~17:30(土日祝日を除く)