非アジャイルマニフェスト

アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。

アジャイルアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな?

agilemanifesto.org

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

 

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。 

 

これをひっくり返して、アジャイルやってないケースを考えてみると...

  • 個人や対話より、プロセスやツールを重視してみたり
  • 動くソフトウェアより、ドキュメントが揃ってることが大事だと感じたり
  • 顧客と同じ方向をみるより、チキンレースや責任の押し付け合いをしてみたり
  • 変化への対応はほうっておいて、計画の未達成を問題視してみたり

だったりするのかな?まあ、これだけでなく、いろいろありそう。作ってみた感触としては、なるべく具体的に考えてみると、現状と理想的な状態との差分がわかりやすくなって、改善すべき点がつかめるかもしれないなとおもいました。

 

同じように、アジャイル宣言の背後にある12の原則の方も、職場によって状況によって、「本当は原則のようにありたいけど、現在の現実はちがうなぁ」というのがありそう。

 

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します

 

 私が書いてみたのはこれです。Scrum Coachin Retreat in Okinawa で、みんなでフィードバックもらっていい感じになってきたきがします。職場ごとに違う非アジャイルマニフェストがあると思いますけど。 

アジャイル宣言は、ものを作っている人にとっては、(理想として)同意できる内容だという人が多そう。だとすれば、アジャイル宣言の各項目をちょっと変えて(理想的でない)現在の状況を記述してみると、改善のヒントになりそう。書き出したら、そこから一つ一つ、よい方向に変えてみれば、幸せで成果の出る職場に近づくんじゃないでしょうか。

私としては、「アジャイルやってない」人に対して、現状どうなっているのか、あなたはどうしたいのかを、もう少し解像度上げて細く聞くきっかけにできるかも。

 

やってみたら、単純に楽しかったので、みなさんも自身の非アジャイルマニフェストを考えてみてはいかがでしょう!

 

アジャイルエンタープライズ (Object Oriented SELECTION)

アジャイルエンタープライズ (Object Oriented SELECTION)

 
Software in 30 Days スクラムによるアジャイルな組織変革

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

 
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

 

ソフトウェア開発における学習曲線を受け入れる by David Bernstein

Beyond Legacy Code の著者、David Bernstein (@ToBeAgile ) さんの記事を翻訳しました。ソフトウェアエンジニアは新しいことを常に学ぶ必要性がある、 それはなぜか、というお話です。

David  さんは DevOpsDays Tokyo 2019 (4/9-10) の 基調講演で来日予定です。

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

 

 

ソフトウェア開発における学習曲線を受け入れる

David Bernstein著 - 2018年6月20日

www.agileconnection.com

要約:ソフトウェア開発の領域では、私たちは常に必要性に迫られ、新しいスキルを習得し続けています。テクノロジーや、それに絡むベストプラクティスは絶え間なく変化してしまいますが、これは業界が急速に進化しているという意味でもあり、むしろよいことです。そしてまた、私たちが常に学習曲線の途中にいること意味します。継続的学習についてのよいマインドセットを持っていれば、ソフトウェアの世界でより遠くまで到達する手助けになるでしょう。

新しいことを学ぶときには、常に学習曲線に直面します。
まず、特定のテーマについて知らなければいけないことの全てを、あらかじめ知っているわけではないことを認めなければなりません。当たり前だと感じるかもしれませんが、人はなにかに熟達すると、しばしば、初心者のマインドセットに立ち戻るのが難しくなります。新しいスキルの習得のために、以前は役にたった古いスキルを放棄しなければならないときは特にそうです。常にもっと学ぶべきことがあり、改善の余地がある。真の達人たちが常に謙虚なのは、それを知っているからです。
きっと100年後の人たちが今の私たちのソフトウェア開発をみたら、おかしいと笑うんじゃないでしょうか。たぶん私たちが昔のまじない師を見るような感じです。もちろん仕事としてはうまくいっていたわけですが、病気の本当の原因はわからず、効果的に治療できたわけではありません。私たちも上手に仕事をこなしていますが、まだソフトウェアの本質を理解できていないのです。ソフトウェアは世界の他のすべてのものと根本的に違うため、それも不思議じゃありません。私たちは未だ、効果的な開発方法を試行錯誤しているのですから。

          *  *  *

新しいプラクティスが効果的かどうかにかかわらず、学習曲線が存在するのが普通です。あるプラクティスの適用が有益かどうかを考えるだけでも、学習曲線のなかで一層の努力が必要になります。プラクティスを取り込んで、いつもやっている活動にできたら、その努力が報われるんだと考えてみましょう。
人は生まれながらに歩く能力を持っているわけではありません。歩き方を学ぶために時間と労力をかけたのです。おそらく覚えていないでしょうけど、何度も転んだに違いありません。でもあなたは挫けませんでした。当初、歩くことはハイハイよりも大変でしたが、あきらめずに努力を続け、現在は常にこの新しいスキルの恩恵を受けている、というわけです。

          *  *  *

