00:00
今回のテーマは、良いコードと悪いコードです。良いコードとはどういうものなのか、良いコードを書くためにはどういうことをやっていかないといけないのかというところについて、いろいろお伺いできればなと思っています。
というわけで、ゲストには前回に続いて良いコード、悪いコードで学ぶ設計入門、著者でLady4株式会社のミノ駆動さんにお越しいただきました。ミノ駆動さん、よろしくお願いします。
よろしくお願いします。
今回は設計について、メインにいろいろお伺いできればなと思います。
エンジニアストーリー by Qiita
では、早速本題の方に入っていきたいのですが、まずは先日出版されたと思うのですが、良いコード、悪いコードで学ぶ設計入門について、いろいろお伺いできればなと思っています。
実は、僕も読ませていただきまして、すごい勉強になったので、今日はいろいろお伺いしたいなと思っています。
ちなみになんですが、この良いコード、悪いコードで学ぶ設計入門を手にしてほしい人だったり、背景みたいな、思いみたいなところがあれば、ぜひお伺いしたいです。
手にしてほしい人としては、本の冒頭にも書いてるんですけども、この本って、いわゆる初級者向けの本なんですね。
設計って聞いたことあるけど、ちょっとよくわからないだったりとか、ハードル高そうだなっていうふうに感じる方、
勉強しようと思っても何から提出できるかわからないっていうような方に手に取ってほしいなっていうところが、手に取ってほしい人ですね。
新筆の背景は重いっていうところですけど、結構設計ってハードルがかなり高いと思ってるんです。
初級から中級に上がるまでのハードルがとてつもなくギャップが大きくて、
例えば設計関連の本といったら、有名なところで言えばリファクターリングだったりとか、レガシーコード改善ガイドだったり、
あとフィンアーキテクチャーとか、ドメイクド設計とかっていろいろあるにはあるんですけども、
どれもこれも結構分厚いし、物によっては難解っていうところもあって、
なかなか新卒で入って1年目っていう感じの人が、なかなか手に取りにくくて学びにくいっていうような非常に大きなハードルがあると。
僕の本っていうのはそのギャップを解消して、なるべくそのハードルを解消するために、
小さくスモールステップで段階的に中級レベルにまで学んでいければいいなっていうようなところをコンセプトに入りました。
まさに実際読ませていただいたときの感想になるんですけど、本当にすごい分かりやすいなっていうのをまず感じました。
ありがとうございます。
僕自身も設計っていうところに興味を持っていろいろ勉強してたりしたんですけど、やっぱり難しい本が多いし、
03:01
あととにかく翻訳系が多いので、文章がそもそも結構読みづらいっていうのがあったので、
美濃工藤さんの本は本当にすごい読みやすいし、とても学びやすい、最初に初学者として手に取りたい本だったなっていうふうに思いました。
ありがとうございます。
翻訳本って言い回しが日本っぽくないっていうところもあったりとか、ちょっと分かりにくいっていう部分ももちろんあったりとかして、
ちょっと素直に読むのが難しいっていうのがあったりとかもするんですけども、かなり読みやすいように、かなり軽易に読めるようにこちらとしても工夫はしました。
本当に読みやすかったです。
この良いコード、悪いコードで学ぶ設計入門、タイトルに書いてある通り、読んでみると悪いコードが書いてあって、
そこを具体的にこういうテクニックとか考え方でリファレンシングしていって綺麗になっていくっていうような、
定裁になっていると思うんですけど、その良いコード、悪いコードみたいなところを載せていく、
定裁みたいなところで拘ったポイントとか、それをあえて採用した理由とかあったりしますか。
そうですね。世の中にある設計関連の本っていうのは、結構理想的にはこうだよっていうふうな書き方を知るものが多いです。
もちろんそのリファクタリングは、こういう良くないコードがあって、
このコードは問題だからこういうふうに直しましょうとかっていうのももちろんあるんですけど、
ものとしてはそんなに多くはないと。
だから設計っていったときに、一体設計ってどんな良いことがあるのっていうところっていうのはやっぱり、
困りごとがないとそもそも設計のありがたみってわかんないと思うんですよね。
はい。
だからまず禁止的に良くないコードを示した上で、これだとすごく変更が難しかったりとか、
いざしたらバグを埋め込んでしまうかもしれないよっていうことを示した上で、
じゃあそれを欠かすにはどういう構造になってればいいんですかっていうようなことを示すと、
設計のありがたみがわかるかなっていうような感じで書きました。
まさにやっぱり設計らへんって、読んでてやっぱりしんどいのって、
そこのこれを適応すれば綺麗になりますっていうのが書いてあって、
でもそれを実感しづらいみたいなのってあるあるな気がするので、
まさにそこを悪いコードを見ながら良いコードにしていくところで、
そこを学べるのはすごい良いなっていうふうに感じました。
今お話の中にも軽く出てきたと思うんですけど、
はい。
設計でこうもう普段活躍していらっしゃる水野工藤さんに、
だからこそあえて聞きたいこととして、
はい。
そもそも設計って何なんっていうところをぜひお伺いしたいなと思って、
先ほどあった通りテクニックとか、こういう例えばデザインパターンとかありますよねっていうのは、
今調べれば結構インターネットとかまさに聞いたとかでも出てきたりすると思うんですよね。
はい。
ただそこって結構断片的だったりするので、
はい。
でも結局設計ってどういうものなんだっけとか、
06:02
何で必要なんだっけみたいなところをぜひ水野工藤さんの口から、
ぜひお伺いしたいなと思っていて。
はいはい。
そうですね。
設計って結構その学術的な定義からその辿っていかないと、
結構意味がバラバラになると思ってて、
そのある人が言う設計ってそのパフォーマンス設計なんですかって言ったりとか、
設計って言ったら要求定義とか要件定義ですよねっていうふうに言う人もいて、
設計っていう意味が人によってバラバラになりがちなんですよ。
結構その設計っていう言葉自体が結構主語としてはとてつもなく広くて曖昧で、
じゃあ設計って何なのっていうようなところの定義なんですけども、
それは僕が書いたその水野工藤本の中にも書いてるんですけども、
そもそもソフトウェアにおける設計っていうのは、
ソフトウェア品質特性って呼ばれてるものがあって、
それの品質特性のいずれかを向上させるための仕組み作りのことを設計っていうふうに言うんですね。
設計っていうのは、例えば、ソフトウェア品質特性っていうのはものすごいいろいろあって、
例えばその機能性だったりとか、機能性っていうのは、
要は顧客のニーズにどれだけリーチするかっていうことを指し示す指標だったりとか、
他にもパフォーマンスだったりとか、安全性、セキュリティだったりとか、
移植性だったりとか、保守性とか変更容易性とか、いろんな指標があるわけなんですね。
設計、そういうものすごくたくさんある品質特性のうち、
要は何かの品質特性を意図的にちゃんと向上させるために仕掛けを作るっていうことが、
設計行為なんですね。ですから、例えば要求定義とか要件定義っていうのは、
機能性を向上させるための設計行為っていうふうにも言えるわけですよね。
他にも、例えばこのサービスは脆弱性に問題があるからっていうような場合には、
要はちゃんと脆弱性を解決するためのセキュリティ設計をするだったりとか、
っていういろんな何かの品質特性を、どれかの品質特性を伸ばすために設計っていうことをしますよと。
じゃあ、僕の身の子どもで扱っている品質特性は何かって言ったらば、
それは変更容易性なんですね。保守性でもあるんですけども、
それは何かと言ったらば、変更容易性っていうのは、
使用変更があったときにどれだけバグをなるべく埋め込まずに、
どれだけ素早く正確に機能変更できるかっていうことを示した度合いのことを変更容易性と言います。
変更が楽になるっていうふうに変更容易性ですよね。
そこを向上させるために書いた設計なので、
だから設計って言ったときにそこの設計っていうのが違うと認識にずれがあるかなっていうところなんで、
09:05
設計って聞いたときに、それがどこの品質特性にリーチするものなのっていうことを、
これから設計って何っていうことを扱うとか興味のある人は、
そこにちょっと気をつけて設計っていうことも聞いてもらえればいいかなと思います。
一言で設計って言っても、求めたい成果だったりとか、求めたい特性みたいなところによって、
考え方とか学ばないといけないところが若干変わるってことですね。
そうですね。若干のところはかなり違うんだと思います。
かなりか。だからそこをわからないままいろいろ勉強しちゃうとちょっとこんがらがっちゃう可能性があるってことですね。
はい。
なるほど。ありがとうございます。
前回のお話の中にもあったと思うんですけど、
特にドメイン駆動設計とか、実際本とか読んでみるとよく話に出てくるのが、
設計ってビジネス理解が不可欠だよねみたいな話ってよく出てくる気がするんですよね。
はい。
特に最近の本とかだったりすると。
そういうのを読んでいると、設計ってただの開発手法ではないのかなっていうのはすごい僕も感じているんですけど、
美野駆動さんとして設計のその、何ですかね、ただの設計手法ではなくて、
どういう関わり方、エンジニアリングとビジネスの関わり方になっているのかみたいなところって、
何か考え方とかってあったりしますか、お意見とか。
そうですね。
特にビジネスの理解が必要だっていうのは、ドメイン駆動設計的な文脈で言ったら、
ドメイン駆動設計って何の品質属性にリーチするのって言ったら、
それは変更容易性と機能性、主に2つの品質属性にリーチする設計手法だというふうに認識しております。
はい。
その2つを高めるためには、どうしても毎日ビジネス理解っていうのは必要であると。
例えば、そもそもビジネスで何やりたいかっていうことを正確にまず理解しないと、
それを実現するシステムが作れない。
どういうことかっていうと、例えばECサイトで言う商品を注文するとか、
商品を購入するっていうのは、Amazonさんでも楽天さんでもよく見る画面操作ですけども、
あれをじゃあそのまま商品購入とか注文っていう形で、
じゃあそのままモデリングしていいんですかっていうところが非常に問題であって、
何を言ってるかっていうと、実はこれは多くのECサイトの利用契約に書いてるんですけども、
実は商品の購入操作をもって、それは売買契約の締結としますよっていうふうに書いてるんですよ。
すると売買契約って何かって言ったら、要は法的な側面を満たさなきゃいけないわけですね。
それが何かって言ったら、売買契約ってのは、いついつまでお金支払えますとか、
支払い方法はこうですよっていうことをちゃんと手にしなきゃいけないっていうふうになってます。
12:00
だから、そういう法的な側面があるんですよっていうことをわからずに、
単に商品を注文するっていうふうな実装してしまうと、
本来必要ないつまで支払うとか、決済手段は何ですよっていうことを
ちゃんと満たせないようなシステムになってしまう可能性もあるわけですね。
ですから、注文するって一体どういうことなのっていうことをちゃんと深掘りするとか、
いうようなことをやらなくちゃいけない。
例えば他の例としては、僕が過去に見てきた例なんですけども、
ものすごくひどい行動であって、そのロジックを見ていくと、
いろんな至るところに何かをリカバリする処理が含まれてるんですね。
例えば撮っておいた画像を復元するだったりとか、
データを復旧するっていうのが、あちこちいろんなところに実装されてるんですよ。
それが一体何のためのものなのかっていうことが、
メソッド名からもクラス名からも何からも類推処理ができない状態なんです。
よくよく調べてみると、それっていうのは停電対策だったんですね。
要は停電したときに自動でシステム再起動したときに、
自動でデータを復旧するための仕組みであって、
本来であればそれは、例えば停電対策っていうモジュールがあって、
そこにちゃんと停電対策用のリカバリ関連のロジックがカプセル化されれば、
分かりやすくなってたと思うんですけど、そうはなってなかったんで、
それが一体何のためにロジックが存在するのかって分からなかったりとかして、
関係してた多くのエンジニアさんが、このロジックって一体何のためにあるんだっていう風に拘束したりとか、
そのために過読性が低下したりとか、過読性が低下するってことは、
要はそんだけ開発精査線が下がるってことなので、
当然その製品のリリースが遅れてしまったっていうような、多分恐らくそういう影響になってたと思いますし、
だからこそ自分たちが一体何のために、どういうビジネス的な要求を達成するためのものなのかっていうことを、
ちゃんと理解してないと満足な設計もできないっていうところですね。
本当にすごい貴重なお話を直で聞けて、僕はとても今ありがたいなと思ってるんですけど、
本当に前回のお話の中にもありましたけど、やっぱりそういうところを聞くと、
やっぱりエンジニアだけでタスクが降ってきて、それを作ってしまうってなると、
やっぱりそういうドメイン、まさにその業務、
自分たち何を作っているかを知らずに何かを作っているみたいな状態になってしまうかなと思うので、
そういう意味で言うと、やっぱりビジネス理解っていうのはしっかりやっていって、開発にそこを落とし込む、
その手段としてそういう設計みたいな手法を使っていくっていうのがアプローチとして、
自分たちのためにもなっていくということですね。
15:00
IT、インターネット業界に強い転職アプリ、グリーンは、今話題のテック企業、プロダクト開発、DX案件など、
グリーンだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、
仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にグリーンをご活用ください。
今、設計に関してどういうものなのかだったりとか、力みたいなところをいろいろお伺いしたいと思うんですけど、
逆に設計を今の話を聞いて取り組んでいこうとなったときに、逆にこういう取り組み方をやめたほうがいいとか、
こういう捉え方をやめたほうがいいみたいなところってあったりしますか。
そうですね。設計って、例えばデザインパターンだったりとかいろんな手法はあるんですけども、
いわゆるそれを銀の弾丸として欲しくはないなという。
よくソフトウェア開発では銀の弾丸なんかないっていうふうに言われてて、
何かある手法が何でも使えるっていうことはなくて、
実際は直面するシステム開発っていうのはいろんな複雑性が伴うものなんで、
何か一つの手法で何か解決するっていうことはないと。
いろんな手法っていうのは課題を解決するための手法として編み出されたものであると。
よくないのは、自分これ使おうって思った手法が今目の前に直面している課題と
ガチしてるかっていうことをちゃんと確認しないまま、
やみくもに覚えたテクニックを使ってしまうっていうのはよくないなというふうに思います。
まずは自分たちの開発に一体どういう問題があるのかっていうことを
ちゃんと丁寧に分析するっていうことと、それから、
もし手法を使うとしても、物にあってはものすごくコストがかかる手法もあります。
例えばドメイン駆動設計だったりとか。
ドメイン駆動設計ってあれは中長期的に効果を発揮する手法なんですけども、
それをやるにはちゃんとそれを適応させるためのアーキテクチャ設計だったりとか、
ドメイン駆動設計自体がやっぱりある種の難しさが伴うので、
それをエンジニアさんの皆さんに周知したりとか、
場合によってはちゃんと情報共有したりとか、こういうやり方なんですっていうふうなことを
周知徹底させるためのコミュニケーションコストっていうのも高くつきますし、
それはものすごく一番コストがかかる例ですけども、
物によってはものすごくコストが高くつくわけですね。
だからやっぱり我々はビジネスのために、お仕事のためにソフトウェア開発をしてるわけであって、
利益を出さなきゃいけないわけですよ。
18:00
だからその利益よりも開発コストが高くついてしまうと、
それはやる意味がないというか、書いて上がらずになってしまうわけであって、
だからその手法がコスト的にちゃんと問題がないかっていうことをちゃんと確認した上で、
技術を選択するっていうことも一応だと思うんで、
やみくもに何でもかんでも自分たちが新しく覚えたものが、
じゃあすぐ使おうとかじゃなくて、ちゃんと使えるものかどうかっていうことを検証することが大事だなと思います。
まさに今聞いていて、僕もすごいその通りだよなっていうふうに思ったんですけど、
やっぱり設計学んだ人あるあるで、
やっぱり学んだテクニックをできるだけ使いたくなっちゃうみたいなのがある気がしてて、
その適用すること自体が目的になっちゃうみたいな。
なので皆さんも今日きっかけに設計学んだら、
それを適用することをまず目的にするんじゃなくて、
まずは自分たちのプロダクトはどういうものなのかっていうところから、
いろいろ知っていけるといいのかなっていうふうに今お話聞いていて感じました。
はい、では続いてちょっと話題変えさせていただいて、
次は設計、ここまでいろいろ設計についてだったりとかっていうところにいろいろお話伺ったと思うんですけど、
それは実際始めていくところのアドバイスみたいなところもお伺いできればなと思います。
設計っていうものが少なくとも今だんだんメジャーにはなってきているのかなと思ってまして、
認知度はだんだん上がってきているし、設計って聞いたらなんとなくあれのことねみたいなものはできてきている気がするんですけど、
いろんな事情で知識を学んではいるけど、
それを仕事の中で取り込めてないとか始められてないみたいな人って結構いると思うんですよね。
なのでそういう設計を次学んだ上でそれを導入していくところで、
まずどういうことから一歩目として始めていけるといいかみたいなところもぜひアドバイスいただけるとありがたいです。
一番はやっぱり設計って手を動かしてみないとその効果の程っていうのはやっぱりわかりにくいと思うんで、
できれば仕事において例えば誰か1人か2人でも仲間を見つけて、
実際にその行動を、プロダクトコードを使って、
例えば変更用意性の品質的に良くないような複雑な行動を、
例えば学んだパターンとかを使って整理してみるとか、
それによってロジックが簡明になって読みやすくなったとかいうような成功体験、
ちっちゃな成功体験をつかんで、
俺たちはやっていけるんだみたいないうような感覚を使うのがまず一番かなって思います。
やっぱり取っ掛かりとしては。
結局そういう成功の体験がないまま、ただ設計やりましょうって言っても、
それって使い物になるんですか?みたいな感じで、
いまいち実感が伴わないまま、疑問風だけがどんどん湧いてきてて、
やっぱり不安に覚える人ってすごく多いと思います。
人間って未知のものに対して恐怖感を覚えるものなんで。
21:01
ですから、まずちゃんとやってみて、やってみてできました、
ちゃんとコード読みやすくなりました、
この構造だと埋め込みにくいよねっていうようなことをちゃんと体験することが大事かなと思います。
まずは小さいところから、一人のところがテクニック的なところで、
いろいろ設計だったりっていうところの力を周りの人に見せていくってことから始めていくということですね。
次のステップとして、まず一人で始めました。
それいいねってのと次に、組織で取り組んでいこうだったり、
ビジネスの人も巻き込んで、さっきあったようなドメイン理解をエンジニアでしていって、
ちゃんとそれをコードに落とし込もうみたいなところもフェーズとして次来ると思うんですけど、
そういう組織として取り組んでいくときの巻き込み方とか、
そういうところの今までの経験からあるアドバイスとかあればぜひお伺いしたいです。
ものすごく難しくて、チームを巻き込んでやるのってやっぱりものすごく難しくて、
先ほど僕は仲間を一人か二人でも見つけて取り組めたらいいねっていうふうには言いましたけども、
じゃあ実際に組織全体を巻き込むとかってなると、
組織ってやっぱりいろんな考えを持ちの方っていらっしゃいますので、
もちろんどんどん新しいことやっていこうっていうふうな考えを持っている人もいれば、
そうじゃなくて、ある種保守的で、なかなか自分を伝えるなんか変えたくありませんっていう人も中にはいるので、
チーム全体を巻き込むことっていうのはものすごく骨の折れる作業だと僕は思っています。
でもやろうと思ったらやっぱりやらなきゃいけなくて、
自分はその辺のところを巻き込むっていうことをしっかりやらないまま、
設計やるやるって言って、結構圧力を生んでしまったっていうような苦い失敗が自分にはありますので、
やっぱりそういう反省点からも、組織で設計を進めていくためには、
ちゃんとチームビルディングがまず必要。一階部分として。
一階部分を抜きにすると、その二階にある設計っていうものはできない。
設計って結構やっぱりソフトウェアの全体にかかってくる部分なので、
その一部分だけできればいいですっていう話でもないんですね。
だから全体にかかってくるからこそ、ちゃんとチームで何とかするっていう、
チームで合意を取るっていうことがすごく必要であると。
僕はそういうチームビルディングを何やらしろにしたまま、
進めて圧力を生んだっていう失敗経験があるので、
だから今の現職のレディー4においても、そこの意思共有。
どういうふうにして進めていきますよだったりとか、
例えばその設計っていうか、進出を高める部分っていうのは全体はやらないで、
例えばちゃんと選択と集中でやっていきますよだったりとか、
とか他にも設計っていうのはこういう課題を可決したくて、
こういう意図でやるんですよっていうようなのを、
エンジニアさん全体にその意思共有の機会を設けたりとかっていうようなことを、
24:01
おおむね2ヶ月ぐらいかけてそういう入社した頃やってきたんです。
だからその不採用を解消してくださいって言われて、
すぐにリファクタリングを始めたっていうんではなくて、
最初にちゃんと皆さんの合意を取ったのにかなり時間、コストをかけました。
そうじゃないとおそらくは、僕が体験したような圧力とかが消失してしまうので、
そこはしっかり、もし組織で設計というのを取り組むのであれば、
本当に根気のいる産業ですけども、
しっかり合意を取れるようにちゃんとチームビルディングしていくべきだなというふうに思います。
今本当にいろいろお話伺っている中で、
やっぱり本当に開発ってただコード書いていればうまくいくわけではなくて、
やっぱりちゃんとリアルの組織だったり事業にちゃんと向き合っていって、
そこをちゃんと知っていって、
いい組織、いい事業を作りながらそれに対応していく、
いいソフトウェアを作っていくっていう流れ全体をやっぱりやっていく必要があるのかなと、
今本当にいろいろお話聞いていて感じたので、
僕もとても発見学びになりました。
ありがとうございます。
では、美濃駆動さん、今回もありがとうございました。
ありがとうございました。
まだまだですね、お話したいので、
次回も美濃駆動さんとお送りできればなと思います。
今回は美濃駆動さんと設計についていろいろお話お伺いしました。
設計の魅力だったり力、そこを取り組んでいくにあたってのノウハウだったりアドバイス、
いろいろお伺いできたので、僕も早速実践していきたいなと思いました。
設計とエンジンやキャラについてお話した前回のエピソードもぜひお聞きください。
よろしくお願いします。
さて、この番組では感想や質問、リクエストなどをお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
Twitterではハッシュタグエンジニアストーリーをつけてツイートしてください。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、
そちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションの下、
エンジニアに関する知識を記録、共有するためのサービスKiita、
エンジニアと企業のマッチングサービスKiitaJobs、
社内向け情報共有サービスKiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
お相手はKiitaプロダクトマネージャーのKiwaのとしふみでした。
