Archive for 2010年2月

月を目指して(3)~CSM研修について結果が出た~

2月 28, 2010

今月から、

会社のお金でCSMへ参加させて

とお願いしたという話を記事に書いてきました。
ひとまずその結果でましたので、その報告記事を書きたいと思います。

結果ですが、

・会社のお金は支給できない
・正当な業務の時間として参加は認められない
・研修への参加は有給休暇を使用して参加すること
・休んだ分は土曜日、日曜日に出社すること
・今後は外部研修への参加に関する制度を確立する

というものです。
はい、大惨敗ですね。
しかし、参加自体は認められたということ、そして、研修制度の確立への流れができたこと。
これらの2点の収穫があったので、やっぱり、大幅に譲歩して「辛勝」ということにしたい、と思います。
正直に言うと、

業務時間としての参加

は可能だと思っていたのですが、最後の最後で認められず、説得し切れなかった感は否めません。
そこで、いまいち会社、上司を説得しきれず、辛勝になった原因について書いてみたいと思います。

<会社の状況が>
現在、私が勤めている会社の状況は思わしくありません。
このご時勢ですので、状況が良いといえる会社も少ないのでしょうが、私の所属する会社もご他聞にもれず、というわけです。
そのような状況では、経営者としても、部長としても、研修という「投資」という考えに目をむけられなくなるのも当然でしょう。
私としてはそのような状況にある会社が取るべき方策、コストカットではなく浮上策のひとつとして、

アジャイル開発の知識とノウハウと知識をもつこと

だと考えているわけです。
が、この点をうまく強調して伝えることできませんでした。
どうしても、会社が不調になるとコストカットに目が奪われがちになりますし、事実、まずコストカットこそが初めに打つ手なのかもしれません。
すくなからず、研修、教育という決してすぐには芽が出ない、利益が期待できない点にお金を支払うことためらう感情は理解できます。
こうしたことから、会社にたいして積極的に研修の話をすることを躊躇してしまいました。

<自分自身がアサインされた状況が>
会社の状況により、自分がアサインされるプロジェクトも変更されました。
結果、3月中に2日間、仕事をはなれるということが難しくなりました。

また、アサインされたプロジェクトでは、いままで携わったことないオープン系システムの開発に携わることになりました。
自分のスキルセットにたいする不安もあり、プロジェクト自体の状況も芳しくないことから、「有給休暇」が当然の権利とはいえ、休むことに弱気になってしまいました。

結果、業務時間での参加はおろか休むことすら心理的にも状況的にも難しくなってしまいました。
そして、なんとか休みをもらうことに腐心せざるを得なくなってしまいました。

<自分の知識と実績が>
結局、一番の問題は、

Scrumやアジャイル開発にたいする知識と経験が足りない

ことだったと思います。
今まですくすくスクラムのような勉強会に参加したり、アジャイルっぽい開発のアプリケーション開発に勉強がてらに参加したことがあります。
しかし、やはりまだ血肉になっておらず、開発プロセスとしてまた、ビジネスとして、その有用性や必要性を自信をもって周囲の人へ、伝えることができませんでした。
むしろ、今回、CSM研修に参加するのは、実践的な場を会社に作るためであり、むしろ、実践するための準備という面が強くあります。
たしかに、自分に実績がなくても、聞き集め、読み集めただけの知識だけでも、知らない人にある程度の説明や魅力を説明することはできます。
しかし、やはり話す内容に自信がもてません。そして、自信がないから話に熱がこもりません。

説明する側の私がそのような話し方しかできなかったために、上司や会社にはいまいちピンと来る話ができなかったと思います。
会社としては、

コストカットができる
新たな利益が見込める

という点がないと新しい技術やプロセスを取り入れる決心はつかないでしょう。
こうした点は、やはり実績がないと厳しい。
話そうとしても、どうしても、つり的な話をせざるを得ないのです。

自分の知識と実績のなさ、これが一番の問題となって、どうしても会社と上司にとって魅力的な話ができませんでした。
<なぜCSM研修に参加するのか>
とはいえ、CSMには参加できることになりました。
また、改めて

なぜ、CSM研修を受けるのか

ということを考える機会を得ることができました。
私がCSM研修を受けるのは、

厳しいけど楽しいチームをつくるため

です。
アジャイル開発は、チームメンバーの開発力をボトルネックにすえて、プロジェクトをコントロールします。
数多くのプロジェクトを効率よくこなして、会社としてチームとして収益を上げようとするのであれば、チームの開発力をあげることが必須になります。
チームの開発力をあげるということは、チームメンバーは自分自身を高めるために勉強会に参加するなど、自己研鑽に励む必要があります。
また、自己研鑽を行うためには、周囲と強調しながらも自分の仕事量をコントロールするなどの自律的に働く態度も求められます。

こうした状況下においても、勉強をしない、自立的に働けない、そして、勉強をしていても身にならない、というチームメンバーがいるかもしれません。
勉強をしない、また、勉強をしてもその成果が仕事に活かせない、というチームメンバーは、チームにとどまることができなくなります。

チームメンバーこうしたプレッシャーにさらされている状況はメンバー内に緊張を生み、厳しいチームを生み出すことになります。
しかし、緊張感があり厳しい雰囲気が求められるから真剣にプロジェクトに取り組める、という側面があるはずです。
そして、真剣だから仕事に限らず、物事は楽しくなるはずです。

緊張感、厳しさ、真剣さ、こうしたものはものごとを楽しくするスパイスです。
そして、スパイスは決して、後付のオマケではありません。
むしろ、他の味のバランスを考慮に入れて計算した結果、加えられる味の決め手です。

スパイスのきいたチームを作り、その一員として働くことで、私は仕事を楽しみたいのです。
そして、周囲の人たちともその楽しさを分かち合いたいと思うのです。

そのためには、まだまだやることがたくさんあります。
そのひとつとなるのが、スクラムによる実績、それも成功事例を社内に作ることだと思っています。
CSM研修を受けることは私にとって、実際に自分がお客さんを見つけ、開発手法として導入し、プロジェクトを成功させる、という実績を得るための段階のひとつです。

今回、研修費の交渉をしたことによって、20万円という高額の研修を、自費で休みをとってまで受けに行く、という実績を社内向けにつくることができました。
今後、もしもアジャイル開発やスクラムの話が社内で出れば間違いなく私の耳に、その話が入ってくるはずです。
20万円という金額はとても高額ですし、有給休暇もとらなければ、CSM研修には参加できません。
今回の交渉にだけ焦点を当てれば多くのものを得ることはできませんでした。
しかし、私がスクラムというものに真剣に取り組んでいることは会社に伝わったでしょう。
これは、社内における私の立場にとって大きな収穫だと思っています。

また、今後の研修制度の確立への流れもつくることができました。
CSM研修でなくとも外部研修を受ける人たちにとっては、少しは役に立てたのではないかと思っています。
とはいえ、今回、「業務時間で研修を受けに行く」ということができなかったことは、今後、マイナスに働くかもしれないという心配があります。
今後、状況を見守りつつも、少なくとも
申請した外部研修は、業務時間で研修を受けに行く
という制度が社内にできるように、社内へ働きかけてゆきたいと思っています。

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

広告

デブサミでクラウドのシャワーを浴びてきた

2月 21, 2010


2010/2/18(木)に「デベロッパーズ サミット 2010」に参加してきました。
本来は、19日(金)もふくめて2日間のイベントなのですが、私は1日目のみ参加してきました。

主に、クラウドの話を中心に聞き続け、

・クラウドは現代のトレンドを指し示す言葉である
・クラウドとアジャイル開発の親和性は高い

という学びを得て帰ってきました。

ちなみに、当日、コミュニティ「すくすくスクラム」さんのブースに行くと、ロゴシールをいただきました。
ありがとうござました!

◆パラソルワード「クラウド」の正体
「クラウドとは何でしょうか」このように問われて、「これです」と指し示せる人は現在はいらっしゃらないでしょう。
そのように多数と意味、使用方法があるのが「クラウド」という言葉です。
株式会社テックバイザージェイピーの栗原さんは講演のなかで、クラウドの定義について、3つのカテゴリーに分けて説明されています。

・広義のクラウド:データセンター、アウトソーシング全般
・一般的なクラウド:IaaS、PaaS、SaaS
・狭義のクラウド:大規模水平スケーリングに基づくIaaS、PaaS、SaaS

こうした説明をうけると多少おぼろげだった像の輪郭が少しははっきりします。
栗原さんもおっしゃっていましたが、クラウドというものを語るとき、「今、どのクラウドについて語ろうとしているのか」という点を明確にする必要があるのです。

栗原さんが講演のなかで、提示された「クラウド」の姿は、現在のシステム業界、IT業界全体に起こっている4つの流れの総称としてのものです。
システムの技術的な要素、そして、システムを用いて提供されるサービスやビジネス的な要素をうまく取り入れた「クラウド像」は、クラウドの勉強を始めたばかりの私にとって、とてもわかりやすく腑に落ちるものでした。
講演のなかで示された4つの流れ、すなわち、4つのメガトレンドは、

・所有から利用
・サーバー中心型コンピューティング
・データセンター集約
・選択と集中

というものです。

大規模なデータセンターを所有するのではなく、利用する。そして、利用した分だけ料金を払う。
クライアントリッチなシステムではなく、ネットワークを通じてサーバーに接続してアプリケーションやサービスを利用する。
複数の場所にデータセンターを持つのではなく、可能な限り集約した大規模データーセンターを運用し、コストダウンを図る。
多角的なサービス展開ではなく、単一のサービスや事業へ資本を集中させる。

こうした、現在のビジネスの流れとそれを実現するITの技術やサービスが「クラウド」と呼ばれるものなのです。
たしかに、経済新聞を眺めていても、Yahoo!など閲覧できるネットのニュースを見ていても、上記の4つの流れを感じることができます。
また、まぬけな表現ですが、4つの流れを俯瞰してみていると「クラウドっぽい」イメージがあります。ようするに、現実、「クラウド」というときにほとんどの人が漠然と「こんなものかな」と考えているところをうまく抑えた言葉のように思います。

さらに面白いのは、クラウドというものいったい何をもたらそうとしているのか、という点についての栗原さんの指摘です。
それは、

すでに進行中の事態を加速させる

という事態をもたらす、という指摘です。
既存に起きている事態とは、

・インフラの保守で継続的な利益を上げるビジネスモデルの崩壊
・ハードウェアを抱き合わせた箱売りビジネスの縮小
・小規模SIerや「ノマド」ワーカーの増殖
・オフショアの激化

というものです。

インフラ保守やハードウェアの抱き合わせ販売は、現在でも、顧客の経済環境が悪化しているため、顧客の中でも「すべて自社の資産として情報サービスを維持しよう」という意識は薄れつつあります。
それが、クラウドにより、Amazon、Google、Microsoft、salesforceなどの大企業によりそれらのドメインが奪われてしまえば、そのようなビジネスが早晩、厳しくなることが伺えます。

また、小規模SIerや「ノマド」ワーカーの増殖、オフショアの激化という点は、クラウドの姿のひとつ、「どこでもつながるコンピューターとサービス」により徐々に進行しつつあります。
「ノマド」ワーカーという言葉は、オフィスを持たずに仕事をする人たちを指します。
もっと具体的にいうと、無料のWeb上のサービスやネットワークインフラをうまく利用しながら仕事をしている人たちです。
会社に所属する、しないにかかわらず、定まった場所と時間で仕事をせずに、効率よく自分で時間や場所をハンドリングして成果を出そう、という働き方は、徐々に増えつつあるようです。
たとえば、下で紹介するアピリオさんがエコポイントシステムを開発した際にも、各々の開発者が自宅で開発を進めた、という話もお聞きできました。
こうした今、兆しが見えつつある新しい流れを主流にまで押し上げてくる力になるなるであろうものが、「クラウド」なのです。

栗原さんの講演は、私のようなクラウドを勉強し始めたばかりの人間にとって、とてもわかりやすく、面白いものでした。
「クラウド」の概要とビジネス的、技術的にちょっと詳細に踏み込んだ内容は、まさに私が聞きたかった点がおさえられていて、とても勉強になりました。

栗原さんが講演で使用されたスライドは下記のURLから観ることができます。
とってもわかりやすいです。
http://www.slideshare.net/kurikiyo/ss-3214105

◆アジャイル開発とクラウドの親和性を感じる
次に印象に残ったのは、株式会社アピリオの山口さんのお話です。
私は不勉強であったために存じなかったのですが、このアピリオという会社は、エコポイントのシステムを通常では考えられない短納期で作り上げサービスを提供した会社、として有名だったそうです。
そもそもアピリオという会社は、クラウドを専門としたシステム構築のプロ集団だそうです。
山口さんのお話は、このエコポイントを構築した開発の内幕でした。

エコポイントシステムは、salesforceが提供している「Force.com」というクラウド環境のシステム構築のサービスとプロセスとして「アジャイル開発」を用いて構築されたそうです。
異例の短納期でサービス提供を行ったといわれるエコポイントのシステムですが、実は、すべての機能を提供するまでには16週間、つまり4ヶ月かかっています。
これは通常のシステムとたいして変わらない速度、と考えることができます。
異例の短納期といわれるのは、ユーザーが使用するエコポイントのポイントを申請するシステムが、開発から3週間後で提供され、主要な機能が6週間後に提供されているからです。

山口さんの講演でも、別の方の講演でも「Force.com」を実際に使用した開発の流れを見ましたが、圧倒的に「速さ」を感じました。
ビジネスアプリケーションに特化したフレームワークを用い、GUIを利用してコードの書く量を減らした開発は、ビジネスアプリケーションの開発において、相当な武器になる、という可能性を感じました。
「Force.com」を使用した開発の手軽さ、いいかえれば軽量性は、個々の開発者の開発能力をかなりの部分までスケールアウトしてしまう、のではないでしょうか。
そして、この開発能力がスケールアウトでき、さらに開発自体が軽量に行えるという点は、頻繁に開発し、テストをし、失敗を発見して修正する、というアジャイル開発の思想にとって、とても親和性があるように感じました。

じつは、栗原さん講演でも「クラウド」のひとつの性質として、’Fail Often’,’Fail Quick’,’Fail Cheap’という性質を上げていました。
クラウドにおいてインフラは、「頻繁に、すばやく、安く失敗する」ものになりえます。
アジャイル開発の思想がプロセスレベルにおけるものであるならば、クラウドはハードウェアレベルで、アジャイル開発の思想を体現するものだと思います。

プロセスのレベルとハードウェアのレベルと領域は異なるものの、アジャイル開発とクラウドが実現しようとしている価値は非常に似ており、しかも、特に「現場の変化に対応する」方法としても親和性の高いものであるように思えます。
山口さんのクラウドの環境とアジャイル開発を使用した開発の実例を聞いて、そのようなことを考えました。

しかし、変化に対応するには、クラウドやアジャイルだけじゃ足りないよね、というお話がどうやら2日目にあったようです。
それが、鈴木雄介さんの『これからのアーキテクチャを見通す』という講演です。
私は2日目に参加しなかったので聞けませんでしたが、プロセス、ハードウェアについで、アーキテクチャから変化へ対応するための提言です。
これはききたかったなぁ。
http://www.arclamp.jp/blog/archives/devsumi2010_architecture.html

◆楽しかった
デブサミに初参加しましたが、とても良い刺激になりました。
こうしたコミュニティに参加して思うのは、「参加してなかったらこんなこと意識しないよなぁ」ということです。
たとえば、KVS、並列アルゴリズム、NonSQL、OSGiなどの考え方は、このコミュニティに参加しても、ちょっとわかったような気になれる程度です。
でも「知らない」ということを知ることができます。
しかし、コミュニティに参加していなければ、それらの存在を意識することもありませんし、「知らない」ということも知らない状態です。
それってとても危険ことだと思います。

なによりも、新しい技術、コンセプト、サービスを真剣に考えている人たちが集まる場、というのはとてもエネルギッシュで楽しい。
というのは、真剣な人たちの情熱を話を通じて、もらうことができるからだと思います。
たしかに、ビジネスよりの自社サービスや製品の紹介、のような講演もあるかもしれません。
でも、その人たちがビジネスという点で真剣だからその話を聞いていると、勉強になるし、楽しい。

参加して、本当に良かったです。

個人的には、並列アルゴリズムとOSGiにとっても興味を持ちました。
学ぶことがまた増えました。が、学びの可能性が多いのはよいことですよね。たぶん。。。

【イベント情報】
◆「Developers Summit 2010 ※すでに終了しています。
http://codezine.jp/devsumi/2010

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

月を目指して(2)~CSM研修について出したメールの返信が上司から来た~

2月 19, 2010

2週間ほど前に、

認定スクラムマスター研修(CSM)を、会社のお金で、受けに行きたい

というメールを上司に送る、という内容のブログの記事を書きました。
結構、周囲の人がブログを読んでくださったらしく、

「あの件、どうなった?」

と多くの方に声を掛けてくださいます。
意外な注目の高さに驚いています。
ですので、今日はその件の続きを書きたいと思います。

メールを送った当初、自分が所属している部署がとくにバタバタしているため、私が送ったメールは無視された状態でした。

自分が考え抜き、思いを込めて出したメールが無視されたからといって、あきらめてはいけません。
そもそも、部長が、会社と部署にとって明らかに、私の研修よりも重要な問題に関わっているとわかっていたので、たいしたショックも受けずにすみました。
これは、私が所属している会社が従業員が100名以下の会社で、5歩も歩けば部長の席、というオフィスの利点ですね。

