Archive for 2010年11月

「早く行きたいなら、一人で行きなさい。遠くへ行きたいなら、みんなで行きなさい」という言葉を聞いても、最近は「みんなと、早く、遠くまで行く」ことを考えるようになった

11月 24, 2010

「早く行きたいなら、一人で行きなさい。遠くへ行きたいなら、みんなで行きなさい」
という言葉あります。
目標を達成するにおいて、示唆に富んだ言葉だと思います。

出典はわからないのですが、どうやらアフリカの諺らしいです。
日本でも、偉い人や有名な人も紹介されているようなので、お聞きなったことがある方も多いかもしれません。

諺のいう「早く行く」というのは、他人と比べて、といった相対的な速度のことを指していないと私は思っています。
「自分にとって早い速度」で行きたいなら、ひとりで行きなさい、という意味で私はこの言葉を捉えています。
そのため、ひとりで事を起こせば、AさんやBさんと比べて、早く目標に到達する、というわけではない、と考えています。

私が考える速度以上で目標に近づくことを、早い、といって良いのだと考えています。
ひとりでことを起こせば、自分でその速度が調整でき、ストレスなく、自分にとっては十分に早い(と感じる)速度で目標が達成できる、ということだと思うのです。

一方、遠くまで行く、というのは、当初の目標よりも更に先、おそらくは考えもしなかった目標へ到達することだと理解しています。
そのため、自分と一緒に目標を目指してくれる人たちがいたほうが良い、という考え方です。

自分と行動を共にしてくれる仲間は、自分にないものをたくさん持っています。
ひとりでは得られないものをたくさんあたえてくれます。
知識や情報をもっていたり、悩んでいれば相談にのってもらえたり、間違いを指摘してもらったり、一緒にことを起こす仲間はたくさんのものを与えてくれるのです。

仲間と助け合いながら少しずつ進んでゆけば、「遠くまで」の言葉のとおり大きな目標を達成できそうな気がします。
私がはじめて会社内に社内勉強会の通知をだしたときは、たくさんの人たちに相談にのってもらい、知恵や勇気をもらいました。

だからこそ、私が、初めてこの言葉を聞いたとき、「無理せずゆっくりとやりなさい」という意味でこの言葉を捉えていました。
なぜなら、私は遠くへ行きたい、と思っていたからです。
もちろん、今も思っていますが。

最近は、会社のおかしいなと感じる部分を変えたい、と願うことが多くなりました。
しかし、簡単には行きません。

自分も含めて、環境を変えるというのはとてつもなく大きなストレスを伴います。
また、会社という単位ではそもそも各社員が抱えている問題も、それにたいする対処方法も違います。
自ずと、組織全体へ影響を及ぼすには、多くの人たちへ影響を与えなければならず、そのために多くの時間を使うことになります。

何かを「私が思っているように」変えることは、多くの人たちに納得して、仕事や責任を引き受けてもらう必要があります。
そのためには、多くの人に納得してもらうまで、私は待たなければいけません。

どのようなものごとに関しても、納得して行動するには、その本人の意志が不可欠で、私が多くの説明を繰り返してもその速度を早めることはできないと思うからです。

説明をしなければ、忘れ去られるだけなので、説明し続けることは大切な事ではありますが。

だからこそ、私は諺の意味を「遠くに行くために、周囲の人たちの速度にあわせて行きなさい」と捉えていたのです。
人も会社も急激な変化はなかなか起こるものではありませんから、周囲の人たちの理解と協力を得られるような努力をするべきなんだろう、と考えていました。

それは上述したように、「遠くまで行きたい」と考えていたからです。
ですが、最近は異なった意味でこの言葉を解釈するようになりました。
すなわち、

「おなじ速度で進みたいと思う人たちと遠くまで行きなさい」

という意味に解釈するようになりました。
ようするに、ひとり孤独に早く行くでもなく、周囲の人たちにあわせた速度で行くのでもなく、自分の速度で「早く、遠くまでいける」ように行動ばいいじゃないか、と考えるようになったのです。
自分がストレスを感じない速度、もしくは、自分が考えている以上に早くものごとが進むという焦りやストレスを感じる速度。
その速度を保ちながら、仲間と助け合いながら遠くまで行く。
このことを両立することは可能です。

周囲の人たちの速度に配慮する、あわせる、といったことは必要なのかもしれません。
しかし、周囲の人たちへの配慮をいいわけに、なにもしない、という選択をしてしまうこともあるはずです。
ですから、「どのように自分の速度を落とさないで行動するか」ということを考える必要があるのです。

