アジャイルもDevOpsも費用対効果より機会損失で考える　DASAアンバサダーが贈るこれからの開発現場へのアドバイス

従来の開発計画とアジャイルの計画の違い

やっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。

従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見積もりをする。見積もりするときの変数としては費用の部分ですね。何人月でやるのか、もちろんあとは期日というかたちになります。

ちなみにすべての要件が固定された状態で始まっているのは、始まる前からデスマーチが確定みたいなものになるので気を付けてください。

計画はいいとして変更するときどうするのかと言うと、固定されている要件は基本的に契約の縛りとかがあって動かせないです。動かせないのでどうするかというと、納期を延ばしてもらうとか、もしくは人を増やしてなんとかするか。大きな声では言えないですが、もしくは品質をごまかすのか、という話になってきますね。

アジャイルの場合はどうするのかというと、この発想からぜんぜん違うんです。アジャイルではまずチーム固定です。そのチームがしっかりと自己組織化され、自分たちである程度すべてのことができて責任をもって、そのチームが成長することを期待するモデルです。

期日のところは、スクラムではタイムボックスという発想があって、1週間や2週間固定でその都度、例えば2週間固定なら2週間ごとに動くものを提供し続けるというモデルを取ります。これはなんでこうなっているかというと、先ほどのステイシーマトリクスでも見ていただいたように要件は固まらないからです。

ビジネスモデルが確立していなかったり競合他社の状況やテクノロジーが新しくなると、どんどん変わっていっちゃうんですよね。最初に全部の要件を洗い出すのを諦め、代わりに粗々なものも含めて今ある現状を全部出していくんですが、しっかりと固まって計算できる粒になったものを優先順位を決めて上から順にやっていくというスタイルに変えるんですね。

粗々すぎて曖昧すぎてわからないものはどっちにしろ始めたってどうせできないです。もしくはお客さんの満足のいくものにならないので先送りするという発想です。ただ、タイムボックスで区切っていてそこの中でしっかりとモノを作っていけきるので、そういうスタイルが今は合っているよということですね。

アジャイルは計画しないわけでも予測ができないわけでもない

アジャイルなやり方をやっていると計画が立てられないじゃないかとか、いつできるかわからないという話をよく聞かれるんですけど、ぜんぜんそんなことはないです。それを示しているのがこちらなんですが、上のほうを見ていただくとスプリントと書いてあるところ、これがタイムボックスですね。2週間なら2週間固定で動かしていきます。

このときに当然ですけどチームメンバーが予測を立てます。計画をして、結果的に計画を下回る結果になることもあります。前回までのスプリントの実績を踏まえて、次のスプリントの見積もりをして、実際に今度はこなすんですよね。2週間なのですぐに結果が出ます。結果が出ますので、それに対して学べるわけですよね。そういうサイクルをうまく使っていきます。これをやっていくとだんだん安定してくるはずなんですよ。

毎回2週間ごとに失敗と成功を繰り返して、そこで軌道修正や改善をしていくことによって、その結果として安定してくるので安定してきたら予測が付きますよね。あと何回スプリントを回せば終わるのかというのが見えてくるというやり方をします。なので、決してアジャイルは計画しないわけでも予測ができないわけでもないということを覚えておいてください。

あとはアジャイルなチームというときに、先ほども成長に期待するという話をしたんですが、1つだけコツがあるのでお知らせしておきます。アジャイルの場合は極論で言ってしまうと、アジャイルチームの中での透明性はあったほうがいいんですが、マネジメントする方はアジャイルチームの中にわざわざ足を踏み入れる必要はありません。

マネジメントにはこの図でいうところのインプットとアウトプットのところに責任をもってもらえばいいです。もしくはそこの確認をしてもらう。アジャイルなチームは自己組織化されていて、あと機能横断的な、要するにフルスタックなチームができればいいので、そこを信じてあげてくださいというやり方になります。

マネージャーはサポートをしてあげてください。チームの成長を期待してくださいという感じですね。

スループットはそんなに簡単には上がらない

この話はあとで資料を見ていだきたいので中の説明は飛ばしますが、ウォーターフォールだったりスクラムだったり、あとはカンバンもここで紹介をしているんですけど、リリースの回数とそこからくるフィードバックの回数を比較しています。これは大雑把に比較をしていますけど、6ヶ月プロジェクトで36の機能があった場合には、単純に計算するとウォーターフォールは1回のリリースで1回のフィードバックしか受けられないと。

それに対してスクラムだったらざっと計算するとここに挙げたようなかたちで12回のフィードバックが受けられますよというかたちですね。なので短い期間でやっていくので失敗することもウォーターフォールほどそんなに大袈裟にはならない、傷が浅いうちに済むというモデルになっているというのがポイントです。