どんな人でも学習曲線を通過する必要があり、それが何であれ、進みながらうまくなるのです。ソフトウェア開発でも、常に新しいスキルを習得します。そうせざるを得ないからです。テクノロジーや、それに絡むベストプラクティスは絶え間なく変化してしまいますが、これは業界が急速に進化しているという意味でもあり、むしろよいことです。

このことは、私たちが常に学習曲線の中にいることも意味します。ほとんどの人は、学校から出たとたんに学ぶことをやめてしまいがちですが、ソフトウェア開発の世界では、常に学んでいくものです。私にとってこのことは、ソフトウェア分野の主な魅力の1つです。私は新しいことを学ぶのが大好きで、それに事欠きませんから。

          *  *  *

新しいものを学ぶことに慣れてくると、学ぶ困難が減っていき、より楽しめるようになります。新しいことを学んでいるなら活発な精神でいられますが、筋肉と同じように、脳も使わなければその力は衰えます。年を取ると、ソフトウェアを書くのは外国語を学ぶようなものです。神経活動を刺激し、心をシャープで機敏に保ちます。
しかし、ソフトウェア開発者というものは、仕事としてソフトウェアの生産が期待されているせいで、継続的に学ぶことが難しくなることがあります。その結果、しばしば業務時間外にも勉強しなければなりません。
20年前には、ソフトウェア開発に関する良書はあまり多くはありませんでしたが、現在は違います。開発者が読んで理解すべき、非常に重要な本がたくさんあります。フレームワークや言語に関する本もありますが、開発技法やソフトウェアでの問題解決のアプローチに関する本もあり、プロのソフトウェア開発者にとって、それらを読んでおくことは非常に重要だと思います。

          *  *  *

ソフトウェア開発分野で私の好きな本を一部あげるなら、マーチン・ファウラーのリファクタリングAlan ShallowayとJames R. Trottによるオブジェクト指向設計の第2版、マイケルC.フェザーズのレガシーコード改善ガイド、私自身の本「Beyond Legacy Code:あなたのソフトウェアの人生(そして価値)を広げるための9つのプラクティス」が挙げられます。
これらの書籍は、高品質でメンテナンス可能なコードを作成するための原則を理解するのに役立つ専門的なソフトウェア開発のコアプラクティスに焦点を当てています。残念ながら、ソフトウェア開発の分野で出版される本の大半は初心者向けです。私たちの業界は絶えず学びたいと望む専門家でいっぱいなのですが。

          *  *  *

しかし、本だけでは足りません。本からソフトウェア開発を学ぶことは、本から脳外科手術を学ぼうとするようなものです。理論的な基礎を得ることはできますが、実際に上手になるには、練習しなければなりません。
どんな科目でも達人になれる秘訣があります。初心を忘れず、常に学び、読み、練習しましょう。

 f:id:wayaguchi:20181027162228p:plain

David Bernstein (@ToBeAgile) | Twitter

 

 

本記事のレビューには松元健さん、伊藤宏幸さん、横道稔さんにご協力いただきました。

 

Netflix でガンダムを学ぶなら

おじさんの基礎知識なので今更学ばなくても...とは思いますが、ご興味ある方は Netflix で正史ともいえる宇宙世紀のシリーズはだいたい追えます。注1

 

とりあえずファーストと言われる第1作の5話大気圏突入あたりまで見る気が起きそうなら、その先も見れそうなので、まずはここからでいかがでしょう。80年代の作品なので作画のクオリティも当時の予算を反映してます。スターウォーズみたいなものです。

Netflix機動戦士ガンダム
https://www.netflix.com/title/80124040?s=i&trkid=13752289

 

もし43話付き合えたら続編はZ (7年後)。読み方はゼータです。アルファ、ベータ... の最後がゼータですね (訂正:6番目だそうです)Zガンダムは中盤から登場するのですが、単体で大気圏突入して飛行できる究極のマシンになってます。複数のメカデザイナーが参加するようになって、ガンプラがたくさん作られました。時代背景も二大国の冷戦が終わって紛争の時代に入った現実世界が反映されてます。武力行動に出資企業がいる、という。この辺りで多感な少年時代を過ごした40代のおじさん達は、Zガンダムで政治を学んでる気がします。政治演説するために議事堂占拠するとか、だいぶすごいことになってます。

