SI開発の標準化で大事なこと

はじめに

この文章について

10分ぐらいで読めるようにしています。

題材はエンタープライズ・V型モデルでのSI開発の標準化です。

寄稿（者）の背景

業務アプリやアプリ方式（アプリ共通）に従事してきました。

V型のウオーター・フォールモデルの開発しか経験しておらず、アジャイル開発は経験ないです。

その中で「何でも屋さん」的に動いた末、一番経験して痛い目みたのが「標準化とその考え方」だと思ってます。

以下のような方に届くといいなと思って書いてます。
- 経験のない中で「標準化やれ」と言われどう臨めばいいか分からない
- 標準化を進めているが周囲からの評判が悪い

・・・

なんやかんやで「標準化」って「テクニカルなこと」だけではなく、「精神論（心意気）」、「マネジメント」も大事なんだよな～

SI開発の標準化で大事なこと（本編）

精神論（心意気）

目線（目的意識）

「標準的なルールを規定する」のは仕事の一部でしかない。

現実的なワークロードで守れないルールは陳腐化するか開発チームの足かせとなり生産性を下げる。

「SI開発を成功させうる標準化」＋「エンハンスに向けて開発チームの文化になりえる標準化」を目指すべき。

「納品時のシステム」の目線だけでなく「エンハンスに耐えうるチームも納品する」という目線（目的意識）が欲しい。

長大／厳格なガイドを極力書かない

長大なガイドは読む意欲、ひいては生産性を下げる。

例えばV型モデルの下流工程でプロジェクトがスケールアップすることが多い。

その時、新任開発者のガイド読了が開発のクリティカルパスの場合、下流工程立ち上げ直後の生産性が出ないし、遅延が発生する。

また厳格すぎるガイド（ルール）は開発者の意欲を削ぐ。

大事なところをだけを抑えて、ある程度開発者（各チーム）に自由な裁量を与える。

一部のルール崩し（≒個別最適化）の相談をされたら柔軟に対応すること。

ツール（自動化）を活用

例えば、ソースコードの静的チェックツールなどがある場合、コーディングルールを文書化しない。

ツールを利用することを標準ルールとして、低いワークロードでルールを守らせる。

そもそも守るのにワークロードのかかるルールは尊重されないため、文化として定着するのに苦しみが伴う。

教育計画をおざなりにしない

「ガイドの読み合わせ会」、「今更聞けないことも聞いてＯＫなＱＡ会」など開催してリードする。

「”読みました”の星取表」、「ガイドとセットのサンプル作成」などを作成して提供する。
（例えば、先行開発に標準化担当もＪＯＩＮして、その成果をサンプルとすればよい）

「ルール／ガイドを作ってオシマイ」ではなくて、あの手この手で「文化が根付くところまで」までナビゲートすること。

また、リードする側が苦しくならないように上記のようなことを「教育計画」としてスケジュールに織り込むこと。

マネジメント

言葉の定義（用語集／辞書）

プロジェクト内で頻出する言葉についてはきちんと「言葉の定義」をすべき。

文脈が曖昧だったり、相手（会話、読者、他）の基礎知識次第で解釈がブレてしまう。

最悪のケースだと、見積時の「単位」の認識齟齬にもつながり、予算ショートを招く。

作成するルールやガイド類だけでなくプロジェクト内のコミュニケーションに欠かせないことなので「言葉の定義」をリードする。

用語集や辞書などを整備するとよい。

数の関係（モノの単位）の規定

言葉の定義と並行して、言葉同士の「数の関係（モノの単位）」を定義すべき。

• 簡単な例（方式チームの領分かもしれない）
  • ユーザから認識できる画面ごとに画面設計書を１Book
  • １画面：nコンテナ
  • １コンテナ：１ｗａｒ：nＡＰＩ（のインターフェース）
  • １ＡＰＩ：１Controller：nUsecase：ｍRepository

数の関係（モノの単位）が曖昧だと、見積やスケジュール作成など「モノを作成する前」の段階で躓いてしまう。

ER図のような形で言葉の数の関係を図示するとよい。

「標準化チーム」の標準化

SI開発では「設計開発標準化チーム」が設置されることがある（以降「標準化チーム」）

各チームに先駆けて標準化を進めなければいけないチームが、以下の例だと、品質管理の文脈で後手を踏む。
（V字モデルでSI開発する場合、Vの字の左側の上部～中部で発生しやすい）

• 例）
  • 「PMOチーム」はアプリケーションチームの設計に先駆けて、品質管理ルールを規定する。
  • 「標準化チーム」はアプリケーションチームのために活動を行うので自チームのルール作成が後手になる。
    → レビュー記録の方法や集計方法のルールがない状態で「標準化チーム」は活動することになる。

これは各チームや影響する活動のクリティカルパスを読み、リカバリや合流するスケジュールをしておくことで対処する。

（踏襲できるか、輸入できるルールがあるならそれを積極活用でもよし。チケット管理ルールなど特に）

さいごに

少しでもご興味もってもらえる方がいるなら、今後もこの文脈で寄稿したいです。

ご質問などあればぜひ。