もう1つお知らせしておきたいのがリトルの法則というものですね。これも話すと長くなるんですけど、基本的なアイデアができてから、それが実際に動く機能として提供されるまでの期間をリードタイムとします。そのときにやらないといけない作業をWIP、仕掛かり作業といって、1日だったり1週間でどれくらいできるのかというのをスループットですね。

みなさんエンジニアだと思うのでスループットとかは説明不要だと思うんですが、そういうかたちで見ていくとリードタイムを短くする、要するに早いフィードバックをもらうようにする、価値のあるものを速く提供するにはどうしたらいいかというと単純な計算になります。これがリトルの法則ですね。

リードタイムというのは仕掛かりの作業をスループットで割ったものになります。なので仕掛かりの数を減らせばそれだけ速く提供できるということですね。なのでスクラムの場合だと1週間とか2週間のタイムボックスを作ってその中にやるものを制限することで結果を早く出すようにしています。とは言えスループットというのも上げたいんですよね。でもスループットはそんなに簡単には上がりません。

クリエイティブとルーティンワークは分けて考える

チームが大事ですとこのスライドには載っていますが、チームになるためには共通の目的とか成果というものが必要ですよということが書かれています。チームという言葉をよく使うと思うんですが、本当にチームになっているのかけっこう怪しいなということをここのスライドでは示しています。単純に言うと同じ景色を見ているのか。同じ目的をもって同じように苦しんで楽しんでやっているのかどうかというのがチームとグループの差かなと考えています。

チームのためにはチームの中の透明性と価値を生む流れを作ること、あとはムダを取っていくことが大事になります。これはアジャイルコンセンサスと呼ばれているものですね。もう1回言いますが、アジャイルではチームがとても鍵を握っています。

反復して構築して学んで改善するというサイクルを取るという意味ではアジャイルな開発もそうですし、あとはビジネスも仮説検証でけっこうそういうかたちになってきています。

実際に考えていくときにはいろんなパラメータがあって、どうやっていけばいいのか難しかったりするのは事実です。そのときに1つの考え方として考えてほしいのがクリエイティブとルーティンワークを分けることです。これらはもちろん分けて考えられるものではないんですが、一旦分けて考えるとけっこう頭がスッキリするんですね。

例えば顧客やチームとの対話とか設計や開発のそのものの作業ですね。計画・ふりかえり・改善というものはクリエイティブなものですよね。それに対してルーティンワークとしては、スクラムの中にあるイベントとかスクラムのルール自体がけっこうルーティンワークで成り立っています。繰り返し可能なかたちになっているんですね。

あとはCI/CDのパイプラインというものもそうですね。これらから学んでデータを提供してくれるので、そこからクリエイティブな仕事をするという関係になっているので、こうやってちょっと分けて情報整理するといいかなと考えています。

スクラムとは

スクラムの説明はザッとだけします。まずこんな感じです。ロールが書かれていて、3つのロールがありますという感じですね。細かいことは省略します。

スクラムにはその3つのロール以外に3つの作成物ですね。プロダクトバックログとスプリントバックログがあります。黒いボックスになっている5つのイベントというのがあります。ここでは詳細は説明しませんが、これらのイベントは全部時間が決まっています。

例えばデイリースクラムなら15分間とか、すべてタイムボックスで決まっているんですね。そういったかたちで繰り返し可能で反復できるようなかたちにして持続可能で成長するチームをサポートするようなやり方というのがあります。今日はそれだけ紹介します。

あとはCI/CDのパイプラインですね。実際にアイデアが出てから価値を生むまでの流れは、ここに挙げたのは一例ですけど企画して要件を決めて、タスクに割り当ててコードを書いてビルドして機能にしてくっつけてリリースみたいな感じの流れになるじゃないですか。見たときには継続的インテグレーションのCIと継続的デリバリーまたはデプロイメントというのが、だいたいこの辺をカバーしています。《https://speakerdeck.com/tnagasawa/aziyairutodevops-hazimeruqian-ni?slide=28》

どちらかと言うと後工程と言われているようなところに自動化をするような要素があるよというところですね。ここの場所は覚えておいてください。CIとかCDをやることによって学びの機会がどんどん増えてデータが集まってくるのでクリエイティブな作業もどんどんよくなっていくよという関係になっています。

ちなみにCI/CDとかだとAWSのCodeStarとか、MicrosoftならAzure DevOpsですね。私がもともとプロダクトマネージャーとかをやっていた製品ですが、そういったようなところとかが活躍できるツールになります。ここまでよろしいですかね？　アジャイルの話をザッとしました。

ビジネスも開発も運用もプロダクトに対してもっと歩み寄る

