私がスクラムマスターを目指すわけ

2010/1/14(木)に、「Agile2.0 ~ アジャイルなチームで何を提供する?」という勉強会に参加してきました。

実はこの日は、純粋な飲み会としての新年会を開催予定でした。
が、その会をほぼ無理やり「勉強会に参加する新年会」と内容を変更して、参加してしまいました。
参加予定だった方には、少々、申し訳ないことしてしまったと思います。

しかし、この会に参加して、わたしが、なぜスクラムマスターになりたい、と考えていたのかがはっきりしました。
それは、スクラムなどアジャイルという開発手法が、

開発者と顧客をつなげることで楽しく良いシステムがつくれる

と感じたからだったのです。

<顧客不在の開発現場>
私の周囲には、コーディングが好きな方とても多いです。
それは老いも若きも関係ありません。
なかには、60代になってもコーディングが好きで、現役でコードを書く方々がいます。

そうしたコードを書くのが好きな人から頻繁に聞く言葉が、「ものづくりが好きだ」という言葉です。
この言葉の背後には、「良いものをつくることは正しい」というすばらしい信念があります。
が、はっきり行ってしまいますが、私は、この言葉が嫌いです。
というのは、この言葉には、「技術的に卓越してさえいれば良いものをつくれる」という信念も含まれているように思えるからです。

そもそも、良いもの、とはいったいなんでしょうか。
それは、人の役に立つものであり、人に喜びを与えるものであり、金銭的な意味をふくめて人に利益を与えるものだと思います。
もっと簡単にいえば、その人、組織にとってプラスの利益を与えるものです。

良いものをつくるには、「どのような人たちに、どのような価値を提供するか」というコンセプトが先に必要です。
それは、ソフトウェアにしろ、サービスにしろ、例外ではありません。
このコンセプトを欠いてしまうと、ターゲットのいないアプリケーション、サービスを作り出してしまいます。
そして、存在しないターゲットを無理やり後付けでつくり、そのターゲットに無理やり売りつけなければならくなってしまいます。
こうした事態を避けるためには、そのソフトウェア、サービスをつくる人たちは、それを誰に届けるのか、どのようなものとして届けるのか、ということを知らなければいけません。
簡単にいえば、顧客を知らなければいけません。

私が「ものづくりが好きだ」という言葉の背後に、「技術的に卓越してさえいれば良いものをつくれる」という信念も含まれていると感じるのは、「顧客を知ろうとしない人たちが頻繁にこの言葉を使う」という印象を持ってしまったためなのです。
というのは、「ものづくりが好き」「コーディングが好き」という人は、概して顧客と会うのを嫌がります。

コーディングが好きか否かにかかわらず開発者が、顧客に会うのを嫌がる、という心理は理解できます。
開発者と顧客との関係の現実は、バグなどのトラブルに際してのみ顧客から連絡があり、問題のあったプログラムの開発に携わった開発者が技術的な説明をするために対応する、というものです。
普段から接することなく、顧客も開発者も、問題が起きたときにだけ、お互いを意識する関係なのです。
こうした関係である以上、たしかに顧客に会いたい、という考えも思いも浮かんでこないことは、むしろ自然なことです。

問題はこうした関係によって嫌な思いをした開発者たちが、顧客に会うことを嫌がり、自分の考える良いものとしてのソフトウェアを作り上げようとしてる、ということです。
つまり、顧客不在のシステム開発をしようとしていることが問題なのです。

顧客不在の開発を生み出す、顧客と開発者の関係は、ソフトウェア開発の構造的な問題です。
ソフトウェア開発の規模が巨大化することによって、処理するべき作業が多くなりました。
その打開策として、作業をフェーズに分けたり、フェーズごとに作業を担当する人間を分けたりしてきました。
その結果、大きなソフトウェア開発に携わる人々は、自分の作業を明確にでき、その作業を効率化し、作業の質を向上させることできました。

しかし、それは局所的な最適化にとどまることもあり、フェーズごとの作業自体や、異なるフェーズに携わる人たちの間に溝を生みました。
また、開発側だけでなく顧客側も大きな情報システムを管理するために、システムを管理するためのシステム部門を立ち上げるようになりました。
利用者、その間のシステム部門、そのシステム部門と話すプロジェクト管理者、そしてプロジェクト管理者と話す開発者、という関係が出来上がってしまったのです。
そうして、開発から忘れ去られてしまったものの1つが顧客です。

このような顧客不在の開発に携わりながら、「ものづくりが好きだ」といい自らの技術を高めようという人たちは、もしかしたら陶器や刃物などの工芸品をつくる職人のような匠と自分の姿を重ねているのかもしれません。
ひたすら自分の技術を磨き上げ、わが道を行く。
もっというと、人里を離れた山の中で、自分が良いと信じるものをつくり続ける、孤高の姿を思い浮かべているかも知れません。
ですが、この昔ながらの職人、匠の姿は完全に間違っています。

