Pages

2017年1月14日土曜日

Regional Scrum Gathering Tokyo 2017に参加しました


2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。

世界中の開発チームが今どんな課題に取り組んでいるのかに興味があって、今回で2回目の参加となります。




2日間で70名ほどの方と新しく出会いました、以前から会いたかった開発者や技術書の著者、アジャイルコーチとも様々なお話をすることができました。

セッションに参加していると、現在企業やスタートアップの開発現場で起きている課題が生々しく伝わってくるとともにソフトウェア開発がいかに難しいかが分かります。しかしこのイベントに参加された皆さんはそういったことを含めてとても"真面目に楽しく"乗り越えようとしています。

ソフトウェア開発の改善をしようと挑戦している人たちが年始に集まっていろいろ話して、また一年それぞれの現場に戻って頑張れること、これがこのイベントの最大の魅力だと思います。

実行委員の皆様、ご参加の皆様、スピーカーの皆様ありがとうございました。
また来年お会いしたいと思います。

【発表資料公開】スケールアップする組織におけるLeSS実践と継続的改善手法

10名規模から50名規模へスケールアップする組織において私達のチームがアジャイル、スクラムのプラクティスを試みユーザーにより多くの価値を届けるために行ったこと、大切にしてきたことを紹介しています。
内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。

2016年8月15日月曜日

ソーシャルチェンジ

どんな状況でも改善できる。

どんなときでも「あなた」から改善をはじめられる。

どんなときでも「今日」から改善をはじめられる。

人間らしいモノづくりに向かって、少しずつ、持続的に、あなた自身が。

ケント・ベックのこの言葉が、とても好きです。

2014年4月26日土曜日

技術者とは何か / プロフェッショナル・ソフトウェアエンジニアの倫理

こんにちは、@wd0214です。

GWはいかがお過ごしでしょうか。サラリーマンの方の中には11連休の人もいるとか。海外旅行とかでしょうか。筆者はさらなるリリースに向け、連休には無縁で連日仕事の予定です。
5 deploy/ 1day くらいがちょうどいいですね。

さて、本日は、プロフェッショナルな技術者とはなにかということについて書きます。



技術者とは


技術者をウィキペディアで見ますと

「主に工学(エンジニアリング)分野の専門的な技術を持った実践者のこと。」

とあります。しかし筆者はこのウィキペディアの解説では不十分と考えています。
(*2014年の現代においてコントローラブルなウェブ上の知識だけで物事を理解しようとすることは非常に危険です、適切なキュレーションが必要でしょう)

紙の辞書を引くとまた違った回答があります。

技術者とは、

「科学上の専門的な技術を持ち、それを役立たせることを職業とする人。技術家。」

ソフトウェアエンジニアも技術者といえるでしょう。だとすると
私たちは、ソフトウェアデベロップメントの専門家として、何らかの役に立つものを実現することを職業にしているのです。

この視点では、医師が、医術を使って人を病から救うことも殺すこともできるように、自らのスキルをどのように役立て、実現しているのか、どんな倫理に基いて行動しているかを見ることによって、その人がプロの技術者なのか、そうでないのかを見極めることができます。


プロフェッショナルの倫理


ソフトウェアエンジニアも、医師が医術を独占しているのと同じように、社会のIT技術を独占している存在です。技術の使い方によっては社会にとって脅威になることもできる存在です。倫理的な存在であるからこそ、社会に存在を容認されています。ソフトウェアエンジニアがプロフェッショナルとして守るべき倫理について、下記に書きます。

・法律・法令・契約の遵守
・役割を果たすこと
・約束を守ること
・実力の保証
・相手の尊重
・利他主義
・客観的な助言
・社会のために働くこと
・道徳性
・誠実、正直、信頼感

ここに挙げられた項目は、いずれも、人として当たり前の倫理です。
ですから、通常は努力をしなくてもこの倫理を守ることができるでしょう。
約束を守る、相手を尊重する、利他的に働くなど、私達が誇りをもって働けばきっと実現できるでしょう。

