アジャイルとは?アジャイルを教わりに行ったら組織哲学を学んだ話。LINEアジャイルコーチ 横道さんにflexyの麻衣子お姉さんが聞く! #アジャイル編

flexy編集部の麻衣子お姉さんが、現場の最前線で活躍するエンジニアへ会いに行くこの企画。

「聞いたことあるけど良く分からない」「ざっくりと教えて」という非エンジニアならではの問いに答えてもらいます。技術書やWebで調べてもいまいち難しくて理解できないあんな技術やこんな技術。プロに優しく教えてもらいましょう。

今回のテーマは「アジャイル」。麻衣子姉さんもアジャイルという単語は聞いたことがあるものの、なぜ巷で流行っているのか、そもそもスクラムとの違いが何なのかは知らない様子。LINEの横道稔さんに伺いました。

アジャイルの基本をわかりやすく教えて!

麻衣子:エンジニアの方がよく口にする「アジャイル」って何ですか……?「ウォーターフォール」との違いはなんでしょうか?

横道:まず初めに、ウォーターフォールとアジャイルは対となる概念ではないということからお話させて下さい。

麻衣子:対比で語られることが多い気がしますが違うのでしょうか?

横道:実はそうではありません。ウォーターフォールは開発プロセスの方法論、一方でアジャイルソフトウェア開発は、方法論という訳ではありません。ではアジャイルソフトウェア開発とは何ですか?という話になるのですが、そこで必ず出てくるのがアジャイルソフトウェア開発宣言です。

「ウォーターフォール」「アジャイル」は対になる概念ではない

麻衣子:アジャイルソフトウェア開発宣言?

横道:2001年に、ウォーターフォールのような重厚な開発プロセスよりも、もっといいやり方ができないかと、それぞれでさまざまな新しいアプローチを試みていた17人が一堂に会して共通点などを議論した結果生まれた宣言文です。マーティン・ファウラーなどはエンジニアに馴染み深い人物だと思います。

これがアジャイルの始まりということになるのですが、とても大事な文章です。

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

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

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発宣言より引用(強調表記は公式ページを参考に編集部にて加えたもの)

横道:要するに、「プロセスやツール」「包括的なドキュメント」「契約交渉」「計画に従うこと」は大事だけれども、「個人との対話」「動くソフトウェア」「顧客との協調」「変化への対応」が大事だよね。ということです。これがアジャイルの考え方です。このようにしなさいという方法論ではなく、アジャイルソフトウェア開発宣言を行った彼らは、これがいいと思っているけど、みんなはどう?というものなのです。

ちょっと脱線しますが、宣言の中で誤解としてよくあるのは、例えば『包括的なドキュメントよりも動くソフトウェアを』と書いてあるのを見て、アジャイルはドキュメントを書かなくてもよいと勘違いするケースがあります。でもきちんと読むと『左記のことがらに価値があることを認めながらも』と書いてあります。左側が不要という話ではなく、より右側が大事ですよねという発想です。だからアジャイルでも、効果があるドキュメントは必要最小限にとどめながら書きます。あくまで価値を生まないようなドキュメントは必要ないよねという話です。そんなドキュメントを作成するくらいなら、動くソフトウェアを作ってみんなで議論したり、リリースして市場に価値を届けてしまいましょうという考え方です。

麻衣子:なるほど。ビジネスサイドとエンジニアサイドが上手く連携するためにも大変必要な宣言ですね。

横道:さらに、宣言文に続く『アジャイルソフトウェアの12の原則』にも本当によいことが書いてあります。これらを読まずに、いきなりアジャイルの方法論の話をしてしまうケースも多いのですが、これらをちゃんと読んでみて、一言一句すべてという必要はありませんが、共感を覚えるかということはアジャイルを知ってゆく上で大切だと思います。

プロフィール

横道稔

