「Jira Software」とアジャイル開発
Jason Wong氏：こんにちは、みなさん。Jasonです。楽しんでますか？ はじめまして。私はAtlassianのPrincipal Product MangerのJasonと申します。私はシドニーに住んでいて、シドニーのAtlassianで働いています。
私と日本の関係を考えますともう20年になります。実は日本には住んだことがなくて、高校に入ったときに英語しかできなかったので、第二言語を学んでおいたほうがいいかなと思って日本語を勉強しました。10年前に妻と出会って、今は小さい子どもが2人がいて、子育てのための日本語を勉強しています。
（会場笑）
5年間、私は「Jira Software」という世界一使われているアジャイル管理ツールのLead Product Managerでした。Jiraを使ったことある方、手を挙げてください。
（会場挙手）
おお。ありがとうございます。
Jira Softwareは、課題を記録して管理するものです。どんなチームのプロセスでも、Jiraのワークフローという機能を使って、ボードでチーム状況を把握できるアジャイル管理ツールです。
世界中どこを探してもまったく同じチームはないと思います。従ってJira Softwareの使い方もそれぞれ異なってきます。開発の仕方にこだわりを持っているユーザーのみなさまのおかげで、Jira Softwareの高いカスタマイズ性が実現できています。Jira Softwareを開発していく中でめぐりあった事例やフレームワークを交えながら、アジャイルをどう実践していけばいいのか、これからのプレゼンテーションでお話ししたいと思います。
日本は最先端のテクノロジーと伝統的な文化がうまく融合している私の大好きな国です。改めまして、今日のプレゼンテーションに来てくれてありがとうございます。一応、私は外国人なので、お手柔らかによろしくお願いします。
日本でアジャイルについて話すのはより特別なことですよね。なぜならアジャイルは日本で誕生したからです。野中郁次郎先生と竹内弘高先生が執筆された『The New New Product Development Game』という斬新な論文に由来してます。しかし、日本ではアジャイルソフトウェア開発がそれほど普及してないと聞き、とても驚いて興味深く感じました。
アジャイルがソフトウェア業界において広く知られるようになったのは2001年で、アメリカのユタ州にあるスキー場でオピニオンリーダーが数人集まり、そこでアジャイルの原理、いわゆる「Agile Manifesto（アジャイルソフトウェア宣言）」を作り出したことにより、以降モダンなソフトウェア開発に最適な方法として急速に普及しました。
アジャイルを「ふりかえる」
Jira Softwareのロードマップを作成するにあったって頭を悩ませていた時、Jira Softwareはアジャイルなチームのためのツールなので、向上させるためにいっそのことアジャイルを使うのはどうだろう？ 「アジャイルのふりかえり」を行って、アジャイルを実践しているチームのニーズについて、オープンなフィードバックをもらおうと考え、そこから「#RetroOnAgile」というキャンペーンが誕生しました。今日のプレゼンテーションのタイトルはそういう意味ですね。アジャイルをふりかえるということです。
ふりかえりは、チームが1回立ち止まり働き方の良いところと悪いところについて話して、どうやって改善するかをチームで一緒に決めるので、とても効果的なやり方だなと思います。
これは海外でイベントを行ったときの写真なのですが、このように大きなウォールボードでアジャイルのふりかえりを行う#RetroOnAgileを始めました。たくさんの方々に手書きで650枚ぐらいの付箋を貼っていただきました。ちなみにDev SummitのAtlassianブースもあるので、ぜひ参加してください。
さらにオンラインでも同様のキャンペーンを行い、世界中のアジャイルコミュニティから3,000以上のdigital noteをTwitter上でいただきました。
#RetroOnAgileのテーマは何でしょうか？ たくさんの意見がありましたが、この3つをとても興味深く感じました。
「アジャイルの意味が歪んできたので、普遍的なアジャイル知識がもっと欲しい」というコメントがありました。また、「継続的な向上のため、もっとアイデアが欲しい」というコメントもありました。チームの健康状態の心配もありました。開発スピードやサイクルタイムなどのデータを意識しすぎる心配もありました。
1つ目と2つ目の問題については、経験や教育である程度解決できていますが、3番目は難しいですね。これはカルチャーの問題ですから。チームの雰囲気が不健康だったら、不健康なソフトウェアができてしまうと私は強く信じているので、今日はこの点について話そうと思います。まずは、この3つのテーマを答えるために、アジャイルの原理について話しながら、いい事例や効果について話しましょう。
計画に従うことよりも、変化への対応に価値をおく
たぶんアジャイルを経験したことがある人はよくわかると思いますが、スライドの右側しか使わないという誤解を幅広く目にしますね。右側だけでなく、左側と右側どちらにも価値があります。使い方は、例えば「計画に従うことよりも、変化への対応に価値をおく」ということですね。この原理について話しましょう。
これはジョークなんですけど、この誤解をよく表しています。我々は戦略がなく、しょっちゅう心変わりして、いつも失敗ばかりしている。上司には「我々はアジャイルです！」と言おう。アジャイルは、実験的な反復型開発であるためにこのような誤解がよく生まれます。ですが、アジャイルはランダムプログラミングじゃないですよね。
計画しなかったり、締め切りを気にしなかったり、ツールを使わないで進めている状態のことを指して英語では「going dark」という言葉を使います。見通しが悪くて、フィードバックが得られない。開発方向もわからず、音信不通になるという意味ですね。
サグラダ・ファミリアに行ったことありますか？ とても斬新な建造物ですよね。この建造物の建築は1882年に始まりましたが未完成です。TripAdvisorによると、人々が世界一訪れている建造物です。
ですので、未完成でもサグラダ・ファミリアみたいに早めにリリースしてください。
（会場笑）
すべてが整った研究室のような使用環境ではなくて、毎日の実践的な使用環境でフィードバックを得てください。フィードバックを得て、お客様にリリースして、経験を重ねましょう。そのためには動くソフトウェアがとても大切で、この原理を実践したチーム事例を紹介したいと思います。
こちらはAtlassianの「Cloud X」というチームです。このチームはAtlassianクラウドの認証システムなどを作っています。法律上の要件があり、そのために絶対に守らなければならない締め切りがたびたび訪れるシステムです。
このチームへのアドバイスは、経験がない時には、計画からじゃなくてコーディングから始めたほうがいい、です。
まず、チームはコーディングを始めて、こうやってホワイトボードに紙を貼り、絵を書いてお互いが何をしてるのか共有しました。けど、外から見たら何をしているかわからないですね。
でも、2〜3週間後、コーディングから着手したおかげで早めに経験値が上り、チームの仕事量が現実的に把握できるようになりました。今回はもう少し計画のかたちになってますね。スプリントごとにトラックを分けてあります。
もっと時間が経つと、チームはすごい計画を完成させました。白いカードは課題で、プロジェクトの進捗の順番に並べてあります。いくつか課題が合流しているところがあります。これはとても強い依存関係にあるという意味ですね。両方が終わらないと片方のチームが先に進めないので、とても重要なポイントです。
青い丸のポケモンが示す意味は、エピックやマイルストーンです。エピックを達成したら開発者が赤い丸のモンスターボールを手に入れてお祝いします。
（会場笑）
右側には川がいつも流れていて、クラウドで稼働するソフトウェアが問題なく動くように支えるために必要な仕事を常に表示しています。このボードはオフィスでみんなが確認できる場所にあって、プロジェクトの状況を見ながらいつでも対話できます。全員が達成感を味わいながら進むことはとても大事です。そうすることでチームが早くリリースして、お客様によりよい体験を提供できます。だから、このようなアジャイルチームは「動くソフトウェアこそが、進捗の最も重要な尺度だ」とよく言います。
プロセスやツールよりも、個人や対話に価値をおく
じゃあ、次の原理。「プロセスやツールよりも、個人や対話に価値をおく」ということですね。私が一番好きな原理です。
これは#RetroOnAgileからいただいたコメントなのですが、アジャイル開発はスクラムだけではないことについて話したいと思います。
「アジャイル = スクラム」はおそらく一番大きな誤解だと思います。「スタンドアップやってますよ。スプリントやってますよ。だからアジャイルです」とよく聞きますが、アジャイルはすることではなく、アジャイルになることが正しいのです。つまりプロセスではないということです。
スクラムは、アジャイルの精神をよく反映しているフレームワークのひとつの実装例で、広く知られています。だから、新しいチームでアジャイルに取り組む際には適していると思います。
スポーツで説明したいんですが、ラグビーは100ヶ国以上でやっているので、たくさんの選手やファンがいます。最近、日本でもラグビーワールドカップが成功しましたよね。ほかに、例えば「AFL（Australian Rules Football）」というゲームを知ってる方、手を挙げてください。
（挙手なし）
やっぱりいないですね（笑）。これはオーストラリアのゲームです。
ピッチはこんな形です。まずできる人がなかなか見つからないので、オーストラリアのビクトリア州以外の人ではチームを組むのは難しく、始めるのに時間がかかります。
この図はチームビルディングの有名な理論、タックマンモデルで、チームがはじめて組まれてからより良いチームに育っていく枠組みです。AFLをやろうと選択した場合、基本を学ぶだけで時間を費やしてしまいますが、ラグビーのように多くの人が知っているものを選んだ場合、おそらく統一期に早く到達して、よりパフォーマンスを上げることに時間を割くことができます。
もっと上のほうに登りたかったら、まずふりかえりを行って、良いところと悪いところを学んで少しずつ調節しましょう。自分たちの状況に適切な、カスタムな働き方を見つけたら、さきほどのAtlassian Cloud Teamの事例みたいにチームワークがよくなるでしょう。
アジャイルとウォーターフォールの棲み分け
開発の仕組みについてはいろいろな比較がありますが、一番有名なのはアジャイル対ウォーターフォールです。アンパンマンとバイキンマンの対決のような構図ですね。
AtlassianのチームはTシャツを作るのが好きです。こういうTシャツ。かつ、Tシャツをあげるのが好きで、私の経験ではこのTシャツが今までで一番人気でした。「I’m agile.」と言われたらみんなうれしいでしょ？ 日本語だと「君は機敏だね」と言われたらうれしいですよね。
アジャイルの意味が歪んできた問題で、名前や言語の問題もありますが、みんなアジャイルになりたいですよね。バイキンマンがアンパンマンになりたいみたいに、アジャイルは時々、変装したウォーターフォールだと言われます。でも、アジャイルはアンパンマンみたいにとてもやさしいですよ。
原理の話に戻ります。プロセスやツールよりも対話と個人に価値をおくという話からすれば、どちらでもOKなのです。それぞれの状況に応じて選ぶことが大事です。「bad agileじゃないですか」とみんな思ってるかもしれませんけど、説明します。
スライドはクネビンフレームワークと言って、問題の複雑さをカテゴライズするフレームワークです。まず右下は簡単な問題です。こういう問題は何回も経験したことがあって、最適なソリューションがわかっています。例えばマックのポテトは最適な作り方がわかっているので世界中どんな国でもおいしく食べられます。この場合はウォーターフォールがいいでしょう。
右上はややこしい問題です。この問題はいろんなソリューションがあるので、専門家を頼んで分析してから開発します。新幹線か飛行機か、どっちで行くかみたいな話で、場合によってアジャイルがいい、またはウォーターフォールがいい。こういうふうになります。
左上はラグビーのような問題です。いいラグビーチームは相手チームの様子を見て、いろんな戦略を使ってみて、試行錯誤しながら強いチームになっていきます。このような問題には実験的な反復型開発のアジャイルが強いです。
左下はカオスです。これは災害みたいな話です。オーストラリアで最近すごくひどい山火事があって、ようやく昨日やっと消えましたけど、ソフトウェア業界ではインシデントなどですね。こういうときに最適な方法を考える時間がなくて、とりあえず問題を止めようとするか逃げるとか。こういった問題にはKanbanが有効です。しょっちゅう優先が変わるから臨機応変に対応できます。
つまり、テクノロジーや要件に、未知のものがあればあるほど、問題がより複雑になって、アジャイルの有効性がはっきり見えるようになります。
真ん中には混乱という崖があります。これは問題の複雑さを間違って見立てた場合です。。例えば複雑な問題のとき、「これは簡単だろ。早くやれ」と上司が命令してしまったら、チームが簡単な開発方法をしがちになるので解決できない。崖から落ちます。関係が悪くなったりいらだたしい状態になりますね。
逆の例もあります。もう最適なソリューションが知られているのにチームが実験ばっかりして、なかなか既存の最適なソリューションを追い越せなくて、結果が出ず、また崖から落ちます。
より良いチームのためには、直面している問題の複雑さに合う解決方法をマッチさせることが肝心です。
契約交渉よりも、顧客との協調に価値をおく
次の原理。「契約交渉よりも、顧客との協調に価値をおく」。
契約にはいろいろな問題があり、いろいろな強制力に縛られていますが、従来型の契約の主な問題点は、片方にリスクを負わせるような形態になっていることです。そのような契約は、お互いの信用性の妨げとなったりチームワークを難しくさせたりします。細かい要件や条件が付加された契約の代わりに、共通のインセンティブがあってこそ、アジャイル的な働き方ができるでしょう。
要件の契約化から、優れたアジャイルチームの採用へ焦点を切り替えるのは、大きな組織的変更です。そこで、AtlassianのTeam Health Monitorを紹介したいと思います。Atlassianは、不健康なチームは不健康なソフトウェアを作ると強く信じているので、チームの健康状態を図る特別なふりかえりを行っています。
例えば「誰かフルタイムオーナーをしてますか？」「チームのバランスはどうですか？」「お客様の問題についての理解をみんなで共有してますか？」などの視点でふりかえりを行います。
それぞれの質問にこうやって答えます。「良い」＝「緑」。「まぁまぁ」＝「黄色」。「悪い」＝「赤」。例えば「～～をみんなで共有してますか？」と評価するときに、みんな手を出して同時に意見を見せます。せーの！ ジャンケンみたいに先出ししたり後出ししたりしちゃダメですね。
この写真は、私のチームがHealth Monitorを行ったときにウォールボードを使ったものです。いろんな結果が見えますね。
ConfluenceというAtlassianの製品の中にTeam Health Monitorのテンプレートがあって、ふりかえりをした結果を記録したり経過が見えるので便利です。
リモートチームはTrelloというAtlassianの製品を使うと便利です。レイアウトの機能があるからです。全部のTeam Health Monitorの結果について話す時間がないときは、真ん中の列のようにみんなの答えがバラバラのところを優先的に話して、どうするか決めるといいです。
Team Health Monitorの情報は、このリンクをご覧ください。
契約よりも顧客との協調を促進した事例として、ハッカソンの話をします。ハッカソンしたことある人、手を挙げてください。
（会場挙手）
これからお話しするのは、Atlassian Cloud Migrations Platform Teamがベンダーさんと一緒にハッカソンをした事例です。誰でもAtlassian製品用にアプリを開発すると、App StoreみたいにAtlassianのMarketplaceで販売することができるのですが、Atlassianの製品は2つのアプリシステムを提供しています。オンプレ版とクラウド版です。
今、IT業界ではクラウドに移行するのが話題ですが、残念ながらMarketplaceの販売契約では、開発者に対してオンプレ版からクラウド版へ移行する必要性を規定しておらず、Atlassian Marketplaceアプリはオンプレ版からクラウド版に移行できないと幅広く思われてました。
そこでアプリのベンダーを誘って、一緒に1週間のハッカソンを行いました。これは、AtlassianのMarketplaceで売る目的のために書かれた契約よりも、私たちのお客様に対して共通の問題であるクラウド移行ツールを一緒に開発するという目的で実施しました。
ハッカソンをやるのは簡単ですが、結果を出すのはなかなか難しいです。なぜならハッカソンの由来は「自由自在な開発」だからです。なので、ハッカソンを始める前にアプリベンダーと「どんな目的を設定するか」と話し合って、このテンプレートを作りました。
ハッカソンをしながら、忘れないうちに情報を入れてもらって、ハッカソンの終わりのほうでインタビューしてニーズを確認しました。
ハッカソンのスケジュールとしては、できるだけ自由なハッカソンタイムを優先にしました。
アプリ移行はかなりややこしい問題です。さっきのクネビンフレームワークでもお話ししたように、予測できない質問が必ず出てきます。そこで、私のチームだけじゃなくて、Atlassianのほかのチームの専門家にも参加してもらい、サポートしてもらいました。このハッカソンは、契約の発注主と請負側という構図ではなく、ベンダーさんと一緒に開発しながら直接に働く機会を作ることで、協調性が生まれ、とても効果的でした。
速やかにクラウドへ移行するデモを行うのは全部のチームの目的で、一番いいデモを見せたチームには賞をあげました。本当に短時間でできたんですよ。
終わりのほうに、もちろんふりかえりを行いました。このハッカソンを実施し、ベンダーの開発者が同じチームメンバーとして開発に取り組んだことで、クラウドへの移行は不可能だろうといわれていたアプリを、たった1週間で移行できるサービスが作れるようになったわけです。
こういうとき、Atlassianの社員はSparring(スパーリング)という言葉をよく使います。簡単にいうと練習試合です。怪我がなく、オープンに練習したり、遊んだり、一緒にスキルを伸ばす意味での練習試合です。このハッカソンは１週間の間に大勢の人が参加した大きなスパーリングセッションでしたが、ホワイトボードを使いながら2人で30分でもできます。Sparringでは、遠慮なく対話できる瞬間を作ることがコツです。
「考えないで早くやれ！」という誤解
次のトピックです。ソフトウェアはこれから表向きもっとスマートになって、中身はより複雑になっていきます。だから、ソフトウェアは製品だけじゃなくてサービスに広がるという話をしながら、アジャイルのことも話したいと思います。
現在のクラウドで動いているソフトウェアは勝手にアップグレードされていて、ほかの人やサービスに常につながっているので、データ量や能力がものすごく上がり全体的にただ処理を行う機械じゃなくなってきてます。
とくにクラウド移行する動き、別名いわゆるSaaS（Software as a Service）は、ソフトウェアは製品だけじゃなくてサービスであるという考え方を促進しています。
ソフトウェアは製品を提供しているだけじゃないのはもちろん、サービスを提供しているだけでもないのです。
ソフトウェアは作っている人と同じ特徴を持つという考えもあります。なので、全部のソフトウェアのコードは機械のためではなくて、思いやりのある接客サービスを提供しようと開発してもらいたいと思います。
日本に来るオーストラリア人は、みんな日本のサービスがすごくいいと言ってます。電車は時間通りに来るし、清潔で、丁寧で、信頼できる。「日本はすごくいい」と言っています。これは日本人がすごくいい製品を作れるし、お客様に対するサービス精神が素晴らしいからで、開発においてもきっとうまくこれを活かせると思います。
これは#RetroOnAgileからいただいたノートなのですが、「考えないで早くやれ！」という誤解について書いてくれました。
効率的かつスムーズに……「lean」という意味で開発すればいいけど、本当にお客様から愛される、lovableな体験を目指さないとダメですね。とくに今日はValentine’s Dayだから、愛されるサービスを目指してください。
leanかつ、lovable。効率的に本当に愛される体験を、どうアジャイルで実現していくのか。 この3つのステージがあると思います。
まずはアジャイルの原理を意識し、反復型開発を導入して、スクラムから始めてカスタマイズ可能な働き方を見つけたら、より良いチームワークになります。
次のステージは、効率的にいつでもしっかりしたソフトウェアを作れる頼れるチームになること。アジャイルをGITに加えて、継続的インテグレーション、継続的デリバリーとつなげて、速く頻繁にリリースできるステージです。これは筋トレみたいですね。強いチームになる。
でも、なんでもかんでもリリースしていいわけではないので、さらに次のステージがあると思います。それはリリースしてから価値を確認することですね。
これは技術の話だけじゃなくて、本当にお客様から愛される体験をつくるために、 デザインも含めて完了の定義を、リリースではなくお客様の満足度にシフトさせましょう。つまり結果よりも成果に価値をおくことを意識するということです。
これは、アジャイルの原理の中では潜在的に意識されていることだと思いますが、明確にはなっていないので、#RetroOnAgileの結論として、私が個人的にこれをアジャイルマニフェストに追加したいと思います。
#RetroOnAgileでは3つのテーマがありました。アジャイルの意味が歪んできたこと、チームの継続的な向上のこと、チームの健康状態のこと。この3つに「結果よりも成果に価値を置くこと」を意識してみてください。
この新しい原理についてもうちょっと具体的な事例を共有したかったのですが、今日は時間がないので、こちらのプレゼンをぜひご覧いただければと思います。以前のプレゼンなのですが、Product Managerの役割や、ロードマップや戦略の作り方について話しています。
今、会場内のAtlassianのブースで#RetroOnAgileを行っています。お客様の価値を理解できる反復型開発の事例がたくさんありますので、ぜひブースにお立ち寄りください。
オープンな開発環境を作れば、アジャイルが元気になる
オープンな開発環境を作れば作るほど、アジャイルが元気になります。それは組織のみなさんにも、お客様にも理解してもらうことが重要です。Atlassianは、オープンなカルチャーを育てるためにアトラシアンの価値観を定めています。これをお客様とも共有していますので、お客様も本音を伝えてくれるので、本当に助かります。
今日のプレゼンテーションに来てくれて、本当にありがとうございます。Developer’s Summitでプレゼンテーションできて本当に光栄です。みなさん、才能を信じて、明るい将来を描いてください。今後アジャイルのふりかえりの機会ががあったら、またよろしくお願いします。
（会場拍手）
