アクティアCOO・高崎健太郎氏が設計でこだわる3つの“エモい”ポイント

設計にこだわるとは？

高崎健太郎氏：はい、では始めます。今日は「設計に『こだわる』とは」というタイトルで、実際に自分自身だったり、一緒にやっている人たちの設計にこだわっているところを紹介することで、集まった方々のお役に立てばと思っています。

そういったこだわりのポイントをまとめていったら少しフワッとした内容になったので、たぶんものすごく「エモい話」になりそうだなと思っているのですが、このメンツを考えたときに僕がエモい担当だろうなと思ったので、「エモい話」に振り切りました。さらに掘りたいところや不明点とかがあったら、質問コーナーで質問してもらえればと思います。

このタイトルを話そうと思った経緯なんですけど、今回の登壇の話をもらった際に「自分は何にこだわって設計をしているんだろう？」という問いが最初のスタートポイントでした。そのときにいろいろと考えて、設計で重要そうな話みたいなものを考えていくとDRYがあったりとか、SOLIDがあったりとか、はたまたアーキテクチャパターンなのかデザインパターンなのか。

もうちょっとコード寄りの話に落ちていってコーディング規約だったり、リーダブルコード、読みやすいコードを書いていくというのもコーディングですけど、ある程度設計にもつながってくるのかなみたいなことを考えてました。こういった原理・原則というのは非常に大事なんですけども、「はて、僕がここにすごくこだわっているか」というのを考えたときに、ここも大事だけど、僕のこだわりポイントはここじゃないなと。

原理・原則みたいなところは手段として使っているような感じで、「自分のこだわりポイントである目的って何だろう？」みたいなところを掘っていったら、今日の発表にちょうどつながりました。

なぜ、設計にこだわるのか？　問いの背景の共有

今日のアジェンダとして、まず問いと背景の共有を行います。次に実際に僕が考えた3つのこだわりとは何かを説明します。僕がシステムを設計する上でこだわっている「背景や全体像を捉える」、「ステークホルダとの認識の共有」、「システムの将来を考えること」を紹介していきたいと思っています。

こういったことを話していこうとしているので、設計の細かい方法論とか具体的な実装がどうこうなるという話ではなく、先ほども言いましたが若干「エモい」寄りの話になっています。

まず問いなんですけど、これは僕が発表するだけではつまらないし、僕も知りたいなと思ったので「あなたの設計に『こだわる』ポイント」というのをみなさん投稿してください。せっかく300人とか400人とか集まりそうなので「#設計こだわる」「#BPStudy」のハッシュタグもつけてください。そうすると、後ほど僕が見るのが楽になります。

この「#設計こだわる」で、ぜひ「こんなこだわりポイントがあるよ」ということ、この発表の中で感じたこと、自分は設計をするときにこういうところに気を付けていますということを共有してもらえるとうれしいです。こういう双方向でやっていけたらいいかなと思っています。

まずは背景の共有です。BPStudyの背景をちょっと捉えていただきたいんですけど、僕は巨人のユニフォームを着てやっています。これをBPStudyのドメインエキスパートは知っているんですが、正装と呼びます。

BPStudyは年に2回、Baseball Play Studyに切り替わるときがありまして野球の会があるんですが、そこから始まったのがこの正装というもので、推しのチームのユニフォームを着て登壇することを正装と呼んでいます。これはドメインの知識なのでみなさんちゃんと覚えておいてください。

改めて自己紹介をします。株式会社アクティアでCOOをやっている高崎と言います。見ての通り巨人ファンです。なので今日は東京ドームからお伝えしています。他にもDDD Allianceだったりとか匠塾といったような、こういったコミュニティにいくつか関わっています。RDRAのやつもやっています。

実際に自分の設計やモデリングとの関わりとかを捉えていくと、ビジネス価値を捉えて、要求、分析、設計、実装、テストをしていく中で自分としてはこういった匠MethodだったりRDRAだったりとか、あとはモデル駆動型開発やドメイン駆動設計みたいなものにアクティアという会社で取り組んでいます。

そのときにさっき出てきた3つのこだわりですね。「背景や全体像を捉える」「ステークホルダとの認識共有」「システムの将来を考える」という上流寄りのことを考えながら、そこから設計や実装につないで行っているなというのが自分の思いでした。

そんな株式会社アクティアなんですが、どんな会社かというと（スライドを見せながら）こんな感じです。やっていることはモデル駆動開発をやっています。その中で設計にこだわったソフトウェア開発をやっている会社だよというのをエレベータートークではよく自分で言っています。そもそも設計にこだわると言っているけど、何にこだわっているのかみたいなことを少し紹介していきます。

モデルを作ることで設計内容を分かりやすくする

モデリングをして、そこからモデル駆動開発ということで、モデルを作ることで、先ほどの神崎さんの発表とかじゃないですけど、設計内容やシステムの内容がわかりやすくなります。お客さんのビジネスドメインからモデルを作って、そしてソフトウェアへとつないでいきます。ビジネスからソフトウェアにつながっていくような開発をしていっている会社です。

それでモデル駆動型開発でこの3層構造＋ドメイン層の中でも、とくにドメイン層のところですね。ここに注力して、ここを書くためのDSLとかを用意してモデルを記述して、ドメインにフォーカスして設計して実装していくというような、そんな感じの開発をやっていたりします。

実際はこんな感じですね。設計にこだわって、モデリングとして人が注力すべきところを設計して、そこからある程度自動生成をしていくと。というようなことをしながら開発をしています。

メンバーに設計のこだわりポイントのアンケートを実施

自分はそんなことをやっていると思っているけど、他の人はどうなのか知りたくて、実際に関わっているメンバーはどういったポイントにこだわっているのかについてアンケートを取ってみました。

「設計こだわりアンケート」をこんな感じで、こだわりポイントをいくつかバーッととりあえず20個ほど挙げて、実際にこだわっている要素とはなんなのかとか、設計にこだわるということを一言で表現するとどうなりますかとを聞いてみました。

アンケートに挙げたものは原理・原則とか、そのままSOLIDっぽく書いてしまうと、それを好きな人だとそれを選んでしまうと思うので、なんとなくちょっとぼやかしました。結局10名から回答がありました。その結果を見ていくと、まず第1位が「ビジネス的な背景を捉える」というところで6票集めました。

第2位が「ステークホルダと理解の共有」で、5票集まりました。3つ目が「言葉」というところが、これが4票集まりました。これ以降はこんな感じでザーッと集まっていて、だいたい1位、2位、3位とかの傾向を見ていくと概ねメンバーと音楽性の違いはありませんでした（笑）。以前から一緒に開発しやすいメンバーだなと思っていたのですが、やっぱり音楽性（感覚）の違いはありませんでした。

そもそも設計とは何か

3つのこだわりを見ていきたいと思うんですが、その前にそもそも設計はどういう工程か説明します。改めて僕もいろいろな文章を見ていきながら調べてきたんですが、V字モデルがあって、基本設計と詳細設計とがあり、この2つが設計にあたります。

基本的に基本設計でアーキテクチャなどの方式を固めて、詳細設計でソフトウェアへと落とし込んでいくというようなものが設計工程と呼ばれるところです。設計の知識領域を調べていくとSWEBOKにあるんですけど、こういったところ（スライドに記載のもの）が知識領域になってきます。この辺が設計が抑えていく領域になります。

こだわり１：背景や全体像を捉える

僕が重要だと思っている3つのうちの1つ目は「背景や全体像を捉えるということ」です。物事を説明するときに詳細からいきなり説明すると「お前何言ってるんだよ」「細かすぎてわかんねえよ」ということが起こるので、だいたい全体はこういうものだよ、そして詳細に落とし込んでいくという進め方を皆さんはやっているんじゃないかと思います。

このプレゼンが背景から話に入ったのも、こういった背景だったり全体像をみなさんに捉えてもらって共有してから詳細の話に落とし込んでいきたいので、こういった構成にしています。設計のベースを考えていくと詳細設計のベースは基本設計で基本設計のベースは要件定義、ここで仕様を詰めていくわけです。

ただ、さらに上流に企画とか計画とか、システムを使うもともとの要望としてのビジネスがあります。こういったものを捉えていくことによって、システムが何のために必要なのかということがわかってくるので、作ったものにビジネス的価値があるかということを抑えていくことができます。

なのでビジネス価値を捉えるときの手法として匠Methodだったり、ビジネスの外観を捉えるときの手法として先ほどの神崎さんのRDRAですね。こういったものを使っていく。そうすることで背景を捉えることになるので、機能を表面的ではなく、真に必要なものを捉えて設計できてコードへとつながっていくと思っています。

こだわり２：ステークホルダとの認識共有