世の中には、成果の基準を勝手に引き下げてしまうチームリーダーがいます。「品質は悪くても納期さえ間に合えば良い」、「指示された機能までやっておけばよい」などの妥協はやがてチーム全体に派生し、誤りであることがすぐに誰の目にもわかるようになるでしょう。リーダーは、高い成果の基準を設定し、それを実現するために行動することが必要です。

また、あまり経験のない分野の仕事を、あたかも経験豊富な振りをして受注することも、「実力の保証」という倫理から外れています。

最近は、現代アートが好きなエンジニアも増えているようで、いろんなスタートアップ企業で優秀なエンジニアの方が講演などで話されますが、

自分の携わっているプロダクトを自身の「作品」として扱うことが大切です。

筆者はこの考え方がとても好きです。



本記事の引用・参考書籍:ドラッカーさんに教わった IT技術者が変わる50の習慣 著:恒川裕康さん


2014年3月29日土曜日

スクラムを採用する3つの理由 / Holland Dozier Holland

こんにちは、@wd0214です。

現在とりかかっているプロジェクトのリリース作業のためしばらく息もつけない日々でした。それにしてもリリースは何度やってもドキドキ・ワクワクします。素晴らしいメンバーとこの瞬間を共に出来たことに感謝します。

筆者はだいたい家で家族が寝静まってから仕事をすることもしばしばなのですが、今レポートを書き終わり、久々にキッチンで奄美黒糖焼酎の「島のナポレオン」をお湯割りで頂いています。春ですね、沖縄、いきたいですね。

ブログを続けます。

スクラムを採用する理由


スクラムが積極的な管理層を巻き込んでプロジェクトを制御していくことを知らない為に生じる管理者の意見の例を見てみましょう。

「開発チームが機能を減らしたり目標に達するためにコストを増大させたりすることがある」

「どのようにすれば予測すべきことを知り、プロジェクトの悪化を阻止し、制御できるようになるのか」

「どのようにすれば開発チームは怠けたり、組織や顧客の期待を裏切ったりしないのか」

「スクラムチームにプロダクトを納品する責任を持たせたい そのチームが納品できないなら他のチームと契約したい」

「スクラムチームは私に管理権限を与えてくれない」

 ※管理者:ユーザーや顧客、または開発プロジェクトに資金を出す投資家


定義ソフトウェア開発プロセスの崩壊

~プロジェクトの最初に確実に要求仕様を決定できるという神話は既に崩壊している


従来の技法を見てみましょう。

・システムのビジョンとすべての要求を定義することから始まる

・プロジェクトの最後の2ヶ月前まで開発されたプロダクトが期待に沿うものなのかどうかがわからない

これまでの手法は、顧客と開発チームのやりとりがほとんどない「壁越しの」システム開発技法といわれています。

プロジェクトマネージャーは計画を持つことによってプロジェクトが制御下にあることを感じ安心します。メンバーは要求された作業を理解してプロジェクトが成功して完了すると感じているが、その計画の基礎となるタスク詳細は不完全です。定義が不完全なので依存関係も不完全、これらの見積もりは作業の割り当てや見積もりを不完全にします。

ほとんどのプロジェクトが高い確率で予測可能だと仮定する場合、PERT図を使い複雑なプロジェクトを制御しようとすると、最善を尽くしていた開発者は、期待されていることに従って行動することに常に失敗し、結局最善を尽くすことをやめてしまいます。

この間違った公式化は、数えきれないほどのプロジェクトのキャンセル「それを元に戻す」ために浪費された多くの努力、コストを産み、適切に管理されたソフトウェア開発の全体的な失敗を導きました。

スクラムはなぜ機能するか
~経験的プロセス制御モデルの採用へ


スクラムは、同一の活動が同一の出力を生成することはほとんどないという見解からはじまります。