ゲームを買ってもらえなかったので「なければ自分で作る」の精神で、親が持っていたWindows 95にて小学生の頃にプログラミングやWebサイトの作成をはじめる。大学はなぜか経済学部に進学。学生時代はプログラミングからも離れていたが、現SCSKに新卒で入社し、プログラミングがまた好きになる。平鍋健二氏の講演を聞きアジャイルに興味を持ち、その後サイバーエージェントを経て2018年2月よりLINEへ。LINEでアジャイルコーチの部署を立ち上げ、LINE全社で4名いるチームを束ねる。アジャイル系の Podcast:omoiyari.fm パーソナリティ。いくつかのアジャイルコミュニティやカンファレンスの裏方。副業でもアジャイルに関する支援を行っている。

麻衣子:まずは基本的なことをおさえるべきなんですね

横道: 『アジャイルソフトウェアの12の原則』に触れておきましょう。

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

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

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

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

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

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

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

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

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

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

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

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

アジャイルソフトウェア宣言の背後にある原則より引用

これが作られたのは2001年ですが、今見てもできていない部分がたくさんあるな、と感じる人も多いのではないでしょうか。今でも、この宣言は価値があると思います。

IMG 5058

アジャイルはマインドセット

麻衣子:すごく良いことが書いてありますね。「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」なんてまさにそう思います。この宣言をみると、気をつけるべきマインドっぽい感じがしますね。

聞き手

麻衣子お姉さん
サーキュレーション flexy事業部 マーケティング担当
上智大学文学部哲学科卒。日本の大手人材会社を退社しWebデザイナーに転向した後、ハワイに渡米、ハワイ現地法人を設立。代表取締役として、ワイキキビーチ近くでリテールストアーの運営しながら、海外進出企業コンサルティング、グローバル人材育成をハワイのオアフ島にて行う。海外生活は、オーストラリアとハワイ合わせて合計7年。日本に帰国後、サーキュレーションに参画し、今はflexyのマーケティングとして特にインターネット活用(SNSやメディア)を担当。

横道:そうですね。アジャイルとはマインドセットの話といっても良いと思います。

アジャイルにはじめて触れるときに起きることがあるのが、いきなり上の人や周りから「アジャイルをやれ、やったほうがいい」と言われて、なぜやるかも曖昧なまま方法論の実行だけに走ってしまうことです。例えばスクラムやXPなどの方法論がありますが、それら自体はとても素晴らしいものなのですが、それらを書かれているとおりにやれば上手くいくというものではないんです。まずはそのアジャイルの価値観に対してどう思うか、なぜ自分たちがアジャイルを選択するのか、経営者レベルから現場レベルまでそれぞれの言葉で説明できるかどうか、というのはすごく大事です。この価値観に共感するからこのアジャイルな方法論を試してみよう、という順序である必要があると思います。

麻衣子:人が働く上で大事なことみたいな感じですね。

横道:私もそう思っています。日本でもソフトウェア開発以外の現場でアジャイルの考え方が適用されている企業もありますし、海外では学校教育にも使われていたりするケースもあります。現代の働き方にも役に立つのではないでしょうか。

アジャイルは今の時代にもフィットするか

麻衣子:働き方というところで、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」とありますが、flexyではリモートワークに興味のある方がすごく多いです。リモートワークや働き方改革が急速に普及する昨今、その辺りの考え方にアジャイルはどの程度馴染んでいるのでしょうか。

横道:リモートでアジャイルをやるのはグローバルでみても珍しいことではなくなっています。フェイス・トゥ・フェイスが効果的であることは、恐らく多くの人が認めることだと思いますが、ただ18年前にはSlackやZoomのような便利なコミュニケーションツールもなかったので、今はフェイス・トゥ・フェイス以外でも比較的効果的なコミュニケーションは可能になってきていると思います。LINEスタンプのようなもので感情も表現できますし、非同期性が実現できたり自ずとログにも残るといったような、ツールならではのメリットもあります。

しかし、例えリモートでやっていても、定期的にチームや会社で集まりそこで関係性を構築すると離れても仕事を進めやすいというのはありますよね。最初の一定期間をフェイス・トゥ・フェイスで一緒に働いた後にリモートに移ったほうが効果的とかもあると思います。弊社でも、グローバルチームはお互いどちらかの拠点に定期的に集まることをよくしています。リモートで飲み会をやっているチームもあります。

