開発ツールの本来の目的を考える

開発ツールの分類学（2）

共有知を生かして個人作業の質を高める

開発ツールと呼ばれるものが提供されるようになって以来、開発者一人ひとりの作業効率は一貫して追求されてきたテーマでした。

それに加えて、ここ数年台頭してきているのが、この「共有知を生かして個人作業の質を高める」というアプローチです。

一人のスーパープログラマによるものづくりならいざ知らず、開発者の多くはチームを組んで開発しているのが現実ですが、その場合、次のような課題を抱えてしまいがちです。

言語や、使用するツールに対する知識、習熟度のばらつきが大きいアプリケーションはその文脈によって求められる要件が異なる（Webアプリケーションと組み込みでは性能要求やメモリ制約等が異なる等々）。文脈に対する経験値が異なるメンバーへの教育やレビューを通して、経験の未熟さを補うわけですが、見方を変えれば、教育する側やレビュアーが持っている知識以上のことは反映させることができない、ということを意味します。近年この障害が顕著に表れているのが、Webセキュリティの分野です。

例えば、SQLインジェクションに代表されるハッキング対策が要件のひとつとして求められるようになってきましたが、開発チームをリードする年代のエンジニアが現役のころには、この種の要件は（おそらく）ありませんでした。

さらに新しいハッキングテクニックの（悪い意味での）発展により、セキュリティリスクは日々増大しています。この状況に、教育やレビューで対応するのは大変厳しい時代になったといわざるを得ません。

このような“経験値の差を埋める手段”として、注目を集めるのが、いわゆるホワイトボックステストです。多くは、ソースコードを解析して以下のことを指摘してくれます。

• プログラミングのワーストプラクティス（Worst　Practice：“悪いお作法”ですね）
• （セキュリティホールでは）典型的なコーディング対処法

ソースコードを対象とすることにより、コーディングの早い段階から問題コードをつぶすことができ、結果として短期間に質の高いコードを仕上げることが可能になります。中間まとめとして、ここまでの話を図にしてみました。

チームから組織の視点へ

「他者と共同で作業する」という意味では、規模の大小によって程度の差こそあれ、共通の課題が存在します。それは情報共有の問題です。

私の所属するIBMをはじめとして、有償ツールを提供するベンダーの多くがここ数年注力しているのが、開発の過程で作成される各種の情報や成果物を有機的に関連付け、管理するソリューションで、いわゆるALM（アプリケーションライフサイクル管理）と呼ばれる分野です。今回はほかにALMの連載があるので、ALM自体の詳細はそちらに譲りましょう。

ALMはいろんなメリットが語られますが、特に日本版SOX法が語られたあたりから、「コンプライアンス」や「ガバナンス」という切り口での紹介がとても多くなったように思います。いち開発者の立場で見ると「必要なのはわかるけど、めんどくさい！」と感じるのではないでしょうか？

では、開発者にとっては、ALMはあまり意味がないのでしょうか？次ページではその辺りに触れていきたいと思います。