そして、目標までの孤独な旅を寂しいと思うなら、目標を超えて遠くまで行きたいと思うなら、ぜひ、自分とおなじかそれ以上の速度で進んでいる仲間を見つけてみましょう。

勉強会やセミナーなどに行けば、さらに多くの人たちと出会えると思います。
たとえ、勉強会など行かずとも、会社のなかにも、自分とおなじ速度で、おなじ目標を持って進んでくれる人たちは結構いるものです。

「みんなで早く遠くまで行く」

同じ速度で進んでくれる仲間が見つかったら、それはきっと可能なことだと、最近は考えるようになりました。

アジャイルとScrumは実践にこそ価値がある、と当たり前のことを反省した@DevLOVE

11月 20, 2010

先日、2010/11/18(木)に、DevLOVEの「DEVLOVE AGILE DEVELOPMENT IN ACTION」へ参加してきました。
そのタイトルに違わずアジャイル開発を実践されている、藤原大さん、永瀬美穂さんのお二人のお話を聞けました。

実践している方たちのお話を聞いて、「アジャイルもScrumもやはり実践だな」と反省されられました。

私がアジャイルに触れたのは2年ほどまえで、Scrumというアジャイル開発の手法を学ぶことから始まりました。
Scrumには、ソフトウェア開発の現実に対応するためのシンプルなフレームワークがあることに、私は魅力を感じていました。

アジャイル開発を実践しないままに認定スクラムマスター研修を受けるなど座学により知識を増やすなかで、Scrumの根本、源流となっているアジャイルという概念にだんだんと惹かれてゆきました。
そして、アジャイルへ惹かれていった結果、私のなかには、アジャイルへの称賛よりも、現状への否定的な感情がつくりあげられていきました。

初期にすべてを計画して一括契約を行うことにより、顧客と開発の双方が、スコープ、スケジュール、コストにがんじがらめになっている現実。

顧客とエンジニアががんじがらめになったために、スコープもスケジュールも変えられないまま、非現実的だと思いつつもプロジェクトを前進せざるを得ない現実。

がんじがらめのプロジェクトにおいて、長時間労働を続ける忍耐力と契約を守ろうとする責任感を持った顧客とエンジニアが消費されるという現実。

契約に縛られ、価値のなくなった要件を変えようとしてもできないという顧客の現実。

システムを使用する顧客が近くにいないことで、本当のシステムの価値を知ることのないまま内向きに仕事をせざるを得ないエンジニアの現実。

その結果、使わない機能が生み出されお金を無駄にするスポンサーの現実。

ソフトウェア開発の現実には、おかしな部分がたくさんあるのです。
何よりも現実のおかしな部分は、多くの人々がおかしいと思いながらも、おかしな部分を変えることができず、同じような失敗や苦労を負いつづけていることです。

セミナーやコミュニティの勉強会に参加したり本を読んだり座学に励んだ結果、頭の中で現実のおかしな部分を否定し、冷ややかに見る日々を過ごしていました。

そうして、具体的な行動を起こさずに頭のなかだけで現実を否定し続ける日々を過ごし、ついには自分の情けなさに気付かされました。
「変化を包容し」「あらゆる状況において最善をつくす」こと標榜するアジャイルを志しながら、自分では何一つ事をなしていないという現実。

これこそが、まず最初に改められるべき現実のおかしな部分であると気付かされたのです。

この気づきをもとに、社内勉強会を開催したり、コミュニティのスタッフをしたり、実際のアジャイル開発手法を用いたプロジェクトに参加するのかなで、さらに気づきを得ることになりました。
その気づきとは、私のやりたいことは、
アジャイル開発ではなく、顧客を含めたプロジェクトチームのアジリティをあげること
なのだ、ということです。

では、アジリティとはなにか。
わたしは、英単語を和訳した意味のまま「俊敏さ」と捉えています。

プロジェクトの変化に対応する俊敏さ。

経営の変化に対応する俊敏さ。

外部環境の変化に対応する俊敏さ。

なによりも、俊敏さを維持するために、可能なかぎり不確定な要素をなくし、変化させないように働きまわる俊敏さ。

状況の変化に対応するアジリティをプロジェクトチームが持つことこそが、おかしいと思う現実を少しでもよくするための重要な要素だと思い至ったのです。

