上司から開発の標準化を指示されました。部門内では複数の開発プロジェクトが動いていますが、技術も進め方もバラバラです。どこから手を付けるべきなのでしょうか。
(中堅システムインテグレーター/開発部/課長)

 「標準化」と聞くと、現場のエンジニアは一様に表情が曇ります。経営層など管理側の要望で推進されることがほとんどだからです。属人性からの脱却、生産性の定量化、一元的な監査といった標準化の活動は、多かれ少なかれ変化を引き起こします。管理側の目線で実施すると、開発現場にとってうれしい変化は起こりませんよね。

 標準化が不要というわけではありません。好きなようにできる“無法地帯”であることは、リスク管理や企業ガバナンスの観点から組織として望ましい姿ではないからです。何より「組織であることの強み」を活かせません。適切な標準化、いわば「魅力ある開発組織作りのための標準化」を実現する三つのポイントを紹介します。

 一つめのポイントは、「成果物ではなく行動様式を標準化する」です。

 標準化というと、「要件定義書」「機能設計書」「テーブル仕様書」といった成果物のテンプレートを用意する組織をよく見聞きします。しかし、この方法は具体的であるがゆえに“うまくハマる”プロジェクトが限定的になります。詳細な工程設計や採用技術などがすべて合致するプロジェクト以外では、テンプレートをそのまま使えません。技術が多様化した現在、成果物を標準化するのはまず不可能です。

 標準化すべきは行動様式です。例えばタスク出しの粒度やタスク見積もりの方法、リリース計画の作り方、コミット時の作法、コードレビューの観点、毎日の朝会、ふりかえりのタイミング、表彰などです。組織内のどのチームに行っても「技術は違うが同じ行動様式で活動できる」ようになれば、組織の価値観が共有され、結果として組織を一体にする引力になります。

 二つめのポイントは「工程を『試行錯誤』と『製品化』に分離する」です。

 実際の開発現場では、プロジェクトの前半で試行錯誤を必要とするタイプの活動を、後半で黙々と実装を続けるタイプの活動を行います。これはウォーターフォールでもアジャイルでも同じです。この2種類のタイプの活動を「エンジニアリングステージ」(試行錯誤)と「プロダクションステージ」(製品化)といった名称で、明確に工程を分離してみてください。

 エンジニアリングステージでは要件定義やアーキテクチャー設計、PoC(Proof of Concept)などを行い、プロダクションステージではUIの実装やエラー処理、運用機能の実装などを行います。適切なステージでタスクを実施すれば、実装に入ってから想定した技術が使えないことが発覚したり、プロジェクト終盤に初めて大きな結合を試みたりといった事態を防げます。

 また、要件定義・基本設計・詳細設計・実装・テストという、ウォーターフォール型を前提とした工程は小さなタスクとして見えてくるはずです。

 三つめのポイントは「開発チームが自律的に策定する」です。

 開発チーム以外の部門が標準化を推進すると、機能しない標準化が生み出されがちです。標準化を推進するなら、開発チームのリーダーに集合してもらって「一緒にやろう」というスタンスで進めてください。丸投げでもない、上から決めるわけでもない、ちょうどいい進め方が求められます。技術も運営手法も移り変わりの速い業界なので、継続的に改善されるガイドブックのような存在にできるとベストです。

 注意すべきは、やりすぎないことです。私もそうなのですが、エンジニアは何事もやりすぎの傾向があります。「組織の価値観を共有する」ことを目的に標準化を進めれば、自ずと生産性や品質の向上、ガバナンスの確立、そして「エンジニアにとって魅力的な組織」が実現できるはずです。