アラタナエンジニアブログ

aratana Engineer's Blog

宮崎でもアジャイルを!AgileJapan 宮崎サテライトに参加しました!

こんばんは。永遠の39歳、しかし前厄Year、木目沢です。

7月14日のことですが、AgileJapanの宮崎サテライトに参加してきましたので、そのご報告です。

www.agilejapan.org

アジェンダ

  • アジャイル開発入門( 永和システムマネジメント 天野様 )
  • 基調講演:モダンアジャイル( 映像:Joshua Kerievsky 氏 )
  • アジャイル開発の事例と動向( 永和システムマネジメント 天野様 )
  • KPT実践

その前に宮崎でのアジャイルについて

AgileJapan宮崎サテライトですが、平日日中の開催というのもあるかと思いますが、
残念ながら参加者の中でAgileを実践している企業がありませんでした。

なかなか宮崎でアジャイルしてるというのも聞かないので、アラタナが宮崎アジャイルのリーディングカンパニーになれたらなんて考えています。

モダンアジャイル

アジャイルソフトウェア開発宣言が発表されて今年で16年。今やアジャイルな開発をしない理由のほうが見つからない時代ですが、『今の時代に合ったアジャイル』をということで『モダンアジャイル』としてJoshua氏が提唱したものとのことです。

モダンアジャイルの原則

Joshua氏は2001年のソフトウェア開発宣言をアップグレードするために4つの原則を提唱しました。

  • 人々を最高にする(Make people awesome)
  • 安全(ANZEN)を前提にする(Make safety a prerequisite)
  • 実験・失敗を繰り返す(Experiment and learn rapidly)
  • 継続的に価値を届ける(Deliver value continuously)
人々を最高にする

人々とは、顧客はもちろん、バイヤーも評価する人も一緒に働いてる人も管理者も含まれます。みんなをawesomeに!

具体的なプラクティス:cross-functionalチーム / プロジェクト憲章・インセプションデッキ / カスタマーエクスペリエンス

安全(ANZEN)を前提にする

Joshua氏は日本語の『安全(Anzen)』という言葉が非常に気に入っているそうです。安全にはこんな思いが込められています。

失敗しないようにするのではない。
失敗が怖いのではなく、怒られるのが怖い
恐れがあると速くなれない

この「安全」というキーワードは先日行われた「DevOpsDaysTokyo」の基調講演でAdam Jacob氏も強調されていました。
Jacob氏の「安全」の定義はこうでした。

人間の安全・情報の安全・意図せぬ結果を恐れずに実行できる個人の能力

「安全」の反対である「恐れ」については自分も過去に書いていました。
lab.aratana.jp

「XP エクストリーム・プログラミング入門 -ソフトウェア開発の究極の手法 」でKentBeck氏が語っていたのは、

すべての方法論は、恐れに基いています。

ということでした。
この本は1999年出版ですから、当時から語られていたことを「安全」というキーワードで定義し直し、より強調したものとも言えますね。

大事なのは、『失敗しないように頑張る』のではなく、『失敗しても問題ない』ように心理的安全』を確保することです。

具体的なプラクティス:セーフティネット・セーフティボード / あんどんカード / モブプログラミング

実験・失敗を繰り返す

Lean more earn more
沢山学んで沢山稼げ

これは、『早く』ということも含まれていると思います。『早く』『沢山』『失敗』して、『学ぶ』ことです。

沢山実験してその中から選ぶことが大事です。

Amazonの創業者ジェフ・ベゾスAmazon Fire Phone(誰も知らないですよね・・・)が失敗したとき

We’re working on much bigger failures right now
もっと大きな失敗を予定するから待ってろよ

と語ったり、
Scrumの親である野中郁次郎氏も

ベンチャーキャピタルみたいな失敗を大きな企業でもしなさい

と語ったりと実験の重要性を説いていました。

アジャイルソフトウェア開発宣言で「変化に対応する」というのがありましたが、Joshua氏はこの言い方だと受動的だと言っていました。
もっと発展させて、「要求を実験に使ってもいい」「顧客が必要としている」か実験することが必要だと主張していました。

ここ最近の時代の変化、お客さんの変化・顧客の変化って凄く早いと思いませんか?
ウォーターフォールだろうが、アジャイルだろうが、次から次へと要望が増え、変わり、やろうとしてたことが中止になったり、違う形で実現を要求されたり、、、それが本当に顧客が必要としているかどうかに関わらず。。。

『早く』『沢山』『実験』が必要なのは、『顧客が必要としている』かどうかを『早く』『わかる』ようにするためです。
「わかるまでやらない」のは結局周りが変化して、本当の意味でやる必要がなくなります。それは失敗ではなく、「逃した」のです。
『早くわかる』ようにするのが近道なのだと思います。

具体的なプラクティス:進化型設計 / MVP

継続的に価値を届ける

言うまでもなく、継続的デリバリーですね。

ソフトウェアは作るのも使うのも『人』であるということ

今回のAgileJapanで感じたことです。

ソフトウェアが人間の手によって作られるということを忘れてしまっては何も役に立たない。結局、人間に焦点を当て、幸せで、向上心を刺激するものであれば、ソフトウェアを納品することができるだろう。

by Kent Beckエクストリーム プログラミング」より

それは、かつてから言われていたことですが、これまではあまり強調されてこなかったことにフォーカスが当たってきた時代なのでしょう。
いろいろなツールが出てきていますが、アジャイルに開発し、ビジネスの成功のために大切なことはツールではないということをJoshua氏も強調していました。

モダンアジャイルもソフトウェア開発宣言もXPも数あるツールも『人』が開発し、使うために生まれたものだと思います。
かつてのウォーターフォール開発はこの視点が欠けているような気がします。

最後に、遠い宮崎まで講演に来ていただいた永和システムマネジメントの天野さんに感謝申し上げます。
貴重なお話を本当にありがとうございました!
来年はアラタナのアジャイル事例を(きっと、、、多分、、、恐らく、、、)紹介できると思います。。。

f:id:kimesawa:20170807232458p:plain