アジャイル開発でとりあげられる朝会も、プロダクトバックログも、ペアプログラミングも、CI(継続的統合)も、目的はプロジェクトにとりくむチームのアジリティをあげることなのです。

重要なことは、アジャイル開発のプラクティスを取り入れるだけでは、短納期、低コストのプロジェクトにより、高品質なソフトウェアに直接はつながらない、ということです。
それは、アイジャル開発のプラクティスをとりれたことにより、プロジェクトチームがアジリティを身につけた結果なのです。

アジャイル開発のプラクティスは、短納期、低コストのプロジェクトにより、高品質なソフトウェアを生み出すアジリティの高いチームを生み出すための知恵、方法に過ぎないのです。

なぜなら、多くのプラクティスを取り入れたとしても、そのプラクティスを実行しつづける技術力や知識がなければ、プロジェクトチームのアジリティを上げることはできないからです。

そして、アジャイル開発をやり通すためには多くの、そして高い水準の技術や知識が必要とされます。
それはアジャイル開発のみならずプロジェクトに関わるエンジニアも顧客ももつべきものです。
しかし、現実はアイジャル開発に取り組めるような多くの、そして高水準の知識や技術を持つエンジニアは多くありません。

アイジャルは、そうした現実をも認め、すこしずつ理想なプロジェクトチームへ向かうための知恵と手法を提示しています。

プロジェクトチームは、チームのメンバーの成長をも視野に入れたアジャイル開発の要素を活かしながらアジリティを高めてゆくことで、最終的に、短納期、低コストのプロジェクトにより、高品質なソフトウェアを生み出すに至るのです。

ここにあるものこそ、本来のプロフェッショナリズムをそなえたエンジニアと顧客によるソフトウェア開発の姿なのだ、と思い至ったのです。

だからこそ、実践者のお二人の話には心が揺さぶられました。
私が頭の中でだけ思い描いていた、現状のおかしい部分を否定し、「すこしでも現場をよくしよう」「ソフトウェア開発の未来をよくしよう」という思いを、アジャイル開発をつうじて実践されているからです。

アジャイル開発を導入した結果として、うまくいったことも、うまくいかなかったこともお二人は話してくれました。

それが現実でしょう。

アジャイル開発を行えばソフトウェア開発の問題がすべて解決できわけではないからです。

アジャイル開発には、現実の過ちを発見するための観察力、観察によって発見された過ちを認める勇気、そして過ちを修正しチームを前進させるための知恵や方法を提供してくれるだけです。

お二人のお話は、現実のおかしな部分をと認めたうえで、アジャイル開発の知恵と方法を利用して、おかしな部分を良くしようと行動した現実なのです。

プロジェクトチームがアジャイル開発が提供する知恵や手法を使い、失敗を失敗と認め、プロジェクトチームが抱える問題を解決する。
少しでも現状を良くして行こうと考える積極的な思考に基づいて、俊敏に変化に富むプロジェクトに対応する。

このようなことを現実におこなったプロジェクトのお話は、私のような実践経験に乏しい人間には何よりも響きました。

座学ばかりで、実践に乏しい自分を恥じる一方で、「なぜ、私がScrumを学びアジャイル開発をやりたい」と考えたのか。

自分が学び始めたときの思いを思い出させてくれた勉強会であると同時に、
Scrumを学び、アジャイルを標榜するのであれば、

「アジャイル開発をできない」という現実に俊敏に対応してみせろ

と私の心に熱を注いでくれた講演でした。

行列の出来る勉強会に参加してきた@Hudson勉強会

11月 14, 2010

2010/11/12にHudson勉強会に参加してきました。

Hudsonとは、日本人の@kohsukekawaさんが中心となって作成されたプログラムの自動ビルドツールです。
@kohsukekawaさんがお話されるとあってか、参加人数が200名を越え、受付の入り口に行列ができるほどの活況をていしていました。

講演内容のバランスも素晴らしかったです。
・Hudson初心者へ向けたHudsonの利便性やチュートリアル的なお話
・Hudsonの方向性や哲学のお話
・実際にHudsonを使って仕事している方たちの実践的なお話
と非常に良い流れでプログラムが組み立てられているなぁ、と感心してしまいました。

私がHudsonというツールを知ったのは、1年ぐらい前でした。
プログラムを自動ビルドしてくれるだけでなく、テストコードを書いておけばそれも自動実行してくれる、という便利さを目の当たりにしてとても驚いたのを覚えています。

その当時から汎用機で開発している私の環境では、テストの自動実行はもとよりプログログラム自動ビルドすらできず、Hudsonを利用している人たちを羨ましく思ったものです。

勉強会に出席して、Hudsonは作成者たちの哲学が感じられる良いツールだな、と改めて感じました。
@kohsukekawaさんは、Hudsonという名前にした理由を、
「英国の執事のような存在にしたかったから」
とおっしゃっていました。

開発中の私たちが煩わしいと思う作業を肩代わりする一方で、人間味のある存在にしたい、という理由があったそうです。

ちなみに「セバスチャン」という名前でも良かったそうです。笑

Hudsonが肩代わりしてくれるのは、私たち人間が苦手とする作業です。
たとえば、
・開発中にビルドが壊れていないか確認する
・テストの実行環境を整える
・修正したプログラムの機能がデグレーションしていないか確認する
・テスト環境などへのデプロイ
という作業です。

頻繁に実行したい(もしくは、実行する必要がある)ものでありながら、手動で行うと多くの時間を必要とする作業です。
正確さが要求される一方で、繰り返しが必要であるという、人間が苦手とする作業です。
だからこそ、人手を介して行う作業ではありません。

Hudsonはこうした作業を、簡単な起動方法、GUIを通じた簡単な設定を通して肩代わりしてくれるのです。
そして、我々から依頼を受けた作業を健気に繰り返し、誤りなく行ってくれるのです。
まさに、主人からの命をうけた英国の執事のような働きぶりです。

苦手で、煩わしい作業から解放された開発者たちは、さらに創造的な作業に集中できるようになります。
これこそが、Hudsonを使用することの最大の利益です。

個人的な、Hudsonは、自動ビルドツールとしてデファクトになりつつあると感じています。
金曜日の夜に200名以上の集めるツールなのです。
その要因はまさにHudsonが、作成者たちの哲学を体現したツールだからだと、勉強会を通じて感じました。

最後に、実践的な知恵を記しておきたいと思います。
・ダッシュボードを使いこなして必要な情報を閲覧できる
・綺麗なテストの実行環境が自動で整えられるようにしておく
・テストケースのメンテナンスが必要なことを念頭にテストケースを構成はよく考える
・ビルド履歴の上限を設定してビルド履歴でサーバーの要領を圧迫しないようにする

なお、日本Hudsonユーザー会が立ち上げられるとのことです。
http://build-shokunin.org/
URLが素敵ですね。

この会に通じてさらにHudsonと自動ビルドという分野が盛り上がって行きそうな気配です。

◆勉強会情報
・Hudson勉強会
twitter-hashtag: #hudsonstudy
・日本Hudsonユーザー会
http://build-shokunin.org/

Kindleをいじりながら電子書籍の未来を考えた

11月 8, 2010

最近、Kindleを使い始めたことで、電子書籍とそれにまつわるビジネスについて強い興味をもつようになりました。
Kindleを使用して感じたこと、それは電子書籍においても、集中できる個人的な空間を用意できるのだ、ということです。
この実感は衝撃的でした。

デジタル、というと個人的な空間であっても集中に適した環境を提供してくれるものではない、というイメージが私にはありました。
その代表がパソコン、PCです。
現代の仕事ではPCを使うことが大半です。
ですが、PCには集中力を維持することを阻害する要因があります。
それは、「なんでもできる」ということです。

不得意、苦手、やりたいくない作業をPCでやろうとすると、その作業に集中できません。
せざるを得ない作業を差し置いて、不要なメールチェックをしたり、ネットサーフィンをしたりしがちです。
1つのことしかできない、というのであれば、仕方なく作業に着手せざるを得ません。
そして、せざるを得ない作業を続けているうちに、もしかしたら集中して取り組めるかもしれません。
しかし、他にもたくさんのことができると、どうしても他の楽な作業をしてしまいがちです。

読書をしている最中に、メールの着信を知らせるポップアップができたり、twitterができたり、という環境。
読書が好きな人が望む環境ではありません。
電子書籍に興味がありながら、iPadに手を出さなかった理由の1つはこうしたPC的な性格があるプロダクトだからです。

iPadは集中した読書空間を提供しない、と直感的に思ってしまったのです。
だからこそ、Kindleに触れたときは衝撃でした。
Kindleは、読書に無関係なあらゆる機能を排除して、集中できる空間を提供しているのです。
加えて、「読みたい」と思ったらすぐに手に入る利便性、「たくさんの本を持ち歩ける」という携帯性、「本を安く買いたい」という経済性、を読者に提供しているのです。

ただ、一点、私が慣れを必要としたことがあります。
それは、ページの切り替わりです。
Kindleはページをパラパラめくれるような連続性がありません。
ページを切り替えようとすると、表示中ページが消えて、次のページが浮かんでくるのです。

その間、一瞬の間がちょっと気持ち悪く、集中力がそがれてしまうのです。
とはいえ、PCやスマートフォンでWebページを閲覧するように、ロード中に固まってしまうことはありません。
慣れてしまえるレベルのものです。

しかし、Kindleが電子書籍とともにビジネスとして成功するか、というのは未知数です。
懸念点の1つは、デバイスの圧倒的な価格の高さ、です。
現在は、日本語に非対応である、という圧倒的なマイナス要素は今後なくなるにしても、1万円以上も支払うデバイスは、読者にとっては大きな先行投資です。

「読んでみたい!」という本がAmazonで販売されており、紙の本は800円、電子書籍は400円で売っているとします。
明らかに電子書籍を買うほうが値段は安いのですが、Kindleをもっていない読者はどちらを購入するでしょうか。

Kindleが仮に1万円であるとして、価格分を取り戻すには、800円から400円に割引された本を25冊、1万円分も買う必要があるのです。

その紙の本だけ読みたい、と思っている読者は決してKindleを購入し、電子書籍を買うようなことはしないでしょう。
もしも、Kindleを購入するとしたら、やはりその本以外にもたくさんの本を読み、Kindleを購入した元を取れる人なのです。

この点から、現在のところKindleを購入する人は、自分の時間を読書に割く、という人にしか手を伸ばさない商品だと思われます。

もう一つは、現在のAmazonユーザーおよび将来の電子書籍ユーザーがそもそも、集中した読書空間を読者が求めるのか、という点です。
読書好きの人たちが集中できる読書空間を求めると仮定してKindleは作れています。(というように私は感じています。)
しかし、それらの人が読む本というのは、どれだけ電子書籍の対象となるのでしょうか。

現在のところ、消費されている電子書籍は、
・日本では、漫画および女性向けのBL(ボーイズ・ラブ)小説
・アメリカでは、SF小説および恋愛小説
だといわれます。

これらの作品はどちらかというと、集中した空間で読む、というジャンルではないと思うのです。
むしろ、ゲームやネットサーフィンと同列に並び、スキマ時間を使って読まれるジャンルではないでしょうか。
そして、それは静かな個人的な空間を欲するジャンルでないと思うのです。

もしも、スキマ時間をつかって読まれるものであるとするならば、本しか読めないKindleよりも、いろいろできるiPadのような、PC的なデバイスが好まれそうです。
たとえば、iPadでの作業が終わってちょっとした時間がある。
その時間を使って、ダウンロードしてある電子書籍を読む、というような状況が考えらえそうです。

現在、Amazonで本を買い求めているユーザーは本当に、集中できる読書空間を求めているのでしょうか。
集中できる読書空間を求めている読者は、俗に活字中毒と言われる人たちではないでしょうか。
また、中毒とはいわれずとも、時間をつくって本を読む人たち、読書を趣味としている人たちです。
そして、Kindleはそのような人たちをターゲットとしたデバイスであるといえます。

しかし、現在のところ消費されているコンテンツは、そうした人たちが好むジャンルではなく、大量消費されてゆく性質が強いジャンルであるような気がします。
そのため、現在、Kindleを通じて購入している作品が、iPadのようなPC的なデバイスでも簡単に購入できるようになったら、もしかしたら、Kindleを所有するひとは、いなくなるかもしれません。

電子書籍が、ゲームやネットサーフィンとして消費されるものであるならば、読者はKindleよりもいろいろなことができるPC的なデバイスに手を出すのではないでしょうか。

読書好きと自認する私としては、現在のところ、Kindleが提供してくれる読書に集中できる空間に価値を感じています。
しかし、電子書籍が出版形態の一部となり、消費されてゆくなかで、電子書籍をもとめる人たちが、本当に集中できる読書空間を求めるのか、というのことは定かではありません。

現在、Amazonは電子書籍という分野では、圧倒的な勝ち組となる企業と考えられています。
しかし、本当にそうなるのか。
電子書籍を購入し、読むプラットフォームとしてKindleは読者に支持され続けるのか。
こうした点は、まだ未知数なのではないか、と思います。

そのようなことを考えると、電子書籍は非常に面白いビジネスになると、感じるのです。