2010年1月28日木曜日

アジャイル・マインド

「アジャイルを実践している人は,自発的にアジャイルの布教活動を行なう人が多い」

-XPJUG関西代表 細谷氏 談-

経験的に,アジャイル開発実践者は自ら率先して様々な活動を展開する。

ある人は本を書き,ある人はセミナーを開き,ある人はコミュニティーを立ち上げ,ある人は会社でアジャイルを広めようと活動し,ある人は独立してアジャイル開発を実践する会社を作る。


この様に,自発的行動を起こす人が,アジャイル開発実践者の中に多く見られることから,「アジャイル開発実践者によく見られる自発的行動へと駆り立てる心(スピリット)」の事を「アジャイル・マインド」と名付けた。

アジャイル・マインドを持つ開発者が増えれば業界が良くなると考えている。

今年開催される「XP祭り関西2010」では,「アジャイル・マインドの育て方」をキーワードにしたセッションが多数行われる。

このイベントの参加者の中からアジャイル・マインドに目覚める人が一人でも多く現れる事を願わずにはいられない。

2010年1月26日火曜日

「アジャイルって良いのですか?」

「マクドナルドのテキサスバーガーって美味しいのですか?」と同じレベルの質問だと思う。

マスコミやネットで騒がれているが,美味しいかどうかは本人が食べてみなければ判らない。食べてみて美味しいと感じる人も居れば美味しくないと感じる人も居る。

ソフトウェアの開発手法にしても,合う・合わないがあるのではないだろうか。問題は,情報量の少なさだと思う。

専門学校や大学で,アジャイルについて十分教育がなされていないから,認知度が低いのである。

もっと大きな問題は,ソフトウェア開発者が儲らないという点。儲らない業種に学生は集まらないから,授業で取り上げる価値が低いのは当然である。

老体に鞭打って勉強会の場だけでアジャイルを伝えるのは,間違いだと思う。

2010年1月23日土曜日

Agile2.0について思うこと。

「アジャイル」という言葉に、どの様な感想をお持ちだろうか。

10/1/14に、「AGILE2.0 〜 アジャイルなチームで何を提供する?」というタイトルのイベンが開催された。
http://kokucheese.com/event/index/1151/

ちょっと気になって「アジャル2.0」でググッてみると、実は2006年にも「アジャイル2.0」という言葉が登場する。

■アジャイル2.0ホームコミュニティ
■アジャイルな世界
■Agile, Orthodoxy and a Message From God

だからどうという訳ではないが。



最近、某IT系出版業界の方とお話した際、「最近、”アジャイル”というキーワードの本は、まったく売れなくなった」と聞いた。個人的には最近、アジャイル関係の書籍が多数出版され、読み手も飽きたのではないかと推測している。

話を戻そう。

私は、「アジャイル2.0」という言葉に大きな違和感を抱いている。
アジャイルを簡潔に表現すると「ソフトウェアを素早くしっかり作りましょう」という基本的理念の呼び名であり、この基本的理念は何も変わっていない(はずである)。

「ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法郡の総称である。」
-ウィキペディアからの引用-


「アジャイル開発手法」=「イテレーション型開発手法」と言われたり書かれたりしているが、実はそうではない。「ソフトウェアを素早くしっかり作る」ことが本質であり、「イテレーション型開発手法」はその実現手段の一つに過ぎない。アジャイル2.0で語られている多くは、実現方法やソフトウェアの品質保証、開発プロセスなど多岐に渡っているが、結局実現手段に関する話題が主体となってる。

「アジャイル開発」の本質は「ソフトウェアを素早くしっかり作りましょう」であり、「イテレーション開発」、「eXtream Programmming」、「スクラム」を実施することではない。この点を見誤ってしまうと、2000年に起こった「アジャイル開発手法の誤解によるプロジェクトの失敗」の再来が起きる。

2000年に「アジャイル開発手法」が日本に上陸した際、アジャイルの誤解による悲劇が起こったと聞く。下記の内容を本気で信じて開発しても、失敗することは明らかである。
・ドキュメントは書かなくても良い
・設計よりもプログラミングを重視する
etc,ect・・・・・・
「アジャイル2.0」、「TiDD」、「スクラム」など、それ単体で確かに価値のある方法であると言えるが、万能な方法ではないことを理解する必要がある。「それは本当に自分にとって有効なのか?」と、常に疑ってかかった方が良い。そうしなければ、アジャイルの誤解によるプロジェクトの失敗を招く結果となる。

他人の考えを鵜呑みするのは簡単だが、それでは失敗してしまう。だから、他人の意見が自分にとって有効か無効か考えて判断することが必要であると言える。

2010年1月16日土曜日

コミュニティのスタッフから頂いた気付き

先日、XPJUG関西のスタッフミーティングが行われ、その場に居た参加して間もないスタッフの方からこんな一言を頂いた。

「会社の人達は、なぜコミュニティに参加しないのだろうか。」

理由を詳しく聞いた所、「自宅で使用しているツールを会社で使わない。もっと自分のやっている事を積極的にアピールすれば良いのに」との事であった。

彼に対するファーストインプレッションは、どちらかといえば消極的という印象であった。
その彼が、コミュニティへの参加の素晴らしさに気付き、発言内容が大きく変化した。
モチベーションの高いメンバーに囲まれると、人の考え方や行動を大きく変化させる効果があることに、改めて気付かされた。

2010年1月13日水曜日

IT系技術者の人材不足について

