00:06
はい、みなさんこんにちは。KEITHこと桑原です。本日もやっていきましょう。KEITHのエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することやエンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日はですね、ネタなんか一個、二日あったんですけど、昨年も書いたブログですね。
の中にソフトウェア開発における無駄っていうタイトルのものが書いてて、ちょっとそれを深掘りしたくなってみたんで、今日はやってみようと思います。
最近、僕のブログは静かなインターネットを使ってますね。ノートもたまに使いますけど、最近はこっちの方にちょっとずつシフトしてきたっていう感じですね。
はいはい、まあさておき。で、ソフトウェア開発における無駄っていうところですけど、そもそもこの話をしようと思ったきっかけっていうのが、
トヨタ生産方式の中にある無駄っていうものの定義をされてて、7個あるんですね。トヨタの中で。
その7個の無駄っていうところが結構面白くて、それをソフトウェアに置き換えたらどうなんだろうっていうのを自分で考えてみたって感じです。
同じようなことを考えたことがもう過去にもたくさんの方いらっしゃって、グーグルで検索をするとソフトウェア開発における無駄っていうタイトルだけでもたくさん出てくるんですけど、まあ久しぶりに僕もやってみたっていうところですね。
はい、まずトヨタプロダクションシステム、トヨタ生産方式っていうらしいですね。
こちらで定義されている無駄ですね。そもそも無駄とは何かっていうところですけど、付加価値を高めない各種減少や結果のことをトヨタ生産方式では無駄と定義しています。
で、この中の無駄の7個ですね。具体的に7個あって、上から順番に述べると、1つ目は作りすぎの無駄です。
2つ目手待ちの無駄ですね。3つ目運搬の無駄。4つ目加工そのものの無駄。
5つ目は在庫の無駄ですね。6つ目動作の無駄。ラスト、不良を作る無駄っていうところですね。
はい、まあ物理的にものを作っている会社だけあって、たくさんの無駄があるんですけど、まあまあそうだよなっていう、ならではの無駄だと思いました。
が、とても参考になりますし、このプロダクトを作っているところって言う、僕らソフトウェアもに通ったところが本当にたくさんあるなっていうところですけど、
これらの無駄を極力減らすことで、製造工程全体のトータルコスト、系統的に減らそうとしている取り組みなんだろうなというふうに捉えてみると、とても素晴らしいというか真似したいなってつくづく感じました。
さすがだなの一言ですね。世界に改善というワードを広めたトヨタってだけはありますね。
ちなみにこのトヨタ生産方式の7つの無駄の覚え方っていうワードもあってですね、もちろん頭文字は取っていくんですけど、
飾って豆腐っていうらしいですね。全然覚えづらと思ったんですけど、さておき7個の無駄を覚えるらしいです。まあ無理やり感あって面白いですけど。
で、これに習ってソフトウェア開発の現場における無駄っていうのを挙げてみたくなりました。
今から舐めますけど、純不動ですし、別に優先順位とか関係ないんですけど。
1つ目、再開発の無駄ですね。モジュールとかコンポーネントとかいろんなものを重複して作ってしまうことってよくあると思います。
03:05
まずは再開発の無駄ですね。2つ目は手作業の無駄です。
まあ自動化できるものに手を加えるのはもったいないので、自動化できるのは自動化しましょうと。
しなかったらそれはもう怠慢と言っていいんじゃないかと個人的には思っています。
3つ目、オーバースペックの無駄ですね。これは開発環境もそうですし、作っている機能とかもそうですけど、必要じゃないぐらいのオーバースペックなものをまだ利用するかどうかわかんないけど、将来的にあったら良いという前提で作るのは違うよねっていう。
確かこれなんか名前ありましたよね。なんだっけ。キープイットシンプルスターピットですね。キスの補足か。
必要がなければ機能を今入れる必要ないよね。オーバースペックの無駄だっていうところが1つですね。
4つ目、技術塞いの無駄ですね。文字通り塞いです。塞いってのはこまめに返しましょうっていうのをずっと言ってますし、
リファクタリングとかそういうものは本来は同時にリファクタリングをしながら開発できるのが理想ではあるよねってことです。
後でリファクタリングフェーズっていうのを取ってやることもできなくはないですけど、得てしてそういうのだいたいコストが爆発的に上がってくるんですよね。
技術塞いってもちろん積まれていくんですけど、単純にその時の塞いの数値っていうのが出たとして、その数値を積んでったら単純に足し算ではなくて、
技術塞いって時間が経つと欠け算になってくるんですよね。早めにこまめに返済できるに越したことはないよねっていうので技術塞いの無駄を挙げてみました。
5つ目はコミュニケーション不足の無駄。もしくは認知の相互とか認識相互の無駄と言ってもいいかもしれないですね。
これももちろんプロダクトをやっているチームメンバー同士もそうだし、メンバー外もそうですね。もしくはビジネスサイドの人たちとの認識の相互だったらあるかもしれないし、お客様との認識の相互があるかもしれないとか、
あとは情報の格差ですよね。に応じて先ほども出てきた再開発の無駄とかをエンジニア同士でやってしまう可能性もあるし、
確認不足によって全然違う仕様のものを作ってしまうとかあったりするんで、コミュニケーション不足の無駄と僕は定義しましたけど、
認識相互の無駄の方が正しいかもしれないですね。続いて6つ目。今のものにちょっと付随するんですけど、ドキュメント不整備の無駄ですね。
ゆったりはないっていう口頭の話も出たりしますし、そもそも定義をしてなかったものがドキュメントを書く中で可視化される可能性はあるのでね。
これやってなかったなっていうのが出てきたり。あとは過不足ですよね。しっかりドキュメントはミニシーに書いていきたいねってのがあると思うんで。
あとは作ったはいいけど、更新してないドキュメントは結局それも不採に近いところはあるので。
ドキュメント不整備による無駄はたくさんあるよなっていうのがありますので、ドキュメンテーションは皆さんしっかりやりましょう。
ラストは高機能の無駄と自分で書いてますけど、さっきのオーバースペックの無駄となんか一緒な気がしました。
はい、これちょっと削除してもいいかもですね。高機能の無駄です。
よくあるシステムの、だいたいECサイトとかよく言われるのは、使っている機能のだいたい2割から3割がユーザーが使う9割の機能だと言われたりするんですよ。
なので、いろんなものを考慮するのはいいかもしれないですけど、実際ユーザーが使うのってそんな多くないよねっていうのが高機能とかのお話ですね。
06:01
あったら便利とかあったらいいよねー系はだいたい使われないとまず思う方が多分いいと思うんで、
MVPか、を決めて絶対に運用する中でこれがないと機械損失になるねっていうところまで一気に絞ったものを作る。
その中から肉付けだったりとか改編だったりとかをするのがいいんじゃないのっていう話ですね。
はい、以上7つ挙げたけど、最後のやつは削ろうと思うので6個ですね。
6個が僕の中で思うソフトウェア開発における現場の無駄だなっていうふうに思いました。
一番でかいのって結局その認識総合の無駄だというふうに思ってます。
そこだけでも解消したらほぼ全部解決できるんじゃないか感はありますね。
手作業の無駄とかはさすがに認識総合の話ではない。
自動化するってところは気づかない人は全然気づかないと思ったりするし、
その時の技術でできる自動化とできない自動化もあったりはするし、
かつ自動化そのものが正義ではない時も絶対あるんですよ。
要件に応じてはここは手動的に人間がコントロールしながらやりたいよねっていうものもいくつかあると思うのでね。
そういうのがあったりしますというところでした。
ソフトウェア開発における無駄のブログとか記事を書かれている方は他にもたくさんいらっしゃって、
その中でも一番とは言わないですけどかなり有名な方はりゅうぜいさんですね。
吉場龍太郎さんという方もブログ書かれていて、2012年ですね。
実に12年前に書かれたブログがあります。
今は現在はアジャイルコーチやったり、どこの会社にいるのかちょっと僕も存じ上げないんですけど。
まあそのりゅうぜいさんが書かれたソフトウェア開発における無駄っていうところから参考にさせていただきたいと思っていて。
まあいっぱいあります無駄があるんですけど。
リスト形式に並べられているのでバーっと一気に読んでいきたいと思いますね。
はいじゃありゅうぜいさんが定義されているソフトウェア開発における無駄です。
1つ目使わない機能、2つ目たくさんのオプション設定、3つ目読まない仕様書、4つ目読まない報告書、
2つ目やたらと体裁にこだわった文書、6つ目更新されない文書、7つ目目的のない会議、
8つ目決定事項が守られない会議、9つ目遅いpc、10個目小さいディスプレイ、
11個目行動の監視、12個目目的化された報告、13個目同じ間違いの繰り返し、
14個目自動化できる作業の手動実行、15個目マルチタスク、16個目詰め込み、
17個目はバグ、18個目作りかけで放置されたもの、19個目チェックインされていないコード、
20個目テストされていないコード、21個目顧客価値と一致しない役割分担、
22個目長すぎるフィードバックプロセス、ラスト過度な先読み、
23個一気に並べられてましたね、とてもいいなと思いましたし、なるほどって思うものもたくさんありますね。
09:01
カテゴライズすると、いわゆるオーバースペックの話と、さっき出ましたドキュメンテーションの話と、
ミーティングとか会議とか、コミュニケーションでいいかもしれないですけど、ミーティング周りですね。
あとはハードスペックの話と、人的監視の話ですね。
あとはソフトウェアにおけるバグとか、仕様周りの話と、
あとはチームビルディングの話がもう1個あるのかなっていうところですね。
ざっくりカテゴライズするとこの7個かなっていう感じですけど、まあまあそれを現場における言語化をしたっていうところです。
いやーなんかすごくわかりやすくて、僕のブログ無駄だったかもしれないって感じがしますね。
こっちの方が素晴らしかった。まあでもその無駄の原因もいっぱいあると思うんですけど、
ソフトウェアって無駄が見えにくいよねって指摘があって、それは本当おっしゃる通りだと思います。
まあそもそもソフトウェア自体が、プロダクトとかシステムならば目に見えるんですけど、APIで目に見えなかったりするので、そもそも見えないものを作っていることも多いんですよね。
なので逆に言うと無駄も見えづらいかもしれないですね。はい。
ディズラ上バグがなかったりテストも書かれています。で、ちゃんと機能しているので、無駄じゃないように見えているけど、実はこのコード重複なので無駄だよねっていうので、
パッと見た目上無駄じゃないコードもあったりするので、やっぱり見づらいよなって思いましたね。
無駄の発見のなんか仕組み、プロセスのがしっかり作られているというのはすごくいい話ではあるので、ここはやっぱり意識していきたいと思いますね。
はい。で、あとは無駄の原因もいくつか書かれているんですけど、遅すぎる仕掛かり中の作業だったり遅延だったり、仕事の引き継ぎとか受け渡しですね。
あとは官僚主義、割り込み、不明瞭なワークフロー。あー確かに無駄の原因になりそう。
で、生み出された無駄として必要以上の機能と不具合と複雑さ。現代は複雑さと必要以上の機能って結構同義、混在してその気はしますね。
不具合はもう未来へシステムとかアプリケーションを作る限り付き合っていかなきゃいけないんですけど、
複雑さと必要以上な機能っていうのは本来は削れるというか作られなくていいはずなので、ここは何か可視化・検知できるもんなんですかね。
わかんないですね、この辺は。はい。で、あとは手作業における無駄はもう言った通りって感じですね。
なのでチーム間のコミュニケーションだったり、コードレビューとかっていうのはしっかりやらないと同じものを作ってたりする。
同じユーティルツを作っている時もあったりしますからね。作り込みすぎのものもあったりしますよね。
いろんな無駄があるし、いろんな作業の中で効率化をすることができたりするので、一番最初にやはりチームビルディングとコミュニケーションパスとか、
あとは心理的安全性をしっかり保つのはすごくいい話ではあると思うんで、なんだかんだまずスタートでしっかりチームビルディングをどこまで時間かけられるかっていうのは僕は大事だと思ったりしますね。
あと走る中でチームのメンバーもお互いで成長し合える環境であるっていうのもいいかもしれないですね。
本当の技術力ってのはそういうところに出てくるかもしれない。
まあそんな感じですね、ソフトウェア開発における無駄と。
で、このブログが12年前、まあ厳密に言うと11年10ヶ月9ヶ月ぐらい前のブログですけど、2012年6月18日に書かれたブログですけど、
12:08
これ現代でも全然適用できるんで、逆に言うと技術がすごい進歩したし、チームビルディングのフレームワークとか手法もいろんなものが開発されましたけど、
人類はずっと同じ課題を抱えてたり同じ無駄を生み出しているってことはこれで分かるなって思いました。
分かるなって言うと僕がいる環境は少なくとも同じことをやっているなと思うので、なかなか人間は成長しないんだなって分かりましたし、
ツールとか技術が進歩するほど人間は退化するので、まさしくそうとなって気がするので、
これを上手いこと仕組み化だったり、より自動で監視できるような環境が揃う、そっちの方の技術っていうのが生まれたらいいのかなと思いますけど、
残念ながらエンジニアの技術はだいたいハードスキルによるので、そういうソフトスキルを活用しなきゃいけないものっていうのはなかなか生み出しづらいですよね。
抽象度が高かったりするので、そもそも生み出しづらいっていうのはあるかもしれないですけど。
先にドキュメントを書くと重複が見つかったりはします。本当おっしゃる通りです。
いわゆる仕様バグって言われるものですけど、
仕様バグはね、意外と最初の要件定義とか設計で見当たらないんですよ。
で、後からやっぱり現場の人とかいろんな方々の意見が入った時に、
ああ、あれもこれもって絶対出てくるので、要件とか仕様の見直しっていうのは定期的に本当はやるのがいいのかもしれないですね。
もう徹底的にやり尽くして、もうこれ以上はもう本当ないでしょう。
で、新しく出たものはもう新しいシステムの機能とかでガラッと刷新するか、
運用も新しいシステムとかで作るのであれば運用フローも変えましょうみたいなところがいけたらいいんですけどね。
残念ながら、えてしてお客様はシステムを変えるけど運用を変えませんみたいなお客様がたくさんいらっしゃって、
じゃあなぜシステムを変えるのかっていう本来の怖いなところに戻らなきゃいけない気がするので、
新しくするんだったら何か自分たちのペインを背負いつつ新しく得られるメリットを享受するための心の準備も必要だよなってのはちょっと思いましたね。
ソフトウェア開発の開発における無駄っていうのはさっき言った通りなんですけど、
根本的なところとか根本的な解決っていうのは開発のお話だけでは全然止まらないなっていうのがやっぱり思うところではありますね。
皆さんもいろんなところで感じるところあると思いますけど、皆さんの声を出すのもすごく大事だし、
まずはちゃんと声を出せる環境があるっていうのもすごく大事だと思うので、勇気出して声を出していくのは一つかなと思いました。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。
