お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

プログラマの救世主・・ だったはずのXP

2008/09/22 07:09
  • このエントリーをはてなブックマークに追加

プロフィール

山田ひさのり

私がプロジェクトマネジメントを実践したり学習したりしていく中で、ためになった考え方やノウハウを紹介していこうと始めましたが、その後ケータイ/ソーシャルビジネスを中心の情報発信に変化しました。暫くの間更新が滞っていましたが、私の転職をきっかけにグロースハック/ハッカーの情報を発信するグログとして投稿を再開しました。
ブログ管理

最近のエントリー

XPの導入をしようとした私はすぐに大きな壁に突き当たりました。それは「全員同席」と「ペアプログラミング」でした。全員同席とはユーザ、マネージャ、開発者が一箇所で開発を行うという考え方で、システム開発のスピードを加速させ、利害関係の不和を解消するために考え出された手法です。特筆すべきは顧客と開発者を同席させると言うもので、開発過程で明らかになる不明瞭な要求や仕様を、同席している顧客に即決させるという画期的な提案でした。これは一見するとドラスティックで素晴らしい考え方に聞こえますが、日本の請負型のソフトウェア開発契約においては大いなる矛盾をはらんでいます。そもそもにおいて顧客と開発者(チーム)が一箇所に継続して同席するということ自体が難しく、特に開発物の要求や仕様を即断できる権限を持った人間を継続的に同席させることは極めて困難です。私のプロジェクトでもお客様に「開発が完了するまで弊社に出向して下さい」とお願いしたり、嫌がる自社の開発者に「開発が終了するまで客先に出向してくれ」と指示することができるはずもなく、このプラクティスは実現以前の問題でした。ブリッジ役となるSEを客先に出向させる方法も考えましたが、"地理的な同席" を前提として様々なプラクティスが絡み合っているXPではそのような中途半端な導入では十分にメリットを発揮できないと判断しました。
またもう一つの壁である「ペアプログラミング」も私の前に大きく立ちはだかりました。そもそもプログラミングとは基本的には個人の作業であり、プログラマにとっては自分の書いたコードが自分の期待通どおりに動作することが開発の大きな醍醐味の一つです。ペアプログラミングは2人で1つの実装を(ある意味)共同で作成することで生産性を向上させるるプラクティスであり、個人での開発に慣れた開発者にとっては非常に受け入れ難く感じられました。当時開発者であった私も「こんなコーディングスタイルでは開発の楽しみを感じられることはできない」と強く感じたことを覚えています。「全員同席」と同じく開発者の抵抗が容易に想像できるこのプラクティスも効果を試すことなく終わりました。(しかし私はペアプログラミングに関しては基本的に賛成です。ペアプログラミングを行うことで享受できるメリットはかなりあると考えています。こちらについては何時か記事にする予定です。)

結局XPについては「短期リリース」や「継続ビルド」など開発者にとって比較的受け入れやすいプラクティスを部分的に導入するに留まりました。それぞれのプラクティスで部分的な効果はあったものの全体として個々のプラクティスの補完関係で成り立っているXPにおいて部分的にプラクティスを導入しただけでは効果を発揮するはずもなく、相変わらず締め切り前の過酷な労働環境が収束することはありませんでした。結果としてXPは(少なくとも弊社では)「使えない開発方法論」の烙印を押されることなりました。


今になって考えると部分的な導入しか達成できなかったXPですがそれでも十分な成果はあったと思います。数値化したわけではありませんがいくつか導入したプラクティスでは以下のような成果が見られました。(ただしこれは私の率いたプロジェクトにおいて観察された成果であり、全てのプロジェクトにおいて同一の成果があるとは限りません)

短期リリース

リリースサイクルを短くし、常に稼動するものを顧客に提供し続けながら開発するこのスタイルは、Try&Errorを繰り返し、発注側と開発側にとってお互いに良いものを追求し続けるこのスタイルは、発注側からすればいつでも動作するものを確認でき、成果物に不満があればすぐに指摘できるというメリットがあり、開発側からすれば進捗報告を実際に作成したモノで行うことができ、進捗報告のための稼動量が下がる上、動作するものが存在するため開発メンバーをモチベートできるというメリットがありました。

一見すると良いこと尽くめの短期リリースですが、このプラクティスに慣れてしまうと「顧客が仕様を決めない」という泥沼に陥ることがあります。このプラクティスは(恐らくケント・ベック氏の予想に反して)「実装物を見てから仕様を決定すればいい」という捻じ曲がった解釈をされることが多く、このスタイルに慣れてしまった顧客の多くは、「仕様は後から決めればいい」、「追加要求はいつでも、いつまでも受けてもらえる」という錯覚に陥ります。プロジェクトにおいて仕様の未決はプロジェクト失敗の最大の原因の一つですが、ともすればそれを誘発する恐れがあります(ケント・ベック氏はその点を計画ゲームとシンプル設計、継続ビルドとのプラクティス間の補完で補うことを提唱しています)。やはり単一のプラクティスの導入のみではXPは成り立ち難いことを実感しました。

継続ビルド、テスト駆動型開発

ビルド用のマシンを別途用意し、少なくとも1日1回は自動(もしくは手動)にてビルドを行った上で、用意されている全てのテストが通過する状態に保つプラクティスです。私のプロジェクトは全てのコードに対してテストを用意することはできませんでしたが、DBとの永続化部分については全てのテストコードを書くことを義務付けました。当時テストコード作成を自動化するツールはあまりメジャーでは無かったため、テストコードについてはプログラマが自分で記述する必要がありかえって開発効率が低下するという副作用もありましたが、テストが完備されているコードは人員の追加投入時の引継ぎをスムーズに行うことができるというメリットも生み出しました。おかげで人員の流動性が高まり総合的に開発の効率UPにつながる効果をもたらしました。
継続ビルドについては別途別のビルドマシンを用意し、自動でビルドするというところまでは辿り着けませんでしたが、「1日1回はstaging環境にデプロイし、実機で(定められた)動作確認を行った上で帰宅する」というルールを設けることで、「いきなりビルドが通らなくなった」、「昨日は動いていたプログラムが動かない」といったありがちな問題を回避することに成功しました。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー