こんにちは。株式会社asken VPoEの安西です。

先日、現場で役立つシステム設計の原則著者の増田亨さんに設計についてご講演いただきました。360名を超える方々にご参加いただき、大変盛り上がり、学びがありました。 asken.connpass.com

書き起こしをして公開するとより多く方に学びをお届けできるのではないかと思い、増田さんにその旨打診したところ、「自分にとっても学びがあるから是非やってください」と嬉しいお返事をいただきました。質疑応答も含めると1時間半くらいあったので大変長文記事になり、要約したほうが良いかなと思ったのですが、増田さんの意図をできるだけお伝えるために、複数ページに分けて公開にチャレンジしてみます。貴重な内容ですので、是非お読みくださいませ。

資料

書き起こしリンク

自己紹介
良い設計を目指す

speakerdeck.com

自己紹介

まずは、自己紹介ということで。

ドメイン駆動設計にこだわっていないと言ったらおかしいのかもしれませんが、エヴァンスの『ドメイン駆動設計』に書かれている考え方と、私がやろうとしていることは同じ方向なのかな、とは思います。

『現場で役立つシステム設計の原則』を出版して、今でもそれなりに地味に売れ続けています。もしまだお買い求めになっていらっしゃらない方がいたらぜひ購入してください。すでに持っている方は、持っていない人が周りにいるようだったらおすすめしてください。

あとは『現場から学ぶモデル駆動の設計』という技術者コミュ二ティで、現場の経験談みたいなことを気軽に話したり、それを聞いたりするような機会を月に1回とか2回のペースでやっています。興味がある方は「現場から学ぶモデル駆動の設計」というコミュニティ名ををconnpassで探していただいて、ご参加いただければと思います。

今回はまず「良い設計とは何か」ということ、そして「良い設計を目指しましょう」ということ、「私自身はこういう考え方でやっていますよ」という話をします。

良い設計といってもいろいろなアプローチや方法がありますが、私自身が採用している方法、私自身が取り組んでいる設計のスタイルについてお話しします。たとえば、クラス設計はこんな考え方でこういうことを重視してやっているとか、テーブル設計は基本的にはこういうスタイルでやっていますよとか、開発設計は基本的にはこういうやり方でやっていますよ、ということを、参考までに一通り説明します。　

設計スキルも、もちろん考え方はいろいろです。設計スキルの学び方も人それぞれだと思いますが、私が考える「設計スキルとはこういうことなのかな」、「設計スキルを磨いていくということはこういうことなんじゃないの？」みたいなことをお話しします。

あとは時間があれば後半のほうで、具体的に私がやっている方法について説明します。時間がなかったら説明は割愛しますが、資料は公開しますので、あとで見て参考にしていただければと思います。

良い設計を目指す

それではまず最初に「良い設計を目指す」についてお話しします。

もの凄く単純な話ですが「良い設計は悪い設計より変更が楽であり安全である」ということです。私が「設計」を一言で言語化するとしたらこういうことなんだと思っています。

これは私のオリジナルな考えではなくて、『達人プログラマー』にも書いてあります。全ての設計原則、設計のやり方というのは、突き詰めたらEasy to change、EtoCなんですよ、という考え方があって、私も基本的には同じ考え方です。

ソフトウェアを変更する理由

ソフトウェアを変更する際には、もちろんいろいろな理由が複合して、いろんな形やいろいろなタイミングで仕様変更の必要性が出てきます。様々な関係者から「ソフトウェアをこういうふうに変更してくれないか」という要望が出てきます。ソフトウェアを開発する際に、私は「変更の理由」の理解を重視しています。

ソフトウェアを開発をしていれば、仕様変更の機会が必ずあります。そういう時に「そもそもなんでこういう変更が起きるのかな？」みたいなことを意識するようになると、変更を楽にするための設計の考え方とか、重点ポイントとかが理解できるようになり、設計スキルの向上につながってくるというふうに考えています。

「こういう変更の際にはこういう考え方にしておけばいいのかな」というように、先読みができるようになってきます。

まず大きな括りでの話として、ビジネスに使うソフトウェアの場合、市場の競合関係。綺麗事で言うと競争優位なんですけれども、その実態は競争劣位に近いんです。「あそこにこのままだと負けてしまう」とか、「今は負けてるけど少しでも追いつきたい、挽回したい」というような、そういう競争劣位をなんとか改善したいという動機によるいろいろな対策の中の一つとして、ソフトウェアの変更という話がよく出てきます。

あとは競争関係が割と安定しているところだと、社会経済や消費行動などの事業環境の変化。たとえば今回のコロナ禍では、競争優位とか競争劣位の話ではなく、本当に社会の経済のあり方とか、消費者の行動がガラッと変わってしまいました。それに合わせた変更要求というのは、皆さんも現場で実際に経験されてるんじゃないでしょうか。

また、企業における事業の遂行能力は固定的なものでもないし、プログラムみたいに手続きを書いておけばその通り動くというように機械的なものでもない。組織の編成が変わったり、人材が変わったりとか、あるいは仕事のやり方が変わったとか、そういうことに合わせるためにソフトウェアを変えたいという要求も当然出てきます。

あとは変更に対して適応的に行動するだけではなくて「今後はもっとこういう方向に進むんだ」とか、「新たにこういう市場をターゲットにしたいんだ」というように事業方針が変わるということも、当然ソフトウェアを変更する理由になってきます。

