三つの基礎力に加え、開発標準やツールへの理解も深め、使いこなせるようになるとよい。開発標準とは、組織やプロジェクトで定めた仕事の進め方に関する手順、方法、あるいはルールといったものだ。ルールや手順は、過去の失敗などを基に作られており、失敗を防ぐための知恵である。チームで仕事をする場合、開発標準は作業の品質や効率を向上させる助けになる。
特に組織で持っている開発方法論や標準WBS（Work Breakdown Structure）は積極的に活用してほしい。SEにとってこれらを理解することは基本中の基本。プログラマがコーディング規則を理解するのと同じぐらい重要である。
ツールについても、設計支援ツール、テスト支援ツール、マネジメント支援ツールなどたくさんある。品質や効率を向上させるために積極的に利用するとよい。ただし、利用時には成熟度を考慮する必要がある。
開発標準が過去の経験を踏まえて作られているのは確かだが、何も考えずに従うのは考えものである。例えば筆者は、「テストの実行結果は、印刷してテスト担当者のサインを入れないといけない規則になっているから、自動テストは認められない」と言われたことがある。昔はテストを多くの人員で分担していたため、テストが行われた証跡を確保する必要があった。しかし、自動テストは再現性があるのだからテスト結果の証跡は必要なくなる。こうした勘違いは、ルールの意味や背景を理解していないことが原因で起きる。
そこで、開発標準と向き合うときに意識したいのが、日本古来より伝わる「守破離」の精神だ。「守破離」とは、剣道・茶道など、あらゆる道の修行の段階を示す言葉で、個人のスキルの成長段階を以下の3段階で表現している。これを開発プロセスに当てはめると、次のように表現できる（図9）。
守：既存のプロセスを守り、やり方を身に付ける段階
破：既存のプロセスを分析して、問題を解決し改善する段階
離：既存のプロセスにとらわれず、最適なプロセスを適用できる段階
このように、まずは型通りに実行することでプロセスの意味や意義を理解し、そこから改善を加えていくことで最適なプロセスが使いこなせるようになる。
プロジェクトを評価し制御する
SEは、自身の取り組みを客観的に評価する姿勢も大切だ。だが、ソフトウエアは、形がなく目に見えないロジックの集合である。このため、ソフトウエアそのものやソフトウエア開発チームを評価することは難しい。
トム・デマルコ氏は、著書「Controlling software projects」の冒頭で「計測できないものは制御できない（You can't control what you can't measure）」という有名な言葉を述べている。計測されないものの評価は難しいが、数値として可視化することで、その数値を改善するための議論が可能になる。これは工学の基本的な考え方だ。
もちろん測れなくても制御できることもあるし、何でも測ればよいものでもない。だがIT系のプロジェクトは、現場で数値化して評価や改善につなげる取り組みが他業界に比べて弱いと感じる。ひとたびプロジェクトが混乱すれば当初の計画がすべて吹っ飛ぶなど、ITプロジェクトはリスク幅があまりにも大きいため、計測へのモチベーションが高まらないのが理由だろう。
そうであっても、定量的な基準やモノサシを持ち、技術の改善へつなげる活動は必要だ。効果を「かなり」「非常に」「やや」「おおむね」といった形容詞や副詞で表すのではなく、数値や図で表すことにより曖昧さがなくなり、正確な判断が下せるようになる。
最近は、生産性に関する統計データがいくつか公開されている。例えば、経済調査会の「ソフトウェア開発データリポジトリの分析」や情報処理推進機構/ソフトウェア高信頼化センターの「ソフトウェア開発データ白書」、日本情報システムユーザー協会の「ユーザー企業 ソフトウェアメトリックス調査」などが有名だ。条件が合致するデータを選んで比較することで、自身の位置付けやレベルが分かる。こうした活動を通じて、より技術を深め、自身の成長につなげてほしい（図10）。
