ラボ型開発の導入
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが赤坂より、開発現場の今と本音をざっくりばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、今回からレギュラーになりました辰巳です。お願いします。
今回からゲストからレギュラーと言いますか、辰巳さんにはずっと出ていただいているので、このまま3人のラジオでも良いんじゃないかという話になり、紹介からゲストという文字を抜いたという記念すべき回ですが、辰巳さんいかがでしょうか。
そうですね。レギュラーになった辰巳の存在感を出して、いろいろ話していきたいなと思います。
いずれゲストを呼べたらという感じですよね。
ゲストを呼びたいですね。
リスナーが30人ぐらい増えたらという感じですかね。
ぜひ皆さん何回も再生していただけると幸いです。
今回のタイトルは、「最近よく聞く、ラボ型開発」とは。
簡潔にまず、ラボ型開発とは何なんでしょうか。
島田さんお伺いしてもよろしいでしょうか。
ラボ型開発というのは、今までの一括請負という開発方法を説明しないと難しいですよね。
一括請負というのが、昔からずっとやられていた開発方法で、お客さんがやってもらいたいことを開発会社に持ち込んでくるんですよね。
それに対して、こちらでこういう風にしましょうかという形で見積もりを書いて、いいですねと。
妥当な企画だと思いますよということで発注いただいて作ると。
納品してお金をいただくというのが、今まで通り一括請負なんですよね。
ただそれをずっとうちの会社もやってきたんですけど、だんだんシステムが複雑になってきてですね。
初めの見積もりっていうのはなかなか書きにくくなってきたと。
動きとかも紙の仕様書ではですね、紙の初めの提案書ではですね、言い表せないような動きをするようになったりですね。
お客さんのユーザーのですね、入力によってパカパカ画面が変わるとか風になってくると、なかなかそれを提案書に書き切れなかったりするんですよね。
あとお客さんがサービスを作っていくというような場合には、その通りに作ればいい。
見積もり自体の通りに作ればいいというのではなくて、エンドのユーザーのフィードバックというか、声を聞いてですね。
どんどんシステムのブラッシュアップというか、改良していかないといけないというようなこともあったりするので、その都度見積もりを書いていると時間が遅くなってしまうので、どんどん柔軟に書いていきたいと。
そういうニーズが結構出てくるようになったんですよね。
なるほど。一括の従来の、最近設計してそれ通り作っていくっていうものを、今聞いていると割とデメリットがあるんだなと。
融通が聞かないとか、細かいところまで最初に固めきれないというところがあると思うんですけど、メリットとしてはどういうところになってくるんですか?
一括の?
一括の方の。
一括のメリットをですね、ちゃんとメリットをあって、予算がしっかり確定するっていうのが一番のメリットですよね。
開発会社が一千万で作りますって約束したら、もうそれ作らなきゃいけないっていう。
途中で多少のブレはあってもですね、作りきるっていう約束をしてあるんで、契約書に書いてあるんで、作りきってくれるっていうのが一括請負の一番のメリットですよね。
なるほどですね。
そうすると予算確保に結構申請がいるとか、承認が多い会社さんとかだと、その方が逆にやりやすいみたいなところがあったりするっていうか、それが普通の流れなんですかね。
大企業とかだとですね、結構一括請負じゃなきゃダメよっていうところが今でも多いですね。
SIer（エスアイヤー）とかも9割9分、そんな感じなんじゃないですかね、今でも。
ラボ型のメリットと展望
そうです。SIer（エスアイヤー）の下請けでやるようなときはですね、SIer（エスアイヤー）ってわかるかな。
今聞こうと思ってました。SIer（エスアイヤー）って何ですか。
システムインテグレーターの略ですね。
そうですね。固有名詞出すと色々と差し支えがあるんですけど、F士通とか、IBなんとかとかですね、そういうところの大きな会社ですね。
主に大きな会社を相手にしてシステム導入するっていう、そういう提案をして。
それに見積もりが通っちゃった後にですね、うちみたいなところを集めてアサインしてですね、チームを組むんで。
もう決まってるんですね、予算枠ですね。だからずるずる予算が動くっていうのは絶対許されないっていう感じなんですね。
別の話ですけど、それによって多重請負構造ができてしまって、下の会社になればなるほど疲弊するという。
なるほどですね。
ちょっとすいません。私は先に一括のメリットを聞いてしまったのでずれてかもしれないんですけど、それに対してラボ型っていうのはまた違うっていうことですね、一括とは。
そうですね。それに対してラボ型は従来の開発方法を一新するようなもので、
基本的には開発チームを作ってですね、毎月毎月どんどん考えながら手を動かしていくと。
大きな2年とか1年2年の計画はあるんですけども、その中でですね、もっとこうした方がいいよねとかって思いついたらお客さんと一緒に考えて思いついたらどんどんやること変えていく。
月決めで働いた工数分だけ、工数っていうのは作業時間だけど、工数分だけ請求させてもらうっていうそういう開発方法ですね。
なるほどですね。
それを今の流れから察するにやっぱり細かい修正とか要件定義、最初の設計の段階で見えてなかったものもそれが対応しやすいっていうのがやっぱりメリットになってくるんですかね。
そうだね。
辰巳さん他にどういったメリット、辰巳さんもラボ型で開発の経験があるというふうに聞いてますが、どういったメリットを感じていらっしゃいます。
そうですね、双方にもちろんメリットはあると思っていて、開発会社側もいちいち過去のやり取りだとか当初の要件定義に遡って、
あーでもない、こうでもないって考える必要はまずなくなるので、開発としてはスピード感が高まるので、エンジニアさんもそっちの方が多分動きやすい部分があると思いますし、
あとはクライアントさんにとって動いた分だけの請求になるので、当初予定していたより多く支払うことになる可能性もありますし、少ない金額を支払う可能性にもなるので、
ちゃんとそこも含めてご理解があるクライアントさんだと、真剣に多分考えて開発に取り組んでくれるというのは、僕個人としてはメリットがあると思います。
やっぱり加通経営だと予算が決まっているので、どれだけ時間引き延ばしても変わらないじゃないですか。
どれだけ動いてもエンジニアさんというかチームが動いても金額は変わらないので、好きなようにいってしまうとできてしまう部分があるので、
ラボだとお互いに制約があるので、クライアントさんにできるだけ少ない金額で稼働する。
クライアントさんとしても最小限でやりたいという場合になるんだったら最大効率で最小工数でやるためにはどうすればいいかというのを考えるので、
自ずと真剣に考えて最適解を出しやすいというのがあると思います。プレッシャーがあるという感じとも捉えるかもしれないですけど。
同じ方向を向きやすいというのは確かに構造的にそうなのかなというのは思いましたね。
それと比べて一括だとある種お金払ってこれで作ってくれるでしょうみたいな、ある種プロに任せするというところもあるのかもしれないんですけど、
そういった構造にはどうしてもなりやすいのが、ラボ型開発だと一緒の方向を向いていけるというところが結構大きい特色と言いますか、
そういったふうに感じたんですが、島田さんはこの認識で合ってますかね。
そうですね。一括の場合はどうしてもお客さんがお客さん意識、お客様意識みたいなのをずっと持っちゃっててですね、
待ってればできるんでしょうみたいないいものがっていう風になってしまいがちなので、
特に大きなシステムとかですね、従来に変えなきゃいけないようなエンドユーザー向けのシステムなんていうのは、
ラボの方がいいものができると思うんですね。ちょっと見て、これ違うなと思ったらすぐ変えていけるっていうのがいいところなんで。
よくうちでも同じ方向を向くっていうのをキーワードに言ってますけど、
社員と同じようにですね、エンジニア社員を何人か雇ったのと同じような形で、
ゴールを同じにして、いろいろと提案を出しながらやっていくっていう、そういうスタイルが取れるんだと思うんですよね、ラボ型開発はね。
開発自体はもちろん物によるとは思うんですけど、やりやすいっていうのがプログラマーさん、もしくはシステム開発会社さんとしてはそうなるっていう感じなんですかね。やりやすいですかね。
言った言わないの話がですね、だいたいシステム開発の後半はそんな話ばっかりになってくるんで、
お互いに疲弊するんですよね。開発会社もそうだし、発注側もですね、あれ言わなかったっけなとか、言ったはずだよとか、一生懸命昔のメールとか探したり出したりしてですね。
あと、いずれにせよ言ってなかったとしても、それでクライアントさんって納得しないんですよ。だいたい。
よく考えたら言ってなかったと思っても、ごり押ししてくるっていうことがあるんで。
うちとしてはなるべくやってあげたいとは思うんだけど、どうしても予算組んでないものは限度があるよね。
そういった意味でも、同じ方向向けるかどうかっていう、一括で決めたら構造的にやっぱり後ろは最後の方だとどうしても揉めそう、ちょっとストレートな言い方すぎますが、揉める部分はあるんだろうなってちょっと聞いてて思いましたね。
現状は一括とラボ型どっちの開発の方が多いんですか。
半々ぐらいじゃないですかね。
半々ぐらい。辰巳さんも体感的には半分ぐらいっていう感じですか。
そのぐらいだと思います。あと、一部保守で定額でお支払いいただいて、浮き出た部分をラボでやるみたいなことも。
アジャイル開発とラボ型の違い
確かにそういったメリットもありそうですよね。ちょっとした修正っていうものと。
これあと個人的に気になるんですけど、最近よく聞くワードとしてアジャイル開発っていうのもよく目にするんですけども、ラボ型とどう違うんだっていうところはちょっと気になってまして。
島田さんどうですか。お伺いしてもよろしいですか。
基本的には変わらないですよ。
うちの一事業部のプライムオーダーはアジャイル開発でやってると思うんですけど、基本的に変わらないですね。
動いた分だけ定額を持ちながら仕事をして、1ヶ月ごとに動いた分だけ請求させてもらうっていう基本は変わらないですけども、
アジャイルの方はですね、もう少し言葉が難しくて、カッチリやってる感じですね。
ちょっと勉強しないとなかなか難しいけども、その勉強したスキームに沿ってやると、カッチリハマっていくっていう感じかな。
勉強っていうのはクライアントさんが勉強するってことですか。
クライアントさんも勉強しないといけないし、エンジニアもちょっと勉強しないといけないっていう感じかな。
なんか特殊なOSを使ってるパソコンみたいな感じですよね。
そうそう。
なるほどですね。
言葉は難しいんでね。
ハマる人はハマりそうですね。お客さんに関しても。
そうそう。
辰巳さんはアジャイル開発の経験ってあるんですか。
いやないですし、正直僕は違いがないっていうのもあると思いますし、どう違うのかそもそもよく分かってないっていうところもあると思います。
アジャイル、本とかは読んだことありますけどね。
そうですね。プラムザ社内ですとアジャイルであればPOD、そっちの事業部にお任せするという流れができてるので、
鴨志田も、あんまりワードは知ってるぐらいで改めて聞いてみたいなと思ったところです。
プラムザのアジャイルとかのプライムオーダーはしっかりやってますけど、
国内ラボ型開発の特性
アジャイルと言いながらほぼ普通のラボっていうか、システム開発のチームを貸して稼働してるだけっていう、
なんちゃってアジャイルみたいなのもあるんで、普通にやってるところもあるんで、
その辺の区別ははっきりしてないと思います。
なるほどですね。
別の機会にあれですね、内藤さんに来ていただいて、プライムオーダーの事業説明を。
何が違うのかってね、ちょっとね。
確かに。
説明してもらって。
ようやくゲスト候補が見つかりましたね。
まずは内部からですね。
そうするとまとめが難しいな。
ラボ型、今話を聞いてるとラボ型基本的には良いんだろうなって。
やっぱりラボ型で開発した方が楽しかったりやりやすかったりするっていうのは、
島田さんも辰巳さんも思うところになるんでしょうかね。
そうですね。
ただデメリットとしてはさっきちょろっと触れましたが、
ほぼないっていうか、起きないようにしますけど、
予算が青天井に理論上なってしまう。
さっきの今日商談あったときにラボの提案をしたときにも、
それって結局開発が頓挫してしまったら払い損ですかっていう質問があって、
結論払い損ですと。
でもそうならないことがアジャイル開発というか、
国内ラボ開発のほうが多いですし、
あとはそうならないためのノウハウとか仕組みも当然ありますという話ですね。
早い段階にですね、お客さんの話聞いて、
スタートするときにはもうこれうまくいくかどうかわかるんですよね。
技術的にできるのかできないのかっていうのはわかるので、
多分やってみてですね、半年やってやっぱりできませんでしたってことは多分ないと思うんですよね。
もし技術的に不安があることがあるのであれば、
そこの部分だけ先にやって判断しましょうって話もできますし、
無計画にやってくるわけじゃないので、ラボ型開発って。
なのでさっき出ていた2人3脚というか同じ方向を向いてチームとしてやっていくために、
双方の透明性ですよね。
情報の開示であったり、綿密なコミュニケーションとかが欠かせないですね。
あと最後にこれちょっと聞くのいやらしいかもしれないですけど、
国内ラボ型開発はプラムザが最初に作ったってホームページに書いてあるんですけど、そうなんでしょうか。
そうだよ。
この言葉だって俺が考えた。
もともとラボ型開発っていうのがオフショアで、ベトナムとかラオスとかでやってる開発手法だったんだよね。
それを視察にベトナムに2014年に見に行って、実際やろうかなと思ったんだけど、
ベトナムの開発会社に出そうかなと思ったんだけど、仕事をね。
でもいろいろとコミュニケーションのトラブルが結構あるって聞いたんで、
であれば同じスキームを日本人でできるなと思って、
で、日本人を集めてやろうって言うんで、社員のエンジニアとパートナーのエンジニアを集めて、
チームを組んでやろうと思ってんで、
頭に国内のエンジニアを使いますって言って、国内って付けたと。
なるほどですね。
ちょっと別の回でも詳しく根掘り葉掘り聞きたいところですね。
プラムザ昔話。
嘘ではないので。
では本日はここら辺でいかがですかね。大丈夫そうですか。
はい。
ありがとうございます。
では本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価お願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。