で、その問題が解決をしたころあいを見計らって、「送ったメールをお読みいただけましたか?」と部長に問いかけると以下のような内容のメールが返信されてきました。
さすがに本文はそのままご紹介できませんので、内容をまとめて紹介します。

システム開発手法や技術には真理は存在しない
アジャイル開発が会社、お客様に有効な手法かが判断できない
要望については社長に申請する。ただし、結果は期待しないで欲しい

1つ目の「システム開発手法や技術には真理は存在しない」という意見は、開発手法というのはミズモノので経営や開発現場の問題を本質的に解決するものではない、という意味だと思います。
おそらく、この意見は上司の経験に基づくものなのでしょう。
上司は、すでにこの業界に30年以上もいるベテランです。
そのキャリアの途上では、多数の開発手法や設計手法が注目を集め、そして、消えていったという経験をしているはずです。
メールにも詳しくは書いてありませんでしたが、「1度、あたらな手法といわれる開発手法を使ったことがある」とも書いてありました。
結果までは聞いていませんが、おそらく成果は芳しくなかったのではないか、と思います。
そうした経験から、「開発手法に真理は存在しない」という結論が導き出されているのだと思います。

この点については、「いえいえ、アジャイルは違います!」と強弁するつもりは、私自身はありません。
おそらく上司が言っていることは正しいと思えるからです。すくなくとも、上司の経験上の事実であることには変わりはありません。
なにより、手法はあくまで手法であり、状況において適切に実行されなければ問題を解決する力にはなりえません。
そうしたことから、「開発手法に真理は存在しない」ということは正しいと思えます。

また、上司の言う「真理」には、「不変」という意味合いがこめられているように思えます。
開発手法やシステムの技術は、同一のものでありがながら呼び名が変わっただけもの、もしくは、理論は立派だけれど現実に対応できないもの、そうしたものが雨後のタケノコのごとく生まれ、消えてきたという歴史があるのも事実です。
そうした歴史から鑑みれば、アジャイル開発もまた、その中の1つとして認識されてもおかしくはありません。

2つ目の「アジャイル開発が会社、お客様に有効な手法かが判断できない」という点についてですが、これは当然でしょう。
というのは、そもそもメールを送るより前の段階に上司にたいして、

アジャイル開発、特にスクラムとはどのようなものなのか
現状の会社、お客様にどのような利点があるのか

といった、上司が当然、抱くであろう疑問にたいする説明をまったくしていないからです。
まだまだ、自分の行動が足りていません。

3つ目の「研修費の負担や研修を業務時間として受講する件については社長に申請する。ただし、結果は期待しないで欲しい」という点も、当然かと思います。
会社を含め、部署の業績も芳しくないさなか、20万の費用は大きいものです。
単純に考えても、「倍の月給くれ!」と要求しているわけですから。
ただ、なんとしても「業務時間内で出席」という点は、話をとおしたい、と思っています。

ようするに、送ったメールにたいして非常に全うな、生意気な言い方をすると予想通りの回答があった、といえると思います。
単純に、上司の返信の内容を悪いようにとると

「まったく」関心がないし、上司による周囲への働きかけは期待できない

というものになるでしょうか。

しかし、良いようにとると

「まったく」関心がないが、上司は自分の活動には理解を示してくれている

というものにもなりえます。
私は、この返信内容を「後者」だと思っています。
これからも行動する余地がある、ということはよいことだと思います。
また、なんだかんだ平社員の意見が社長まで届く、という会社の環境もよいものだと思います。

実は、今日はメールを送った上司とこの件について、飲みながら話す予定です。
飲み会では、

どのような開発手法を用いたことがあって、どんな結果になったかを聞く
アジャイル開発を導入することの利点を説明させてくれないかを頼む
なんとか業務時間内でCSM研修を受けさせてくれないかを頼む

を目標にいろいろ話してみたいと思います。

この記事は、「今夜、やるべきことをきちんとやりますよ」決意表明、みたいなものですね。
今夜の結果は、また後日。

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

JaSSTでアジャイル的なテストの話を聞いた-その2

2月 16, 2010

先日、JaSSTについての感想のエントリを書きました。
その時は、基調講演の話だけで力尽きてしまったので、今回、その続きとして、

・チュートリアルならびにライトニング・トークスの感想

また、結論としてフォローしきれていなかった

・「品質」をつくりこむことにもアジャイルの考え方は有用
・テスターはだんだんと滝の上流に向かおうとしている

という点について、書きたいと思います。すごく長くなっていましました。

<チュートリアルでアジャイルな振る舞いについて考える>
基調講演に引き続き、Johanna Rothman氏(以下、Rothman氏といいます)のセッションに参加しました。
タイトルは『Becoming an Agile Tester in a Waterfall World』といい、日本語にすると「ウォーターフォールの開発においてアジャイルなテスターになる」というところでしょうか?
このタイトルを見て、

ウォーターフォール(以下、WFといいます)の開発において、テスターがアジャイルに振舞うにはどうするか
また、WFの開発において、どのようにアジャイル的なテストを導入してゆくか

などの手法、アプローチの方法が学べると思っていました。
しかし、話の主題はむしろ、

テスターがagileに振舞うことがどのようプロジェクトに影響をあたえるか

ということを座学とワークショップを通じて学ぶ、というものでした。

期待とは外れた内容でしたが、それでも多くのことを学ぶことができました。

◆WFは理想の形では終わらないことは深刻なこと
これは、Rothman氏のお話を聞いていたとき出てきた話題です。
ソフトウェア開発に携わる人間であれば、誰もが共感を覚える言葉だと思います。
事実、ソフトウェア開発に携わる人であれば、要求定義、内部設計、外部設計、開発、テストなどの各フェーズの作業が、当初の計画通りに終了することが稀であることを知っています。
計画通りでない、という点においては、スケジュールの前倒しと超過、という2つの場合が考えられます。
が、現実はたいてい後者であり、その遅れを取り戻すために、超過勤務をおこなう、ということもしばしばあります。
苦笑いを浮かべて「そうそう」といいたくなるのですが、改めて考えるとWFがいびつな形でしか行えない、という事実は深刻な事態です。

テストの視点から、スケジュールの超過が問題となるのは、

テストがリリースの時期を越えてしまう

ひどい場合になると

リリースにあわせてテストの時期を削る

という事態を引き起こすことです。
両方共に、前段のフェーズにおけるスケジュールの超過の影響を受けて、品質が「確認不十分」のままソフトウェアを出荷してしまうことになるのです。

WFにおいては、現時点の作業が常に後段の作業のボトルネックとなります。
ある段階の作業がすべて終わらない限り次の段階の作業には進めない、という制約を設けることは、その段階において最大の問題、一番、解決するのが難しい問題をボトルネックとして据えることを意味します。

各段階の作業にも、簡単に解決、消化される作業もあり、解決が難しく、消化されづらい作業もあります。
このとき、解決が難しく、消化されづらい作業、すなわち、最大の問題となる作業をボトルネックとして据えてしまうこと自体には、過ちにはなりません。
むしろ、最大の問題となる作業が終了する時点にあわせて、すべての作業を終わらせることが、無駄を省く良い手段になりえます。
しかし、それは、すべての作業の終了計画を柔軟に変更できる、という条件を満たす限り、すなわち作業すべきを量や時間を適宜、調整できる限りです。
ようするに、必要なとき、必要な分だけ届ければよい、という開発プロジェクトであれば問題にはなりません。

しかし、ソフトウェア開発プロジェクトは、定められた納期を遵守して製品を提供しなければなりません。
こうしたときには、
いかに作業を前倒して、早く作業を消化するか
が重要です。
この場合は、難しい作業が終わるまで、終了した簡単な作業とそれに続く作業を放置し続けることは、単なる無駄になってしまいます。

ようするに、作業を前倒しで進めてゆく、納期遵守のプロジェクトにおいて、最大の問題となる作業をボトルネックに据えてしまうと、

消化可能な作業もリリースができない状態で抱え込む、すなわち仕掛在庫になってしまう
最大の問題となる作業が超過すればするほど後段の作業が削られる
結果、最終段階のテストの時間が削られる/超過する

という事態を招きます。

WFにおいて、テスト不十分のままでソフトウェアがリリースされる、という背景の1つには、ソフトウェアベンダーはリリースしないとお金がもらえない、という経済的な背景があります。
ですので、ソフトウェアベンダーにとって、このとき最悪なのは、顧客と取り交わした納期に開発が間に合わず、すべての作業が仕掛在庫として無駄になったまま捨てられる、という事態です。
当然、顧客からの信用を失いますし、作業に投下した分の費用が回収できずに、赤字になってしまいます。