昨晩、コミュニティ繋がりで知り合った方との呑みに行った。

その席上で、「本当に欲しいと望むIT技術者に、なかなかめぐり合えない」という話題が挙がった。
自分が若かった頃、プログラムの知識が一切なまま仕事を任され、非常に苦労した。その結果、ある程度スキルが身についた。そんな自分が言うのもおかしいが、当時の自分の様な知識の無い人と一緒に仕事したいと思えない
大学卒業しても、プログラムの知識なんかほとんど持っていない新人が殆どなのが現状。だから、会社が費用をだして教育させる必要がある。大手のソフトウェアハウスの場合、入社から数ヶ月間言語研修が行われ、そこでスキルを身につけるのが一般的だと思う。
小さな会社では、教育費が確保できないため、自己啓発(=自宅で勉強)に大きく依存する所もある。
中には社員の能力以上の肩書きを与えて仕事させ、現場で成長ささせる考えの企業もある。

様々な業界において、「免許」という制度が存在する。たとえば、飲食業界には「調理師免許」、医療業界には「医師免許」、タクシー業界には「車の免許証」など。しかし、ソフトウェア業界にはこの「免許」が事実上存在しない。

先に述べた通り、ソフトウェア技術者のスキルは、それぞれ歩んできた道のりにより異なるが、それを定量的に示す物差しが存在しない。スキルを知るためには、実際に一緒に働いてその働きぶりを見るしか方法は無いのが現状である。

プログラムも知らないままソフトハウスに就職し、能力以上の肩書きを与えられ社外へ出て仕事をし、定量的に測定不可能ながらも少しづつスキルを身につけ成長するのが、一般的なIT技術者の成長過程なのではないだろうか。

定量的に測定不可能なスキルと、スキル以上の肩書きとを見比べて人材を評価しようとしても、真に望む人材を見つけることは難しい。

いっそのこと、大学生よりIT系専門学校生を採用した方が期待に答える人材を見つけられるのではないかという意見で合意した。

2010年1月10日日曜日

感動するソフトウェアはどうやって作るのか?

TVで木村カエラさんが「butterfly」という曲を歌っている映像が流れているのを見聞きして、その曲の美しさに感銘を受けた。

その時、ふと思った。

「感動するソフトウェアを作ることができるのか?」

-◆-◆-◆-◆-◆-◆-◆-◆-◆-◆-◆ー

人は、「素晴らしい」と感じるものに感動する。

人は、五つの感覚器官「五感」を使って受け取った刺激の良し悪しを判断する。

例えば、車の場合、車体の形状(視覚)や、エンジン音(聴覚)、高級感(視覚、触覚)に感動する。
料理の場合、匂い(嗅覚)、見た目(視覚)、味(味覚)、舌触り(触覚)に感動する。
パソコンの場合、色や形(視覚)、キーボードの感触(聴覚、触覚)、処理速度(視覚)に感動する。

これらを刺激するソフトウェアとしてすぐに思いつくのが「ゲーム」である。
確かに、ゲームは人の五感を直接揺さぶり、感動させる力を持っている。
それでは、ゲーム以外、人を感動させる事はできないのだろうか。


-◆-◆-◆-◆-◆-◆-◆-◆-◆-◆-◆ー


ふと思いついたのが、上記の五感以外で感じる喜びに「知的欲求の満足」と「達成感」がある。
人は、知的欲求が満たされた時や、何かを達成した時、喜びを感じる。

ソフトウェアは、これらの喜びを得ることが得意なのではないか。
創造的なグラフィックや動画製作、或いは、Excelによる表計算シートの製作にも「知的欲求の満足」や「達成感」を味わうことができる。

これらの得意分野を駆使し、更に人の五感に訴えるようなソフトウェアを使うと、人を感動させることができるのではないだろうか。

2010年1月6日水曜日

誰のために開発するのか。

アジャイルは手段であって目的ではない。

しかし,『目的の達成』というゴールへの道のりは楽しい方が良い。

だから僕はアジャイルの考え方が好きだし,実践したいと願っている。

たとえ成功できなくても,失敗という経験から何かを学び,成長すれば良いのではないか。

『成功』より『成長』するために,アジャイルを実践したい。

そして,大きな『成功』を得たい。

2010年1月2日土曜日

「アジャイルしてます」とはどういう状態か?

「アジャイルしてます」と言う時,何を持って「アジャイル」と判断するのだろうか。


アジャイルという言葉から連想するものが,アジャイルに関する経験や知識によって異なるのではないだろうか。


一方,ウォーターフォールという言葉は,広く世間に浸透しており,大筋で類似した回答が得られる。


自分自信,アジャイルとは「アジャイル開発宣言」の価値を重視する手法としか理解しておらず,実感が伴っていない。


ちなみにXPとアジャイルは類似しているが明確に異なるものである。「アジャイル開発手法」とは,アジャイル開発を抽象的に定義したものであり,「XP」とは高品質なソフトウェアを効率的に開発する具体的な手法である。つまり,下記の関係が成立つ。

アジャイル開発>XP

「イテレーション開発してます」「ペアプロしてます」「テスト駆動開発してます」といった状況を総称して「アジャイルしてます」というのは,本来のアジャイル開発の趣旨から反するのではないだろうか。


しかし,ウォーターフォールのように,なにを持って「アジャイル開発」とするか明確な定義がないため,判断が難しいのは確かである。


アジャイル開発の知識体系をまとめると,法則や規則が見えてくるかもしれない。