次に「ステークホルダとの認識共有」です。ビジネスとシステムの関係者ですね。ビジネスから仕様を捉えて設計してつないでいく中で、さまざまな多くの関係者であるステークホルダが関わってきます。ステークホルダがみな同じ考え方になるかというところなんですが、先ほどの神崎さんの発表にもあった通り「ユーザさんはそもそも四角を書いてもわからないよ」とか、そういったことになってしまいます。

そういったことが起こる原因は、言葉や名前の解離です。ドメインエキスパートは技術的ではないところの自分の得意分野の専門用語を使い、開発者はどちらかというと自分の得意分野である技術的な用語よりのことを話してしまいます。

このように言葉だったりとか呼び方（名前）には、断絶があります。断絶があると「通じていたようで通じてなかったり」とか、「用語が一致していない」とか、「通訳するのに余分な労力がかかったり」といったことが起こってしまうので、ドメイン駆動設計で言うところのユビキタス言語で共有していく必要があります。

そういうことをしていくことによって、「ドメイン固有の型としてコードに落とし込んでいったり」とか、「言葉がちゃんと定義されたということは単一責任になったりしやすいのでソースコードが簡素化されたり」とか、そんな感じでみんなが言葉、名前付けにこだわるようになっていっています。

適切な名前や言葉がちゃんと捉えられたということは機能を正しく理解して設計できている状態です。一方でまだ名前がぼんやりしていたりとか、「こいつのことをなんて呼んだらいいかわかんないや」というときには、機能を十分に理解できておらず設計できていないのかなということで、やっぱり関わっているステークホルダの間で何という名前にするのか、そういったところにこだわりながら設計を行っています。

こだわり３：システムの将来を考える

そして3つ目ですね。「システムの将来を考える」ことです。システムは完成して、終わりではないですよね。完成したあとずっと使われていきます。その中で時の流れとともに、使う中でのフィードバックが発生したりだとか、ビジネスや技術の変化が起こったりだとか、そもそもステークホルダが変化したりします。

例えば、僕がちょっと前に関わっていた案件だと、メインで関わる人たちがシステムのことをわかっている人だったので、利便性のためにバリデーション（入力チェック）をあまり盛り込まないシステムを作っていました。そうしたら、その人たちが辞めてしまって、（システムを使用する際に）「バリデーションが入ってないと初心者のミスが多いんです」というようなことが起こってしまいました。ステークホルダの変化として、そういうことが起こることがあります。

そうしたときに変更に対応しやすい設計になっていれば、今話したようなことが起こったような場合でも、なるべく早めにバリデーションを入れていったりすることができます。

よく変化を考慮して設計するものの一例として、設定値的なデータはどういったかたちで設計していくかというところが、みなさんもいろいろと考えているのではないかなと思います。1つはコードに直書きしてしまうというような方法だったり、あとはパラメータとして持つ、あるいはマスタデータとしてけっこう動的にもたせるようなやり方があります。

消費税とかですよね。今は消費税が変わっていくのが当たり前になっていると思うので、マスタデータとして管理することがもちろん多いですが、昔はコードに直書きで消費税が5パーセントになったら対応できないということが起こっていました。やっぱり将来を見据えていなかったと思います。

変化するかしないかでどれを使っていくかを決めるんですが、コードよりもマスタデータのほうが変化しやすいです。ただ、ただ単純に入れてしまうと複雑度が増してしまうので、マスタデータ（としての設計）がいるかいらないかちゃんと考える必要があります。基本的に迷ったらいらないんじゃないかと思っています。

ただ、迷ったら設計として入れないということが基本ですが、ちょっと先は見据えないといけないとも思っています。少し先の変化を予測して対応していくということが大事だと思っています。

すべてのこだわりは繋がりを築いていくために

まとめです。設計にこだわるというところで、この3つのこだわりを考えていったときに自分が一言で表すと何だろうと思ったら「繋がりを築いていく」ことが良い設計につながるのではないでしょうか。ビジネス価値から始まって実際に実装へとつないでいくというところだったり、フワッとしたものをシステムへと落とし込んでいく。その際に人と人とのつながりだったりだとか、将来へのつながりというものを意識して設計の中に織り込んでいくというのは、自分の設計へのこだわりなんじゃないのかなと思います。

「設計にこだわる」を一言でアンケートをしたときに、メンバーからこんな感じ（スライドに表示された）の一言が返ってきました。