Netflix機動戦士Zガンダム
https://www.netflix.com/title/80146402?s=i&trkid=13752289

 

で、アムロ/シャア編の完結が逆襲のシャアです。Zのさらに数年後です。これが名作。劇場版オリジナル作品です。お金かかってる。ちなみにビームが線じゃなくて粒子っぽい表現になりました。メガ粒子砲という設定のためです。手描きアニメなのですごく手間がかかると思います。

Netflix機動戦士ガンダム 逆襲のシャア
https://www.netflix.com/title/60024179?s=i&trkid=13752289

 

ここまでみられたら卒業といっていいのですが、ここまでみたら、むしろ色々見たくなると思いますので続きへどうぞ。

 

ファーストとZの間の話が0083。この作品はテレビじゃなくて、有料のビデオシリーズとして展開されました(お金かかってる)。優れたメカデザイナーが参加して名作モビルスーツを多く生み出しました。富野由悠季氏以外の製作で宇宙世紀ものが展開される分岐点になった作品。

Netflix機動戦士ガンダム 0083 STARDUST MEMORY」
https://www.netflix.com/title/80146416?s=i&trkid=13752289

 

逆襲のシャアのさらに数年後がUC(ユニコーン)で、福井晴敏脚本を得て宇宙世紀ものがリブートした最新作。UCは宇宙世紀(Universal Century)の略です。絵がとても綺麗。これもビデオシリーズですが後に再編集されてビデオ公開されてます。

Netflix機動戦士ガンダムユニコーン RE:0096
https://www.netflix.com/title/80186285?s=i&trkid=1375228

 

ファーストガンダムの設定に無理がある部分を手直しした「the Origin」が、キャラクターデザインの安彦良和さんによって漫画化されてます。

 

同氏監督のアニメシリーズも近年公開されてます。お金かかってて素敵。Netflixにはないですが。

http://www.gundam-the-origin.net

 

あと第08MS小隊(ファーストガンダムと同時代のサイドストーリー)も、モビルスーツがかっこよくていいですよ。

Netflix機動戦士ガンダム 第08MS小隊
https://www.netflix.com/title/80146281?s=i&trkid=13752289

 

モビルスーツのかっこよさといえば、Thunderbolt 素晴らしいですね。これはファーストガンダムの終盤くらいの時間軸です。近年の作品でビデオシリーズなのでお金かかってます。

Netflix機動戦士ガンダム サンダーボルト
https://www.netflix.com/title/80215580?s=i&trkid=13752289

 

UCのさらに未来の話がF91宇宙世紀の続編をここから始めたかったんだと思いますが、企画自体は一作で終わってしまいました。モビルスーツが小型軽量化します。UCに出てくる小型モビルスーツ「ロト」はこの作品の設定からのフィードバックです。

Netflix機動戦士ガンダムF91 完全版」
https://www.netflix.com/title/70026237?s=i&trkid=13752289

 

あと、宇宙世紀ものではあるのですが、宇宙世紀の時間軸では最後の作品とも言えるターンAガンダム。だいぶ未来の話です。黒歴史という言葉を生み出しました。

Netflix∀ガンダム I地球光 / II月光蝶
https://www.netflix.com/title/80215428?s=i&trkid=13752289

 

 

注1: Zの翌年に放映されたZZはNetfilxにないので、一部キャラクターがなんで逆シャアに出てこないかわからないかもしれないけどそれも数名なのでまあ大丈夫でしょう。

 

以上、宇宙世紀ものでした。

 

パターンを ”使う” ワークショップ

だいぶ日本語のパターンも増えてきたので、ぼちぼちパターンを使う機会を増やしていければと思っております。

パターンというのは専門家が共有知として「良さ」を書き出したものです。それをユーザーが操作して自分なりの価値や欲しいものを表現する、という使われ方をするものだと認識しています。

例えばFearless Change だと、何か組織内に普及させたいことがあった場合に使えそうな戦略がパターンになっているので、自分の状況に合わせて、一つ一つ適用し確認することで、一歩一歩前に進む手助けになることを意図しています。もちろん考えるのも試すのもユーザーですし、書いてないことをやるのも全く問題ないわけです。ただ、組織は違えど先達がすでに歩いた道であれば、真っ暗な道で絶望して立ちすくむより、わずかな光明を伝って前に進める方がだいぶいい。

というわけで、パターンを使う側のワークショップとして、Jim Coplien のスクラムパターン研修があります。=> スクラムパターン

f:id:wayaguchi:20181021140632j:image

あと、通るかどうかわかりませんが、Regional Scrum Gathering Tokyo 2018 にも笹さんと原田巌さんがプロポーザルを出しているので、応援をお願いいたします。

