Avanade tech talk #1イベントレポート【前編】—— アジャイルとスクラムを徹底解説

イベント
2019年7月1日(月)、アバナード株式会社による「Scrum on Azure DevOps - Avanade tech talk #1」が開催されました。 「Azure DevOps」と「スクラム」をテーマに、アバナード開発部隊の取り組み事例と明日から現場で使えるティップスを、実際のデモと共に紹介した今回のイベント。 本レポートでは、イベント前半の講演内容をお届けします。
Avanade tech talk #1イベントレポート【前編】—— アジャイルとスクラムを徹底解説

イノベーションが生まれるオフィスと会社を

オープニングトークとして、アバナードってどんな雰囲気の会社?について語る、代表の安間 裕氏。軽快なトークで会場の雰囲気を和らげてくれました。

▲安間 裕(あんま ゆたか)/アバナード株式会社 代表取締役

今日はTECH PLAYさんの素敵な会場でイベントをさせてもらえることをとても嬉しく思います。弊社は先日、泉ガーデンタワーという場所に移転をしたばかりなのですが、その際、この会場のようにオープンで風通しの良いカフェのようなスペースを設けました。そして、会社の空間そのものを『デジタルスタジオ』と呼んでいます。

それはなぜかというと、各会議室にカメラやモニターを標準装備して、会議室でミーティングをやっている裏でローコード開発のエンジニアがその様子を見ながら形にし、作ったものを会議室に持ち込んですぐ共有する。しかもそれが単なるPoCではなく、そのまま動くモジュールになっている!みたいなことを実現したいと考えているんです。そんな風に瞬時にアウトプットできるオフィスにしていくことで、エンジニアの方々が集まる集団にしていきたいと思っています。

コンセプトは、「来なくてもいいのに来たくなっちゃうオフィス」。オフィスに来ると遺伝子爆発的に色々な発想が生まれて、イノベーションが巻き起こり、新しい仕事が生まれる。もし会社に来れなかったとしても、テクノロジーは距離と時間を超えるので議論には問題なく参加できる。そのような文化や仕事のやり方を兼ね備えたオフィスであり、会社にしていきたいと思っているところです。

また、最近私がよく言っているのが、“Encourage Failure” という言葉。「失敗を恐れるな」ではなく「失敗しろ」と言っているんです。失敗のないところに新しいアイデアは生まれてこないですし、学びやチャレンジしようという気持ちは出てこない。会社のカルチャーを変革することによって、イノベーションを起こしたいと思っているわけです。きっと、今日のメンバーもたくさん失敗しているはず。

とにかく私はみなさんとたくさんお話をしながら、新しいことに取り組んでいきたいと思っています。今日は、そんな弊社から生まれた事例や学びを得て、会社に持ち帰っていただければと思います。どうぞよろしくお願いします。

アジャイルは、プロセスや方法論ではない

▲髙橋直樹(たかはしなおき)/テクニカルコンサルタント テクニカルアーキテクト アジャイルコーチ

今日はAvanade tech talkの第1回目ということで、スクラムをAzure DevOpsの上でどのように動かしているのか、そしてアジャイルの難しさについて話していこうと思っています。後半のデモ実演で効率よく学んでいただくために、アジャイルの復習からお話していきます。

私は、「アジャイルって何?」と質問された時には、「プロセスや方法論ではなく、文化や考え方である」と、真っ先に答えます。まずここを理解していただきたいです。

ビジネスの変化に対応するには、スピード感を持って対応していく必要があります。結果、昨今アジャイルが注目されています。

今日お話するスクラムとアジャイルは、従来型のウォーターフォールの対立軸としてよく言われますが、これは決して相反するものではないということも、きちんとご理解いただきたいです。

ここからは、実際どんなところでアジャイルが使えるのかについて説明していきます。

スクラムとアジャイルには適用範囲がある

私自身、開発をするならアジャイルの方が楽しいに決まっています。でも、残念ながら全てのプロジェクトに当てはまるとは限らないのです。

これらの3つの条件においては、スクラムとアジャイルでの開発が適しています。