顧客としても、WFにおいて最終フェーズに位置するテストが終わらない限り、発注した機能が手にはいらない状態となります。
ですので、納期を守って製品を納品してもらおう、とします。
というのは、納期は、大抵、ビジネス的な制約から決められるからです。
たとえば、顧客が、「Webサイトからの製品購入ができるようにします」とプレス・リリースしてしまった場合、この期日を守って顧客の顧客にサービスが提供したい、と考えます。
(ま、開発前にプレス・リリースを流すようなマネはしないとおもいますが。。。)
また、社内システムでも、「この日までには、その機能がリリースされます」と約束する場合もあるでしょう。
このような場合、納期までにテスト十分されず、品質評価が不十分でも、顧客としては自分たちがサービスを提供する人々への約束を守るため、しぶしぶその製品のリリースを許可することもあるのです。

また、ソフトウェアベンダーにとって、このとき最悪な事態は、顧客にとっても最悪な事態です。
ソフトウェアベンダーとともに、自らが投入したリソースに見合うサービスが、まったく受けられないことになるのです。

こうした観点からは、アジャイル開発は有用な点があります。
それは、

1つのイテレーションが終了すれば顧客にとって優先順位の高い機能が提供されている可能性が高い

という点です。
アジャイルは、1週間、2週間ないしは1ヶ月といった一定期間をイテレーションと呼び、そのなかでシステムの一部の機能(といってよいのでしょうか?)をリリース可能な状態にするよう作業します。
このため、ソフトウェアベンダーと顧客にとって、リリースできない不完全な作業、すなわち仕掛在庫となるような作業は少なくなります。
また、イテレーションの中には、TDD(テスト駆動開発)やIC(継続的な統合)というプラクティスを導入することによって、

常にシステムをリリース可能な状態に保つ

という思想があります。
これを実践できれば、前段の作業の遅れによって削られてしまった時間の中で、納期にあわせるため駆け込み的にテストを行う、という事態は避けられます。
ひいては、品質確認がまったくなされていないソフトウェアを出荷しないで済むようになります。

今までの商習慣であれば、実はWFにおいても、作業が膨らめば顧客との話し合いによってリスケジュールが行われてきました。
しかも、顧客がリスケジュールによって追加してかかる費用を負担してきた、という歴史があります。
ようするに、なんとかしてWFをいびつな形に終わらせない、という努力を顧客とソフトウェアベンダーの双方してきたのです。
ですが、昨今は、両者の話が折り合いがつかず訴訟問題に発展する場合も、見受けられます。
双方の努力が限界を迎えつつある、ということのように私には思えます。

WFが理想の形で終わらない、という言葉には、ソフトウェア開発が抱えてきた問題が多く含まれている、そのように考え、受け止めるべきだと、あらためて思いました。

◆ワークショップは難しすぎた
Rothman氏のお話につづき、8人程度でチームをつくって大人用、子供用の2種類のモビールをつくる、というワークショップを行いました。
プロジェクトマネージャが1人、オブサーバーが1人、その他の人たちは開発者とテスターに分かれて、作業を行います。
一定時間(たしか、10分)がすぎたら作業を止め、作業の進捗と今後の作業にかかるであろう見積もりを報告する、これを3から4回(すみません、うろ覚えです)繰り返すというものです。
ようするに3~4回のイテレーションで、2種類のモビールを作ってみましょう、という課題です。
ちなみに、オブサーバーは、ワークショップの観察者で、ワークショップの中で参加者がどのような行動をとっていたか、という記録係を果たします。

・役割が不明確になると現場は混乱する?
第1イテレーションでは、開発者/テスターの役割を明確に分けて作業を行おうとしました。
しかし、テストを行おうにもその対象がないために、テスターの人は完全に手が空いてしまいます。
ですので、テスターの方もモビールの材料作り、飾りとなる色紙を切ったり、木の棒と輪ゴムでモビールの骨組みを作ったりという作業に参加することになりました。
こうすると、現場は、誰が、何をやっているか、ということが把握しづらくなります。
そのため、自分が今、何をやるべきか、という点が不明瞭になりがちです。
理想としては、開発者が早く材料を作り、作られた材料の品質チェックを随時、テスターが行う、という流れが作られるべきだったのでしょう。
しかし、材料作りが進みづらいために、テスターが材料作りに参加してしまい、結果、材料の品質チェックが十分に行えない、という状況が出来てしまったと思います。
これは、おそらくRothman氏が意図した状況ではなかったと思います。
とはいえ、クロスファンクショナル、という考え方においては、テスターが材料作りに参加する、という状況は正しかったのではないか、とも思っています。
単に、その状況下で、品質をチェックする、という作業をうまく組み込むことができなかっただけなのかもしれません。

・度胸が足りない
実は、私の参加したチームには、英語圏の方がメンバーとして2名、参加されていました。
が、この方たちとチームでまったくコミュニケーションが取れませんでした。
プロジェクトマネージャを担当された方のみが英語ができたので、その方のみが英語圏の方々とお話しする、という状況になっていました。
私はコミュニケーションを取ることにしり込みしてしまい、まったくお話ができませんでした。

言語の壁を越えて多くの人々とコミュニケーションとることを目的に、英語を勉強しよう、と考えているにもかかわらず、いざその機会を迎えてしり込みするのですから、なにをかおいわんや。

英語能力うんぬんではなく、自分のコミュニケーション能力を見直したほうがよいのではないか、と反省しました。
初対面の人と話すのは、大半の人は「怖い」という気持ちを抱きがちです。

相手がどんな人か分からないから、怖い
相手がどんなことをしてくるか分からないから、怖い
相手にいやな思いをさせて嫌われてしまうことが、怖い

こうした恐怖心を乗り越えるのは、簡単なことではありません。
しかし、「怖い」と思っているのは相手も一緒です。
だとすれば、まず自分から「怖い」という気持ちを捨てて話さないと何も始まりません。

この「怖い」という思いを捨てる度胸を身につけるために、英語を勉強するのでしょう。
だとすれば、洋書を読む、という以外にも英語圏の人たちと話す、という体験が必要になるはず。
そういう努力も今年はしたいと思います。

・クロスファンクショナルってなに?
なにより、面白いのは、結局、テスターも材料作りに参加してしまう、ということです。
というのは、作業が開始された時点では、品質チェックするものはなにもなく、どうしても手が空いてしまうためです。
ようするに、手持ち無沙汰な状況がすぐに生まれてしまうので、「なにかやらなきゃ」という気持ちが生まれ、部品の作成作業にかかわろう、という気持ちもまた、生まれるのです。
これをソフトウェア開発に、照らし合わせてみると、テスターという人にたちがWFでいうところの上流工程や開発工程に携わる、ということです。
そして、携わり方もクロスファンクショナルな、携わり方だった、といえるのではないか、と考えています。

私はテスターという立場で仕事をしたことがないので、想像でしかないのですが、テスターは、上流工程や開発工程から携わるとしても、平行して行うことが可能なテストを行っているのではないか、と思っています。
携わる工程や品質評価の対象がかわっても、やることはテスト作業だけ、というのでは、やはりクロスファンクショナルとは言いがたい、と思います。
私自身、最初はクロスファンクショナルとは、ある工程に複数の職責の人間が関わることだと思っていました。
ですが、Rothman氏の講義を受けて、クロスファンクショナルとは、工程などという大枠ではなく、

ひとつの成果物を生み出すために複数の能力をもった人々の視点を利用する

ということなのではないか、と思うようになりました。

詳細設計書を書く、というときに、テスターは詳細設計書の内容をチェックするチェックリストを作るのではなく、詳細設計書自体を書く。
そして、コードを書く、というときに、その時点のコードの内容をチェックするのではなく、テスターはコードを書く。
こうしたことをクロスファンクショナル、というのではないか、と思うようになったのです。

あるドメインのスペシャリストを集め、その人たちが自分のドメインについてのみ作業を行うことは悪いことではないでしょう。
しかし、それ以上にそのスペシャリストたちが、自らのドメインを超えてお互いの作業に関わりあうことがより、高い価値を生むのではないでしょうか。
それは、仮に、一人ひとりがスペシャリストでない場合を想定すれば、ドメインを超えてお互いの作業に関わりあうことで、複数の視点を利用して、作業の穴をふさぐ確率を上げることができる、と考えられるからです。
スペシャリストが参加した場合でも、その穴の指摘がより高次なレベルなだけ、なのだと思います。

クロスファンクショナル、という言葉がもつ意味が、私が思っているような意味ではないかもしれません。
また、ドメインを超えて作業に携わりあう、ということは、お互いの仕事に無知であると、単に現場が混乱するだけかもしれません。
なにより、PMや開発者、テスターなど開発に携わる人々が、互いのドメインに携われるスキルセットをもっていないと成立しません。

こうして考えると、クロスファンクショナルというのは理想論なのかもしれません、また、PMが開発やテスト作業をするべきなのか、という疑問もでてきます。
クロスファンクショナルチームがとるべき理想のバランス、それがいったいどのようなものなのか、これは今後も追求して行きたいと思います。