Regional Scrum Gathering Tokyo 2019 - 明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ | ConfEngine - Conference Management Platform

f:id:wayaguchi:20181021140650j:image

これまで Mary Lynn Mannsさんと井庭先生に来てもらってやったこともあります。英語と比べて日本語のパターンは多くないのでハードルが高いですが、一つ一つやっていければと思います。

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 
組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

 
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

 

 



 

あなたのいうウォーターフォールとアジャイルはそんなに違うものじゃないよという話

日経SYSTEMSの安藤さんの記事が、それなりに盛り上がりまして。

3分でわかる アジャイル開発 | 日経 xTECH(クロステック)

以下の記述が、企業さんなんかを訪問させていただいて意見交換していると出てくる「私たちウォーターフォールでー」というご発言の部分をうまく写し取っているのではないかと思いました。膝ポンです。

現在多くの開発現場で利用されているウォーターフォール型の開発では、要件定義工程で要件を確定させてから、設計工程や開発(製造)工程に移る。後工程になって要件定義の漏れや変更などが発覚すると、要件定義の工程まで戻って作業をやり直さなければならない。

 要件定義の漏れや変更が発生した際、アジャイル開発では次のイテレーションの始めに要件の優先度を再検討する。これにより変更リスクに備えつつ、より価値の高いソフトを提供できるようになると言われている。

この2つは実はほとんど同じことにすぎないのではないかと思ったんです。

どういうことかというと...

A->B->C->D の手順で作る必要があるんだ!だからいつまでにAを終わらせよう、と考えるわけですが、やってみて気づくこともある。なので実際は手戻りすると思うんです。(しない仕事もあるのは認める)

で、手戻りが起こるかどうかは事前にわからないので「起きてからきちんと手戻りしよう」でもよいでしょうし「手戻りするかも/しないかも、だけどチェックポイントはあらかじめ決めとこう」もよいと思います。(たぶん前者のことをウォーターフォールとみなさん言ってて、後者がスクラム/アジャイルかな。)

 

大事なのは、手戻りするということは「計画から誤差が出る」ではなく「以前は得られていなかった情報を得て意思決定をアップデートした」ということで。

その辺がアジャイルマニフェストの「計画に従うより変化への適応を(より重視)」というところかなと思いました。

アジャイルソフトウェア開発宣言

 

皆さんはどう感じたでしょう。

安藤さん、興味深い記事ありがとうございました。

 

素晴らしいセッションを自分たちで選ぶオープンプロポーザル

Regional Scrum Gathering Tokyo では、オープンプロポーザル方式を採用しています。いわゆる公募方式でプレゼンテーションやワークショップをご提案いただき、Like数上位のものや、幅広いカテゴリにマッチするもの、最新の事例、新しい発表者など、総合的に検討してプログラムを組んでいきます。

Regional Scrum Gathering® Tokyo 2019

f:id:wayaguchi:20181017065455j:image

 

10月末までが投稿および投票の期間になっていますのでぜひ投票やコメントをお願いいたします。ぜひみんなでいいギャザリング(集まり)を作っていきましょう!

 

まだLike数が少ない最新の投稿もあります。ぜひあなたの目と手で発掘してください。最新の投稿からのリストはこちら。
Regional Scrum Gathering Tokyo 2019 - 62 Invited, Accepted and Proposed Submissions | ConfEngine - Conference Management Platform

 

f:id:wayaguchi:20181017065251j:image

「へぇ、あそこでもスクラムやってるんだ!」もし共通の課題を持っていそうな人たちなら課題の解決のヒントをもらえるかも。上司や経営陣を動かすネタに使えるかもしれません。思い切って社内勉強会での講演をお願いするのもよいかもです。

「へぇ、こんなやり方があるんだ」プラクティスや考え方を大いに参考にしましょう。もし今回セッションにならなくても、共通の話題を見つければ、3日目のOST(オープンスペーステクノロジー)で議論することもできるはず。なにかを提案すれば誰かがきっと見つけてくれます。

LikeするにはConfEngineへの登録が必要です。決まったポイントが割り振られます。手持ちのポイントを使ってLikeをしていってください。自分のプロポーザルを投稿するなど、貢献に応じてポイント残高が増えるようになっています。

 

ぜひご参加を!

次回のチケット販売は公募セッション確定後の11月中ばを予定しています。

Scrum Allianceメンバーの方は、今のうちに10%ディスカウントコードの入手を(Regional Scrum Gathering Tokyo 2019 ディスカウントコード問い合わせの例文 - kawaguti’s diary)。