00:05
はい、みなさんこんばんは。株式会社ゆめみのキースことくわはらです。
本日もやっていきます、Web 業界のなんでも雑談室です。
この番組では、みなさんに何かプラスになる情報提供を目指してお届けしていきたいと思います。
第57回ですね。第57回は、モグラ叩き開発について話していきたいなと思います。
こちらの言葉は聞いたことある方もいらっしゃると思いますけど、
初めて聞く方もいらっしゃると思うので、話していきたいなと思いますが。
まず、あるエピソードを紹介しようかなと思っております。
わかりやすさのためにですね。
はい、ある2人のプログラマー、山田と鈴木という2人の架空の人物がいたとしましょう。
はい、でも2人とも有能で、同じ程度のドメイン知識を持ち合わせていて、
かつ言語スキルとかも同じくらいだと思っていただければと思いますが。
はい、しかしですね、この2人には結構大きな差がありましてですね。
はい、1人目の山田の方ですね。山田は実装スピードがとにかく早く、
とにかく終わらせることに専念しているという人物ですね。
それに対して、鈴木というものはリファクタリングに結構時間を使う。
あと行動の品質とかにも時間を使いたい人で、
鈴木は変数名とか関数名がもちろん優れていて、
機能を動作するところまで実装したとしても、
行動をモジュールに分割したりとか小さく分割したり、
またテストも書いていたりするという人物ですね。
はい、これだけを聞くとなんかエンジニア目線で見たら
鈴木の方が優れていますよねというふうに感じますけど。
ただしですね、やっぱりタスク完了自体は山田の方がやっぱり早いんですよね。
リファクタリングとか後からするか分からないですけど、
数学ともタスク1個1個に対しての完了の宣言は山田の方が早いため、
何も知らない方、マネジメントの人がそこまで意識しないという方だと、
多分山田の方が優れたエンジニアだろうというふうに判断されると思います。
はい、そこはしょうがないですよね。
それをちゃんと見ていないマネージャーはどうなのという話はあると思いますけど、
それは一旦置いておいてください。
ではですね、ある機能の実装終わってテスト動作確認して、
とりあえず大丈夫だったというところで、
次にですね、この状態からもちょっと仕様の変更とか、
私はちょっと機能をこういうふうに改善したいという要望がお客さんから上がって、
それじゃあコードを修正しなきゃいけないですよねという話になったため、
またそのコードの修正を山田と鈴木に再依頼したとしましょう。
この時ですね、鈴木ならですね、そして鈴木のコードなら今回の変更も何らか行われて、
かつてまた動作検証しても問題ないだろうなというふうに皆さんも想像つくと思いますし、
今回のエピソードでもそうなりました。
逆にですね、山田はですね、今回の変更もやっぱり鈴木よりも早く変更の完了を宣言したんですよ。
はい、もちろんやっぱりそのスピードについては山田の方が早いですからね。
しかしですけど、その山田のコードをですね、動作検証してみますと、
新しく変更した機能については満足いくようにちゃんと動作してたんですね。
03:04
ただしですけど、以前動いたところの機能に不具合が発生して動作しなくなったというところですね。
しょうがないのでそこの不具合の修正をまた再度山田に指示しまして、
また終わったというのでまた再度動作検証しました。
そうしますとですね、今回の修正した箇所も確かに動作をして直っているんですけど、
今度はまた別のところに不具合が発生しましたという感じですね。
1個不具合を顔を出してきたらそれを叩きますと。
そうするとまた予想外のところにまた新たな不具合の顔が出てきて、
またそれを叩く、延々とこれの繰り返し。
あれでモグラ叩きのようですよねということで、
このようなことをモグラ叩き開発と言ったりします。
はい、ちょっと古い言葉なんですけども。
こうなった場合にですね、
根本的に山田の設計とか実装そのものが間違っているっていうことが往々にしてありますし、
その場合って全部のモグラ叩きまくるのかっていうと、
多分それだと根本的に解決しないことが多いので、
もうやっぱり一から作り直すか、実装をもう一回見直さなきゃいけないっていうことが結果として早いことも多いんですよね。
経験、私の経験からもやっぱりそれを思っていて。
はい、ですので、スタート時って鈴木の方がやっぱり確かに実行速度がすごく遅かったですよね。
山田の方がすごく優秀に見えるかもしれないんですけども、
はい、ですけども鈴木というのは初期からプロジェクトスタートの時からコードの品質が高いし、
この実行速度っていうのがずっと維持できるんですよ。
持続した実行速度を叩き出せるというのが鈴木の特徴で、
またやっぱりそうやって最初から品質が高いため変更にも強いですし、
テストも書いているから新しく仕様変更があった時にその仕様そのものの検討をもう一回見直しもするとか、
今のソースコードの互換性のチェックもできますし、
またフィードバックも結構簡単に得られることもできると。
得られますよねっていうことですね。
山田はですけど逆にとにかくスピード重視ですので、
あまり先のこととかを見据えられていない、
もしくは全体的な視点がちょっと抜け落ちたまま実装されている可能性が結構高くてですね。
これは往々にしてありがちなんですけど、
今回のように不具合が発生したりとかして、
後から結構失速する開発速度がですね。
もしくは完全に一回ストップして見直ししなきゃいけないか、
もしくはやり直しをして全部白紙にならない可能性すらあるんですよね。
ですので品質の高いコードって結構大事で、
その代わりでも高いコードと品質の高いコードとテストを書くことにはやっぱり時間がかかるんですね。
コストがしっかりかかるというところですね。
これってやっぱり短期的に見ると結構損失に見えるんですよね。
スタートからやっぱり山田は早いのでこっちのほうがいいよなっていうふうに、
マネジメントしてる側からしてると思うかもしれないですし、
06:00
鈴木のその速度は遅いというところで被損してるよっていうふうに言われるかもしれないですけど、
やっぱり長期的な目線でいくとやっぱり鈴木のように品質高いコードっていうのはやっぱり利益をもたらすんですね。
もっと言うと、別の言い方をすると後から失うお金がなくなるっていうことですね。
結果をして利益をもたらすことができるっていうことになります。
目線のタスクとかもやっぱり実装を早く終わらせることっていうのは本当に大事ですし、
それは確かにわかるんですけど、
やっぱり品質をしっかり保つことっていうのもすごく大事ですし、
後から失うお金がなくなるっていうのはすごく大事なことですので、
意識した方がいいなっていうふうに思っております。
そのためにはですね、やっぱり見積もりってマネージャーの皆さんやられると思うんですけど、
見積もりするときは各機能の実行速度とかどれくらいできますかっていうよりも、
プラス品質ってのをちゃんと意識して、そのコードをちゃんと綺麗に保てます。
そしてちゃんと動作しますし、テストも書きますみたいなところまで、
見込んだ見積もりをしていくのがすごく大事かなと思っています。
なのでできるところまでっていうので見積もりを出すんですけど、
それにさらにある程度バッファーを積むとか、テストをしっかり書くみたいなコースまでしっかり見てですね、
テストコースを今回取らないというプロジェクトであったら、
やっぱりちゃんとバッファーを積むというところですね。
で、その積んだ上で一つ一つの機能実質の全部の見積もりを集計して外産見積もりなんですけど、
だとしてもそういうのを集計してお客さんに出すのが正しいのじゃないかなというふうに思っております。
はい、ということで今回はこんなところで収録を終わりたいと思います。
やっぱりモグラ叩き開発は怖いですし、やっぱり見積もりって気をつけた方がいいですし、
やっぱり品質を保つのがすごく大事だなということを今日は言いたくてお話しした形ですね。
はい、以上となります。
また何か聞きたいことが話してほしいことがありましたらいつでもレーターお待ちしております。
では次回の収録でまたお会いできればなと思います。バイバイ。