麻衣子:関係性や円滑なコミュニケーションのためですか?

横道:そうですね。フェイス・トゥ・フェイスが効果的であるということを意識しながら、今は多様性やタレント獲得などの観点で、リモートワークやリモートチームを選択肢にいれて両立を試みるのも全然ありだと思います。

私も普段はチャットでのコミュニケーションが時間的にはむしろメインです。ですが、チャットだとリードタイムがムダに伸びるだけで効果的でないなとお互い感じれば直接話したり、ビデオ会議をつなぎます。この原則もゼロイチの話と一緒で、最も効果的なのはフェイス・トゥ・フェイスだよね、と言っているだけで、何が何でも常にフェイス・トゥ・フェイスでやれという話ではないんです。

そういう話だと、少し脱線しますが「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」の「2-3週間から2-3カ月」というのも18年前は確かにこれでも短かったのでしょうが、今だと1日に何十回、何百回もデプロイやリリースができるテクノロジーがありますよね。時代の変化に伴って数字は古く感じるかもしれませんが、相対的に短いリードタイムを実現できるようにしてゆくことは今でも大事です。

アジャイルはゼロイチではない。自信をもってアジャイルに挑戦しよう

横道:もう一つ重要なことは、そもそも「agile」という単語の日本語訳は「機敏な」ということです。英英辞書を引くと『able to move quickly and easily』と書いてあり、素早く動きを変えているというようなイメージです。アジャイルは「機敏な」という形容詞であって名詞ではありません。カッコイイやカワイイなどと一緒ですね。

つまり形容詞であるアジャイルはゼロイチにはならず、アジャイルであるアジャイルではないという二元論のような考え方はそもそも存在しないということです。あくまで度合いの話であって、よりアジャイルか、あまりアジャイルじゃないという見方をすることも大切です。 ほんの少しでもアジャイルである状態から、ひょっとすると宇宙一アジャイルであるというところまで段階がなだらかに続く、グラデーションのイメージを持つと良いと思います。

麻衣子:宇宙一アジャイル…!

横道:これに関しては個人的に2つメッセージがあって、「これをやらないとアジャイルじゃない」ということはない、ということと、「これをやっていればアジャイルだ」というものもない、ということです。

前者については、例えば、スクラムをやっていなくても、このアジャイルの価値観に共感して継続的な改善を進めている、なども、アジャイルの道にいると言ってもいいとも思います。

麻衣子:守ればいいとなると結構広いですね

横道:そうですね。これからアジャイルに触れられる方で躊躇している方がいたら、少しでもよくできることがあったらなにかやってみて欲しいなと思います。

本当に幅広いので、たとえば「うちの会社は全然アジャイルじゃなくてだめだ」というような過剰な卑下をしてほしくないと思います。

組織の習慣で「アジャイルソフトウェアの12の原則」に一致しているものがあるんじゃないでしょうか。自分はフェイス・トゥ・フェイスのコミュニケーションを大事にしているなとか、あの人も大事にしている、というようなことがあるはずです。それを一つでも見つけてそれをきっかけにして欲しいと思います。それを見つけることがアジャイルの一歩であり、自信持ってより良くしていきましょうと言いたいです。

また、同様にせっかく良い価値観のもと皆働いていて前進しているのに、「ペアプロをやっていないからあのチームはだめだ」というような、他者否定的な考えを持つ必要ももちろんありません。

後者についてですが、これをやっているのでアジャイルです、おしまい、というものもないので、無限に行く道があります。私も含めてアジャイル実践者たちは「僕たちの組織はもうアジャイルだよね」と止まってしまわず、Amazon や Microsoft、 Netflix 、Spotify など世界中の成功している企業を見渡して、それらを上回るような道を歩んでいきたいなと思います。

アジャイルの世界に終わりは無いと思います。世界一機敏で成功しているチーム、プロダクト、組織ということを目指せると思います。

麻衣子:追及すればエンドレスですね。

横道:アジャイルは本当に奥が深いものだと思います。すぐにでも飛び込んで欲しいと思いますし、その先はいくらでもあり、それをずっと突き詰め続けるのがアジャイルだと思います。

