アジャイル開発の概要
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。進行は私、鴨志田と、
はい、今回も島田さんはお休みで、私、辰巳と、
今回引き続きゲストとして、株式会社プラムザ専務取締役、PRIME ORDER事業部の内藤さんにお越しいただいております。
よろしくお願いします。
よろしくお願いします。
内藤さんのPRIME ORDER事業部では、アジャイル開発を行っているというところになりまして、
おかしな言い方ですね、すみません。今回のタイトルは、アジャイル開発って結局開発会社が嬉しいだけでしょ、という尖ったタイトルになっておりますが、
まずはアジャイル開発について、内藤さんからざっくり概要をお伺いしてもよろしいでしょうか。
はい、アジャイル開発のお話は、もちろん我々のお客さんもですね、アジャイル開発って聞いたことないとか、言葉だけ聞いたことありますとか、
あるいは分かってますよっていう方がいらっしゃるんですけど、僕が説明するとだいたい短くてもですね、20分はかかっちゃうんですよ、初めての方にお話しするとき。
そうすると今日の回終わっちゃうので、その中でもいくつかのところにフォーカスを当ててお話ししたいかなと思ってます。
まずアジャイル開発って一番大事なことは、逆にですけど何だと思います?これ鴨志田さんイメージでもいいんですけど。
ウォーターフォール型の問題点
でも前回の話からさ察するにお客様とのコミュニケーションと共通理念みたいなところなのかなって思いましたね。
そうですね、まさにそういうゾーンの話なんですけど、アジャイル開発ってどんなのっていうとですね、結構皆さん知ってる方だと、
例えばデイリースタンドアップっていう毎日会社で立ち話ししてから始めるんだよねとか、そういうプラクティスの話に注目が集まったりする傾向があるんですけども、
どっちかというとそういうのは枝葉でしかなくて、アジャイル開発で一番大切なことは心構えであったりとか、人としてのプロジェクトへの関わり方、そういうところの態度であったりとか、そこなんじゃないかなというふうに思ってます。
実際そういうふうに言われてる部分があるんですけれども、今回のタイトルがちょうど面白いなと思うのは、結局アジャイル開発ってシステム開発会社だけが嬉しいんでしょっていうタイトルはすごく象徴的で、完全に逆なんですよね。
実はウォーターフォール型開発っていうのが昔から、世界でも今はそんなに使われていませんけど、日本だとまだまだたくさん使われている方法かなと思うんですけど、ウォーターフォール型開発っていうのはシステム開発会社しか嬉しくないと思うんですよね。
ウォーターフォール型の開発ってどういった開発になるんでしょうか。
ウォーターフォール型の開発はですね、何を作るのかっていうのを設計書とかであらかじめ細かく決めていって、それをお客さんの承諾を取って、その次の工程に進んでいく。
次の工程は、例えば最初はざっくり設計します。その次はしっかり設計します。その次はすごい細かく設計します。段階を分けて進めていくわけですよね。
もうしっかり設計が終わったら、細かい設計が終わったら、じゃあ実際にプログラミングしますねと。
プログラミングして、できたものをまとめて見ていただくっていう感じなんですけど、すごく途中途中お客さんの確認がたくさん入るんですよね。
これ何でやってるかっていうと、確認しましたよねと。確認してOKってなったからこの設計通りに作っていきますよみたいな形で、システム開発会社が作るものをですね、お客さんに何というか、これでいいですよねって念を何度もしながら作っていく方法なんですよね。
その設計書通りにプログラムができていたら、仮に現場の人たち、ユーザーがこれ使いづらいよと。こんなの誰が使うの?もっとこここういうふうにしたらいいじゃん。いろんな意見が出ると思うんですけど、それが出たとしてもシステム開発会社はその直す必要がないというか、直すんだったら追加料金ですよみたいな形になってしまって、システム開発会社の権利は守られてるんです。
でもお客さんの、まさにそのシステムを企画した方の立場からすると、全然嬉しくないと言いますか。なんでこれを直してくれないんだとか、逆に誰が僕の味方なんだろうって感じになっちゃうと僕は思っていて。
だからウォーターフォール型開発っていうのは非常にシステム開発会社が身を守るための方法。例えば見積もりをするときに、何を作るかが決まってないと見積もれませんよって多分言うと思うんです。ウォーターフォール型開発は。
だから要件定義と呼ばれるような言語化ですよね、これはね。何を作ったら私たちは納品したというふうに言い切っていいのかを書いてください、あるいは書きましょうというのがウォーターフォール型開発の考え方で。その要件定義終わったからいくらですって見積もれますと。
ここに書いてあることしかやりませんよみたいな感じになっちゃうんですよね。ここに書いてあることは抑えつつもっとすごいの作りましょうという契約では全くないのが従来型の開発上のウォーターフォール型開発になると私は思っています。
アジャイル開発はどう違うのかと言っていくと、結論から言っちゃうとアジャイル開発はシステム開発会社も嬉しいし、クライアントであるお客さんも嬉しいし、さらにはそれを使うユーザーも嬉しい。その3者が嬉しくなるのがアジャイル開発という方法だと思います。
これは僕は断言してもいいんじゃないかなと思っていて、タイトルに沿って言うと、なんでアジャイル開発はシステム開発会社に有利なものというふうに思われてしまうかというとですね、アジャイル開発って本物と偽物がすごい入り乱れてるんですね、今特に日本の場合には。ほとんど偽物だと思っていいんじゃないかなと思います。
例えば、この部分はアジャイルにやりましょうみたいな。そんな考え方ないんですよね。アジャイルでやるんだったらアジャイルしかない。
さっき1回目のセクションでもお話しした通り、インセプションデッキというのを作ってお客さんのやりたいことを言語化するとか、もう本当に入り口からして違うんですよね、ウォーターフォール型開発とは。
なのに、この部分だけアジャイルにやりましょうっていうのは、作るものは決めないで、できたものをウォーターフォール型で出すので、ちょっとこれで違ったら言ってくださいみたいな。ある種、表面だけ模倣した形のアジャイル。これは確かに偽物というふうに僕は思いますけど、世の中多いんじゃないかなと思ってます。
アジャイル開発の利点
要件定義だけ、例えばですけど、アジャイルというか準委任でやって、ちゃんと工数が出たらそこはきっちりそこの中で収めたいから、開発は項数に従って要件に従ってやるっていうのは結構大きい開発だとあるかなと思いました。
そうですね、実際にウォーターフォール型開発とアジャイル開発で比較する話になってしまうのは、実はそもそもアジャイル開発ってウォーターフォールに対するアンチテーゼだからなんですよね。つまり、相入れない双方は別のものというところで、今辰巳さんがおっしゃったように、要件定義は準委任やる。
なぜなら、ゴールがどれくらいあるかわからないから、こちらの開発会社側からしても、どれくらい時間かかるかわからないものをあらたじめ料金に提示できないので、1ヶ月だったらいくらです。2ヶ月だったらいくらです。3ヶ月かかったんでいくらでしたみたいな、そういう方式のほうがいいよねということで、準委任でやるっていうのはあると思うんですけれども。
実は、これ言うとすごく乱暴な言い方になるんですけど、アジャイル開発は要件定義をしないんですよね。この言い方すると、すごくいろんなコメントいただくんですけど、要件定義はしないんですよ。ただ、どうやってやるのっていうところなんですけど、要件定義をしないっていうところにアジャイル開発のコンセプトが詰まってるなと思っていて、要件定義って細かくしたほうがいいですよね。
そうしないと見積もらえないし、それに作るものはこれでいいかどうかっていうのをお客さんの合意を得られないので、結構細かくやる。アジャイル開発は作る前に細かく決めるのやめようぜっていうのはあるんですよ。
なんでかっていうと、作って触ってもらってから、もっとこうしたいよねっていうような対話式のアイディアを入れていきたいから、あんまり決めすぎないでおこうよっていう感じでやっていくので、その点で最初に決めないことによって、むしろ本当にいいものが作れる。
ただ、それだとクライアントの皆さんがいつも不安になるのが、いくらかかるかわかんないじゃないですか。どれくらい時間かかるかわかんないじゃないですか。ってなっちゃうので、アジャイル開発では見積もりはざっくりやろうよっていうふうになってます。
実際我々もそうなんですけど、チームが1日動いたらできるなが1ポイント。2日あればできるよね2ポイントみたいな感じで、ポイントで点数付けしていきます。
例えば、会員登録フォームを見積もってくださいって言われたときに、要件定義していけば、こういう項目を入力すると。こういう入力があった場合にはここだし、まず確認メールが飛んで、それを踏んでから本登録が終わりますとか、結構書くかもしれないんですけど。
アジャイル開発の場合には、要件定義という言葉を使わずに、ユーザーストーリーという言い方をするんですけど、ユーザーストーリーとしてこう書くんですよね。簡単に会員登録できて、すぐに利用開始できるって書くんです。
もう全然細かく書かない。簡単にとかすぐにとか、ユーザー目線でそうしてほしいというような部分はちゃんと盛り込みながら、どうやったら簡単に会員登録できるかとか、すぐに利用登録ってどういうこととか、そういうのは作るときにもうちょっと言語化していくというか、ブレイクダウンしていくんですよね。
目的を達成できてればいいみたいな感じで。
そうです。方法はいっぱいあるので、それを2ポイントでやりましょうみたいな感じで決めるんです。2ポイント以上使ってもいいんですけど、そしたら予定よりもお金かかっちゃうし、期間もかかっちゃう。2ポイントでやるんだったら、ちょっとこの機能までにしておきましょうかとか。
Googleアカウントで会員登録できるよってよくあると思うんですけど、あれ入れたらちょっと3ポイントになりそうですなのか、その辺を対話で進めていくようなイメージになっていきます。
なので、アジャイル改造をざっくり言おうと思ったら、今話してたところ、要件定義ではなくて、ユーザーストーリーでやっていくっていうところ。
アジャイル開発の価値
そして、そうすることによって、作りながらお客さんに相談していくので、こんな感じの画面でどうですかねとか、パスワードの制限どうしましょうかとか、一回こちらでこうだったらいいかなっていうのを作ったりしますけど、それを見てもらって改善を繰り返していくスタイルになるので、
まずお客さんにとっても本当に欲しかったものに近づける。そして、ユーザーにとっても使いやすいものの結果としては、やはりなっていくと思いますので、アジャイル開発の方法そのものは開発会社だけが嬉しいわけじゃなくて、むしろお客さんとその先にいるユーザーにとっても嬉しいもの。
もちろん僕らも嬉しいんですよ。やりがいがありますからね。アジャイル開発の場合には、作らされているわけじゃなくて、お客さまの授業を成功させたい。成功させるためにはこの機能はこういう理由で必要なんだってことを全員が知っている。テストをするスペシャリストもいるんですけど、その人だってそのことを知っている。
だからこの機能は絶対にしっかりテストしないといけないよねっていうことが分かっているので、非常に高いやり気で皆さんがやっていけるっていう嬉しさがアジャイル開発にはあります。
満足度かなり高そうですね。それをやると。
そうですね。ワクワクしますよね。
要件定義を大雑把に言ってしまえばしないというところを理念とか組織だって進めることでうまくお客さまを巻き込みながら進めていくっていうような形を一緒になって進んでいくっていうのが目に見えて面白いなっていうふうにやはり思ったんですけども、この要件定義をしないっていうところと完璧なシステムを最初から目指さないっていうのがリンクしているものになるんですか?
そうですね。そうなると思います。結局、要件定義って完璧なものが見えてる人がこう作れば完璧なんですよってことを細かく書いていくものだと思うので、でも完璧って最初は分からないよね。
マーケットに投入しないと分かんない。使ってみないと分かんないよねっていうところからスタートしているので、あえて決めすぎない。むしろ作りながら変えていける柔軟性を残していこうよというところ。
全く同じ考え方だと思います。なので、完璧を目指すのではなくて、本当に細かい単位でリリースを続けていく。重要な機能からリリースをしていって、ユーザーの反応を見ながらアップデートしていくというところで、まさに前回お話の内容とつながってくるかと思います。
細かいリリースを繰り返していくことによる利点とか、逆にデメリットみたいなものってあるんでしょうか。
まず利点としてはですね、大きなリリースってやっぱり怖いんですよね。大きな変化が加わるので、急にシステムが負荷が高くなってしまって障害につながってしまうであったりとか、あとはテストも大規模になってきてしまう。
リリースを溜めてしまうと、それを投入するために行うテストも長くなってしまうので、非常に時間がかかって気便じゃなくなっちゃうんですよね、システム変化が。小さくやるってことは当然細かく、それこそ1日に2回3回リリースすることもありますので。
そういう意味で、例えば極端な話ですよ。朝リリースした機能によってちょっとこういう弊害出てきたっていうことに、もう夕方に対応してしまうとか、そういうこともできるので、その点はメリットかなと思いますし、何度も繰り返しちゃいますけど、ユーザーのフィードバックをすぐ手に入れることができるということで、リリース頻度を短くするのはメリットだと思います。
一方、デメリット。デメリットは、アジャイル開発の中で細かくリリースすることのデメリットを感じたことはないんですけど、他の会社さんに僕らのスタイル見てもらったときに、よくやりますねって言われたことがあって。
つまり、プライムオーダーさんって、どんなに長くても1ヶ月に1回は納品してるって感じじゃないですかと。日によっては週に1回納品してたりとか、それで作る側からするとげんなりしますねって言われたことあるんですよね。納品の回数なんか少ない方がいいじゃないですかみたいに言われて。
それはデメリットだとしたら、そもそもアジャイル開発じゃないだろうなと思うんですけれども、事業を成功させるために必要なことは、短いサイクルでリリースを繰り返していくことだと思うので。
ただ、こういう言い方になると思います。デメリットは、合わない人には合わないというか、このリリース方式。ちょっと昨日もリリースしたばっかりじゃないですかと。今日はもうそんなやる気ないんだよみたいな人にはきついだろうなというのはあると思います。
プロジェクトの成功を保証する方法
確かにサイクルが分散されていくので、その分何でしょう。工数が結果として上積みされるんじゃないかっていう懸念を考えられている発言なのかなと。
確かにね。そうですよね。だから、アジャイル開発って面白いなと思うのは、リリース方法にめちゃめちゃ効果があるんですけどね。
いわゆるデプロイって技術的にはよく言われているような気がするんですけれども、手元で開発してテストが終わったコードを本番環境にお届けする作業、デリバリーする作業っていうんですかね。
そこの自動化とか、テストの自動化であったりとか、非常にその辺にアジャイル開発に携わっている人たちは力を注いでるなというのがあって。
リリースの回数が多くなっても、そこのコストが累積されないように工夫しているというところは確かにありますね。
テストコードを書いたりだとか、コードパイプライン。
そうですそうですそうです。
すごいですね。ちゃんとできるのはすごいと思います。
これちょっと技術的な話になるかもしれないですけど。
僕の方からちょっと質問としては何でしょう。
結構似ているところは国内ラボ型開発、プラムザ全体でもやっているところでは多少あって、国内ラボ型開発を提案するときにもよく、
それこそ開発会社寄りにメリットがあるような話に聞こえられてしまう要因として、
例えばさっきおっしゃっていた要望がある機能が1から10だったとして、合計で1000万の予算がありますみたいなお客さんから話が来たときに、
結果的にそれをアジャイル開発でやった場合、ちゃんと予算内にクリアできるのかという問題。
国内ラボ型開発でやったときも同様ですけど、
準委任のスタイルでやった場合に予算がどんどんやりたいことが含めていってオーバーしてしまうんじゃないかという懸念が多分クライアント側であったりすると思うんですけど、その点ってどうですかね。
そうですね。それはやっぱり特にお客さんで責任者の方だったりすると一番気になるところだと思うんで、必ず聞かれますけど、
だいたい答えは何パターンかで、例えば予算も潤沢にあってスケジュールも十分にあった場合は、それはご心配なさなくても大丈夫だと思いますよと。
あとはどこまで品質を高められているかという部分だけだと思いますって答えられます。
でもそういうお客さんはむしろ少なくて、やっぱり予算も決めてるし、期間も限られてる中でやれって言われてるんですっていう中で言うと、
たぶん分からないが十分チャレンジできるみたいな言い方をします。
つまり絶対できますっていうのは、なかなか予算とか時間とか用意してくれない限りはこちらも言えないし、特にプロジェクトの内容によってチャレンジングなものってあったりするじゃないですか。
本当にまだ僕らも作ったことないような機能だったりとか、使ったことない技術を使う必要があるなとかだったり、そういうのが含まれているプロジェクトの場合には、僕らが保証することはできないですよね。
それはもう正直にお伝えします。なので、僕もでも分かるんです。
準委任型のサービスをお客さん向けに営業していくとき、今からもう7,8年前かな。
このPRIME ORDERって形を取る前に、それこそ国内ラボ型とか準委任の営業していくときに難しいなと思ったのがそこだったので、約束できないのに発注できないよとなりますよねと。
その担当者の方がいいなと思ってくれても、上長がやっぱり一括受けよって形じゃないとダメだよと、失注してしまうっていうのがあってですね。
でも、アジャイル開発に振り切ったら、その辺の解決策も既に用意されていて、システム開発が成功することを保証する人は1人じゃない。
それは開発に携わる開発チームのリーダーやメンバー、でも彼らだけでもない。
そこにお願いをしている発注者であるお客さん、その情シスであったりとか組織、その全員で責任を持つんだよっていう考え方がアジャイル開発にはあります。
だから僕に聞かれても困ります。僕らは絶対成功させますから、お客さん、あなたも成功させるようにお願いしますよ。
予算をしっかり確保して、スケジュールをいただき、実現すべきストーリーは何なのかっていうのを一緒にじっくり時間をかけて考えていきましょう。
そして僕らと十分なコミュニケーションをとってくださいっていう形になるので。
アジャイル開発にはトレードオフスライダーっていう非常に神がかってる考え方があって、営業するときにはこれを僕は必ず話すようにしてます。
システム開発を左右する4つの要素。まずお金。お金がいっぱいあればいろんなことできる。お金が少なかったらできることは限られる。
当たり前でお客さんも分かっていただけると思うんですよね。次は時間。時間も同じですよね。時間いっぱいあればいろいろできる。なきゃできることは限られる。
それから品質ですよね。品質を高くしようと思ったら時間はかかる。品質いじめていいんだったら短時間でできる。
最後にスコープ。スコープって言うと範囲、つまり実現する機能の数って考えていただいていいと思います。
実現する機能の数が多ければ多いほど時間かかるしお金もかかる。だから削っていただけるんだったら時間も短くなるしお金も安くなります。
この4つって全部関係しあっているので、だからどうします?どれが一番大事ですかってお客さんに聞くようにしています。
僕も若い頃、もっと大きな会社でお客さんと話している営業を見てて思ったんですけど、営業の方って費用はお客さんが希望している通りにちょっと安くしてあげますよと予算で収まるようにします。
スケジュールもご希望通りに収めますと。品質はもう任せてください、最高品質で。もちろん機能は言われた通りの要件的に全部入ってますよと。
じゃあぜひぜひ発注お願いしますっていうような感じで営業してくるんですよね。
確かに。
全部最高で固定しちゃうというか、そうしたら仕事取れるっていうところですよね。
それ持ち帰ったら開発チームと大喧嘩になりますよね。そんなできるわけないとか。
アジャイル開発の基本
なので、アジャイル開発でやっているプライムオーダーとしては、この4つは全部最高にはできないんです。そこを諦めてもらうところからスタートですっていうお話をお客さんにしてます。
その中で、これだけは譲れないってどれですか?
例えば予算が決まってるってなったら、お金が一番ということになります。
お金は無限にあるわけじゃないけど、それより納期決まってると。年度代に実現しないといけない。
じゃあ時間が最高ですね。
そういう感じで優先順位をつけていきます。
そうすると、だいたい最後の方で天秤にかけられるのは品質とスコープ、機能の数。
だからこの流れでお話をしていくと、もう仲間なんですよ。僕らも実現したいと思ってる。
別にお安くしたいから頑張りますとかって話じゃなくて、それを実現するためには品質をいじめるか、機能を少なくするかしかないわけです。
ただ品質をいじめるって言っても不具合がある状態での納品と言いますか、お渡しはできないので。
いじめられる範囲ってせいぜい応答速度であったりとか。
あと使い勝手ですよね。ここ本当はタグ入れるときに、これまで入力してたタグは選択肢から選べたらいいのにみたいな。
それはちょっとつけられなかったりするとか。
あと実現したい機能。本当はここまで欲しかったけど、これはちょっと今回諦めますってお客さんの方で考えていただく。
そうやってプロジェクトを予算内で実現できるであろう形に近づけていきましょうというのを一緒にプライムオーダーではやってますね。
品質と経験の重要性
めちゃめちゃ参考になる話ですね。
この4つ、お金、時間、品質、スコープというところを、開発している側からしてみればそういうものなんだろう。
そうでしょうっていうものを改めてお客さんに共有することで、一気に当事者に持ってくるパワーもあって、なかなか面白く参考になるなと思って聞いておりました。
POD自体に力と自信があるからこそ言えるんじゃないかなっていうのをちょっと思いましたね。経験ですかね。
そうですね。確かに時間かかりますよって言ってるけど、うちのエンジニアさんはまだ初めて2年なので、こういうファイルアップロードとかすごい時間かかっちゃうんですよとかっていう見積もりを出してたら話崩れちゃうというか。
なので、プライムオーダーはもうそういう意味だと、これは本当に過激な発言になっちゃうんですけど、人材の育成は行っておりません。
もう10年以上の経験を積んで、実力が確かなメンバーだけ、エンジニアだけじゃなくても、通常のスタッフメンバーであっても、そういう方だけ厳選させていただいているので、これぐらいの時間はかかるんですということが。
むしろ、他の会社さんよりもこの時間は短い時間で提示しているっていう部分もあると思うんですけど、逆にそれをこれ以上短くすることはできないと自信満々に言えるのは、僕というよりは、そういうベテランのエンジニアさんたちの力量で、押し測ることができるかなっていうのがありますね。
非常に興味深く、正直いつまでも聞いてられそうなんですけども、そろそろ時間かなというところがありますので、ぜひこの先、内藤さんの話をもっと聞いてみたいという方がいらっしゃいましたら、
プラムザまたはオプライムオーダーのほうにお問い合わせいただけますと、内藤さんがまずアジャイル開発について説明していただけると思いますので、ぜひお問い合わせいただければと思います。
お願いします。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。また、Xでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。それではまた次回お会いしましょう。内藤さんありがとうございました。
ありがとうございました。