・スクラムは、すべてのプロセスは予期できないと考えます。
〜とても複雑で事前に定義することができず、再現できないときは経験的プロセス制御モデルを採用。管理者、顧客、開発チーム間がより密接に協力し、優先順位の高い、小さい要求群を最初に完成します(通常これで 3ヶ月の分量はあります)。

・チームはスプリントの中で新規のビジネス機能を開発します。

・スクラムはすべてをオープンにします。

コミットメントを果たすための生産方法の改善はチームが自主的におこないます。スクラムを使用すると、少なくとも2週間ごとに直接かつ即座に遅延を発見することができます。

スクラムは何が起こっているかを定期的に理解するために活動を定期的に検査し、求められる予測可能な結果を生む活動を経験的に順応させます。

チームは常に臨機応変に対応し、最初にコミットしたもの以上のものをスプリントレビューで実演して管理者を驚かせます。

顧客とのオープンで正直な関係を構築します。
これがスクラムで最も重要な点です。


スクラム・ソフトウェア・デベロップメントとソウル・ミュージック



筆者は、ソフトウェア・デベロップメントはバンド活動に近いと感じています。
ロボットではできない、人間がつくる作品はいつも感動を与えてくれます。
ソフトウェア・デベロップメントもバンドも、間違えても面白い、改善を繰り返し、メンバーのみなさんと一緒に素敵なイノベーションを起こしたいと強く思います。

本日は、筆者の大好きなラモン・ドジャーを紹介します。
70年台ソウル・ミュージック・シーンにおいて多大な功績を残した作曲家にもかかわらず、本人たちのオリジナルアルバムはリリースされず、オリジナルはシングル5枚のみしかリリースされませんでした。中でも一番好きな曲をかけます。

それではまた、皆様良き週末をお迎えください。




Holland Dozier Holland - Why Can't We Be Lovers?


2014年3月9日日曜日

デイリースクラムミーティング / 君が僕を知ってる

こんにちは、@wd0214です。

今回はアジャイル開発で最もポピュラーなメソッドであるスクラムを紹介することを試みます。スクラムの概論は数あるサイトにて見つけることができると思います、このサイトでは、何回かに分けて実技から入っていきましょう。

まずはどのチームでもすぐに導入できるデイリースクラムミーティングを紹介します。


忌野清志郎/君が僕を知ってる






「ミーティングなんて言ってるようじゃダメなんだよ。普通に集まってさ、普通にワイワイ言ってることが大事だと思うんだよな、俺は。そういうことじゃない? 夫婦とかもさ。友達とかも。」


デイリースクラムミーティングとは



15分の日次ミーティング(朝会)、全員が3つの質問に答えます。

1.前回のスクラム以降何を行ったか


2.次回のスクラムまでの間何をするか


3.作業をする上で何が障害となっているか


報告はお互いの顔を見ながら行います。

全体で15分程度、チーム全員が参加し、一人ずつ報告し全員が聞き、チームを妨害している要因を洗い出し、すべてを見える化し、スクラム開発が機能するようにします。


デイリースクラム後のフォローアップミーティング



3つの質問だけでは状況がつかめず議論が必要な場合、 フォローアップミーティングを開催します。

「スクラムの後でこの問題について話をしたい、関心がある方は残ってほしい」

必ずデイリースクラムの後に行います。


アジャイルのすべてのメソッドについてとても大事なことは、例えばこのデイリースクラムミーティングを開催するかどうかについても、「チームが自分達自身で決める」ということです。


スクラムマスターの役割



・スクラムマスターはミーティングを適切に進めます。

・スクラムマスターはミーティングの場所と時間を設定します。

・チームメンバーは時間通りに行動します。

・スクラムマスターはメ ンバーが出席しているかどうかに関わらず、予定の時刻にミーティングを開始します。

・遅刻したメンバーはスクラムマスターにすぐに1ドルを支払います。

・優秀なスクラムマスターはミーティングが始まる前に椅子を机の周りに並べておきます。

