「方式設計の時点でセキュリティに関する開発ガイドラインを整備する現場は増えているが、十分に機能しているケースは少ない」とHASHコンサルティングの徳丸浩氏（代表取締役）はいう。SQLインジェクションなどの脆弱性を防ぐコーディングルールをまとめた開発ガイドラインは、脆弱性を作り込まないためにぜひ整備したいものだ。
付きっきりで教える
しかし、せっかく用意したガイドラインも「開発メンバーに渡しただけでは決して浸透しない」（野村総合研究所 基盤ソリューション事業本部 DIソリューション事業部 主任システムアナリスト 関倫賢氏）。ガイドラインがあるからと、メンバーにセキュリティ対策を任せてしまうのは間違いだ。
この間違いを防ぐ方法は、大きく分けて二つある。一つは、メンバーへの教育を徹底すること。もう一つは、開発ガイドラインに頼らなくても、脆弱性を作り込まない仕組み作りである。
メンバーのコードを毎日レビュー
経験の浅い開発者にとって、自分が記述しているコードとガイドラインに書いてある対策が、簡単には頭の中で結び付かない。開発者に対策を徹底するには、何らかの工夫が必要になる。
新人エンジニアが相手なら、まずは付きっきりで教育するしかないだろう。インテックの木村慎吾氏（ネットワーク&アウトソーシング事業本部 N&Oプロダクト部 システム第一課）は、メンバーとペアプログラミングを行ったり、レビューを徹底したりすることで知識を身に付けさせた。
木村氏がメンバーへの教育で苦労したのは、あるパッケージソフトを開発するプロジェクトだった（図6）。木村氏は当初、「新人メンバーであってもSQL インジェクションくらいは常識の範囲だろう」と考えていた。試しに、DBへアクセスするコードなどを4人の新人に書かせてみた。すると脆弱性があるコードばかりが上がってきた。
木村氏は当面、教育に徹するしかないと腹をくくった。まずは、SQLインジェクションなどの脆弱性があると何が起こるのか、テストサイトを使って実践してみせた。脆弱性が引き起こす被害を体感させる狙いである。次に各メンバーと交代でペアプログラミングを実施し、木村氏が脆弱性のないサンプルコードを書いて、それを改造させるようにした。メンバーが書いたコードは木村氏が毎日レビューした。
4人の新人が必要な知識を身に付けるまでに3カ月掛かったが、その効果は大きかった。その後新たにプロジェクトに参加したメンバー6人には、この4人がペアプログラミングをするなどして、知識を全員に浸透させた。
