フリーエンジニアのブログ

今年の夏に知人から紹介してもらった人が書いた書籍なので購入し最後まで読んでみた。

レベルは初級～中級者向けと書いてあるが、ある程度オブジェクト指向開発の経験を積んだ人でも読んでみると良いと思える内容であった。オブジェクト指向の基礎から始まり、開発プロセスのそれぞれの場面応じたモデリング方法(ＵＭＬ使用方法)がポイントを抑えて丁寧に説明されている。また、著者の経験に基づいた開発作業上の注意点が書かれていてそれも参考になった。厚さはあるが、文章がわかりやすいので３日ほど一生懸命読めば読み終わる。

この本を読み終わり、開発プロセスについてあらためて考えてみた。最近のはやりとして「アジャイル」な手法が話題となっている。これは「暗黙知」を頼りとしてドキュメントをなるべく作成せず、「ソースコードが全て」の開発プロセスである。

アジャイル手法の主張する事もわかるが、私はやはりある程度のドキュメントは必要であると思っている。
人の「わかった」には非常に個人差があり、その個人差はそのままプロジェクトのリスクにつながっていく。
プロジェクトメンバーがそれぞれ「わかったつもり」で進んだプロジェクトはその後半で、
大きな手戻り等、ダメージが大きいアクシデントが待ち構えている事であろう。つまりリスクが高い状態である。

そのような事にならない為にも、ドキュメントを作成する事である。

図を作成し、文書を作成する。図にできないと言う事は理解が曖昧であるという事である。
目に見えるものでお互いの暗黙知を確認する事により、お互いの認識にずれがある事がわかる。
図をベースに認識を確認するような場で検討不足項目も洗い出されいく。
つまり、ドキュメントはプロジェクトの叩き台となり、リスクを下げるための道具ともなるのである。
そのような検討フェーズを経て、ドキュメントは仕様書となり、設計書へとつながっていく。保守用のドキュメントとしても、納品物としても使用できる。

このように非常に有効なドキュメントなのに、なぜ作成しないのか。

それは、適切なドキュメントを作成できる能力を持った人材が少ないからである。
頭の中ではシステムの仕組み・構成についてしっかりと把握しているエンジニアの数は少なくない。しかしそれを人の目にみえるかたちにする事が不得意なエンジニアが非常に多いと私は実感している。
なので、ドキュメントを作成を依頼されると嫌がるエンジニアは多いし、ドキュメント作成に自信を持っている人も少ない。そのような状況であるから、ドキュメント不要、コード重視型のアジャイル手法がもてはやされるのであると私は考えている。

最近の開発では、組織にプロセス定義が行なわれていない限り、ドキュメントは他の人から強制的に求められる事も少なくなってきている。
しかし、上述したようにプロジェクトのリスクを少しでも下げる為には叩き台となるドキュメントを作成できるエンジニアが必要であり、
そのようなエンジニアがいるプロジェクトは成功する可能性が高いと私は考えている。

但し、注意点としては、開発期間が短縮されている状況なので、ドキュメント中毒にはならない事である。
期間、システム仕様のバランスを考え、作成ドキュメントについてその都度検討する必要があると思う。

バランスのとり方としては、ドキュメントをフルに作成した場合の、プロセス定義・成果物定義を行い、
その後、期間・人員によって、不要なものを削っていけば良いとおもっている。