システム開発における課題
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳と、本日、先週に引き続きゲストに来ていただいております、
株式会社プラムザCTO、株式会社フェッド代表の小林さんです。引き続きになりますが、よろしくお願いします。
はい、よろしくお願いします。小林です。
よろしくお願いします。
さて、今回のタイトルなんですが、システム開発の一体言わないの、水かけ論をどう防ぐというタイトルになります。
これはそうですね、やっぱり開発するにあたって一体言わないということはよくあることなんでしょうか、辰巳さんいかがでしょうか。
逆にほとんどのケースを除いてないことはない気がしますけどね。
もうほとんどあるのか、もはやそれがシステム開発みたいなところですか。
それはありきみたいなところは、それがよくないようなかもしれないですけどね。
これは小林さんも完全に同意というところでしょうか。どうでしょうか。
そうですね、開発現場に限らず、どんな仕事でも一体言わないってあると思ってるんですよ。
なんか普通の営業だとか、例えば経理の仕事だとか、人事の仕事だとかでも、どの仕事をとってもこれって発生するのかなとは思ってるんですけど、
開発現場で話題になりがちなものだなっていうのは印象としてあります。
なるほど、ありがとうございます。
システム開発における一体言わないっていうこの水かけ論がなぜ起こるのかっていうところをちょっといろいろ話していけたらと思うんですが、辰巳さんどうでしょうか。
仕様変更の影響
一番はですけど、人間も生きてれば考え方も変わりますし、成長したら知識も増えると同じくですね、プロジェクトというかプロジェクトも生き物なんでそこ移り変わるんですよね。
そこも特に何かすでにやるもののリプレイスとかだったらまだそんな考えること少ないんで、変わることも少ないですけど、特に世の中にないものを一から作り上げるみたいな話になってくると結構そこはよく言えば柔軟。
悪く言うとそういう一体言わないが起こる、日進月歩で要件が変わってくるっていうのはあるかもしれないですね。
なるほど。これを最初に要件定義とかでガッチリ固めてもやっぱりどうしても変わってくるものですか。
辰巳さんいかがでしょうか。
そうですね。だんだんシステムってだんだん目に見えるようになってくるので、お客さんとしてはそれを見るとですね、こうなってるんだったらこうなってほしいなとか、あれも入れられないかなとか、どんどん要望は増えていくものだし、
あるいはこれ作ってもらったけどこれいらないなみたいな、いらないから別の作ってよみたいな、いや作っちゃったんだけどみたいな、ここまで作っちゃったんだけどっていうのをそれをなしにして、別の代わりにこれつけてもらえばいいかなみたいな、いろいろとこう言ってくるわけですよね。
それは自然のことです。この業界25年とかもっとか30年かいりますけど、それは変わらないですね、昔から。
なるほど。辰巳さんにはこの助理工程に入ってもらうということも含む、実際に作っていただくっていうところにも参画いただいているプロジェクトもあると思うんですけど、これやっぱり現場としてもあるあるなんですか?どういうふうに受け止めてやってらっしゃるのかなっていうのをちょっと聞いてみたいなと思いまして。
はい、そうですね。結構捉え方は人によって変わる部分、エンジニアさんによって変わる部分もあるかなと思ってて、やっぱり仕様変更っていうこの4文字にすごく敏感なエンジニアさんはいらっしゃいます。
あ、また仕様変更かみたいな。結局、直接エンジニアさんがお客さんと話しているわけじゃないパターンの方が結構多いじゃないですか。なんでそのエンジニアさんの手の届かないところで何か見えない不思議な力によって仕様変更が加わってしまって、エンジニアはそれを伝えられるだけっていうのが結構往々にしてあるのかなと思ってて。
で、そこで言うと確かにネガティブな印象というかイメージを持っているエンジニアは少なからず、多からずいると思ってます。
多からず。
そうですね。逆に近年のアジャイルだったり、スクラブだったらアジャイルの開発手法によっては、仕様変更っていうネガティブな感じのイメージじゃなくて、フィードバックっていう前向きな捉え方をして実装に入れるっていうエンジニアさんももちろんいるので、進め方、伝え方、コミュニケーションの取り方次第なのかなとは思ってます。
なるほど。仕組みとかにもよりますが、基本的にはネガティブに捉えられるっていうところだと思うんですけど、それってなんでなんですかね?やっぱ作ったものが無駄になるとか、もっと労力かかるとかそういったところになるんですかね?
そうですね。無駄になるというよりも、この想定で作ってきたところ、例えばなんかジェンガとかで縦に全部積んでいくじゃないですか。
はいはい。
で、いきなり横にこうじゃあ途中から積みましょうって直すと積み直しになっちゃうんですよね。
はい。で、全部縦に積んでいくっていう方向性でジェンガを組んでたと思うんですけど、いきなり横が入ることによって土台から組み直さなきゃいけないっていうパターンも少なからずあります。
はい。
なんで手戻りになる範囲っていうのが結構見えない、読めない部分が多いんですよね。
なるほど。
はい。
これ辰根さん、こういった場合、一括で受け負って開発していって、これ変更したいってなった時に追加の工数とかが出てくるっていうところが今の話を聞いてると出てくるんですけど、そうするともうその都度クライアントさんとプログラマーの間に入って取りまとめていくっていう感じになるんですかね。
そこで言うと、最初の段階でこちら側で考慮できなかったりだとか、超簡単なものだったりだとか、あとはそれがないともう運用上回らないっていうのが明らかな場合とかだったら、ちょっと無理くり、ボリュームによりますけど、押し込んだったりとか、
あとはそうじゃなかったら追加でやる、あとは一旦リリースした後に考えましょうっていう提案をすることが非常に多いですけれども、そうなってくるとこちら側にシワがやってきたりだとか、実際それで変質担保できなかったり、じゃあ納期が遅れたりとかして、なって最終的にお客さんのところにまたそのシワが寄り返していくんじゃないかなとか思ったりしますけどね。
なるほど。正直、要件定義から変わったものを作るとなると、そこのある種の練り直しとか、どうそれを対処するのかっていうところに新たに労力を当然かかってくるっていうところなんですかね。
そうですね。これはじゃあちょっと小林さんにも聞いておきたいんですけど、エンジニアさんの観点からで、そこってあらかじめ上流工程にも勘で、ある程度そこを仕様変更とかを想定しつつコントロールしに行きたいのか、それとも降ってきた要件に沿って実装するだけで満足なのかっていうと、そこら辺でどうなんですか。
難しい質問ですね。結構エンジニアさんによって違うかなっていうのはあるかもしれないですね。自分の今のポジションがプログラマーっていうポジションであれば、降ってきた要件定義をさばいていくっていうのがさばいていくのは好まれる方もいらっしゃると思うんですけど、さっき辰巳さんがおっしゃっていただいたように、上流工程に勘でエンジニアとしてアドバイスだったり意見を出したりとか、
仕様変更の話し合いの場で、それやるとかなりまずいですっていうのが言えたりするのって結構アドバンテージだとは思うんで、僕は比較的上流工程に一緒に食い込んでやらせてもらうことの方が多いなとは思ってるんですけど、結構好きかどうかは人によるかなっていう感じです。
それでもあれですか、仕様がバンバン変わってきちゃうことに対しても受け入れられるものなんですかね、自分でその上流に入り込みたくないからといって。
受け入れざるを得ない感じはありますよね。そこ関係ないからしょうがないっていうふうに思ってる人もいるとは思うんですけど、
別の観点だとそんなに仕様が変更するっていうシステムは仕様変更になってしまう原因も別であるのかなとは思います。
最終的にこのシステムが何を解決したいのか、どこに向かっていきたいのかっていう一本の道筋が決まってなかったりフワフワしてる場合だと結構仕様変更、細かいところで起きやすいなっていうのは思ったりしますね。
なのでクライアントさんといかにそこを最初に握れるかっていうのはある気がしてます。
そこも結構難しいところで、最初の要件の段階で先方が特にイメージができなくて、上がってきたものを見てレビューするしかないっていうのは往々にしてあるからと思ってるんですよね。
そうですね。ここが作ってみないとわからないというか、無形商材を販売してると思うんで、最初からイメージが伝えられないっていうのは難しいところかなとは思います。
本当そうだと思いますね。
国内ラボワート開発の導入
小林さんとかであれば、ここ怪しくないですか?怖くないですか?っていうところを結構言ってくださるじゃないですか。
それやっぱり思いつつ言えないような関係性であったり、人の性質っていうんですかね、そういう性格であると結構やっぱりエンジニアさんのストレス溜まりそうだなっていうのは今ちょっと聞いていて思いましたね。
まあでもそうですね、どうなんでしょう。相性は多分エンジニアとかでいうふうに限らずあるとは思うんですけど、そこって結局コミュニケーションのやり方の話だとは思うんで、いかにしてエンジニアとコミュニケーションを取っていくっていうのはPMとかプロダクトを動かすっていう人の手腕が問われるというか腕の見せ所なのかなとは思ってますね。
なるほど、ありがとうございます。では、プロジェクトを進めていくにあたり、要件定義がどうしても起こってしまうという中、プラムザではどう解決しているのかっていうところを改めて島田さんからお伺いしてもよろしいでしょうか。
そうですね、ずっと言ったり言わないの見かけなのっていうのは必ず発生してきたんですね、ずっとプラムザもね。途中からだんだんこれはですね、やっぱりなんでそうなるかっていうと、お客さんとね、うちら開発会社の方がですね、同じ方向向いてないなっていうのがやっぱり一番原因かなというふうに思って、
やっぱり契約する時点で、お客さんの方とね、これをじゃあ作りましょうって言って契約するんだけど、それを契約した瞬間からですね、開発会社としてはその約束を守ればいいんですねっていう、じゃあこれを作ればいいんですねっていう意識になり、お客さんの方は何とかその中にですね、いろんな機能を突っ込みたいと、同じ金額でね。
っていうその、バカ試合みたいな攻め合いが発生するわけですよね。それがやっぱり一番問題であって、それをお互いに対面しちゃってる利益が相反しちゃってる状態っていうのがやっぱり一番良くないので、そこを同じ方向向くような契約にならないかなと思って、2ゼロイチ7年ぐらいかなに始めたのが国内ラボワート開発なんですよね。
ありがとうございます。他の会でも何度か国内ラボワート開発っていう話をしてきているわけですが、ちょっと改めて辰巳さん簡単にでいいので、国内ラボワート開発、準委任契約のことについてお伺いしてもよろしいでしょうか。
はい。従来の一括お伺い型だと、見積もりした金額から逸脱しない固定の金額をお支払いいただくみたいな感じなんですけど、準委任契約の形になるので、前を稼働した分だけご請求しますという感じなので、早く終わったらその分少ない方数で請求できますし、当然最初このぐらいの見積もりになりますっていう提示はするんですけど。
ラボ型開発のメリット
それで最短距離でやっていくっていうのが簡単ではありますけど、コンセプトですよね。なので島田さんがおっしゃるところで言うと、お互いそこで真剣になれるというか、やればやるほどお金かかるんで、そこは当然クライアント代わりに責務が発生すると言いますか。
普通だったらこの金額でパンって出しますから、じゃあその中でちゃんとやってくださいって話になると思うんですけど、お互いちゃんとそこで細かにコミュニケーションを取ってやるっていうスタイルにならざるを得なくなってくるんで、そこでちゃんと優先度だったり、後から追加で増えちゃったらまずいから、今のうちから真剣に考えようっていう気持ちになりますね。
ありがとうございます。仕組みとしてクライアント開発会社とともに同じところを向けるっていうところで、国内ラボ型開発っていうところになるんですが、今回ゲストに小林さんがいらっしゃってますので、エンジニア目線でラボ型開発っていうのはどうなんですかっていうところをちょっと聞いてみたいと思うんですがお願いします。
はい、そうですね。あんまり考えたことなかったのが正直なところではあるんですけど、やっぱり従来のウォーターフォール型の開発、先に要件定義をするのはおそらくラボ型もそのウォーターフォールも同じ工程としては入ってくると思うんですけど、実際の進め方としてラボ型開発の方だと比較的頻繁にクライアントさんの方にデモを行ったりとか、それこそPMである辰美さんとコミュニケーションを取ったりだとか、
比較的会話のタイミングっていうのがラボ型開発の方がエンジニアから見ても増えるのかなっていうのは印象としてあります。
あー、そうなんですね。
そうですね。結局ここをこうした方がいいです、ああした方がいいですっていうのは従来のウォーターフォールに比べるとラボ型の方が柔軟に対応できるっていうところが多分メリットだと思ってるんで、そのあたりでコミュニケーションの数が増えるっていう点ではエンジニアからすると作ってるものが本当にこれでいいのかっていう不安がちょこちょこ解消できるタイミングがあるっていうのはいいことなのかなとは思ってますね。
なるほど。確かにエンジニア目線から見て会話が増えるっていうのは初めて聞いた。確かにそうかもっていうふうに思ったんですけど、辰美さん体感としてもそんなところですかね。
あると思います。クライアントともそうですし、エンジニアとも増えるっていう感じになると思うんで。そこを嫌う人はいいかもしれないですね、もしかしたら。
一括で受けてると、普通の受託の一括受験を受けてると、なるべくあんまり話したくないんだよね。話すと話し方変わってきちゃうんで。
なるほど。
話すよ話すけど、やべべなことは言わないようにしようとかって思ってしまうわけですよね。
ラボのときはですね、いろんな話をして全然構わないので、透明性持ってやるのが大事なので、ここまで作ってきたんだけどちょっと効率悪いと思いますとか、こういう方法にした方がいいんじゃないかとかっていう提案がどんどんできるわけですよね。
そのほうがコースが減りますよっていう提案もできるわけですよ。だからそういう意味ではね、会話はどんどんしていくっていうのがラボのいいところだと思いますけどね。
なるほど。そう考えると、クライアントと開発会社というか上流工程だけでもならず、エンジニアさんも同じ方向を向くっていうのがラボアート開発になるんですね。
クライアントとのコミュニケーション
エンジニアさんからもね、何か作ってて新しいこと思いついたり、何か非効率なことやってるなと思ったらどんどん言ってもらえれば、お客さんにそれ説明して、では方針変えましょうみたいなこともできると思うんですよね。
ありがとうございます。小林さん、上流工程も入っていただくことあると思うんですけど、小林さん個人的にはどう思うんですかね。
僕は結構エンジニアでもありつつ、コミュニケーションするべきだというタイプの人間なんですよ。なので上流にもガンガン入って、何ならクライアントさんと直接話させてもらって、
本当にクライアントさんのやりたいことが何なのかっていうのをヒアリングして、技術的にそれが解決できるかどうかを翻訳して紙砕いて説明するっていうのはエンジニアにしかできないことだと思ってるんですよね。
なのでそういう会話が僕増える分には全然苦じゃないというか、むしろ本来の開発であるべき姿だと思ってるんで、そこはラボ型開発のエンジニアからした時の特定の人に対するメリットだと思ってます。
ありがとうございます。
小林さんは開発会社の社長がやってるわけだから、経営視点でも話を聞けると思うんだけど、フェットさんのほうもあれですよね、ラボ型開発やってるってお聞きしたんですけど。
そうですね、弊社のほうもやってまして、プラムザさんと同様に順位任で入るようなことも多かったりします。
やっぱりクライアントさんも最初からすべてを理解してゴールが見えてるわけではないんで、なんかこう伴奏っていう形で一緒にシステムを作っていくっていうやり方が結構多いかなと思ってます。
僕本当に独立するときに思ってたのが、絶対従来のウォーターフォールを繰り返したくないなっていうのが本当に思っていて、なんであえてこういうコミュニケーション、やる人からしたらコミュニケーションなんて無駄じゃないかと思われるかもしれないですけど、僕はそっちのほうが大事だと思ってるんで、それが重視できるこういうやり方を今、弊社のほうでも進めてるっていうのはありますね。
ありがとうございます。
そうですね、今回話を聞いていて、前に言ってたことと違う、一体言わないが起こる、要件が変わるっていうことは必ず起こることなんだなっていうところを前提としたときに、固定契約とかウォーターフォール一括っていう場合は摩擦になるところをラボ型であれば仕組みとして受け止められるんだなっていうふうに改めて思ったのと、個人的にはクライアントさんと開発がした上流工程とエンジニアさんも同じ方向向くっていう仕組みになってるんだっていうところをちょっと個人的に、
ウォーと思ったところでした。
プラムザは一括ももちろん受け止まっているんですが、変化に強いスタイルでの併装、ラボ型での併装も可能ですので、ぜひご相談いただければと思います。こんなところでいかがでしょうか。
はい、ないと思います。
小林さん、2週にわたりご参加いただきありがとうございました。
はい、こちらこそありがとうございました。またよければお早いお誘いください。
はい、ありがとうございます。
本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。またXでも最新情報を随時発信しますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