工芸品とは、そもそもが日常生活に使用される生活用品として先にあり、その後、芸術として再発見されたものだからです。
日常生活に使われるものでしたから、そのものに求められる機能も、非常にシンプルです。
包丁は肉や野菜を切るものであり、皿は料理を盛り付けるものです。
そして、こうしたシンプルな機能を満たす良いものをつくることすら、それを利用する人たちを離れてつくられてきていません。

日々の生活を送る人たちを、間近で見ていた腕の良い職人たちが、

・こんなものを切るには、刃を長さをもっと長くしたほうが良いな
・ああした料理を盛り付けるには、もっと底を深くしたほうが良いな

と、役に立つ、より良いものを目指してつくり続けてきたのです。
ようするに優れた職人は、顧客の近くにいることで、顧客が求める機能、ときには顧客自身が認識していない要望すら実現し、それを洗練させつづけてきたのです。
そして、ついには機能と美を備えた工芸品といわれるまでの「良いもの」を作り上げたのだと思います。

一方、顧客不在のソフトウェア開発は、顧客からの要求を満たすことはありません。
そうした環境下で開発者求めるの良いものとは、コードの美しさ、構造の美しさ、というものです。
しかし、それは、教科書的、利己的な開発者の美学によって定められてものに過ぎません。
システムを利用する顧客からしてみればむしろ表面的な美のみを追求しているかのようです。
もちろん、優れた機能、サービスは、美しいソフトウェアの構造美しいとコードから生まれる、ということは否定しません。
しかしながら、顧客を知らずして美しい構造と美しいコードは実現できません。
なぜなら、ソフトウェアの構造やプログラムのコードの元になる仕様は、顧客の要望をいかにみたすか、によって変化するからです。

顧客の要望をいかにみたすか、という問いは、まずは顧客が何を望んでいるのかに答えることであり、次にはどのように解決するのかに答えることです。
これらの答えは、単に技術に卓越し、知識にとんだ開発者によってのみ生み出されることはありません。
というのは、たとえ同じ問題を抱えている顧客がいても、解決する際に異なる制約があり、すべての顧客に、一様な解決方法が提示できないからです。
一方の顧客は時間はあるけれどお金はない、もう一方のお客は時間はないけどお金はある、というときに、はたして同じ答えがでてくるのでしょうか。
きっと、ソフトウェアの構造もプログラムの仕様も異なってくるに違いないのです。
ですから、美しい構造のソフトウェアを、美しいコードでつくりたいのであれば、顧客を知る必要があるのです。
そして「ものづくりが好き」「良いものを作りたい」「コーディングが好き」という開発者ほど、顧客から離れてはいけないのです。

ソフトウェア開発においても、顧客を無視して今まで開発が行われてきたわけではありません。
開発側、顧客側の双方で取り入れられた分業制という構造によって、少しずつ開発というフェーズから顧客が離れていってしまったのです。
そして、顧客が離れていった結果、開発に携わる人から顧客、という存在が忘れ去られてしまったのです。
また、顧客の役に立ちたい、と思う人は、開発現場にとどまることを許されず、顧客が近くにいるフェーズのプロジェクト管理や仕様書の作成にしか携われなくなってしまったです。
結果、いまソフトウェア開発に携わる人々も顧客も苦しんでいます。

<アジャイルで顧客と優秀な開発者を開発現場に呼び戻す>
顧客不在の開発による不幸な状況を打開するためには、開発現場に顧客を呼び戻す必要があります。
そして、それを可能にするのがスクラムなどのアジャイルという開発手法だと私は感じているのです。
というのは、アジャイルでは、「真の顧客の参加」として、顧客が開発現場にいることが推奨されているからです。

そして、開発現場に顧客が参加していることで、優秀な開発者が現場にとどまり続けることができる、とも感じています。
なぜなら、顧客が開発現場にいるのですから、顧客を知るために開発現場を離れ、プロジェクト管理だけ、仕様書の作成だけをやる必要はありません。
分業制では、優秀な開発者が顧客を知ろうとしたとたん、作業フェーズを飛び越えるため開発現場を離れて、管理フェーズにまで行かなければ行けませんでした。
その状況を変え、優秀な開発者が開発現場にとどまり、顧客の要望を掘り下げ、価値のあるシステムをつくることができれば、開発者にとっても顧客にとっても有益です。
開発側は、早く、品質の高い高付加価値のシステムを開発でき、顧客側は自らの要望をかなえるシステム、サービスを享受することができるからです。

もちろん、アジャイルという手法が、ソフトウェア開発や私自身が抱えている問題をすべて解決するものにはなりえません。
しかしながら、顧客の不在による問題を改善し、優秀な開発者を開発現場に残すことができる、という点で、私はアジャイルという開発手法にとてもおおきな期待と魅力を感じています。
そして、その開発現場において優れた良いシステムがつくれる、顧客と開発者が満足できる楽しい開発現場がつくれる、と感じているのです。

アジャイルによって開発に顧客を呼び戻し、楽しく、真に良いものづくりをする、このために私はスクラムマスターを目指すのです。

長々と書きました。
今回はこのあたりで。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。