<LTはおもしろい!>
この日、最後に参加したセッションは、LT(ライトニング・トークス)です。
ここでも、コードの共同所有やTDDなど、アジャイル開発となじみの深いトピックスが、TLでも聞くことができました。
また、観客(?)として参加していた方々とお話ししたときも、「WFは限界が迎えていると思っている」という言葉を残された品質評価に関わるベテラン社員の方もいらっしゃいました。
ということで、ますます

アジャイルの流れがきてるなぁ

と都合のよく、品質管理における流れを解釈しました。

なによりも面白かったのは、歌、です。

いままで、多くのLTを見てきましたが、歌を聴いたのは初めてです。
柏原よしえさんの『春なのに』の替え歌で、『バグなのに』という歌でした。
詩の一部には、「バグなのにお別れですか」という一節がありました。
プロジェクトの終盤のテストでバグが発覚したのに、当の開発者はすでに別案件のプロジェクトに投入されている、という状況に直面したテスターの悲哀を歌い上げたものなのでしょう。
ですが、この状況は本当にあるんでしょうか。
だとしたら、誰が修正するんでしょうか。
かなり悲惨な状況ですよね。
自分がその状況におかれたら笑えませんが、そうした状況を歌にして笑い飛ばせるテスター、品質管理の人たちの器のでかさを感じることができました。笑

<気づき>
◆アジャイル的なアプローチで品質を作りこむ
アジャイル開発における、イテレーションという期限を設けたタイムボックスを用いた開発における特徴のひとつが、クロスファンクショナルチームがつくられる、という点にあると思います。
というのは、あるイテレーションごとに、WFでいうところの設計、開発、テストが詰め込まれるためです。
クロスファンクショナルという言葉について、正確な定義は知りません。
ですので、私見になりますが、クロスファンクショナルとは、

ある物事にたいして、複数の知識、視点が提供される

ことが重要なのだと思います。

ようする、チームとして一緒にいること、が重要なのではなく、同じ作業に複数の専門性をもった人びとが関わることが重要なのだと思うのです。
確かに、ある作業によっては、専門的な知識を持ったスペシャリストが行ったほうが早い、正確、という作業もあるでしょう。
また、すべての作業が複数の人間が関与することになると、個人ごとの意識やスキルセットによって、作業の質や方法にバラつきが発生する恐れもあります。
しかし、こうした状況に対処するときにこそ、スペシャリストの専門性が発揮されるべきなのです。
チームメンバーの作業が、早く、正確になるための成長を促すため、自らのスキルとプラクティス、知識を提供する。
また、チームメンバーにとって未知の状況においては、自らの専門性をもって指針となる。
クロスファンクショナルチームにおけるスペシャリストの役割は、そうしたものになると思います。

アジャイル開発では、各イテレーションにおいて開発されたシステムは、「リリース可能な」状態、品質であることが求められます。
この制約の元、各々のドメインにおける最高の知識を提供しあうクロスファンクショナルチームにより開発される製品の品質は、イテレーションごと磨きあげられてゆく、と期待できます。
これは、テスターというテスト、品質確認のスペシャリストが製品が開発される過程のすべてに関わることができている、という状況ができているからです。

WFでは、各段階を経て、最終的にテストが終了した時点で、その品質が「最高」であることが保証されます。
しかし、最終的に品質確認を行う、というのでは、テストは「品質を確認する」というだけの場で終わってしまいます。
品質が悪い点を発見できない、というのではなく、発見できても適切な修正を施せない、つまり、「修正を目的としてテストを行う」ということができない状況を生みがちです。

アジャイル開発においては、そうした点を念頭に置き、常にリリース可能な状態にシステムを保つ仕組みを取り入れようとしています。
アジャイル開発におけるテストは、「常にリリース可能な状態」を保つために行われるのであり、それは「バグの発見と修正」を目的としているのです。
テストコードを書いてからコードを書く、というTDDを開発に取り入れること。
さらに、CIを取り入れて一定期間で自動ビルドがなされる仕組みを開発に取り入れること。
こうした、常時システムをリリース可能な状態に保つための、テストにたいするアジャイル開発のアプローチは、かなり有効です。
また、イテレーションを組んだり、顧客を巻き込んだりするよりは、WFの開発現場にも取り入れやすいはずです。

私自身も、この点から徐々に社内にアジャイルのプラクティスを導入できるのではないか、と期待しています。

◆テスターが滝を上ろう、としている
開発者として、上記のようにTDDを取り入れたり、CIを取り入れたり、という品質チェックを開発段階に取り入れよう、と考えているのですが、この要請はテスター側からもあるようです。

よくコードのみならず、設計の不具合はすべてが「負債」といわれます。
WFでも要求定義段階や設計段階よりも、開発、テスト段階での不具合の修正が高くつく、といわれます。
それは、前段すべての作業を後戻りして、修正をしないといけないためです。
そのため、バグは早期に発見することが求められます。
早期に発見したほうが作業のて戻りが少なくすむためです。

逆に、バグがプロジェクトの最終段階になって発覚すると、その修正の手間は格段に増えてしまう。
早めに返せば(修正すれば)その分の手間は減り、返すのが遅くなればなるほど、その手間が増える。
こうしたバグの性質を捉えて、バグは「負債」にたとえられるのですが、問題はその負債を返す人が違う、もしくは完全に返しきれない、ということです。
私は、テスターという存在がいるプロジェクトに参加したことがありません。
ですので、実態はわかりませんが、LTの歌のように「バグなのにお別れ」の状態が本当に存在するのであれば、テスターはまったく自分が関与できない段階での負債をすべて背負い込む存在になってしまいます。
これは、本当につらく、精神衛生上も良くありません。
私がその状況に置かれたら、すくなくともPMから開発者まで前段の作業をやっていたすべての人が嫌いになるかもしれません。

なんであいつらのミスを俺がフォローしなきゃいけねーんだよ!

という気持ちが生まれそうです。

少なからずこうした経験をした方がいるのであれば、自分たちが上流工程から作業にかかわり、品質のチェックや改善を行いたい、と思っているのではないでしょうか。
そして、基調講演にアジャイル的なアプローチを推進するRothman氏が招聘されたり、自分が参加していたすべてのセッションでアジャイル開発への期待が聞けたり、という点から、私としてはテスターの人たちも下流工程から上流工程へ積極的に関わりたい、という意識が芽生え始めているのではないか、と思いました。
アジャイルのプラクティスである、TDDやCIを開発段階に取り入れることで、今までより早く、品質のチェック、バグの発見と修正をおこなうことができる。
こうした期待をテスターの方々も持っているのではないか、そのように感じました。

◆アジャイルなテスターを支援するアジャイルな開発者でありたい
アジャイル開発、もしくはそのプラクティスの一部を取り入れることで、よりシステムの品質は向上する、という期待が、私にはあります。
そして、テスター、品質管理に携わる人たちも、その期待をもっていると、JaSSTに参加して感じました。
ですが、Rothman氏いわく、テスターの側からも「アジャイルに振舞うことは、簡単ではない」とのことでした。
これは開発者と呼ばれる仕事をしている私も常々、感じることです。

受託開発に携わる以上、アジャイル開発はどのフェーズに所属する人でも、簡単に導入することはできません。
たとえ、開発組織の長であるPMや組織の長の社長が決断を下したとしても、最終的には、顧客の決断が必要になるからです。
なにより、今までの業務プロセスを大幅に変更する必要がある、という時点で、組織内に大きな影響を与えて、周囲を巻き込む必要があります。

そのような状況を想定して、なお、アジャイルなテスターであろう、という人がいたら是非、その人に協力したい、そのように私は思っています。
それは、アジャイル開発がしたいから、というのではなく、「品質の良い」システムをつくるためには、テスターというテストのスペシャリストが、開発の段階で携わっていて欲しいと感じているからです。
なによりも開発者である私自身が、テストの工程に目を向けて積極的にテストに関わるアジャイルな開発者として振舞いたいと思います。

<やりたいこと>
◆社内LT大会

LTのよさは、時間の短さに加えて質疑応答がないことなんですよ、とある方がおっしゃっていましたが、確かにツッコミがない、というのは気軽に話せてよいのかもしれません。
気軽でかつ、プレゼンの練習にもなるので、是非やってみたいと思います。
とくに社内でやれば気軽で、盛り上がりそうな気がします。

ゆくゆくは「LTに出たい、と思っているけど、なかなか勇気がでない」という方々に集まっていただき、プチLT大会を開くのも面白いかもしれません。

◆『FEARLESS CHANGE』を読む
Rothman氏のワークショップに参加し、英語ができないことの危機感を今まで以上に強く感じました。
また、「どうすればアジャイルな要素を会社やプロジェクトに取り入れることができますか」という質問を、ある方に質問したところ「『FEARLESS CHANGE』を読め」とのアドバイスをいただきました。
そもそも英語については、「読めない、書けない、しゃべれない」という意識が強すぎて、「読まない、書かない、しゃべらない」というのが今の私の状態だと思います。
今の苦手意識、忌避意識を少しでもなくすために、「英語を使う」という行為は一番、効果的だと思います。
そして、『FEARLESS CHANGE』には、自分が英語とは別に持っている問題意識を解決できる知恵が詰まっているのですから、さらに有効です。

