最近、日経コンピュータとか読んでも、時々「アジャイル」という言葉を目にする。数年前に流行ったと思っていたが、着実に現場にアジャイルは浸透されたりしてるんだろうか。システム運用なんかにも適用できないかと思い、興味本位で読んでみた。いろいろ考えたことを書く。
俊敏と規律のバランスを考える
本書の中では、システム開発の進め方を、アジャイルと計画駆動という大きく２つに分類し比較することで、アジャイルの特徴を述べている。この本を読んで思ったのは、どこまで規律を求めるか、ということ。何でもかんでも文書化して指標とって、コントロールすれば良いという訳ではない。チームの規模やシステムの複雑性、メンバの能力などに応じて、必要な規律の度合いは異なるでしょう、ということ。フットワークを重視すると、変化に柔軟に対応できるが、その分コントロールが行き届かず、責任も不明確になり易い。
どこまで文書化したり指標をとったりするかは、それぞれの状況によって適切な度合いがあるはず。それを常に考えることが必要。余りに規律を厳しくすると、作業が非効率になったり、無駄な作業を生んだりする。基本的には、手戻りや無駄な作業が多く発生しているポイントは、規律を強化した方が良い。
顧客をどのように巻き込むか
アジャイルでは、顧客の知識度合いや距離感を非常に重要視しているが、これはどの手法であってもどのシステムであっても重要であることには変りない。本書の中では、「CRACK」と表現していたが、その通り、
協力的（Collaborative）で、顧客の意思をきちんと代表しており（Representative）、権限を持ち（Authoraized）、献身的で（Committed）、知識のある（Knowledgeable）人
であることが重要なのだ。システム開発や運用の円滑な進捗は、カウンターパート（ユーザ側の窓口）がいかにCRACKであるかが、大きな割合を占めると思っている。ユーザ側の窓口を選ぶことはなかなか難しいけど、顧客の要求仕様のブレが手戻りを招いたり、ちゃんとテストして品質を上げてリリースすることが、リリース後のシステム運用の効率化に寄与することを教えないといけないと思う。
例えば窓口担当者が、現場からうまく要求を吸い上げられないときは、一緒にヒアリングについていったり、情報を整理してあげたり、漠然としたヒアリングではなく選択肢を作ってあげたり、できることはいろいろある。
顧客には顧客の論理がある。ベンダにはベンダの論理がある。これをお互いが理解して、協力的になることが必要なのだ。改めて思った。
システム運用にアジャイルってどうなの
結論からすると、余り向かないと思われる。アジャイルの特徴は、小規模で変化を重視するタイプであり、メンバの暗黙知を活用することを前提としている。しかし、システム運用では、既に稼働しているシステムに対して大きく変更が加わることは稀であり、システムの安定稼働が最優先とされる。つまり、品質と速さをバーターの関係で考えた場合に、品質が重要視される。
ただ、全く活かされない訳でもないと思う。システム運用でも、短いタームでクイックに結果を出して、システムが改善され業務が改善される実感を作ることは望ましい。だから、極力小さめで、業務にインパクトが大きいものを優先してリリースしていく運用スキームを顧客と作り上げるのが良いんじゃないだろうか。
あと、アジャイルで特徴的なペアプログラミングなども、ナレッジの継承としては有効かも、と思う。システム運用は数年単位で行われるし、その間に人は入れ替わる。いつでも知識の継承は課題になるから。特に、ソースに関する知識は、直接目に見えない部分も多いため、属人的な知識になりやすい。