これらは事業視点の話なんですけれども、それ以外にも、開発者の事業活動に対する理解が変わるということもあります。

私も何度も経験しているんですけれども、ほとんど経験がない業種とか、ビジネスモデルとか、業務内容とか、そういうところで最初に話を聞いただけでソフトウェアを作った時と、ある程度長くお付き合いさせていただいていくうちに、「この会社ってこういう事業もやっているんだ」とか「ここはこの会社にとってポイントなんだな」というように、事業活動への理解度がだんだん変わってくるんですよね。すると自分の作ってきたソフトウェアについて、「これはちょっと理解が違っていた」「正直言ってまずいな」というような発見があったりします。それは当然設計変更の一つの動機に十分なり得ます。

あとはこれも私自身の経験なんですけれども、やっているうちに開発者としての設計能力が変わってくるということもあります。「こういうやり方をすればこういうことができるんだな」というような発見もあったり、「以前はこれが一番いいやり方だと思っていたんだけど、今となってはこれは違うよね」というように、設計能力が変わるということも、ソフトウェアを変更する大きな理由の一つになります。

さらに、利用できる技術の費用対効果が変わってきていることも、大きな理由の一つです。

昔だったらメモリは非常に高価だったりとか、使えるものに制限があるとか、ネットワークの帯域に関しては意識しないと性能が出ないとかいうことがありました。しかし最近だとクラウド上で実行するならメモリが贅沢に使えます。安い価格で。

通信に関しては10年前ぐらいと比べても、本当に通信し放題みたいな、非常にレイテンシーの小さい通信ができるようになってきています。そういうものを活用するためには、ソフトウェアを何らかの形で変えることによって、もっともっと有効に活用できるようになります。そういう技術要因、あるいは技術の選択肢の変化ということによっても当然ソフトウェアを変更します。

こういう様々な要因がいろいろ複合し、角度とか濃淡が変わりながら、いろいろな変更をしていくということがソフトウェア開発の基本活動ですよね。

ソフトウェアの変更が楽で安全であれば

ソフトウェアの変更が楽で安全であれば、当然事業活動の変化のスピードを上げられるし、事業活動が変化していく時のコストも下げられます。それから開発者の事業活動への学びが深まるごとに、それをどんどん変更しながらソフトウェアに反映していけるし、そうやってよりよいソフトウェアを作っていけます。

また、開発者がいろいろなことにチャレンジしながらソフトウェアを変更し、その結果を見るということを繰り返すことによって、開発者の成長の機会にもなります。

費用対効果の高い技術に移行しようという時にも、楽で安全にできる範囲が広いことで、スムーズな移行が可能になります。

ソフトウェアの変更がやっかいで危険になると

逆から見てみると、ソフトウェアの変更がやっかいで危険になると何が起こるかというと、まず事業活動の変化のスピードが落ちてしまいます。事業そのものを変えたいと思っていても、システムが足かせになっているというようなことが、特に歴史のある企業では明らかにそういう現象が起きています。

企業自体が変わっていかなきゃいけないんだけど、システムを変えられないが故にスピードが落ちてしまう。あるいは事業活動が変化していこうという時に「ソフトウェアを変えればいいんじゃないの？」みたいな話が出ても、実は相当大変な作業になってしまって、そのためのシステム開発が1年半かかって数億円とかいうようなコストになってきてしまう。変更が楽で安全な設計になっていたら、もしかしたら数百万円、1ヶ月ぐらいでできるようになっていたかもしれない。そういう桁違いの変更コストが企業の変化を縛ってしまうみたいなことが実際に起こり得ます。

これは私がここ数年リアルに見ている世界で、そういう企業からいろいろ相談を受けてお手伝いをしている、というのが私の最近の仕事です。

ソフトウェアの変更をやりたくてもできないと、開発者の成長の機会が減ってしまいます。開発者が学んだり成長して、もっともっといい設計ができるようになったり、もっと事業に合った、事業に価値を見出せるソフトウェアを作る力を付けてきても、それを実際のソフトウェア開発になかなか活かせない。

技術者から見れば「こういうところをもっと変えられたらもっとスムーズに動くのにな」というようなことがわかっていても、なかなか実行できないということもあります。

あとは費用対効果の悪い、非常にコストパフォーマンスの悪い技術を、ソフトウェアを変えられないが故に使い続けているということも実際に目にしています。

要するに「良い設計を目指すということはどういうことか？」という問いへの答えは、「変更が楽であり安全な設計を目指す」ということ。それが開発者がやるべき仕事です。

もちろんソフトウェアを作る上で、いろいろな「いい仕事」ということに対する評価基準というのはあると思います。ただ私の価値観としては、変更が楽で安全になれば、どんな課題も全てやりやすく、スピードが上がりコストが下がるんで、突き詰めればソフトウェアの価値を高めるには、変更が楽で安全になるように設計しておくということが中核の価値だと思います。

変更容易性のレベルを一定以上に保つことができていれば、ほかの課題、ほかの指標でもっとソフトウェアを改善したいという話が出てきた時に、性能面でも、使い勝手の面でも、全てのものに対して対応するスピード感、コスト感が変わってきます。そのためにも、開発者たるもの、やるべき仕事は「変更が楽で安全であるソフトウェアを作る」こと。それが良い設計というものです。