スクラムマスターは、チームが自分達自身で問題を解決できることを支援します。


デイリースクラムでの障害の識別、判断



スクラムマスターはその障害を記録し、取り除く責任があります。

デイリースクラムミーティングでのチームの報告例:

「サーバー、ネットワークが遅い、落ちる」
「管理者に他の作業を頼まれてしまった」
「どのようにして先に進んだらよいかわからない」
「設計上の判断が下せない」

効率よく作業を行う妨げが何かをチームメンバーが見極めたらスクラムマスターは障害をホワイトボードに書き留めます。

スクラムマスターが障害を理解できない場合、 ミーティング後に発言した人と会って学習します。

未解決の障害がホワイトボードに溢れてきたら、それは 上位組織がチームをサポートしていないことを示します。この場合、スクラムマスターはスプリントをキャンセルする強力な切り札をきることができますが、その前に管理者のサポートの欠如がもたらす結果について慎重にかつ熱心に議論する必要が有ります。

コミットメントを達成する為の判断をチームが下せない場合、スクラムマスターはなるべくその場で判断を下します。

その場で判断を下せない場合、スクラムマスターはミーティング後1時間以内に判断を下し全員に周知します。


デイリースクラムミーティングの規則について12のこと



1.チームメンバーの数に関わらず、15分のタイムボックスで行われる。

2.毎日同じ時間かつ同じ場所で行う。日次スクラムは一日の始まりに行うのが最適である。こうすると、チームメンバーは職場に到着するとまず前日に行った作業とその日に行う作業を考えるようになる。

3.チームメンバーは全員出席する必要が有る。何らかの理由で参加できない場合は電話で報告するか、別のメンバーに自分の状況を報告させるような形で参加する必要が有る。

4.チームメンバーは時間通りに行動しなければならない。スクラムマスターはメンバーが出席しているかどうかに関わらず、予定の時刻にミーティングを開始する。遅刻したメン バーはスクラムマスターにすぐに1ドルを支払う。

5.各チームメンバーは3つの質問にだけ答える。 このプロジェクトに対して、前回の日次スクラム以降何をしたか、このプロジェクトに対して、今から次の日次スクラムまでに何を行う予定か、作業を出来るだけ効率的に行うことを妨げていることはあるか。

6.チームメンバーはこれらの質問以外の、懸案、設計、問題の議論、ゴシップなどの議論へ外れてはいけない。スクラムマスターは責任を持って、各人の報告をテキパキと進める。

7.日次スクラムの間は一度に一人だけが話すことが出来る。その一人とは、自分の状況を報告している人である。他の人はその報告を聞き、別の会話をしてはならない。

8.あるチームメンバーが他のチームメンバーに関心がある報告を行ったり、他のチームのサポートを必要としたりするときは、日次スクラムの後に集まって、関心のあるメンバー間ですぐに調整を行うことが出来る。

9.「ニワトリ」は会話や観察や拒否反応など、日次スクラムにおいて自分の存在を目立たせるようなことを行うことは出来ない。

10.ミーティングに参加している「ニワトリ」が多すぎる場合、スクラムマスターはミーティングを順序よく集中的に進行する為に、出席者を制限できる。

11.「ニワトリ」は、ミーティングの後で報告内容を確認したり、アドバイスや指示を行ったりする為にチームメンバーと話すことは出来ない。

12.上記の規則に従うことが出来ない「ブタ」や「ニワトリ」は、ミーティングから退席させられる(ニワトリ)か、チームから外される(ブタ)


スクラムが機能するのは、頻繁なインスペクションと適応に対してすべてのことが目に見えるようになる場合だけ。スプリントの間はチームの邪魔をしない。スクラムマスターは意味のある精度で、すべてのことを可視化します。

物事を解決する第一歩は、明らかにすることです。


次回に続きます。

2014年2月12日水曜日

エクストリーム・プログラミングとソウル・ミュージック