本はすでに手元にあるので、少しずつ読み進めたい、と思います。

◆業務時間に勉強時間を組み込む
業務時間に勉強時間を組み込む、という考え方は、基調講演でRothman氏がお話されていたことです。
重要なことは、

定期的な時間として組み込む
業務に関係ない分野でも良い

ということだと思います。

就業後に勉強をする、というのはなかなか心理的なハードルが高い、と思います。
勉強したことが役に立つか否かもわかりませんし、なにより仕事の後はゆっくりとしたいものです。
このハードルを少しでも低くするために、一定の割合で勉強の時間を業務の時間として認めることが重要が有用だと思います。

「勉強したくない」という気持ちはよくわかりますし、現実、早く家に帰らねばならず就業後に勉強する時間が取れない、という状況も人によってはあります。
こうした人たちに業務時間内に勉強時間を用意することで、すこしでも勉強すること、新しい知識や情報を得ることの取っ掛かりになります。
また、業務に関係ない分野でも良い、とするのは、さらに心理的なハードルが下がるはずです。
私としては、それがITに関連していなくてもよい、と思っています。
そうすることで、社員たちは「自分のため」に勉強し始めるからです。
会社が、業務に関係がなければ勉強時間としては認めない、と勉強することに制限をかけてしまうと、社員たちは「会社のために勉強している」という意識を持ってしまいます。
「会社のため」という「やらされている」感覚では、「勉強をする」ということそのものにたいする心理的なハードルの高さはさがりません。
また、知識や情報の吸収の度合いも低くなるでしょう。

会社としても、受託開発をしているのであれば、他業種の業務ドメインの知識が必要になるときは、多いはずです。
会計、経理をはじめとして、小売り、通信販売、医療、法務などの知識を社員が自主的に身につけていた場合、そのドメインのシステムをつくるときには、その知識を利用することもできます。
なによりも、「自分たちのために会社が制度をつくってくれる」と社員たちが感じ取ってくれれば、社員たちは「会社を好き」になってくれるはずです。

こうしたことから、会社にとっても業務時間を一定の割合で社員の勉強時間として割く、というのは有用です。

会社には若干、働きかけてみましたが反応は微妙。
もう少し粘り強く交渉してみよう、と思います。

まぁ、長々と書いてしまいました。
しかも、後半、力尽きました。

うだうだとではなく、簡潔に。
今後は、そのように文章を書きたい、と思います。
自分でも読む気がおきない文章って、どうよ?ってな感じですし。

なお、TDDに関しては、アツい議論がtwitter上で交わされていたようです。
以下のURLでtogetterでのまとめが読めます。
http://togetter.com/li/5878

TDDとテストの関係、TDDは開発におけるテストなのか、はたまた設計なのか。
このエントリで書いた気づきや疑問もこの議論に集約されていくのかもしれません。

◆JaSST公式サイト
http://www.jasst.jp/

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

「「エレメント」 構造デザイナー セシル・バルモンドの世界」展で構造の重要さを体験する

2月 14, 2010

先週、2010/2/6(土)に、東京オペラシティで開催中の「「エレメント」 構造デザイナー セシル・バルモンドの世界」を見に行きました。
私は、セシル・バルモンドのことをまったく知らず、「構造デザイナー」という職業が存在することも知りませんでした。
ですので、「構造デザイナー」というあだ名で呼ばれる、有名な建築家なのだと思い込んでいました。
しかし、実際は違いました。
セシル・バルモンドは、「構造デザイナー」という職業において、優れた才能をもつ存在として注目されています。

「構造デザイナー」とは、ある建造物を設計、建造する際に、その建造物の骨組みなどが十分な耐久力をもてるよう技術的なサポートをおこなう役目をもっています。
たとえば、建築家が自らの理想とする姿をした建造物をデザインしても、それが実現するにはさまざまな物理的な制約があります。
「構造デザイナー」は、その制約を念頭に置き、デザインされた建造物が、十分な耐久性が維持できるような骨組みの組み立て方、つまり構造を設計することで、建築家の理想的なデザインの実現をサポートする役割をになっているのです。

セシル・バルモンドは、そうした「構造デザイナー」として、数々の有名な建築家から依頼を受ける優れた才能を持っている優秀な人なのです。
ちなみに英語のwikipediaでは、セシル・バルモンドはstructural engineerとして紹介されています。
ですので、「構造デザイナー」という言葉が正確に日本語として使用されているかは、若干、疑わしい部分があります。
エンジニア、すなわち技師、技術者ですので、「構造デザイナー」というのは、アーティスティックな部分を強調して、この展覧会独自の言葉なのかもしれません。

<構造はモノにとって力強く、重要な存在>
ソフトウェア開発は、よく建築となじみが深い、とされています。
その一端をあらわすものとして、アーキテクトと呼ばれる職業がソフトウェア開発にも存在することがあげられます。
かなり乱暴な説明になりますが、ソフトウェア開発におけるアーキテクトは、技術的なリーダーの役割をにないます。
建造物がその土地や周囲の環境、ならびに 建材の材質に大きな影響を受けるように、ソフトウェアは、使用するOS、ミドルウェア、開発言語などの影響を受けます。
こうした要素を作成するソフトウェアにあわせて適切に取捨選択することが、ソフトウェア開発におけるアーキテクトの役割です。
また、全体的なプログラムのつながり、すなわち構造を設計するのも、アーキテクトの仕事であり、この際には、デザイン・パターンというものも用いられます。
このデザイン・パターンという考え方もまた、建築家であるクリストファー・アレクザンダーの建築技法に基づいています。

このように、ソフトウェア開発は、建築ととてもなじみ深いといわれています。
ただ、ソフトウェア開発におけるアーキテクトは、建築における建築家と「構造デザイナー」の両方の役割をになっているようにも思えますが。

私が、セシル・バルモンドの作品の中でも魅せられたのは、『H_edge』という作品です。
チェーンと、弧を描いたプレートという、バラバラな状態の部品を規則的に組み合わせることで、1つの自立した柱や壁を築く作品です。
この作品を観ると、セシル・バルモンドが単なる技師としてではなく、ある美学と企てをもって構造設計に携わっていることがわかります。
それほど、幻想的な世界が構築されるのです。

何より、強く印象付けられたのは、バラバラの部品が構造を規定することで、ひとつのものとして自立している、という事実でした。
考えてみれば、この世界の建造物はもとより、大半のモノは一つ一つの部品が「設計」された構造の元に統合されて、ひとつのモノとして自立しています。
今この文章を書いているパソコンしかり、住んでいるアパートしかり。
普段、完成した姿をみているとそれらがバラバラだったときを意識することはありません。
しかし、『H_edge』という作品をみていると、ひとつのものが、元はバラバラの存在で、それが「構造」という一つの要素でつながっていることを強く意識させられます。
そして、完成されていると思っていたものが、「構造」という1つの要素によって支えられていると思うと、か弱く繊細な存在であるように思えてくるのです。
一方で、完成された姿を支える「構造」の力強さも感じることができます。

職業柄、「構造」という言葉を良く聞き、重要なものだと理解しているつもりでした。
ですが、それはあくまでも聞いた情報を元に想像した世界に過ぎないものでした。
今回、『H_edge』という作品を通じて、「構造」があるモノの姿を規定する力の強さ、そして、その重要性を体験できたと思います。

ソフトウェアエンジニアの中でも、「構造」の重要性を聞いて知ったつもりになっている、という方は意外に多いのではないでしょうか。
そのような方は、是非、会場に足を運んでみてください。
モノにおける「構造」の重要性が体験的に理解できると思います。

【会場情報】
◆東京オペラシティ-「「エレメント」 構造デザイナー セシル・バルモンドの世界」展
http://www.operacity.jp/ag/exh114/
◆TAB-「エレメント 構造デザイナー セシル・バルモンドの世界」展
http://www.tokyoartbeat.com/event/2009/3B6D

【作家情報】
◆セシル・バルモンド(Cecil Balmond)
・Wikipedia-セシル・バルモンド
・Wikipedia-Cecil Balmond
【次の予定】
◆未定
※引越し作業中につき展覧会へはなかなかいけそうにないです。。。

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

JaSSTでアジャイル的なテストの話を聞いた

2月 7, 2010

2010/1/28(木)にJapan Symposium on Software Testing、通称・JaSST(ジャスト)に参加してきました。
遅ればせながら、各セッションのまとめと感想を書きたいと思います。
ちなみに、JaSSTは2日に分かれて行われています。
私は1日目のみ、参加しました。

シンポジウムの話を聞いた感想は

「品質」をつくりこむことにもアジャイルの考え方は有用
テスターはだんだんと滝の上流に向かおうとしている
技術者として胸の晴れる技術を身につけるべき

