SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。
SIerは自動化する対象が違っているのでは？ - Togetter
これは、私が
- 作者: Jez Humble,David Farley
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/07/27
- メディア: ハードカバー
- 購入: 3人 クリック: 141回
- この商品を含むブログ (23件) を見る
をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行われたアジャイルカンファレンス東京にて、マーティン・ファウラーとともに来日したジェズ・ハンブル氏によって著された本で、今年のJolt Awardにも入っており英語圏では話題となっているようです。
この1年の優れたIT系書籍はどれか？「Jolt Awards 2011」が6冊を発表。 － Publickey
以前から、Excelで記述された画面項目定義書やテーブル定義書からソースコードを自動生成するような、SIerの提供するフレームワークにありがちなツールは、個人的にあまり好きではありませんでした。（SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？ - 達人プログラマーを目指して）ただし、一方でアジャイル開発では自動化を重視するということも知っており、同じ自動化でもなんとなく嫌いな自動化と好きな自動化があるということを感じてきたのですが、今回のTwitter上での議論をきっかけに、どうして同じ自動化でも好き嫌いがあるのだろうということがなんとなくわかった気がします。
つまり、頭をあまり使わなくてもできるくり返しの単純作業は、なるべくツールを使って自動的にできるようにする一方で、複雑なドメインロジックの記述など、プログラマーの能力を発揮すべきところでは、テスト駆動でクリーンコードを保ちながら頭を使ってリファクタリングを続けるべきということですね。ジェズ・ハンブル氏も来日した際の講演の中で「アジャイルは優秀な人の能力を発揮できるようにすべき」というようなことを述べていたと記憶しています。自動化も使いどころを間違えると、善にも悪にもなり得るということですね。ソフトウェア開発では、単に特定の工程の全体を自動化すればよいというものではないということです。
もちろん、たとえば、ビジネスロジックが本当に単純な場合（データベースのCRUDと基本的な項目レベルのチェックのみ）については、EDD*1を使って、すべてのコードを自動生成するということも有効かもしれません。しかし、後から独自のロジックの記述が必要となった場合、自動生成のプロセスが入ることで以下のような点が必ず問題となります。
- 自動生成されたコードと手でメンテナンスするコードとの同期が問題となる。
- 開発者が自動生成されたコードの内容を理解していない場合、障害解析や機能拡張が困難となる。
- 通常、自動生成されたコードは冗長で、無駄な記述を含んでいることが多い。また、実質同じような内容のコピーとなる傾向が高い。
- 自動生成の都合で余分なクラス、インターフェース、設定ファイルの生成が行われる結果、侵略的なフレームワークとなる傾向がある。
- 画面項目から自動生成されたコードは基本的にモジュールやレイヤー構造を持たないSmart UIアンチパターンとなる傾向が高い。
それゆえ、ソースコードの自動生成については、採用すべき箇所や、採用の是非について十分に検討した上で、適切に使い分ける必要があります。間違っても、開発者のスキルが低いからアプリケーションの全体を自動生成させようなどと考えるべきではありません。
さらに、CRUD処理のような簡単なアプリケーションは、そもそも手動で記述しても、コードの記述自体にそれほど時間がかかるわけではなく、自動化による工数削減メリットは限定的です。そういうところが自動化されたとしても、保守の部分まで含めれば、全体のコストが大きく下がるとは思えません。費用対効果からいえば、そのような部分の自動化は、最後の仕上げでやれば十分とも考えられます。
一方で、ドメインモデリングなどのプログラマーの設計スキルが必要な領域であれば、コードをエディタを使って実際に書き下す時間などは、インターフェース設計、リファクタリングやテストの作成工数から考えれば、無視できるレベルのものなのではないでしょうか？
一方で、以下の部分は繰り返し行われるにもかかわらず、毎回手動で実行した場合は基本的に単純作業となります。
- 開発環境の準備と構築
- アプリケーションプログラムのビルド
- 静的解析の実行とチェックレポートの作成
- テストの実行とテスト結果の検証
- テスト環境、ステージング環境、本番環境へのデプロイ
システムは一回作って終わりなのではなく、段階的に機能追加したり、バグを修正するなどのメンテナンスを行うなど運用のコストもかかります。そのような場合には、以上のような単純作業を自動化してくり返し実行できるようになれば、大きなコスト削減につながるはずです。さらに、開発チームと運用チームとの間の距離を小さくすることができ、価値のあるソフトを短期にデリバリできるようになります。*2
特に、最近は開発環境一式を仮想イメージとして提供して、そのままクラウドでも実行可能にするようなツールがいろいろと利用できるようになっているみたいです。たとえば、
Bitnami Application Catalog
Cloud Foundry – Open Source Cloud Application Platform
OpenShift: Container Application Platform by Red Hat, Built on Docker and Kubernetes
http://www.cloudbees.com/
さらに、開発環境はLinuxの方が自動化しやすいと思いますが、会社のWindows PCでも、以下のようなツールを使えばある程度開発環境の構築を自動化することができると思います。
Ninite - Install or Update Multiple Apps at Once
Google Code Archive - Long-term storage for Google Code Project Hosting.
IDE Management by Secure Delivery Center - Genuitec
とにかく、伝統的な慣習にしたがってプログラミングを下流や製造の工程ととらえ、コスト削減の対象としか考えないのは、今では完全に時代遅れになっています。むしろ、（マスターメンテナンス用のCRUD処理などの例外を除いて）、ソースコードはそこから新たな価値を創造する資産なのであり、そういうところこそ、職人プログラマーによってきちんと作成されるべき対象と考えるべきではないのでしょうか。逆に、本来高給取りのSEがやるべきでないビルド、デリバリ、テスト実行などの単純作業は、なるべく自動化されることでコストを下げることができます。
もちろん、こういうアジャイル的な発想はSIerの側からは、ビジネスの収益構造上からも、なかなか出てきにくいかもしれませんが、ユーザー企業、ユーザー系SIerからシステムが業務にもたらす価値という点を意識をするようになれば、日本のSI業界でも少しずつ取り入れていくことができるのではないかと思います。