赤坂や 歩くところに 飲み屋あり

こんにちは、 @wd0214です。

週末は大雪でしたね。都内でのこんな大雪は20年ぶりというニュースを見かけました。筆者は20年前の大雪の時、父親と二人、神戸・三宮から高速バスに乗って春からの上京のため新宿に部屋探しに来ていました。思えばあれからずっと、実家に戻ることはなく、ここ東京で暮らしています。日本酒でも飲みたくなりますね。

さて、今回は前回に続きアジャイル・メソッドの一つであるエクストリーム・プログラミング(XP)について紹介することを試みます。

エクストリームプログラミング、XPとは

人によって人のために書かれるソフトウェア


エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)であり、正式にはエクストリームプログラミング(eXtreme Programming)、略してエックスピー(XP)と呼ばれています。

筆者が注目しているXPの利点は下記です。

人間性、人に焦点を当て、人に力を与え、人に利益を与えるなら、自分とチームメイトは、人々が一緒に働き、新しく革新的な方法で問題を解決することに人々を没頭させるようなプロセスを見つけられるようになる。

XPでは、赤ちゃんの歩幅で小さく前進し、それぞれの反復内で小さいサイズの機能を実装、時間が経つにつれ大きな歩幅が成し遂げられます。

細かく見ていきましょう。

XP の特徴


• 5名から10名のプログラマーからなるチームが顧客とともに同じ場所で働く

• 開発は頻繁なビルドもしくは反復形式で行われる

• 要求はストーリーとして明示され、ストーリーにはユーザーが要求した機能性が含まれる

• プログラマーはペアになって開発する。厳格なコーディング規約に従い、彼ら自身で単体テストを行う

• 変化を許容し、要求、アーキテクチャ、設計はプロジェクト活動を通して形作られていく

• 具体的な12のプラクティスが定義されている

難しい言葉が続きましたね。
では次に具体的な12のプラクティス(技法)を見てみましょう。こちらはどんな開発チームでもすぐに実施できるプラクティスとも言われています。

12のプラクティス


1.計画ゲーム(The Planning Game)
 ビジネス優先度と技術的見積により次回リリースの範囲を早急に決めること

2.小さなリリース(Small Releases)
 新バージョンを非常に短いサイクルでリリースすること

3.メタファー(Metaphor)
 システムの動きを示すメタファーを共有すること

4.シンプルデザイン(Simple Design)
 シンプルに設計すること、余分な複雑さは悪

5.テスティング(Testing)
 プログラマは継続的にユニットテストを書き、 顧客は機能テストを書くこと

6.リファクタリング(Refactoring)
 システムの動作を変えることなくシステムを再設計すること

7.ペアプログラミング(Pair Programming)
 コードは2人のプログラマにより一台のマシンでおこなう

8.共同所有権(Collective Ownership)
 誰でもどのコードでも修正できること

9.継続的インテグレーション(Continuous Integration)
 一日に何回もビルドし,テストを 100% パスさせること

10.週40時間(40-Hour Week)
 週40時間以上の仕事はよい結果を生まない

11.オンサイト顧客(On-Site Customer)
 顧客をフルタイムでチームに加えること

12.コーディング標準(Coding Standards)
 全プログラマがコーディング標準に従うこと

すぐに皆さんのチームでも適用できそうなものがいくつかあると思います。

ここではXPの面白いところ、特にペアプログラミング(Pair Programming)週40時間(40-Hour Week)のプラクティスが定義されているところに注目したいと思います。

ペアプログラミングは、プログラマー2名が、ドライバーとナビゲーターに分かれて交互にコーディングを行います。プログラマーは一人ひとり違った人間なので、それぞれバラバラのコードを書きます。プラクティスを適用すると、コードは常にレビューされ、可読性の高いプログラミングが行えます。プログラマー同士の知恵を出し合え、テクニックの共有とチームとしての開発力の底上げにもつながります。