というものです。
1日目の基調講演、ならびにチュートリアルでは、Johanna Rothman(ジョハンナ・ロスマン)氏のお話を聞いたのですが、その内容はアジャイルの考え、手法を色濃く反映されていました。
また、ライトニング・トークスでも、トーカーの方々が、お話の中でアジャイルのプラクティスに触れるなど、全体的にとてもアジャイル色の濃い内容になっていました。

アジャイルというと、ある点からは「乱暴」「乱雑」というイメージがあり、「きっちり」「しっかり」というイメージの「品質管理」「テスト」と相容れない、とテスターの人からはうけとめられているのかな、と思っていました。
しかし、現在進行形で品質管理に携わる人々も、アジャイルの考え方や手法の有効性を取り入れようとしている、ということを知ることができました。

<基調講演ではAgileな教訓を学ぶ>
基調講演は、Johanna Rothman氏(以下、Rothman氏といいます)が、経験を元に、ソフトウェア・マネジメントについて17の教訓を紹介する、という内容でした。
ソフトウェア・マネジメント、ということから、開発者とテスターに関係なく、ソフトウェア開発に携わるすべての人間にとって役に立つ内容でした。
Rothman氏の経験から得た教訓が、その経験からアジャイル的な考え方やプラクティスに近いもの近づいていったのか、もしくは、経験の途上で意識的にアジャイルを取り入れたのか、そうしたことはわかりません。
が、内容の柱は、アジャイルの考え方やプラクティスを中心にすえていたようにおもいました。

個人的には、以下の話が印象に残っています。

◆優秀なマネージャとスタッフは大幅な改善を促す
改善を促す、とはいえ、何の改善を促すのか、その主語がわからなかったのですが、仮に「チームのパフォーマンス」として話を聞いていました。
話によると、
・プログラムの再利用は350パーセント
・優秀なマネージャは65パーセント
・優秀なスタッフは55パーセント
・プロセスの改善は35パーセント
それぞれ改善を促進する、というものでした。

私が注目したのは、優秀な人材による改善率の高さが、プロセスによる改善率の高さを上回っている、ということでした。
というのは、プロセス改善によってこそが、大幅なチームのパフォーマンスが改善される、と思い込んでいたからです。

個人的に、アジャイル、とりわけスクラムは、チームにおけるプロセス改善を主眼においている、感じていました。
もちろん、プロセス改善を導入することで、個人、個人の能力が向上してゆく、ということもあり得る、とも思っていました。
が、基本的には、スクラムなどの一定のプロセスにしたがっていることで、どのような能力・スキルセットのメンバーが集まっても、チームのパフォーマンスが改善される、と思い込んでいたのです。

いまでも、この考え方が間違っている、とは思っていません。
しかし、Rothman氏のお話を聞くまで、

チームを構成する個人、個人が成長しない限りチームの改善はありえない

という単純な事実を、私は忘れていたのです。

アジャイル、スクラムなどによってソフトウェア開発のプロセス改善を促そうと思ったところで、チームのメンバーがそのプロセスを前向きに受け入れられなかったり、必要な学習プロセスを拒否してしまったりすることで、プロセス改善の道は簡単に途絶してしまうのです。
プロセスの改善は、チームのメンバーを選ばず、ある種、その型にはまることで、チームの能力を向上させる、というものです。
ですが、その過程では、かならずチームメンバーの成長、能力の向上やスキルセットの変更、価値観の変更、が求められます。

少なからず、アジャイルやスクラムによるプロセス改善は、かならず個人の能力の成長を求めるものだと思います。
そして、いかなるものであれ、プロセスの改善に伴う変化へ対応する必要があります。

優秀な人材ほど、成長にたいして前向きで、変化には柔軟に対応できます。
こうした点から、プロセスよりも人の能力改善、および優秀な人材の投入が、チームのパフォーマンスの改善を促す、ということに納得がいきました。

プロセスの改善は優秀な人材を生み出す仕組みとなりえる一方で、優秀な人材により促され発展してゆく、人材にも依存するものなのです。

◆「人を増やせるならどういったメンバーを受け入れたいか」を常に考えておく
これはRothman氏の話を聞いていて、おもわず「はっ」とされられた部分です。
この視点は、

今のチームに必要な要素は何か

言い換えれば、

今のチームの弱点は何か

というものである、と感じたからです。

もちろん、人事権をもつマネージャであれば、Rothman氏の言葉をストレートにとらえてしまえばよいとおもいます。
しかし、私は人事権をもたないので、組織において人材を左右する立場にはありません。

ですので、上記のよう視点を変えて、チームが必要としている要素、弱点を見極めるための「問いかけ」として使ってみたいと思います。

◆毎週、人にあう
お話の途中では、チームに会わない人は「クビ」にする、という考え方も示されました。
しかし、これはあくまでも、チームメンバーとの頻繁なコミュニケーション、およびフィードバックが前提とされています。
Rothman氏自身も、あまりにフィードバックのなさに、「自分が大切されていない」と感じて転職された経験があるそうです。

チームのミーティングで「みんな」で顔を合わせて話し合うことも重要ですが、1対1でのコミュニケーションの重要性を、Rothman氏は特に強調されていました。

確かに、そのフィードバックが良いものであれ、悪いものであれ、ちゃんと事実に基づいたものであれば、ある程度、納得もできますし、自分自身の改善にも活かせます。
また、良いフィードバックはチームメンバー前でも本人にとって良いものになるでしょう。
しかし、悪い点を指摘するものにかんしてはチームメンバーの前で行ってしまうと、フィードバックされた本人にとっては屈辱であり、傷つくものになってしまいます。

加えて、良い点のフィードバックしかせず、悪い点をフィードバックしない、ということも、問題になります。
まったく悪い点をフィードバックしない、ということは、その人が自分の悪い点を改善する機会を奪ってしまいます。
そして、その機会を奪っておきながら、あるとき能力不足などを理由に「クビ」する、という不意打ちを行うことになります。

なによりも、まったくフィードバックを行わない、ということは、その人の行動や存在を無視している、というメッセージを発していることになります。
それは、Rothman氏が転職してしまったように、大変なダメージをメンバーに与えてしまうことがあるのです。

アジャイル、スクラムというと、毎日、朝会、簡単なミーティングをおこなっているため、頻繁にコミュニケーションをとっているように思えます。
それは、おそらく通常の開発チームよりも多くのコミュニケーションを生んでいるのだと思います。
しかし、毎日の朝会だけでは、メンバーとの良好なコミュニケーションを維持するのには足りていないのです。

ちょっとした休憩に、机にいるメンバーに話しかける、というのも良いコミュニケーションのひとつ、だとは思います。
が、実際に仕事中に話しかけられることが、嫌な場合もあります。プログラミングのときや障害対応をしているときなどです。
そうしたときは、良好なコミュニケーションを行うことはできません。
そのようなことになるよりは、正式な話し合いの場をちゃんと用意して、きちんとフィードバックするという習慣を、チームの中で設けるべきだと思います。

◆チームのメンバーを簡単に動かしてはいけない
Rothman氏は、難しいが、長年、同じチームにいても個人の個性を保つことはできると言います。
そして、組織全体がチームのメンバーを動かすことを常態化することによって、プロジェクトごとにチームビルディングが必要になってしまう、コストを強調していました。
ただし、チームとして硬化しないように、チームのスキルセットや人の本性に根ざしている個性が違う人をメンバーとして組み込むことを提案していました。

しかし、私は、この点についてかなり懐疑的です。
というのは、チームが硬化してしまう、ということはなかなか防ぎようがない、ということを、私は感じているからです。
私はすでに稼動して15年近くになるシステムの開発および、保守に携わっています。
長い人では10年を超えて、その開発および保守に携わっています。
こうしたチームにおいては、「暗黙の了解」がチームの支配しがちです。
そして、この「暗黙の了解」こそが、チーム内において知識の属人化を進めたり、チームの硬化をまねく原因になります。

チーム内で「暗黙の了解」が成立する、ということは、むしろ良いことだといっていいはずです。
むしろ、「暗黙の了解」が成り立つからこそ、長い期間、同一のメンバーでチームを構成している意味があります。
ですが、知識が属人化しがちなことは避けられません。
これは、アジャイルかウォーターフォール(以下、WFといいます)にかかわらわず、かなりうまい仕組みづくりを行い、かつ、仕組みがうまく働いているかの絶え間ないチェックが必要になります。

知識が属人化してゆく背景には、「信頼」という暗黙の了解が働きます。
ある人がある業務にはすごく詳しい、ある技術にすごく詳しい、ということがチーム内に認知されてしまうと、暗黙的にその人が詳しい部分について抱え込みがちになってしまいます。
格好よく言うとスペシャリストです。
そして、いったんスペシャリストが認知されると、そのものごとに関しては、「スペシャリストが行えば良い」「自分がそれほど詳しくなくても良い」という雰囲気が生まれがちになります。
そうすると、スペシャリストはさらに「自分が詳しくなければ」という意識が働き、よりいっそう知識を高めてゆきます。
そうすると、チームメンバーは、さらにスペシャリストまかせになり。そうすると…、といったように、徐々にものごとはスペシャリストに集中してゆきます。

