はじめに
まじめにやっているのにうまくいかない。標準なんだからその通りにやればいいじゃないか。そう思われるかも知れません。
しかし開発標準で守らないといけないことには幅があり、それなりの自由度があります。きちんと理解した上で適切にモデリングすれば、効率的なモデリングが可能になります。
開発標準
開発標準は成功したプロジェクトを参考に、良いプロセスの実施が容易な様に、実施すべき各作業とその確認方法を定めたものです。開発者を支援して、一定のレベルへの底上げや組織的な改善を可能にします（その反面、さまざまな罠もあります。標準は諸刃の剣）。
モデリングをする際にも、ある時はガイドやノウハウ集として使えますが、時には収集したデータの正常範囲を定めるなど、モデリングや実装の作業を制限します。
開発標準を良く読む
大切なのは開発標準を良く読むことです。開発標準には以下のようなことが書かれていると思います。
- 全体の構成と考え方（ガイド）
- 守らないといけないルール（制約）
- 一般的な方法（ガイド）
ガイドに当たる部分はうまくいったプロジェクトで行われた一般的な開発の方法や作業が書かれています。制約に当たる部分は守らないといけないルールで、作業だけでなく何らかのメトリクス（尺度）が定められているでしょう。作業のエビデンス（照査）となるデータの収集が必要です。レビューやテストの項目数や時間など一定の量が必要になり、作業が制約を受けるでしょう。
開発標準には多くの役立つことや勉強になることが書かれていますが、必要なことが全て書かれている訳ではありません。書かれていることに従って、それだけをコツコツ実施しても、必ずしもうまくいくとは限りません。
リスクが工数に見合うだけ低減するなら、下記のようなモデリング作業の変更が必要になります（同程度でも実施します）。
- 増やす
- 必要なモデリングを追加します。多くの場合、設計作業の追加はあまり禁止されていません。
- 前倒し
- よりリスクが低減するなら後工程の作業を前倒しします。一部詳細化したり、プロトタイピングの実施など、本格的な実装でなければ許容されるでしょう。
- 分解
- モデリング作業を分解し、調査、整理、考えるといった作業を前倒しします。会議内で（モブ）モデリングしても良いでしょう。
逆らっても徒労に終わることが多い
若気の至りで開発標準に抗議したこともありますが、逆らっても徒労に終わることが多いです。開発標準は必要な作業の抜けを防ぐ目的で組織として決めたものです。個別のプロジェクトに対してテーラリング以外の変更を要求しても、許容する権限が担当者にありません。
逆に制約だけを守れば、意外と自由度があるものです。ガイドを読んでしっかり活用することで得られることも多いでしょう。
とはいえ、どのような標準も使っていれば時代遅れになるもので、改善案は提案してください。パイロットプロジェクトで確認することも必要ですので、改訂には複数年かかるでしょう。
開発標準のフィールドで走り回れ
多くの競技にはコートのような活動領域が決められていて、競技者はその範囲を有効に使いながら、敵を攻略します。
開発標準は縦にだけ動けるサッカーゲームの様に、典型的ないわば「型」を示したものです。定められたフィールドからはみ出さない程度に、右に左にゴールに向けて戦略的に攻撃ください。
おわりに
効率的なモデリングをマネージメントする方法を3回に分けて説明しました。以前はうまく開発できていた人が、プロジェクトが変わると急にトラブルに巻き込まれる。そんな姿を見たくありません。
開発標準と改善活動はフィットするプロジェクトにはとても効果的です。しかし、それぞれの作業がなぜ必要なのかをきちんと理解しなければ、典型的なプロジェクト以外に応用がききません。
何が制約であり、なぜそのようにするかを理解すれば、開発標準を味方につけられます。そして、自由なフィールドを手に入れて様々な実施方法ととることができます。
釣りは「ぼーっ」としていては釣果が出ないそうです。常に「ああかな」「こうかな」と状況を見極めて必要な行動が必要だそうです。ソフトウェア開発でもいつもリスクを見極めてダイナミックに適切な対応をとることが、リスクと戦う効率的な方法だと思います。
「だから、あなたがたは気をつけていなさい。」マルコによる福音書/ 13章 23節（日本聖書協会 新共同訳）