(1/2)開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。});文書作りは好きですか?今回からこの連載を担当いたします、アクセンチュア・テクノロジー・ソリューションズの宮本和洋です。システム開発プロジェクトでは、さまざまな文書が作られます。私の連載ではこの文書に注目し、「文書ドリブン開発」という考え方を紹介したいと思います。文書ドリブン開発は私の造語です。「文書が作成されることにより、具体的な開発作業が進行していく」ことを意図しています。多くのITエンジニアは、文書作りではなく、動くものを作ることに楽しさを見いだすと思います。その作業の楽しさの中には、システムの設計に悩み、動作実証実験を繰り返す楽しさも含まれているのではないでしょうか。「この仕組みでちゃんと動くかな〜、どうかな〜」と試してみることが、ワクワクドキドキして楽しいという経験がありませんか?開発プロジェクトそのものの設計にも、「動くかな〜、どうかな〜」と同じような楽しみがあります。人の動きや情報の動きを設計して、開発プロジェクトを形作っていくという点ではモノ作りと似た醍醐(だいご)味があります。文書作りの作業は、プロジェクトそのものの設計作業にほかなりません。文書作りに、少し興味がわいてきませんか?認識共有のための文書の重要性システム開発プロジェクトで作成される文書には、大きく分類して以下の3種類があると考えられます。範囲の人間との認識を同じくするための文書。情報伝達ある人間の考えを別の人間に伝えるための文書。証左ある出来事が確かに起きた、起こしたという記録を残すための文書。システム開発プロジェクトで作成される文書の種類システム開発の現場で作成量が最も多く、作成に最も時間をかけるのは、設計者から開発者への「情報伝達」を目的とした設計書だと思います。作成すべき設計書の種類やその記述レベル、記述項目は、「認識共有」の文書で定義されます。「証左」として残すものの定義についても、やはり認識共有の文書で決定されます。認識共有の文書の出来いかんで、プロジェクトの成否が決定されるといっても過言ではありません。認識共有の文書の量や内容は、プロジェクトの人数規模や工数規模によって調整されます。作成のタイミングは、「認識共有」をしたいと思われる都度です。計画書を作ろう認識共有を推進するために、工程ごとに計画書を作ることを推奨します。プロジェクト規模の大小にかかわらず、作成する方がよいと考えます。各メンバーはこの計画書を読んで、それぞれの工程ですべきこと、ゴール、プロセス、アウトプットの意識を共有することになります。工程ごとのキックオフ資料と呼ばれているものと意味は同じです。仮に計画書が作成されなかった場合、成果物の記述レベル・品質は開発者によってバラバラ、仕事の優先順位は決まらず、タスクの遅延、共有すべき情報の漏れなどが発生し、プロジェクトの混乱を生むでしょう。計画書は行動指針にもなるため、できる限り実行性を考慮したものがよいでしょう。すべての物事が考慮され、綿密な計画が立てられたうえで記述されることが望ましいですが、プロジェクトは生き物であり状況は刻々と変化するので、ある程度は途中で変更せざるを得ません。以下に、普段私が作成している計画書の記載項目を紹介します。状況や工程によって記載内容は変化するため、それに合わせて書き換えています。優先すべき基準(品質、納期、コストなど)。流れ、インプットとアウトプット作成する成果物アウトプットの種類、管理方法を明確に指定。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。