近年では「ペアプログラミング合コン」というものもあります。どうでもいい情報ですが筆者は行ったことはないです。

ペアプログラミングのやりかた

また、週40時間(40-Hour Week)というプラクティスでは、

「知的作業には週40時間の労働時間が最適であり、特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さず、そのため、計画的に開発スピードの調整を行う」

とされています。

現在では、多くのテストやデプロイの自動化などにより、この部分を週30時間にしたほうが効率が上がるという議論も出てきています。

XPについては「ソフトウェア開発はロボットでなく生身の人間が行うもの」というアジャイルの本質に関わる基本精神が貫かれているところが筆者の好みです。

国内の企業では、なかなかこういったプラクティスを適用するのは困難かもしれません。しかしあなたが意欲あるエンジニアで、本当にチームとしてのスピードと品質を上げたいなら、管理者層やチームを巻き込んでここにチャレンジすることをお勧めします。

XP の価値


XPの価値は以下4つとされています。

Communication(コミュニケーション):顧客とのコミュニケーション、開発者とのコミュニケーション

Simplicity(シンプルさ):後に必要になるかわからないもののための設計をしないこと

Feedback(フィードバック):軌道修正ができること、そのために単体テストを重視すること

Courage(勇気):上記3つの価値が揃ってはじめて、時にはソフトウェアに大きな変更も行い、難局を乗り越える

Communication + Simplicity + Feedback = Courage. これがXPの流儀です。

XPコミュニティ


国内でもコミュニティとメーリングリスト「XP-jpメーリングリスト」で議論されていますので紹介します。
http://objectclub.jp/community/XP-jp/
(※12のプラクティスの和訳はこちらの平鍋健児氏の論文から引用させていただきました)

今回はここまでにします。

エクストリーム・プログラミングとソウル・ミュージック


本日はEXTREMEでもと思いましたが、エクストリーム(究極)なソウル・ミュージックというところで。
雪ですしこんなセクシーな曲でも聴きながら東京の夜を過ごしましょう。


うーんやっぱいいですね。

次回は最もポピュラーなアジャイル・メソッドで、筆者の大好きなスクラム(Scrum)を紹介します。


2014年2月2日日曜日

アジャイル・メソッドとロック・ミュージック

こんにちは、@wd0214です。

今回はアジャイルソフトウェア開発手法について書くことを試みます。

アジャイルの誕生


アジャイルは2000年ごろに生まれたと言われています。

90年代までのソフトウェア・デベロップメントは、予め決められた計画を遵守することで正しいソフトウェアが得られると考えられていました。しかし次第にソフトウェアのオープン化が進み、ビジネス要求の複雑化と要求スピードに対して、従来の開発手法では満足できるソフトウェアを得ることが困難になりました。

まずは作ってみないことには、目的とする事柄に合っているのか、またステークホルダーの要求を満たすソフトウェアなのかどうかさえわからないのです。