麻衣子:世界一といいつつも、A社の世界一の姿とB社の世界一の姿はまた別ですよね。

横道:その通りですね。アジャイルの度合いも0から無限大に向かって直線で示してしまうのも違和感がありますね。方法はそれぞれで違っているでしょうし、その会社の特性によっても変わってくるでしょうね。

アジャイルに、これをやれば必ずうまくいきますというベストプラクティスはありません。あくまで特定の状況下で上手くいった事例があるだけです。100社あれば100個のパターンがあるので、アジャイルはコミュニティでは情報交換や事例発表の機会が多く、キャッチアップした情報を持ち帰っては自社の背景にあわせて取り入れ、各現場で切磋琢磨しています。

たとえばスクラムは経験主義的と言われるのですが、これをやって実際にうまくいったから体系化しましたというものです。私はこれでうまくいった、あなたはどうですかというものです。

アジャイルの方法論を実践する際に、スクラムを導入してみることが多いと思います。その際に自分たちが上手く進められず、自分たちに問題があることに気が付きます。スクラムはそのように自分たちの課題を気付かせてくれるようなフレームワークでもあるんです。スクラムをやってみると世の中はこれで成果を増幅させているチームがあるのに、私たちのチームは全然うまくできない、何でだろうと考えさせられて、そのギャップである課題を明らかにして少しずつ改善していく流れができたりします。改善の話は、12の原則の一番下にありましたよね。定期的に振り返って、より効果的にする。

アジャイルのはじめかた

麻衣子:横道さんは副業でもアジャイルの導入支援を行っていますよね。「アジャイルをやりたい」ですっていうご相談が企業から来たときに、まず何から始めるのですか。

横道:「まずは何をすべきか」とよく聞かれるのですが、その前に「なぜやりたいのですか。なぜそこでアジャイルなのですか」と聞くことにしています。 この問いはアジャイルを始める際、一番重要になる問いかけだと思います。そして特に、経営者やマネジメント層がどう思っているのかが重要です。その後はもう、ケースバイケースです。

最近関わっているアジャイル支援は、これからキックオフして立ち上げるというタイミングのプロジェクトで、アジャイルの何に価値を見出すのか、これまでのユーザー企業対ベンダーという構造をどう崩すのか、それを崩してまでなしとげるべきことはなんなのか、どのようなチーム構成をとるのか、どうすばやく意思決定を進めるのか、というような話をしながら、ミニマムな要件がどこにあるのかを探す要求探索のフェーズに入っています。マネジメント層や現場のリーダー層が価値観に深い共感を示して熱意を持って取り組んでいるため、成功の香りがしています。

アジャイルをはじめるならまず「振り返り」だけでも良い

麻衣子:とはいえ手段を教えてくださいというような人はいらっしゃらないですか?哲学的に感じるので、じゃぁ何から始めていけばいいのか……みたいになりそう

横道:そうですね。価値観に共感しているのであれば、もちろん具体的な実践を始める必要がありますし、それは早ければ早いほどよいです。開発のプロセスとしては、まずはスクラムを実際に実践してみるのが良いと思います。リーンソフトウェア開発の考え方を使うのも良いですし、XPのプラクティスでも、継続的イテレーションなど欠かせないものがたくさんあります。もちろんデザインスプリントのようなプロダクト探索のためのプラクティスも有用でしょう。

もしそれらが難しい事情がある場合は、定期的で継続的な振り返りをまずはじめて見るのがよいと思います。自分たちのやっていることを立ち止まって振り返って、少しでもいいから変えていくということを定期的にやることが大切です。

これはまず1人で自分の働き方の振り返りをやってもいいと思います。次に身近なチームメンバーと仕事の振り返りができるとなおいいですし、チーム全体でやれるとなお良いです。振り返りから始めてみて、課題や有りたい姿をベースに、方法論をいろいろ勉強してみて、その中から取り入れられそうなものというものをやっていくのでも良いと思います。

弊社内でも土台として最初にこれを始めることが多く、別にスクラムなどの方法論を導入していなくても、継続的な改善が習慣化されるだけですごく効果的なチームになったりすることも多いです。