こうした状態がさらに進むと、あるものごとを判断するのは、特定のスペシャリストだけになります。
そうなるとチームの決定や行動自体が属人化して行き、ついにはチームの意思決定や判断は硬直し始めます。
というのは、特定のスペシャリストのみが判断を下すための知識を持っており、そのため声も一番大きくなるからです。
また、周囲のメンバーには、スペシャリストの得意分野に切り込んでゆくための知識も自身もなくなってしまっているからです。

たしかに、ペアプログラミングなど、アジャイルには知識の共有をはかるためのプラクティスも存在します。
また、単に知識を集中させたくない、チームの硬化をさせたくない、という理由だけで、人を移動させることは、とても乱暴な解決策だといえます。
もしかしたら、Rothman氏がチームを解散させてはいけない、というのは、知識の属人化やチームの硬化を防ぐという理由だけで、そうしてはいけない、という意味なのかもしれません。
チームのメンバーが固定化しているから、知識の属人化やチームが硬化するのではありません。
チームの硬化を防ぐための適切な仕組みがないために、知識の属人化やチームが硬化するのではないでしょうか。

とはいえ、そのことについての有効な仕組みとはどういったものでしょう。
しかも、人を入れ替えることなく、という方法で。
また、仕組みをつくったとしても、今度は、その仕組みが陳腐化していないか、などを見直す必要も出てくるでしょう。

私は、その仕組みのひとつに、「人が入れ替わるかもしれない」というプレッシャーも、必要なのではないか、と今のところ考えています。
みなさんは、どのようにお考えになるでしょうか。

<技術力のともなった技術者でありたい>
基調講演を聞いた後、思ったことは、

自分は技術者として有効な技術力をチームにもたらしているか

ということでした。

現在の会社に入社して以来、汎用機での開発に携わってきた私は、技術的に現在の技術をキャッチアップできていない、という劣等感があります。
先日まで、ちょっとしたゲームのWebアプリの開発に携わっていましたが、自分に技術力がないのが良くわかりました。
アジャイルであれ、WFであれ、技術者が提供するのは、技術力が基礎となるはずです。
これを無視してはいけない、そう思うようになりました。

私は、ビジネス・マネージャでもなく、さりとて現在の中心的な技術に携わるSEでもありません。
技術者でありながら、技術に疎い立場です。かなり中途半端な、立ち位置いる技術者です。
ですので、技術のわからない人が、プロジェクト・チームに入っていることの戸惑いがわかります。
一方で、技術のわからない人が、プロジェクト・チームにどのような影響を与え、メンバーの精神状態を悪くするかもわかります。
こうした立場の人たちをつなげる役割をにないたい、と考えていました。

が、その役割は、技術力をもっていてもできるのです。
プロジェクトにおける人系のスキルというのは、システム的なスキルをもたない人間のために、あるわけではありません。
なにより、システム開発というプロジェクトにおいて、チームメンバーに認めてもらうためにも、自信をもってチームメンバーにサジェスチョンを行うためも、システム的なスキルにおいて自信のもてる分野が不可欠だと思います。

Rothman氏の話を聞いていて、技術者としての自分の立脚点を確保したい、そのように強くをおもいました。

ちなみに、基調講演の俯瞰的な内容は、以下のURLで簡単にまとめられています。さすがプロ、簡潔ですね。
http://journal.mycom.co.jp/articles/2010/02/01/jasst/index.html

本当は、チュートリアルの感想、さらにLTの感想も書きたかったのですが、力尽きました。
後日、今週中にでも、つづきを書いてみたいと思います。

文頭に書いた結論のフォローもできてないですしね。

◆JaSST公式サイト
http://www.jasst.jp/

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

月を目指して(1)~CSM研修について上司へメールを出してみた~

2月 2, 2010

以下のメールを、認定スクラムマスターの研修申請として、会社へ提出してみました。
もちろん本物のメールとは文章を変えています。

このメールを送ったことで、

・参加の許可はもらえるのか?
・研修費用の補助はもらえるのか?

など、何が起こるのか。
結果はまた後日、お知らせします。

———————————————————————————————————
部長

お疲れさまです。

事前に一度、申請をいたしましたが、受講したい研修があります。
2日にわたる研修ですので、出社扱いで研修を受講したいと考えております。
本日は、その許可をいただきたく、メールをいたしました。

また、この研修は、研修費が20万円と高額です。
そのため、可能な範囲で研修費の金銭的な補助をいただければ、思っております。
もちろん、現在のわが社の状況は理解しているつもりですので、金銭的な補助について無理を申し上げるつもりはありません。

以下、簡単に研修内容とその意義について私見を述べさせていただきます。

名称:認定スクラムマスター(CSM)
開催日: 2010/3/15(月) ~ 2010/3/16(火)
内容:
開発手法の1つスクラムについて、座学で学びます。
研修後は、認定スクラムマスターという資格を得ることができます。
国家資格ではありません。

私見:
スクラムは、ソフトウェアのあらたな開発手法、アジャイル開発の手法の1つとして、注目を集めはじめています。
現在では、マイクロソフトやIBMも開発に、スクラム、およびアジャイル開発を取り入れ始めています。
その流れを汲んでか、日経コンピュータでも、スクラムなどのアジャイル開発について特集が組まれています。(※ PDFをご参照ください。)
(※PDFの内容は、『日経コンピュータ』の連載記事「幸せを呼ぶアジャイル開発」のコピーを貼り付けました。)

私は、昨年からスクラムの勉強会に出席してきました。
添付したPDFにも登場しております、「すくすくスクラム」という勉強会です。
勉強して感じたのは、スクラムが、今後、システム開発において主流の開発手法の1つになる、ということです。
そして、わが社でもスクラムをはじめとしたアジャイル開発の知識、技術をもたないことは、非常に大きなリスクになる、ということを感じました。

現在、日本において、アジャイル開発およびスクラムはほとんど導入事例がありません。
しかし、世界においては若干、状況が異なっています。
たとえば、世界88カ国、2570人から回答を募ったアンケートでは、約20~25%の組織がアジャイル開発を導入した経験がある、との調査結果があります。(※ PDFをご参照ください。)

また、別の米会社の調査では、1300人のディベロッパーからの回答で、約45%が何らかのアジャイル開発を導入している、という結果もあります。
(http://www.eweek.com/c/a/Application-Development/Report-Agile-Development-Hitting-the-Mainstream-539452/)
両方の調査において、アジャイル開発の中でもとくにスクラムの採用率は1番高く、現実的な開発手法として受け入れられているようです。

また、スクラムという開発手法は、日本的な組織にもなじみやすい開発手法だとおもっています。
というのはスクラムが、富士ゼロックスやHONDA、日本電気やブラザー工業など数々の日本企業が採用していた開発プロジェクトが元になり、アメリカで誕生した手法だからです。

いままで、設計手法や開発手法、開発言語、果ては経営管理の手法なども、新たなものが出現するたび、一過性のブームとなり消滅しています。
そうした点から、スクラムという開発手法も、単なるブームで終わる可能性はあります。
また現在、わが社を取り巻く環境は非常に厳しく、新たな試みをする余裕はないのかもしれません。
しかし、変化についてゆけず、取り残されることも、わが社が恐れるべきことだと思っています。

たしかに、現在のわが社がおかれた状況は、部長の言葉をお借りすれば経営の状況は「守り」にあるのだと思っています。
ただ、「守り」の時期こそ、変化に備え、「攻め」に転じるための準備をする時期であると考えております。
そして、スクラムなどのアジャイル開発の手法を学ぶことが、変化に備え、「攻め」に転じるための準備になると、私は考えております。

もちろん学ぶだけでは、何も意味はありません。
ですので、たとえば、学んだ知識を活かして、社内システムの開発に試験的に導入するなど、知識を力に変えることもできると考えております。

今後、わが社が「攻め」の時期を向かえた際、なにか推進力なるものが必要なはずです。
そして、推進力となるものが、スクラムの手法の知識と経験をもつエンジニアだと思っています。

なによりも、変化に取り残されるリスクを避ける必要があります。
世界におけるアジャイル開発の現状を見ると、スクラムを含めて、アジャイル開発について無知であることは、非常に高いリスクであると思っています。
こうした点からも、スクラムを学ぶ意義はあると考えております。

以上のように、スクラムを学び、知識を得ておくことは、今後、わが社の利益に結びつくものと考えております。
ぜひ、受講の許可がいただけますよう、ご一考をお願いいたします。
また、だめもとですが、金銭的な補助についても、よろしくお願いいたします。

長々と失礼いたしました。

———————————————————————————————————
さて、どうなるでしょうか?

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