はじめに API経由でクラウドのリソースを操作すると、コントロールパネルで行う煩雑な操作を自動化できます。たとえば、サーバーの起動・停止や設定変更をスクリプトに組み込むことで、再現性の向上、ヒューマンエラーの削減、大規模 […]

リクルートのデータ推進室にて、データエンジニアリンググループのマネジャーを務める山本 哲生。ゲーム業界で10年以上にわたり

こんにちは、QAコンサルタントのヤマダです。 ソフトウェア開発の現場では、日々、品質の確保、生産性の向上、そして技術の継承といった課題に直面します。経験豊富なエースエンジニアの活躍で一時的に問題が解決されても、そのノウハウがチームに共有されなければ、同じ問題が繰り返し発生してしまいます。 こうした「属人化」という名の落とし穴を避け、チームとして継続的に成長していくために不可欠なのが 「標準」 という考え方です。 「標準」と聞くと「形式的で堅苦しい」「創造性を縛るもの」といったネガティブなイメージを持つ方がいるかもしれません。しかし、標準は開発現場を混乱から救い、より高品質なソフトウェアを、より効率的に生み出すための強力な「羅針盤」となり得ます。 この記事では、まず「標準」そのものについて深く掘り下げ、具体的な事例を交えながら、標準を形骸化させずに「生きた資産」として育て続けるためのアプローチについて解説していきます。 そもそも「標準」とは何か？ 「標準」には、その成り立ちや適用範囲によっていくつかの種類があります。大きくは、公的な機関が定めたものと、市場で事実上標準と見なされるようになったものに分けられます。 デジュールスタンダード (de jure standard) 国際標準化機構（ISO）や日本産業規格（JIS）といった公的な標準化団体によって策定・発行された、公式な規格です。「法律上の」といった意味を持ちます。 デファクトスタンダード (de facto standard) 公的な機関が定めたものではなくても、市場での競争や業界の支持によって広く普及し、事実上の標準として機能しているものです。「事実上の」という意味を持ちます。 しかし、私たちが現場で意識すべき「標準」は、これだけではありません。チーム内で定められた コーディング規約 、プロジェクトで共通して使われる 設計書のテンプレート 、 Gitのブランチ戦略 といったものも、私たちを日々の迷いから救ってくれる重要な「現場の標準」なのです。 ソフトウェア開発に関連する「標準」のランドスケープ では、具体的にどのような標準が存在するのでしょうか。ここでは代表的なものを「デジュール」と「デファクト」に分類してご紹介します。 デジュールスタンダード (公的標準) 国際的な合意形成に基づいているため信頼性が高く、認証制度と結びついているものも多くあります。 標準/規格名 発行元 概要 ISO 9001 ISO 品質マネジメントシステム の国際規格。製品・サービスの品質保証の仕組みを構築・運用するための要求事項を定めています。 ISO 21502 ISO プロジェクトマネジメント の手引に関する国際規格。デファクトスタンダードであるPMBOK®ガイドなど世界中の知見を基に策定されました。PMBOK®が詳細なツールや技法（How）を含むのに対し、本規格は組織が従うべきハイレベルな概念やプロセス（What）を定義するガイダンスであり、相互補完的な関係にあります。 ISO/IEC 25000 (SQuaRE) ISO/IEC ソフトウェア品質 に関する国際規格群。ソフトウェアの品質モデルを定義し、その測定と評価の方法を規定しています。 ISO/IEC/IEEE 12207 ISO/IEC/IEEE ソフトウェアライフサイクルプロセス の国際規格。ソフトウェアの企画から開発、保守、廃棄までの一連のプロセスを定義しています。 ISO/IEC/IEEE 29119 ISO/IEC/IEEE ソフトウェアテスト に関する国際規格シリーズ。テストプロセス、テストドキュメント、テスト技法、キーワード駆動テストなど、テストに関する包括的な内容を扱います。 ISO/IEC 27001 ISO/IEC 情報セキュリティマネジメントシステム (ISMS) の国際規格。情報資産を保護するための管理策を体系的に示しています。 デファクトスタンダード (事実上の標準) 技術の進化に迅速に対応しやすく、特定の分野で強い影響力を持つものが多くあります。 標準/規格名 発行元/管理者 概要 PMBOK®ガイド PMI プロジェクトマネジメント の知識体系。公的規格であるISO 21502の策定にも大きな影響を与えた、業界で最も広く参照されるガイドラインの一つです。 CMMI® ISACA 組織の プロセス成熟度 を5段階で評価・改善するためのモデル。元々は米国カーネギーメロン大学（SEI）で開発され、現在はISACAが引き継いで維持・管理しています。 ITIL® AXELOS ITサービスマネジメント におけるベストプラクティス集。多くの企業のIT部門で運用管理の指針として採用されています。 OWASP Top 10 OWASP Webアプリケーションのセキュリティ に関する最も重大な10のリスクをまとめたレポート。セキュリティ対策の基準として広く参照されます。 【事例】標準を知らないと、実績のあるベテランでも大怪我をする ここで、標準の重要性を実感していただくために、ある現場で実際に起きた 「実績のあるベテランが、標準を知らなかったために大失敗してしまった」 苦い事例をご紹介します。 ある小規模な医療系システムの開発プロジェクトに、開発歴20年で数々の修羅場をくぐり抜けてきたエンジニアのAさんが助っ人として参画しました。Aさんは技術力も高く、過去の経験をもとに独自の「秘伝のタレ」のような効率的なテスト方針を組み立て、 圧倒的なスピードと手際の良さ で次々とテストを消化していきました。チーム全員が「さすがAさんだ」と安心していました。 しかし、プロジェクトの最終盤、クライアントである大手医療機器メーカーによる 品質レビュー が入ったときに事件は起きました。 先方の担当者から 「国際規格である『ISO/IEC/IEEE 29119』に準拠したテスト成果物（ドキュメント）を見せてください」 と求められたのです。 Aさんは「独自の効率的なやり方」でテストを進めていたため、国際規格が求めるプロセス（どのような根拠でそのテスト技法を選び、どう成果物を残すべきか）を満たしていませんでした。Aさんにとっては「十分にテストした」という自信がありましたが、先方からは 「国際規格（標準）を満たしていないため、品質が客観的に証明されていない」 という最悪の評価を下されてしまったのです。 結果として、膨大なテストのやり直しとドキュメントの再作成が発生し、プロジェクトのリリースは数ヶ月延期。Aさんのプライドも、チームの信頼も大きく傷つく結果となってしまいました。 Aさんの技術力や熱意は本物でした。しかし、 「世界中の知見が集まった『標準』を知ろうとしなかったこと」 が失敗の原因でした。 どれだけ実績のあるベテランであっても、自分の「経験則」だけで標準という「集合知」に勝つことは難しいのです。 なぜ私たちは「標準」を活用すべきなのか？ Aさんの事例からも分かるように、標準とは単なる堅苦しいルールではなく、先人たちが同じような失敗を重ねた末にたどり着いた「これさえ守れば絶対に大怪我をしない」という防御壁（ベストプラクティス）です。これらを適切に活用することは、開発チームに計り知れないメリットをもたらします。 品質の安定と向上: 先人たちの知見に基づき、担当者のスキルに依存しない一定の品質レベルを客観的に確保・証明します。 生産性の向上: 「車輪の再発明」や「プロセスの独りよがり」を避け、開発者がより本質的な課題解決に集中できるようにします。 コミュニケーションコストの削減: 「共通言語」を持つことで、組織内外との認識の齟齬や無駄な手戻りを減らします。 技術の伝承と人材育成: 標準化されたドキュメントは、新メンバーや次世代のエンジニアにとって最高の「教科書」となります。 「標準」を育てる：知識創造のアプローチ「SECIモデル」 標準を導入しても、それが形骸化しては意味がありません。また、先ほどのAさんのように外から与えられた標準に振り回されるだけでなく、自らの知見を標準へと昇華させ、チームの資産として育てていくことが重要です。 標準の改善というと、多くの方が品質管理の基本である 「PDCAサイクル」 を思い浮かべるかもしれません。確かに、 既存の標準をより効率的に、 より安定させる といった「改善」のフェーズにおいてPDCAは非常に有効です。 しかし、「エースエンジニアのノウハウ」のような まだ形になっていない知恵を標準化する 、つまり 「創造」 のフェーズではどうでしょうか。この「0→1」を生み出すプロセスで特に力を発揮するのが、知識創造のフレームワークである 「SECIモデル」 です。 SECIモデルは、個人の「暗黙知（経験や勘）」を、組織の「形式知（＝標準）」へと昇華させていく4つのプロセスから成ります。ここからは、別のチームの成功事例を追いながら、そのプロセスを見ていきましょう。 【事例】開発チームが「無敵のエース依存」から脱却した話 新機能の開発を進めていた開発チームには、セキュリティ実装にめっぽう強いエースエンジニアのBさんがいました。Bさんが担当する機能は常に堅牢でバグもありません。しかし、Bさんが他の重要案件で手一杯になると、チーム全体の開発スピードがガクンと落ち、他のメンバーが書いたコードにはセキュリティ上の指摘が多発するという「属人化」の課題を抱えていました。 そこでチームは、Bさんの頭の中にあるノウハウを「標準」に変えるため、SECIモデルに沿った取り組みを行いました。 共同化 (Socialization) – 暗黙知から暗黙知へ まずは若手メンバーがBさんとペアプログラミングを行い、Bさんがコードを書く際に見ているポイントや「なんとなく怪しい」と感じる勘所を対話を通じて肌で学びました。SECIモデルは、PDCAのように明確な「計画」からではなく、こうした現場での自然な知識共有から始まります。 表出化 (Externalization) – 暗黙知から形式知へ ペアプロで得た知見をもとに、Webアプリケーションで特に注意すべき脆弱性対策を誰もが理解できる形に言語化・図解化し、5項目の簡易的な「セキュリティレビュー・チェックリスト」を作成しました。ここで初めて、組織の資産としての「標準 Ver. 1.0」が誕生します。 連結化 (Combination) – 形式知から形式知へ 生まれたばかりのチェックリストを、チームが元々持っていた「Gitブランチ運用ルール」や「コードレビュー方針」のドキュメントと組み合わせ、より体系的な開発フローのガイドラインへと発展させました。 内面化 (Internalization) – 形式知から暗黙知へ 体系化された標準をメンバーが毎回のプルリクエストで実践しました。繰り返すうちに、意識せずともセキュアなコードが書けるようになり、メンバー全体の新たなスキル（暗黙知）として体得されました。 SECIモデルとPDCAサイクルの融合 この開発チームの取り組みには、さらに続きがあります。 作成したチェックリストを運用していく中で、チームは業界のデファクトスタンダードである 「OWASP Top 10」 の存在を知りました。そこで、自分たちの標準（Ver. 1.0）とOWASP Top 10を見比べ、「あ、この視点が抜けていたね」と気づき、 PDCAサイクルを回して標準をさらにアップデート（Ver. 2.0へ） していったのです。 このように、SECIモデルは特に、属人化しがちなノウハウを組織の力に変えるための新しい標準を生み出すプロセスとして非常に有効です。そして、SECIモデルによって生み出された「標準 Ver. 1.0」を、今度は日々の運用の中でPDCAサイクルを回して「Ver. 1.1、 1.2」へと磨き上げていく。 このように両者を組み合わせることで、組織は創造と改善の両輪を手に入れることができるのです。 まとめ ソフトウェア開発における「標準」は、デジュール、デファクトといった公的なものから、現場のテンプレートまで多岐にわたります。これらを単に導入するだけでなく、チームの資産として育てていくことが重要です。 個人の経験則だけで突っ走ると、世界の標準に通用せず思わぬ大怪我をすることがあります（Aさんの例）。一方で、エースの持つ優れたノウハウを SECIモデル で組織の「標準」へと昇華させ、それを PDCAサイクル で磨き上げ続ければ、チーム全体の力が底上げされます（Bさんの例）。 標準は私たちを縛るものではなく、無駄な作業や致命的な失敗から解放し、より本質的な仕事へと導いてくれる強力なパートナーです。創造と改善のサイクルを回しながら、チームの力を最大限に引き出す「生きた標準」を育てていきましょう。 The post なぜ、車輪の再発明をやめるべきなのか？ ソフトウェア開発における「標準」の本当の価値 first appeared on Sqripts .