Q.クラウドを採用する開発プロジェクトで、成果物をうまく作れずスケジュールの遅延につながっています。また、ドキュメントの保守も難しくなっています。(SIベンダー/ベテランSE)

 この2~3年でシステムを構成する技術が驚くほど変化しました。以前の感覚のままだと、プロジェクトは思うように進みません。

 ほんの数年前まで、業務システムの新規開発はJava+Oracle DBが鉄板構成。アプリケーションサーバーにWebLogicやWebSphereといった大がかりで汎用的な技術を使い、その上でプログラムを書くものでした。特定技術の利用が前提だったので、「仕様書」や「プログラム設計書」といった標準テンプレートのドキュメントを組織で用意して、各プロジェクトはそれを“埋めるだけ”で設計が完了しました。

 現在は技術の「専門特化」と「細分化」が進み、様々な技術を活用して、より安く高品質で使いやすいシステムの開発を目指す流れになっています。

 例えば、フロントエンドでは、「AngularJS」のようなJavaScriptのフレームワークを使います。バックエンドはAWSやAzureといったクラウドサービスを活用します。データは「Redis」や「Elasticsearch」「Amazon DynamoDB」といったNoSQLデータベースをRDBと組み合わせ、目的ごとに異なる技術で保持します。

 こうした環境では、実は定型ドキュメントの出番はほとんどありません。テンプレートを埋めたところで、設計できないからです。利用技術が変化する中で、設計という言葉の意味が「技術の選択と組み合わせの妥当性を確認すること」に変わってきています。

 変化に対応するには、(1)軽く設計してすぐに試す、(2)固まってきたら文書化する、(3)Living Documentを実践する、といった心得が必要です

 設計者が机上で文書を書くのではなく、ホワイトボードで「これならいけそうだ」「いやそれじゃうまく動かない」と議論し、これだと思った組み合わせを実際に試して動かしてみる―。これが昨今の設計の姿です。

 文書化するのは、議論と試行錯誤を経てうまくいきそうな組み合わせが見つかってからです。ドキュメントは方針と設定値とコード、これだけです。方針は、ホワイトボードに手書きした絵をパワーポイントで清書すればいいでしょう。時間がなければ写真を貼り付けるだけでも構いません。設定値は吸い出したパラメーター、コードはサンプルコードをガイドラインとして残しておけば十分すぎるほどです。

 最も重要なのは方針です。「なぜこの組み合わせなのか」を、保守や拡張開発を担当するエンジニアに伝わるようにしておきます。

 Living DocumentのLivingとは「生きている」、つまり「更新され続ける」ということ。これを可能にするには、ドキュメント管理に一工夫が必要です。これまでは、WordやExcelで作ったドキュメントをファイルサーバーに保管するのが典型的でした。この方法は「更新意欲が削がれる」という良くない影響があります。古いファイルと新しいファイルが散在し、目当てのドキュメントの最新版を探す段階でくじけそうになるからです。

 常に最新の情報に更新し続けるには、Wikiベースのドキュメント環境の採用をオススメします。Wikiソフトウエアはプロジェクトの環境や規模に合わせて選んでください。文書が散在しない、自動で履歴管理する、全文検索できるといった特徴があり、思いついたら遠慮なく記述を更新できます。PDF出力ができるため、レビューや納品といった区切りでの静的ドキュメント化も容易です。

 続々と登場する新しい技術に適応していくには、工程やドキュメントであまり細かな定義をせず、自由度を残しておくことが上手なプロジェクト運営の秘訣になります。