スクラムって?アジャイルと同じこと?

麻衣子:いまさらな感じですが、そもそもスクラムってどんなものですか?

横道:スクラムという、こういう枠組みで仕事を進めましょうというフレームワークと呼ばれるものです。スクラムガイドという、スクラムの創始者の方々が書いたドキュメントがあるのですが、18ページぐらいの簡潔なものです。


スクラムガイド

麻衣子:この二人!

横道:さっきのアジャイル開発宣言の署名にも入っていた二人ですね。名前のついたものとしては、グローバルや日本でももっともよく使われているもののひとつです。

スクラムの進め方

スクラムガイドには、

役割を3つ決めましょう(プロダクトオーナー、スクラムマスター、開発チーム
5つのイベントを定期的にやりましょう(スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ
3つのものを作り、アップデートしながら進めましょう(プロダクトバックログ、スプリントバックログ、インクリメンツ

ということが書いてあります。基本的には何かプロダクトを作るための進め方ですが、そうでなくても活用できます。

プロダクトオーナーと呼ばれる、作るものやその優先順位の検討を通じて、プロダクトの生む価値に責任を持つ人と、それを実際に形にしていく開発チーム。あと特殊なのはスクラムマスターと呼ばれる、プロダクトオーナーと開発チームがより効果的に働けるように支援をするという、ちょっと第三者視点でサポートやコーチしていくような役割の人がいます。

3つの役割

これらの3つの役割がいて、その役割の人たちが関わる5つのイベント3つの作成物があります。

アジャイル スプリント

順に説明すると、まずプロダクトバックログと呼ばれる、「何を作るか。どんな価値を生むか」というものが書かれたリストがあります。ここで初めてウォーターフォールとの違いに触れるのですが、このリストの粒度を十分に小さくし、短い期間をぐるぐる回して作っていくというのがアジャイル開発の基本になります。

例えばスクラムでは1ヶ月以内の一定の周期をひとつのサイクルにして物事を進めていきます(スプリント)。たとえばこの周期を1週間に決めたとすると、スプリントプランニングというイベントで、この1週間でどこまで作ろうか、どこまで作れるか、をみんなで話し合ってゴールを決めます。そこからゴールを達成するためのTODOリストのような スプリントバックログと呼ばれるものを作ります。それをもとに1週間で作っていきます。

その1週間の間でもデイリースクラムと言われる、毎日チームの中で「決めたゴールを達成できるか?課題をチームでどう乗り越えるか?」というような話を毎日行います。

そしてできたものを関係者を集めてみんなでスプリントレビューの場で見ます。「この1週間で作ったものはこのようなものです、どうですか。プロダクトの方向性はあっていますか、もっとよくできるところはないですか。」というような話をして市場に出すなり、市場に出す準備をするなり、をします。それが終わったらこの1週間の僕たちはどうだったかという振り返り(スプリントレトロスペクティブ)をみんなでして、さらに今後どうやって効果的に進めていくのかという話をします。その後、またスプリントプランニングをするという、この一連のサイクルをくり返していきます。

ポイントは、この短い期間の中でも「ちゃんとみんなで目に見える価値あるもの(=インクリメンツ)をつくってフィードバックを得ましょう」ということです。

IMG 5117

経営陣こそアジャイルを理解すべき

麻衣子:なぜこんなに世間から「アジャイルは方法論だ!」と思われてしまったのですか。

横道:ひょっとすると、「なんとかビジネス課題、組織課題を解決したい。藁をもすがる思いですぐに判り易いものがほしい」という受け手の思いが、方法論の部分だけを強調してしまったのかもしれません。あとは、良いマインドセットが定着している組織は、価値観の部分が当たり前すぎて述べられなくなっていたり、方法論もたくさん試されているので、情報量として目に付きやすいというのはあるかもしれません。

麻衣子:「アジャイル ウォーターフォール」と対比して考えたり検索されることも多いみたいです。

横道:ここ数年ぐらいで DX(デジタルトランスフォーメーション)という言葉が日本でよく使われており、これまで「ユーザー企業側」「受託企業側」といった分断したソフトウェアの作り方をしていたユーザー企業やSIer企業も、アジャイルを会社としてやっていかなければならないのでは、という危機感が生まれている気がしています。

これまでウォーターフォールのみでやってきていたため、自分たちのやり方をどう変えなきゃいけないのか、ということでウォーターフォールと比較して検索するのかもしれません。ただ、繰り返しになりますが、「これをやればアジャイルです。おしまいです。」というものはないですよ、というのは強調しておきたいです

麻衣子:それぞれの会社でベストな答えっていうのは絶対違ってきますよね。

横道:ウォーターフォールでは、長期間にわたって「これを作る」と要件を決めて、さらに長期間をかけて作りますよね。たとえば1年後にモノができ上がったものの、1年も経てば市場や社内の事情が変わって使い物にならなくなってしまう、というのはよくあるケースです。

その発想でも問題のないソフトウェアは一部分ではあると思いますが、すべてのソフトウェアをそう作るのは危険です。「価値を生むもの」が何かをきちんと探求し、最小限でどうその価値を実現できるかを考え、そして小さく作って早く価値を出すことが必要です。 かつては、サーバーを調達するのに稟議、発注して稼働まで早くても数ヶ月かかっていたことも成約になっていたと思いますが、今ではクラウドプラットフォームを利用して数クリック、数秒で作れるという時代がきてもいますしね。そして、なによりもそれを支える自律的なチームが必要です。

麻衣子:アジャイルに進めていくために自社でどのような取り組みを行えばいいのか、というのは、やはりそれぞれがちゃんと導き出さないと駄目だということですね。

横道:そうですね。僕は経営者や意思決定層の方々がアジャイルをしっかり理解するのが必須と考えています。周りで「あの会社がアジャイルというものをやって、うまくいっているらしいからうちもアジャイルやりなさい」と、経営陣が本質を理解していないケースがあるとしたらおかなしな話なんです。

また繰り返しのような話ではありますが、アジャイルの世界では『Don’t just do Agile, Be Agile.』という有名な言葉があります。アジャイルはするのではなく、そもそもアジャイルな状態になることを目指そう、というものです。そのためには企業ビジョンやプロダクトビジョン、技術力獲得への投資、チームの成長へのサポートや権限委譲、従業員エンゲージメントが高まるような組織運営、などさまざまな要素が必要ですし、それらが持続性のある「組織文化」という形で保たれるようにになっている必要もあります。どう考えてもそこには経営者の正しい理解と後押しが必須ですよね。「アジャイルをする」ものだと思っている経営者やマネジメント層がいると悲惨だと思います。

麻衣子:そうですよね。対等じゃなくなってしまいますし、「やれ」になってしまうとアジャイルの原則にあっていないと感じます。エンジニアだけでなく、経営層の人がどう勉強すれば良いのか、アドバイスをお願いします。

横道:私はコミュニティーやカンファレンスの裏方もやっているのですが、ぜひそれらに来てほしいです。例えば2019年7月8日に「アジャイルリーダーシップサミット」という、いわゆるエンタープライズ系やウェブ系など垣根なく、アジャイルを推進している人が集まってディスカッションをするイベントをやります。実践者たちからカルチャーショックを受けるかもしれませんが、こういった場に来てそのエネルギーを感じてほしいと思います。

麻衣子:経営層に参加してもらえるように説得する材料ってありますか。

横道:それこそ「DX」にかこつけて説明してよいのではと思います。また、実践されている現場を直接見に行ってもらうのも良いと思います。最近だとデンソーさんやヴァル研究所さんがアジャイル導入に成功していますので、そういった会社さんへ、現場を見に行かせてもらうこともできるのかもしれません。やはり実践の現場や議論の現場を見て実感を持ってもらうというが一番だと思います。まさしくアジャイル宣言と一緒で、動いているもの、場などを直接見てもらわないことには動かないと思います。

麻衣子:そういう見学ツアー的なものも積極的に受け入れている会社さんもあるんですね。

アジャイルが合わない会社は世の中にひとつもない

麻衣子:アジャイルというのは、一言で表現するならば、何と言えるでしょうか。

横道:以前Facebook上で、アトラクタという有名なアジャイルコーチングの会社のアジャイルコーチの方が「アジャイルを学生に一言で説明するとしたら何といいますか」とコミュニティーに呼びかけたんです。そしたら数十件の異なる表現が返ってきたんです。それこそがアジャイルの多様性表しているなと思います。

麻衣子:横道さんはなんと答えましたか?

横道:僕は「楽しい」というキーワードを入れたと記憶しています。僕自身は「いかに楽しく成果を出すか」というところを大切にしたいと考えています。今の会社もそうですけど、自分も周りも、楽しみながら最高の成果を出してほしいと思っています。

「うちにアジャイルは合わない」ということはない

麻衣子:たまに、スクラムを始めたけどうちに合わないなという人がいると思うんですが、それは方法論から入ってゼロイチの考え方だからそうなるのであって、この原則に従っていればそんなことはないということですか。

横道:僕はそうだと思っています。スクラムを常に完璧にこなすことは難しいですし、うまくいかないケースもよくあります。そう感じてしまったのは、スクラムをやること自体を目的にしてしまったことが問題なのかもしれません。そして、そもそもスクラムをうまくできなかったからアジャイルではないのか、というともちろんそうではありません。

麻衣子:アジャイルというのは100社あれば合わないところは1社も存在しないと。

横道:僕はそう思っています。人間が働いている以上、アジャイルがまったく合わない組織はないと思います。アジャイルの世界は多種多様です。自社に合うアジャイルの形を、「アジャイルソフトウェアの12の原則」に照らし合わせて、考えてみてほしいと思います。

ちなみに弊社でも、私のアジャイル推進組織では、弊社ならではのアジャイルの捉え方を日々考えながら組織の成長を支援しています。もしご興味ある方がいましたら、募集要項をご覧ください。読んでいただくと、ここからも方法論だけにはこだわっていないことが見て取れるかと思います。

アジャイルコーチ(Agile Coach)
https://linecorp.com/ja/career/position/1405

アジャイルをはじめる時にオススメの参考書

麻衣子:アジャイルを勉強するのにお勧めの参考書はありますか?もっと勉強してみたいです!

横道:ベストセラーになっていますが『カイゼン・ジャーニー』は方法論にあまりこだわらずに書かれていると思います。社内で研修した後、はじめにオススメするのはこの本でもあります。『エンジニアリング組織論への招待』もかなりアジャイルのことを取り上げていて、特にエンジニアの方に水が合うかもしれません。テイストがかなり異なる2冊ですので、まずは好きな方を読んで、小さなことでも良いので何か実践して改善を続けていくのがよいと思います。

麻衣子: もっと方法論を教えてもらえるのかと思ったらかなり哲学的な話でわかりやすかったです!ありがとうございました!

最後に座右の銘を書いていただきました。「楽しく結果を出す!!」


この記事を書いた人
仁田坂 淳史
株式会社ZINEの編集者。技術評論社で『WEB+DB PRESS』の編集、mixiで「Find job! Startup」の創刊/編集を経験し株式会社ZINEを創業。テクノロジーの取材が専門分野

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

React

テーマ クラウド入居者管理システムのフロントエンド開発(リモート可)
勤務日数 2-3日/週
報酬 4万円/日
必要スキル React
勤務地 東京
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

Go

テーマ 家族型ロボットのサーバサイド開発
勤務日数 3-4日/週
報酬 5万円/日
必要スキル Go GCP
勤務地 東京
リモート 相談可

AI

テーマ AIを活用した新規事業立ち上げの技術顧問
勤務日数 週1日〜
報酬 5万/日
必要スキル Python、AIの知見、新規事業立ち上げの経験
勤務地 東京
リモート リモートと常駐のMIX

PMポジション

テーマ 複数のプロダクトごとにPMを必要としているため急募
勤務日数 2-3日/週
報酬 5万円/日
必要スキル PMとしての経験、PHP、JavaScript
勤務地 東京
リモート リモートと常駐のMIX
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)