アジャイル開発とプロジェクトの進行
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが赤坂より、開発現場の今と本音をざっくりバランに話していこうという番組になります。進行は私、鴨志田と、
今回は島田さんがお休みで、私、辰巳も参加しておりまして、
本日ゲストをお迎えしておりまして、株式会社プラムザ専務トリシマル役、プライムオーダー事業部の内藤さんです。よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
まず、ざっくりで良いので、内藤さんは自己紹介をよろしくお願いします。
株式会社プラムザのプライムオーダー事業部からやってきました、内藤といいます。どうぞよろしくお願いします。
僕はですね、何年だろう、2000年問題の年ぐらいにITエンジニアになりまして、だからもう24、5年やってるんですかね。
ずっとエンジニアとかプロジェクトマネジメントとかいろいろやってきていたんですけれども、
現在はですね、アジャイル開発という手法に特化したプライムオーダーという開発集団を、その中でですね、いろいろとプロジェクトの整理だったりとか、
あるいはお客さんとのやり取りであったりとか、広くやらせてもらってるという感じです。こんなんでいいでしょうか。
ありがとうございます。
本日のタイトルなんですが、サービスインまでに完璧なシステムを目指してはダメな理由というタイトルになっております。
アジャイル開発についても聞きたいところなんですが、まずタイトルがサービスインまでに完璧なシステムを目指してはダメな理由というところで、
できるだけこれに沿った話をしていければなと思っております。
このタイトルに何か辰巳さん的に思うところってありますか。どうですか。すみません、ざっくりしておりますが。
よくある話では実際あると思っていて、そのシステムを作っていく中で、結局プロジェクトが進むとやりたいことが増えていったりとか、会社としての状況が変わったりするので、
本当にミニマムな部分を抑えて、そこを先行してリリースして使っていく中で、フィードバックをもらってサービスと一緒に成長していく、チームを成長させていくというのが一つで有効な手段ではあるかなと思っています。
そういったことをPOD、プライムオーダーほどしっかりはやっていないですが、他の事業でも展開をしているかなという印象ですかね。
ありがとうございます。今、辰巳さんの話を聞いていると、プライムオーダー事業部のほうではそこら辺をきっちりやっているというのは、組織だって明確なものが決まっていてやっているみたいなイメージであっています。
これ、内藤さんにお伺いしてもよろしいでしょうか。
完璧なシステムを求めるリスク
そうですね。考え方としては先ほど辰巳さんが言っていただいたことでも、そのままかなと思いますので、この後特に僕がしゃべることももうないんですけれども。
いやいや、嘘です。
そういう理想の考え方があったとしても、こういうところで難しいよねとか、お客さんってこういうことを考えているよねとかっていうところもあるので、
その部分をプライムオーダーとしてはお客さんと考えていきませんかということをずっとやってきているというところにおいては、その考え方は徹底しているかなと思っていますし、
ベースになっているのが、アジャイル開発というコンセプトの中に、もう小さく作ってすぐリリースしようぜっていう考え方が基本にあるんですよね。
すべて短い期間でリリース、それの積み重ねだよっていう考え方があって、
それするためにはお客様には全部の機能が揃っている完璧なシステムを作らなきゃいけないんだというふうに、
勢いというか力まれるお客さんもいらっしゃるので、まずはちょっと力抜いていきましょうみたいな話からスタートすることは実際多いですね。
なるほど。最初から完璧なシステムを目指す、いきこんでいるとどういった弊害といいますか、障害みたいなものが出てくるものなんでしょうか。
そうですね。まず、完璧という表現からいくと、完璧なシステムを知っている人はきっといないというか、作る段階ではわからないというのがベースにあるかなと思います。
例えば、完璧だと思って企画書まで細かく書いて、こういう機能がこういう人たちに刺さるんですっていうところを考えてやっても、
もしかしたら受けないかもしれないし、使ってもらったらここすごい使いづらい、もっとこういう機能だったらよかったのにとか、そういう意見が出てくるかもしれないので、
完璧、いわゆる100点だったりを最初から狙っていくっていうのは無理があるよねというところがあるのが一つと、
それからもしそんなことをやろうとしたら、100点かどうかわからないけれども、100点を取ろうとしているわけですから、すごいパワーが必要ですよね。
パワーと時間、それってコストっていうところにも跳ね返ってくるので、
なので、そういうふうになってくると、最初のリリースっていうのはすごい先になってしまったりとかしてしまうというリスクがあるんですけど、
話しながら質問忘れちゃいました。何でしたっけ、質問。
完璧なシステムを最初から目指すっていうことにはどういった弊害があるんだろう。
なるほど、そうですね。
じゃあ、大体あってるかな。
というふうにプロジェクトが長期化してしまったり、費用がすごいかかってしまったり、その割に本当にマーケットに刺さるかどうかわからないもの。
すごい長い時間かけて作ってしまう。
その間に競合他社がもっといいサービスとか、そういうのをどんどん出していっちゃうかもしれなくて、
そういう機械損失というよりもマーケットに参入できなくなる、あるいは参入が遅れるというリスクがありますね。
やっぱり一番言いたいのは、最初に本当に完璧なものなんて考えることできないから、
ユーザーに使ってもらって、フィードバックをもらいながら一緒にサービスを作っていこうよというのが、
現代の最もスマートなやり方、合理的なやり方かなと思いますので、
完璧なものを作るぞといき込むことには、いき込んでしまうとそういう作り方を放棄するリスクがあるなと思います。
ユーザーとコアバリューの重要性
ありがとうございます。
サービスインに完璧なシステムといっても、システムを作るには時間がかかる。
その間に作っていくうちに、違う方向性とかこうであるべきというものが変わっていくのが自然である。
そうあるべきだということで、目指してはダメなんだろうというところで、そこを放棄しようというところになるんですかね。
そうですね。ただ、本当に軸足がなくてブレブレなサービス、プロダクトというのは当然マーケットにも刺さらないと思いますし、
これは今、いわゆるマーケット向けのサービスだけじゃなくて、社内向けに機関システムを作るぞという話でも同じなんですけれども、
ユーザーというのがいるわけですよね。
そのユーザーに魅力的に感じてもらう必要は必ずあるので、本当に何をお届けしたいのかという一番コアになる部分、
そこをしっかりと見つめることが大事ですよねっていうのが趣旨かなと思っています。
その上で、その周りの機能とか関連のサービスだったりとかっていうのは、後から必要に応じて足していけばいいんじゃないかなと思うので、
どちらかというとそれもなくて、いろんな機能揃っているから、ぜひこのサービス利用してくださいみたいなものを作りながら考えていくというほど、
何も考えなくていいことじゃないと思うんですけどね。
やっぱり核となるこのサービスのコア、コナンだというところをしっかりと見つめることが大事かなと思っています。
ありがとうございます。ちょっと話を聞いていて、個人的にYouTubeの配信とかに似ているなっていうことをちょっと思ったりしましたね。
コメント欄を見て方向性を修正するっていう、もちろん自分の中でやりたいこととか目指したいことはありつつ、
そういったフィードバックをもらいながら修正していく、そのために最初から完璧に作る必要はやっぱりないよねっていうようなことをちょっと、
例えばあれかもしれませんが思い浮かべましたねというところですね。
そうじゃないですかね。今本当にユーザーと価値を高めていくっていうのが非常に大事なことなので、
ユーザーの意見を無視しながら一人用がりなものを作るっていうのはやっぱり無理がありますよね。
僕からもちょっと感想を交えつつ質問したいなと思っていて、
実際に過去の案件でも作ってみたもののこの機能全く使われないみたいな本当によくある話だなと思っていて、
ただやっぱりクライアントとしてはこういう理想があるんだと、これを成し遂げたいんだという気持ちが結構強い中で、
そういったコンセプトを伝えしていく中で、どういったところが納得いくためのポイントといいますか、
どういう話を普段されるのかなというのがすごい気になった感じですかね。
まずお客さんには、システムっていうものを買うっていうつもりで挑まないでくださいということは最初に言っています。
例えば1200万円払うからいいの作ってよっていうものじゃないよというところからも話をしていて、
例えば1200万円であれば7ヶ月かけてシステムを作っていく、そのチームに我々が入ってきましたよというところからスタートなので、
そういうふうにしたときにお客様の思い、この世の中をもっと良くしたい、何々を通して良くしたいみたいな思いってあるじゃないですか。
その思いもしっかりと全てチームメンバー全員で聞いて言語化するところから始めています。
これプライムオーダーではインセプションデッキって言うんですけれども、アメリカだとすごく有名なエレベーターピッチっていうのかな。
投資家さんに自分がこれからやろうと思っている事業の魅力を伝えたい。
でも投資家さん忙しいからエレベーターで偶然乗り合わせた手でそのエレベーターが目的の階に着くまでの短い時間で自分の事業の魅力を伝える。
お客様から僕らが相談された時もそんなエレベーターピッチを作っていただいてるんですよ。
そうすることでそのサービスが出来上がると誰がどういうふうに幸せになるのかなっていうことが言語化されていく。
プライムオーダーとしてはそのために全力を尽くしますというところから話をするので、どの機能が揃ってないといけないかっていうのはその次の話になってくるかなと思うんですよね。
なので正直ここまで行ってからどれをどの時期に完成させようかっていう話をしていくだけで、お客さんの方でもお買い物感覚でシステムを作ってもらうって感じだとこうはならないかなと思っていて、
1200万円のこの機能を全部揃っている状態にしてもらうよと、納期はこんぐらいだよと、じゃああとはよろしくねっていう感じになっちゃうと思うんですけど、それだとうまくいかないのでやっぱりちょっとおこがましいですけどお客さんにも僕らと同じチームメンバーとして目線を揃えていただくっていうところからスタートするので、
これができない場合には実は僕らもお仕事ちょっと難しいですねっていう感じでお断りさせていただくことも多いですね。
なるほど。
エレベーターピッチっていうのはお客様に書いていただくっていう形であってます?
それが一番理想なんですけど、書いてきてくださいって言っても難しいので、穴埋め形式の文章のテンプレートをお渡しするんですよね。
そのユーザーの誰々はこの製品何々を使用することで何々の価値を手に入れることができる。
なぜかというとこのサービスには何々というメインの機能がありとかそういうテンプレーがあるんですよね。
それをちょっと埋めてみてくださいっていうふうに言いますね。
それって内藤さん自身で考えられたんですか?
いやいやまさか。
アジャイル開発の基本原則のプラクティスの一つではあるんですね。
もうちょっと話したいので横に反れるかもしれないですけど、ちょっと聞きたいこともありまして。
やっぱり内藤さん的に言語化すると結構変わってくるものですか?どうですか?
そうですね。言語化は本当に大事だなと思いますね。
まずチームが責任感というかやる気に満ちてくるっていうのは間違いなくあってですね。
このプロジェクト何でやってるんだっけ?何で僕ら集まってるんだっけ?っていうことを言語化しないまま始めていくと結局お客さんが欲しいものを作ってあげてるあるいは作らされているみたいな関係にしかならないので。
そうじゃなくて僕らがここにいるのはこういう理由なんだよ。
お客さんがやろうと思ってるこの事業でこういうのを作ると世の中がこう変わっていく。
僕らはそれに賛同してその実現のために毎日時間を投入してるんだ。
なので言語化してそのままどっか横に置いていったらダメなんですけど、僕らは言語化したものを常に見れる場所に置いておいてですね。
少しみんなが迷子になってるなとか若干モチベーションが下がりそうだなとかっていう時にはもう一度言語化されたインセプションデッキを見直して、
そうだったね最初はこういうこと考えてたよねとか立ち戻りたいよねっていう本当に道しるべになってくれるので言語化はすごい大事だし、
そしてそこで言語化しておくとクライアントと気持ちが離れてしまうこともないというか、例えばクライアントがおかしなこと言ってるぞ。
このインセプションデッキで最初にやりたいって言ってたことと全然違うことを言い始めたぞと。
サービスインの重要性
そっちで大丈夫なんだろうかっていう時にもクライアントと僕ら最初こういうつもりでやってましたけど最近それ変わってきてたりしますかみたいな話をして。
変化がいけないわけじゃなくて変化はとても大事なものだと思うんです。理由があって変化すると思うんで。
その時が来たらじゃあインセプションデッキも書き換えていきましょう。
つどつど言語化をしていくっていうことはとても大切だろうなと思います。
お客さんと共に作り上げることによって一つのワードをそれを元に進んでいくっていうのは何でしょうかね。
これも聞きかじった話なのであれですが、Googleの社訓の中にその製品の出来とか考えるときにGoogleらしくあるかどうかみたいなものがあるっていうこと。
対応するときもそうらしいですね。Googleの社員、Googleに似合うかどうかフィットするかどうか。
でもそれを絶対に言語に出してはいけないらしいですね。
そういったものをお客様と一緒に作ってそれを共有しながら進んでいくっていうのは確かに目に見えて一体感が出るだろうなっていうのは今話を聞いていて思いました。
僕もちょっと追加でもう少し聞ければと思っていて。
スラックでちょっとあったウェブサービスを始めるなら半年以内にサービスインしましょうという話があって。
これって実際問題なんでしょう。結果として6ヶ月、半年やってみたものをリリースさせるのか。
必ずこの目的、これまではこの半年以内ではこれを達成しなくちゃいけないというものがあって、それを達成できているのかというとどっちですか。
達成してますね。
むしろ6ヶ月と言わず大体3ヶ月ぐらいでサービスインすることが多くて、6ヶ月以上リリースがないっていうのは非常に危険なことだと思いますね。
だって本当に今僕ら作ってるのをユーザーに求められてるんだろうかってことがフィードバックが得らないまま6ヶ月以上走っていくわけなので。
それよりはもう3ヶ月でまず少しの機能からリリースしていって、本当に一番最小限に大事な機能だけから。
毎月リリースをしていくんですけれども、だんだん月1回のアップデートで新しい機能が入っていく。
その時にまたユーザーからのフィードバックもあるので、次のアップデートにはそのフィードバックも入れるのかという形で一緒に作っていけるので、それは徹底してると思いますね。
最終的にはシステムって当然成長していくものっていうのもあるので、完成という概念、完璧という概念って多分ないと思うんですけど、
結果的にお客様に満足いただけるような完成形に近づくっていうことがある程度実現できているっていうような感じなんですかね。
そうですね。いわゆるB2Cと呼ばれるような、一般の方々向けにサービスを提供するときは本当に終わりはないと思うんですよね。
もう完璧なシステムっていうゴール地点はないので、当然競合もいたりとかしますし、いなかったとしてもやはり常にサービスをより良くしようっていう動きがないとお客様離れていくと思いますから、それは確かに終わりないかなと思います。
社内向けのツールとか、あるいはBtoBで取引に使うためのプラットフォームとか、BtoBのプラットフォームも終わりないと言えばないんですけれども、
社内向けのツールだったりすると、やっぱりどこまでコストをかけるのかっていう話は当然お客様考えているので、その中でいうと終わりを決めるのは別に構わないかなと思うんですよね。
例えば、最初の4ヶ月でリリース、サービスインして、社内で使い始める。6ヶ月目でもうおしまいにしちゃうみたいな。それで、後は社内で運用で回していこうよっていうふうにすることもできるとは思います。
そこの運用の部分、社内のサービスとかに関してもある程度形が見えてくる中で、たまに保守系の案件とか多重業務にパスされることが多分あるかなと思っていて、
そこをある程度もうクライアント内で完結させる仕組みを作っているのか、そもそも保守をやっていないのかっていうのはそこら辺のポリシーとしてあったりするんですか?
完璧なシステムの限界
事実としては、保守がすごい昔から続いているお仕事はありますので、それは責任を持って続けさせていただいているんですが、新たに保守サービスというものは承ってないというのが現状にあります。
理由としては、保守ってなんだろうって話だと思うんですけれども、僕結構お客さんを間違えちゃってるっていうあれなんですけど、たぶんこの業界が悪いのかなと思うんですけど、納品が終わった後に不具合が出てきたりするのがすごく日本って多いですよね。
不具合が出てきたけど、それってもう納品終わってから何年も経ってるから、業者に連絡しても直してくれないとか連絡つかないとか、それって怖いよねと。自分たちで中身見れないんだから、だから保険として払っておこうよっていう形でやられてること多いなと思っていて。
本来そういう不具合っていうのは、納品までプロジェクトが終了するまでに潰しておきたいものだと思うんです。なので、プライムオーダーとしては、これは本当に口で言うのは簡単なことなんですけど、不具合っていうのはすごい少ないと思ってます。
もちろん小さな不具合とか、全部細かいところまで見てってゼロですよってことはないんですけども、本当にこれ業務インパクト大きいよねと、すごく影響を与えちゃうよっていうような不具合っていうのが出ないような仕組みづくり、そしてチームづくりっていうのをしてるので、そうなってくると、もう機能出来上がった後にプライムオーダーに保守サービス求めますっていうことってあんまりないというか。
昔はそれこそ機械の不調、サーバーの不調とかでシステム止まっちゃうこと多かったんですけど、そういうときに確かに誰かいてほしいよねってなるんですが、最近AWSとかGCPとかいわゆるクラウドコンピューティングの世界になってくると、もうその辺の障害っていうのがまずまず起きない。
あるいは起きたとしても、すぐに自動的に切り替わりの仕組みを入れておけるとかなっているので、人間が本当にずっと見ている必要があるのかっていう部分が僕らすごく感じています。
でもお客さんが保守を求めるのは、最初にお話した通り、開発時点の不具合だったり、不具合と言えるかどうか微妙なんだけど、でもこれ困るよねっていうことがつぶしきれてなかったりとか、そこに対する保険っていう感じが強いなと思っているので、むしろそういうのを維持するよりも安心できるプロダクト作りしていきましょうっていうふうにお話はしています。
ただ、成長し続ける事業ってあるじゃないですか。そのプロダクトもサービスもどんどん成長していく。そうなると保守っていうよりも開発が継続するんですよね。
なので、その開発が継続する限り、我々は常にお客さんと一緒に走っているので、その中で例えばちょっとした困ったこととかあれば一緒に解決できるという形なので、保険的な意味の保守だけを切り出してご提供するっていうのはしていないという感じになるかと思っています。
なるほどですね。すごくクリアになりました。ありがとうございます。
プラムザ全体で保守をやっていないわけではないので、保守を当然お問い合わせいただければなというふうに思っています。ありがとうございます。
そうですね。あくまでプライムオーダーは保守には向いていないというか、開発にすごく振り切っている組織なんでっていうふうに考えていただいてもいいかもしれません。
ありがとうございます。
内藤さんの話が面白すぎて、ちょっとまだまだ聞いていきたいんですが、特にアジャイル開発についてですね、また次回ゲストということでアジャイル開発についてお伺いさせていただければと思います。よろしくお願いします。
よろしくお願いします。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。また、Xでも最新情報を随時発信していますので、よろしくお願いいたします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。それではまた次回お会いしましょう。
ありがとうございました。
ありがとうございました。