筆者は1999年の大晦日、KDD新宿本社ビルで2000年対応のため年越しで仕事をしていました。
「だいたい2000.1.1に問題が起こるなら、1999.9.9にすでに起こってるはずだよね。」
C言語のプログラマーならそんな愚痴でもこぼしつつ、万が一に備えて新年を迎えられた方も少なくなかったことでしょう。(結局何も起こらなかったけど

あれから14年程経ちますが、アジャイルはロック・ミュージックと同じくたいていは誤解されています。

考え方は至ってシンプルですが、習得するには非常に困難で、正しい理解と継続的な開発現場での実践が必要です。アスリートが日々自身の身体をチェックし、鍛錬するごとく真摯にエンジニアリングに向かわなければ、本質的に習得することは難しいと思われます。

ニワトリとブタ


アジャイルでは次のような「ニワトリとブタ」の寓話が有名です。


ニワトリとブタがいた。ニワトリは「さあ、レストランでもやろうよ」と言った。ブタはよく考えてから「レストランのメニューは何にしようか」と言った。ニワトリは答えた。「ハム・エッグさ」。ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」

これは、デイリースクラムミーティング(朝会)での参加や発言権について「傍観者としてのニワトリは必要ない」ということへの理解のための喩え話で、シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」(ピアソン・エデュケーション)で紹介されています。

アジャイルの本質


アジャイルはシンプル、ほとんどすべてがこれまでと異なっている

アジャイルの捉え方については、世界中で語り尽くせない様々な意見がありますが、一つ確かなことは

開発現場をよりよくするためには、必ず自分自身がソフトウェア開発をしなければならない

というところです。一番プロダクトを理解している人自身が開発(コーディング等)を行うことこそアジャイル(俊敏)という意味です。

あなたがエンジニアならなおさらですが、ご興味があれば、上記を踏まえた上で原則を読んでみましょう。

アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/

アジャイルソフトウェアの12の原則
http://agilemanifesto.org/iso/ja/principles.html

アジャイル・メソッド


アジャイルと呼ばれるメソッドは下記が有名です。すべてのメソッドは各々異なるチャレンジを持っています。

• エクストリーム・プログラミング(XP)
• スクラム(Scrum)
• ラショラム統一プロセス(RUP)
• リーン・ソフトウェア開発(LSD)
• ダイナミックシステム開発メソッド (DSDM)
• フィーチャ駆動型開発(FDD)
• etc...

あなたならどちらのチームに仕事を依頼しますか?


あなたがプロダクトをビジネスにしたいと考えた時、
「あなたならどちらのチームに仕事を依頼しますか?」

*ウォーターフォール(従来のやりかた)
 大量のドキュメントを納品し、依頼したソフトウェアは最後まで秘密とされるチーム

 *アジャイル
 お客様が一番大事だと考えている順に機能を実装してテスト済みで毎週必ず届けてくれるチーム


  北アメリカとヨーロッパでは企業の14%がアジャイルを採用しており、19%は興味を持っているかすでに計画を立てているようです。

  ▼アジャイルを採用している企業調査(なぜアジャイルを採用したか?)

  1.生産性とタイムツーマーケット(66%)
  2.コスト削減(48%)
  3.品質向上(43%)
 [ForresterResearch,2005] ←古くてスミマセン

  アジャイルへの動機は、これまで同様、ソフトウェアをより早く、より良く、より安く開発することに加え、さらに、高い生産性、高い士気を生み出すことができます。


管理者層に対する最も重要な哲学


例えば、スクラムには「プロジェクトマネジャー」の役割はありません。

アジャイルではリーダーシップとマネジメントは全く異なったものと捉えており、これまでソフトウェアエンジニアに指示をして開発をすすめていた管理職の方は、アジャイルを導入する際にまずこの部分でつまづくと思われます。前述したように自身でソフトウェア開発をしないスタッフはスクラムチームのメンバーに入ることは(原則では)できません。

その意味で、アジャイル、スクラムの価値、原則、プラクティス (管理者層に対する最も重要な哲学)は、

• ビジョンとチャレンジをチームに与えるが、チームが目的を達成するための具体的なステップを与える訳ではない

• 「ここに私たちの欲しいものがある、どうやってそれを成し遂げるかは自分でみつけてくれ」というアプローチ

• 自己組織的なプロジェクトチーム

• 信頼こそがコラボレーションの基礎であり、個々の約束を果たすことが信頼関係を構築する基本である

深く、いいですね。今回はここまでにします。

アジャイルとロック・ミュージック


ロックってほんと最高ですよね。
アジャイルが生まれた頃のロック・ミュージックを一曲紹介します。



やっぱかっこいいですね。

筆者は世の中で一番かっこいいのはバンドマンだと思います。
Bobbyみたいにガリガリにダイエットして、熱唱していきたいところです。

本当に好きなことをやるのが一番、それが一番アジャイルな人生だと思います。

次回からは一つ一つ、アジャイル・メソッドを紹介していきたいと思います。