①要件的・技術的に複雑で困難な場合
②ビジネス上の変化が発生する場合
③比較的小規模の場合

②においては、特にイノベーティブな市場である場合、日々の変化が著しくなります。従来のようなエンタープライズ的な開発でリリースまで何ヶ月も要してしまうと、機会損失が生まれて結果的に収益が下がる。そこに我々は機敏に対応しなくてはいけない。そのためのアジャイルなのです。

ところが、実際にはアジャイルの普及はそう簡単には進まず、いろんな壁が立ちはだかっているのが現実です。ここからは、アジャイルへの壁とその乗り越え方をお伝えします。

アジャイルへの壁と、それを乗り越える方法

特に日本でうまくいかない要因として顕著に現れているのが、「従来の商習慣への固執」「従来と異なる価値観への拒絶」、試したけれどうまくいかないという「過度な期待と落胆」、そして「数々の誤解」です。これらがアジャイル普及の壁になっています。

壁を壊すためにどういうアプローチをするのかというと、まずはこれまでとは違った「適切な契約」をしなくてはいけない。今までは目の前にあるものに対して予算をとってお金を払ってきましたが、そうではなくなるので、お客様からよく「どうやって予算取りしたらいいのでしょうか?」と聞かれます。

ここは冒頭にもお伝えした通り、文化形成が必要な部分です。ですから、お客様と一緒に悩みながら進んでいかなくてはなりません。お互いが歩み寄りながら、どうやったら違う世界にいけるのかと一緒になって取り組んでいく必要があります。

だからアジャイルへの壁を壊すには、「継続的な活動」による「文化の醸成」が必要なのです。

スクラムはアジャイルな開発手法のひとつ

ここからは、今日のメインのデモにも出てくるスクラムとは何か?という話に移ります。

スクラムとは、アジャイルな開発手法のひとつで、複雑なプロダクトを開発・維持するための軽量なフレームワークです。スクラムの中で定められているフレームワークというのはあくまですごく小さいものです。これらは、価値の高いプロダクトを作るために提供されています。

ちなみに、実はご存知ない方も多いかと思いますが、XPというエクストリーム・プログラミングより歴史が長いものなんです。

また、スクラムとは、次に話す「3つの柱」とそれを実現する為の「5つの価値基準」を元に成り立っている理論です。この理論について話を聞くと、みんなすぐわかったような気になりがちですが、実に習得が難しいもので、やはり実践しながら学んでいく必要があります。

スクラムをつくりだす「3つの柱」と「5つの価値基準」

スクラムには3つの重要な柱があります。

一つ目が、「透明性」です。これは、常にオープンで「見える化」しましょうということです。

二つ目が「検査」。これは品質に関してです。アジャイルに関するよくある誤解として、「品質をおざなりにしてでも前に進むんでしょ?」「バグが出ても気にしないんでしょ?」といったことが挙げられますが、本質的にはそうではありません。

しっかり定期的に検査をして前に進む。そうすることで、次に進んでも高品質なものが維持できる。だから、決して検査に手を抜く訳ではありません。

そして三つ目は変化を受け入れ臨機応変に「適応」して行きましょうと、ということ。

これらの柱を支えるために存在するのが、5つの価値基準 です。

一つ目は「確約」です。私の意訳になりますが、「献身」という意味もあると思っています。ゴール達成するためにどうやって尽くしていくのか。

そして、「勇気」を持って立ち向かっていくことです。見積もりなんかに出やすいのが、どうしてもバッファを積んでしまって、「もうちょっとできるはずなのに…」 ということがあります。ここには勇気を持って向かう気持ちが大事です。

また、目の前の最も重要なことに「集中」することです。ありがちなのが、長い開発になると、いつか必要になるかもしれない、あったら便利かもしれない…なんて考えて開発してしまうこと。こういうものは、だいたい使われないんです。

加えて、いいものも悪いものも全て包み隠さず「公開」していくこと。

常に自分たちや関係する人全員に「尊敬」の念を持って、尊重しながらやっていくこと。

これらがスクラムにおける、大事な価値観です。

スクラムの流れと全体像