ここからはDevOpsを話しますね。DevOpsはよく開発と運用の対立からそれを脱却するムーブメントと言われてます。アジャイルはアジャイルマニフェストという宣言があるんですが、DevOpsには明確な定義とか宣言とかはありません。

ざっくり簡単に説明すると、開発と運用はミッションとかメトリクスを測るものとか、方法論とかツールがけっこう違うんですよね。なぜかというと、やっぱりミッションが違うからというところになります。ただ共通しているのはビジネスの成功であることは変わらないはずなんですよね。ビジネスが成功するためにいいものを作りたい開発と、ビジネスの成功のためにしっかりと運用をして止まらないようにするというミッションが違ったりします。

ここで対立が起きるんですね。簡単な話で言うと、アジャイルなやり方にして機能を1週間に1回リリースできるようにしたとするじゃないですか。でも運用側は1週間に1回のリリースは怖いんですよ。リリースして止まったらどうしようという話ですよね。なのでどんどん価値を提供したい開発と、価値を安定的に供給したいために止めてしまう運用というのがよくある課題だったわけですね。といってもこれはもう10年以上も前の話ですね。

そういうときにおすすめしている考え方はビジネスのメトリクスが何なのかという話です。そこに対してどう貢献できるのかで考えていくことですね。昨今だとプロダクトやサービスと呼ばれているものは非常に大事になってきているので、ビジネスも開発も運用もプロダクトというものに対してもっと歩み寄っていってやっていけばいいんじゃないかなという話を、よく経営陣にはざっくりとお話します。

DevOpsとは組織を全部チームにして自分ごとにすること

さっきグループとチームという話があったんですが、「今まで組織とかグループだったところを全部チームにして自分たちの自分ごとにするということ。そこの中で自己組織的にできるような関係にもっていくことをDevOpsと言えばいいんじゃないですか？」という話をしています。

だいたいセクショナリズムで組織が別だったりするわけですが、目的にそれぞれのスペシャリティを発揮できるチームをビジネスと開発と運用で作っていければ、それはDevOpsな活動ではないかと言っています。

そのときにもやっぱりクリエイティブなものとルーティンのものを分ければいいんですが、DevOpsの文脈の中でもやはり共同作業とか今までの考え方を変えましょう、対話をもっと増やしましょうという、簡単に言ってしまうと文化の話ですね。その話とあとは徹底的な自動化。

先ほどの最初に佐藤さんのお話があったようにInfrastructure as Codeもそうですよね。Lambdaの話もそういうのに近いと思いますが、そういった自動化とかそういったテクノロジーをうまく使っていくというのももちろん大事になります。その両輪があるということですね。ここでもこの2つを分けて考えるとスムーズに開発と運用で対話ができるかなと考えています。

次は目標設定の例です。これがいいというわけではないんですが、よく例題として出すのがOKRで見ていくとけっこうわかりやすいかな。詳細説明は置いておきますが、肝は真ん中のところですね。ITとして見たとき、ビジネス側から出てきた目標に対して、ITとしては例えばリードタイムを短くしたいですとか、MTTRを短くしたいです。

それに対して開発と運用は何ができるの？　何を協調できるの？　と、考えていくとお互いのよさを生かせるシーンが出てくると思います。

費用対効果よりも機会損失

よく他のものでも出てくる言葉でK.I.S.S.というのがあるんですね。Keep it short＆simple.というのが大事です。大きな組織なので大きくやるにはどうしたらいいんだという相談がよく来るんですが、大きな組織はやはり大変です。なのでまず小さく始めましょう。小さいチームを作りましょう。

ただ、DevOpsでやるときにはビジネスパーソンと開発と運用が必ずいるようにしてください。どこかが忙しいからいません、よくありがちなのがビジネスの人がいませんとか、あとは運用の話はあとでするから運用の人は後回しというのはやめましょう。小さなチームを作ってそこから始めていくとけっこう学びがあって、大きく展開していくための鍵が見えてきます。

あとは費用対効果を考える前に機会損失をまずぜひ考えてください。上の人にもこの言葉は効きますので。困ったときに「機会損失です」と一言言ってください。あと、資料には進め方のもう少し細かいものを載せてありますので、こちらも興味のある方は見ておいてください。

ということで、まとめです。費用対効果よりも機会損失ということと、ビジネスフォーカスであること。あとチーム指向であること。BMLといった小さく学んでやっていくような仮説検証のモデルというのが、やはり必要になってきます。あと1つのコツとしてクリエイティブなものとルーティンワークというのを分けて考えると何か突破口が見えてきたりするので、やってみてください。

ということで私からは以上となります。私もTwitterをやっていますし、何か今回の話の中で困ったこととかがありましたら、まずお気軽に連絡してもらえればと思います。以上です。