Hatena::ブログ(Diary)

達人プログラマーを目指して このページをアンテナに追加 RSSフィード Twitter

2011-09-08

SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい

ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。

SIerは自動化する対象が違っているのでは? - Togetterまとめ

これは、私が

を読み始めて、ふとつぶやいた

をきっかけに始まった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 Stacks

Pivotal Cloud Foundry | Pivotal

OpenShift: PaaS by Red Hat, Built on Docker and Kubernetes

CloudBees

さらに、開発環境はLinuxの方が自動化しやすいと思いますが、会社のWindows PCでも、以下のようなツールを使えばある程度開発環境の構築を自動化することができると思います。

Ninite - Install or Update Multiple Apps at Once

Google Code Archive - Long-term storage for Google Code Project Hosting.

Secure Delivery Center | Eclipse Team Distribution

とにかく、伝統的な慣習にしたがってプログラミングを下流や製造の工程ととらえ、コスト削減の対象としか考えないのは、今では完全に時代遅れになっています。むしろ、(マスターメンテナンス用のCRUD処理などの例外を除いて)、ソースコードはそこから新たな価値を創造する資産なのであり、そういうところこそ、職人プログラマーによってきちんと作成されるべき対象と考えるべきではないのでしょうか。逆に、本来高給取りのSEがやるべきでないビルドデリバリ、テスト実行などの単純作業は、なるべく自動化されることでコストを下げることができます。

もちろん、こういうアジャイル的な発想はSIerの側からは、ビジネスの収益構造上からも、なかなか出てきにくいかもしれませんが、ユーザー企業、ユーザー系SIerからシステムが業務にもたらす価値という点を意識をするようになれば、日本のSI業界でも少しずつ取り入れていくことができるのではないかと思います。

*1Excel駆動型開発

*2:DeveloperとOperationをくっつけてDevOpsと言うそうです。

tolkine9999htolkine9999h 2011/09/13 01:59 べき論で理想を語っているだけで、現実に即していない。ただたんに、ソッチの方がカッコイイでしょ?と言ってるだけでリアリティがない空論。

ryoasairyoasai 2011/09/13 22:09 Continuous Deliveryについては、既に様々なシステムで導入されて実績のある技法として紹介されていますし、現実味があるというか、かなり実践的な手法だと思うのですよね。特に、最近はPaaSなどを使えば、環境構築なども自動的にできるようなツールが一般にも利用できるようになっていますし。
空論とおっしゃるのは、最後のSIに導入しよう書いている部分についてでしょうかね。確かに、大きな組織に対して導入することは簡単ではないですが、まったくの夢物語というわけではないですし、他社が導入すれば自然と広まっていくのではないかという期待もありますがいかがでしょうかね。

splendorsplendor 2011/09/23 13:24 システムテストの自動化ツールなら既にあると思います。価値の低い作業はオフショアすれば良いですし、プログラマーには、そこまで求められないです。ちゃんとSEが設計するので。コーディング自体は特にクリエイティブな作業ではないので、優秀であれば企画・要件定義に当てるべきですね。またH/W、ネットワーク、セキュリティまで含めたアーキテクト的な役割なら話は別ですが、職人プログラマーは何が求められているコアなのかを理解しないと駄目だと思いますよ。画期的なアルゴリズムを書きたいとかなら、ベンチャーか研究機関の方が向いているのでは?と思います。

ryoasairyoasai 2011/09/24 00:14 >コーディング自体は特にクリエイティブな作業ではないので、優秀であれば企画・要件定義に当てるべきですね。
このように考えられるのは何を根拠にしているのでしょうか。言語環境や対象によりますが、コーディングはそれ自体非常にクリエイティブな作業であると思いますよ。仮に画期的なアルゴリズム等なくても、
-分かりやすいクラス名や変数名を考える
-保守しやすいようにメソッドやクラスの分割を考える
-単体試験しやすいコードにする
-リファクタリングにより似たようなコードを一か所にまとめる
-ドメインモデルを表現する設計にリファクタリングする
など、きりがありません。ここで重要なことは、一般的に業務システムのコードは一回書いたら終わりということではなく、長期間保守されるということですね。

k.hasunumak.hasunuma 2011/09/24 04:29 思うところがあって、ちょっと噛みつきます。
SIerに勤める「SE」と呼ばれる人達の約80%は、まともなシステム設計ができません。特に新卒で入社して、2〜3年目から設計専従になっている人達の設計スキルは惨憺たるものです。能力のないSEの尻ぬぐいをしているのは、いつも下請けの「PG」と呼ばれる、高いスキルと強い忍耐力を持った人達なんです。
プログラミングは、とてもクリエイティブな作業だと私は考えています。それ故、単純作業はできるだけ自動化すべきというのは私も同意見です。その一方で、プログラムの自動生成は、自動化してはいけないものの1つだと考えます。最もクリエイティブな部分を自動化してしまったら、元も子もないからです。
いつも思うに、プログラミングという作業を貶めているのは「SE」と呼ばれてふんぞり返っている人達であり、はっきり言ってそんな人達はこの業界には不要です。何しろ、まともにプログラムを組めず、理論的根拠もなしに自分たちの想像だけで作ったExcelのシステム設計書を「PG」に押しつけているだけですから。
参考まで、日本以外の国には、日本で言う「SE」に該当する職種はありません。例えば米国では日本のSEとPGを足した「ソフトウェアエンジニア」という職種があります。彼らは優秀なシステム設計者であり、現役のプログラマでもあるです。また米国で「システムエンジニア」と言えば、稼働後のシステムの運用・保守を専門に行うスペシャリスト集団のことを指します。

masa711115masa711115 2011/09/24 08:07 結局、自分たちで殆どコードを書かず外部に書かせるから判らないんでしょうね。コードを書くのは障害などでメンテしなければならない場合のみ。だからこそ内容ではなく個々の質の違い / 書き方の違いだけを気にするし、プログラミング出来ない(本人たちは出来ると思っているフシがありますが)設計者が書いた設計書だけでプログラムのすべての記述内容が網羅できていると思っている。
あまり言うと"仕事がなくなる"可能性はありますが…

大手SIer大手SIer 2011/11/14 21:36 筆者の言う自動すべき部分は、自動化すべき部分というより、高速化すべき部分ではないでしょうか?
自動コード生成を批判するため、良い自動化を対比したかったんでしょうが、少々無理がある。