ここからはポイントを説明していくのですが、その前に、全体像を把握しておきます。

スクラムのフレームワークを表した全体像がこちらです。

これらの流れを、最大でも4週間で実行していきます。

スクラムのポイント①スクラムを取り巻く人々

スクラムにおける重要なポイントの一つ目は、登場する人物です。

まず、製品の使用に関して責任を持ち、開発の価値を最大化すべきプロダクトオーナー(PO)は、常に一人にすべきです。

開発を行うチームは、常に自己組織化されている必要があります。機能横断型チームというのは、インフラでもフロントバックでもいろんな方々が特定の業務を行うために集まったチームのことをいいます。

スクラムマスターは、このチームの人々が働きやすくなるように存在します。

これら3つを合わせてスクラムチームが出来上がります。

そして、この外側にステークホルダーが存在していて、チームには含まれません。レビューの時にのみ登場してきます。

これらの関わる人々の関係性をもう少しわかりやすくすると、次の図のようになります。


このスクラムの中で重要になるのは、

①各々の役割をきちんと守ること
②役割を持った人がしっかりと働けるよう適切な権限を持たせること

です。これがスクラムをきちんと機能させるための非常に重要です。

そして、一番ここで大変な役割はPO(プロダクトオーナー)です。なぜなら、見てわかるように、彼らは開発側とステークホルダーの板挟みになってしまうんです。ですから、POは本当に大変な役割。

私はいつもお客様に、「大事なのは組織としてPOをサポートすること、POを尊重することです」と申し上げます。場合によっては、この図には出てこない経営層からいきなり何かを言われることもあるので、そういう時にも組織としてPOを守ってあげることも大事なんです。

スクラムのポイント②タイムボックス

スクラムにおけるポイントの二つ目は、タイムボックスです。

なぜタイムボックス化するのか?それは、集中することで「実装を最適化」し、不具合やトラブルにおける「被害を最小化」するためです。

ここは、従来のウォーターフォールとスクラムの比較をしてみましょう。

まず実装面はでは、ウォーターフォールは無駄な機能を作りがちになります。結果、多くの機能が使われないだけではなく、複雑化して保守コストもかかります。

スクラムは、最小限の機能のみ作成し続けることで必然的に最小構成になります。ビジネスにおいても、必要な時に必要なものを作ればいいという考えです。

不具合が出た時、ウォーターフォールでは手戻りが大きいです。開発者としては不要だとわかっていながらも、一度時間をかけて作ったものをなかなか簡単には捨てられないため、抜本的な対策を打てなくなります。この負債に対して利息がつくことになりますね。

スクラムの場合は、最大でも4週間の損失で済むので、その程度であれば捨てやすい。そして失敗から得られる気づきをプロダクトに反映することができます

スクラムのポイント③作成物

スクラムにおける最後の重要ポイントは作成物で、下記の通りです。

スクラムに入る前のビジョンやコンセプトの定義が大事

スクラムについての本を読んでいると、フレームワークの解説が多いのですが、私たちアバナードは、作成物のバックログがどうできるのか、そして、そのビジョンやコンセプトが大事だって思っているんですね。しかしながら、ビジョンはどうしても間違えられがちなんです。

コンセプトとビジョンをはき違えると、適切なバックログは生まれないですし、結果的にちゃんとビジネスに寄与する製品にはならない。ですから、ここが非常に大事なポイントだと思っています。

ここがブレると、終わらないバックログが山積みになっていたり、「進んでみたけど、これ使えるんだっけ?」「儲かるんだっけ?」 なんてことも発生してしまうのです。

アジャイルとスクラムについて理解を深めたところで、次からはDevOpsの解説とデモ実演に移ります。

後編はこちら!

関連するイベント

おすすめのコラム

アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは?

イベント

アビームコンサルティング(以下、アビーム)ではアジャイルを正しく理解するためのイベント「アジャイルマニフェスト...

アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは?

システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?

トレンド

どうも、totokoです。 SNSやWEBサービスを始め、今はとにかくなんでもネットに繋がっている時代です。 そして同...

システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?