9月27日に開催したCTO meetupではREADYFOR株式会社のミノ駆動さん、スターフェスティバル株式会社のytakeさんをお招きしてソフトウェア設計やアーキテクトのキャリアについて語って頂きました。

アーキテクトってどういう仕事？

本イベントでフォーカスするソフトウェア品質特性のすり合わせ

ミノ駆動氏：
一旦目線合わせのためにアーキテクチャって一体なんなの？という説明を簡単にしたいと思います。アーキテクチャはソフトウェア品質特性のいずれかの特性を促進するための仕組み作りを指します。色々と特性がある中でこの辺りの目線が揃っていないと設計という言葉を聞いたときに「パフォーマンス設計の話なのか」「要求や要件定義といった上流工程の話なのか」、人によって設計に対する捉え方が異なってきます。
今回テーマとして挙げるアーキテクチャの品質特性は「機能適合性」「保守性」にフォーカスを当てます。
「機能適合性」というのはシステムが顧客ニーズに対してどれだけ満たせているかの指標で、高ければ高い方が顧客ニーズを満たしており、収益をもたらしていることがわかります。
一方保守性は保守にかかるコスト、仕様変更にかかるコストをどれだけ低減できるか測る指標で今回はこの2つについて話をしていきます。

今回取り上げる設計/アーキテクチャの対象範囲

ミノ駆動氏：
アーキテクチャと言っても幅が広いので、今回対象とするのは、ソフトウェアアーキテクチャと呼ばれる範囲でアプリケーション層・ミドルウェア・データベースまでを指します。いわゆるシステムアーキテクチャと呼ばれるハードウェアやネットワークといった物理的な構成のところまでは対象としません。

アーキテクトの主な役割

ミノ駆動氏：
これは僕が考えるアーキテクトとしての仕事なのですが、1つ目にシステムの品質特性を向上させる設計をしたり、チーム全体としてどうしたら良いかのアドバイスがあります。
2つ目ですが品質特性はトレードオフの関係になりやすい、例えば保守性とパフォーマンス性の関係が挙げられるのですが、パフォーマンスを上げようとして人が読めないコードをやむを得ず書くシーンが出てきます。人が読めないということは保守性が下がっていることを指しますが、このような各状況に応じて何を優先するのかトレードオフを解決する役割を担っています。
3つ目は先程のトレードオフの話とつながるのですが、各状況でどのような品質特性に注力するのかという政治的な調整とその実行に向けたチームビルディングだと思っています。

ytake氏：
僕もその通りだなと思います。トレードオフのところとかまさにそうで、例えばいかに綺麗に作るかという点をいろんな人が考えると思うのですが、会社の予算やコストとかスケジュールなど考えることはさまざまです。
僕自身が一番気をつけていることとしては、課題を定義してこういう手法でやるぞとなったときに自分しか知らない手法を選択するとチームにとっては何の意味もなくなってしまいます。仮にその手法を選択するのであればしっかりチームに浸透させて、自分自身が抜けた後もみんなが動ける状態を作れるよう意識していますし、これもアーキテクトの仕事の振る舞いなのかなと思っています。

事業フェーズ別で見る必要な設計パターンの具体例と推進するアーキテクトの立ち振る舞い方

PMF前のサービスにおいて設計で意識すべき点とは？

ytake氏：
PMF前ということで連想されるのはスタートアップの人や大きい会社でも初めてこういうサービスを出すんだよね、という人が該当するのかなと思います。コンテキストによって色々変わったりはすると思いますが、このような状況でアーキテクトとして何をやるのかということをお話していきたいと思います。

point.1：早すぎる最適化や高度な抽象化は行わない

ytake氏：
あとの話にも繋がるのですが、PMF前はプロダクトがマーケットにフィットするか分からない時で、いかに利用者の問題解決、しっかりとテーマに沿ってできているのかを見定めないといけないフェーズです。色んな物事に左右され不確実性が高いので、PMF前は特に”我々が作っているものは間違っている”という前提でサービスを出していく必要があると思っています。本で読んだからという理由等であまりにも最適化を進めると目的を見失ったり、物事が変わった時にかかる労力が大きくなってしまう。PMF前にして、これからその上にサービスが乗ってくるんだぞということを考えると、やっぱりやりすぎても良くない、という話になってきます。

point.2：ビジネスを一緒に作る

ytake氏：
これはもう当たり前のことなんですけど、ビジネスを一緒に作ることですね。言われて作ったらいいということではないんですけどね。

ミノ駆動氏：
よくあるケースが仕様書だけぶん投げて後よろしくね、みたいな。結局ビジネスとしてどのような目的を達成したいのか、エンジニアが理解できないまま単に仕様だけのものを作ってしまう。結果としてよく分からないものを作ってしまうので良くないと思いますね。

ytake氏：
ちょうどトレンドのような話で、twadaさんが先日仰られていた内容ですが、我々は今正解というか何を作っているのか分からない、先が見えにくい時代にいてその上でどうするかを考える必要があります。この状況で「いや私はビジネスのことが分からないので作るだけです」みたいになってしまうと先が分からないことを一緒に分かろうとしない、昔からある顧客が本当に必要としていないものを作ってしまったという状況がより激しく現れるのではないかなと感じます。なのでPMF前とか大きい会社でこれから新しいサービスを作っていくぞという状態にある人たちは是非サービス作りとか、何をするんだっけ？というのを一緒に考えてもらうといいのではないかなと、非常に大事なポイントだと思います。

point.3：構造を作ることで負債を恐れない

ytake氏：
これはやりすぎるとpoint.1に寄ってしまうのですが、例えばソフトウェアのコードレベルだととりあえずインターフェース挟んでおきましたぐらいな、そんなのでもいいのかなと。ある程度こういうルールで置きましたというくらいでいいと思うんですよね。最初なのでそれしかできないと思っていて。仮に世の中で言われる間違った手法であったとしても、point.2にもあった一緒にビジネスを作っていく段階に入っていけば、ここは今後変更するかもしれないとアジャイル的なサイクルと共にソフトウェアが変化する未来も見えてくると思うので、それに併せて構造化をしていけば良いのではないかと思いますね。

ミノ駆動氏：
全く構造化しなくていい、というのも僕は怖いなと思っていて、かつてローンチ後1年くらいのサービス開発に携わった時全く構造化されていない状況に遭遇しました。いざ開発を進めると1個目と2個目のバージョンでもう開発が苦しく、変更もキツくなってバグだらけになったんです。その辺りはある程度設計的な部分を抑えてコントロールしていく必要はありますね。

ytake氏：
このようなポイントも踏まえて、よくあるケースや私自身どうですか？とお話しされることなのですが、後々の採用広報、採用容易性を見越してフィットするか分からない流行りのRustを言語として採用したり、エッジケース的なもの、あとは最初からマイクロサービスアーキテクチャを採用します、という声を結構寄せられたりします。
あとは技術的負債、先ほども言ったようにビジネスが先に行っていて技術の追従は遅れるため負債になるのは当然という前提のもと活動していて、それを埋めようと構造化して綺麗にモノを作りやすくしています。それにも関わらず新しい技術を使っていないから負債である、という誤った捉え方のもと最新で流行りのものを採用すると、後々どうするんだっけということになってしまいます。しっかりと見定める必要があり、作る人のスキルセットにもよってくるため無理しすぎないことがポイントです。分割しすぎないようにして、まずは自分達が何を作っているのかをまず大事にして価値を届けることにフォーカスするべきですね。あとは難しすぎるものでエッジケース的なものを採用しすぎるといわゆる技術的な認知度負荷が非常に高まるので、チームでできる技術スタックでどうするのかを判断できるようになると良いかなと思います。

ミノ駆動氏：
ここら辺は難しいですよね。認知度負荷が高まりすぎてしまう点もあります。僕の場合今回はこういう風に設計をしていきますとかチームに対して技術の目線合わせをすることもあるので、状況によってではありますが現実なところで進めやすく、かつどうしても技術的に使っていかないと辛くなる点についてはそこは採用していくというような水平転換をしていく必要がありますね。

ytake氏：
先にこれは絶対必要な技術になるぞ、という場合にはトレーニングも含めて対応すべきというやつですね。この技術がいいからと聞いて入れて、採用後は知らん顔というのはやっぱり良くないですからね。
後先のことを考えないと、利用者にとって価値を届けられるサービスなのかを検証しながらまず道を作った後、作った人がいなくなってから苦労するということが大体発生します。それまでの物事のコンテキストを理解しているわけでもないし、作った人と全く同じ技術スタックでもないので、後に来る人の苦労をそういうのもなるべく減らしたいのですが0にするというのは難しいんですよね。

ミノ駆動氏：
今仰られた価値を届けることを最優先にする、というのは僕が冒頭説明した品質特性のトレードオフが生じる話に通ずると思います。スタートアップがサービスをローンチしたときは保守性と機能適合性がトレードオフ関係になっていて、スタートアップ時は機能適合性にウェイトを置いて重点的に開発を進めるのかなと。ただ全く保守性を考えていないのも良くないのでややコストをかけながら開発を進める、というような感じですよね。

サービス展開5年〜（PMF後〜大企業まで）において設計で意識すべき点とは？

ミノ駆動氏が考える意識すべき点

ミノ駆動氏：
これはサービスが軌道に乗ってから5年後とか、乗り始めたからの話ですよね。意識すべき点としてはコントロールすべき品質特性が変わってくる時期なので、例えば3つポイントを挙げたのですが。1つはコスト戦略、2つ目は技術的負債をどうするか、3つ目はアーキテクチャ全体をどう転換していくのか、という点になります。

point.1：サービス開発のコスト戦略
ミノ駆動氏：
例えば機能適合性、スタートアップ時は狙いどころがわかって、そこを目がけて一気に開発工数をかけていくと思うのですが、さすがに5年くらい経つと増えるエンジニアの数に比例せずサービス規模の方が大きくなっていきます。そうなると機能適合性といっても中心的にどこを開発していくのか分からなくなって、サービスを作っている人たちも「一体何を作っているのか」「我々の売りは何か」が段々分からなくなってくる。そこでドメイン駆動設計のコアドメインという考えを用いて、自分達の中心的な事業領域・コアドメインを特定して、中心的に開発コストをかけていきましょうというコスト戦略が必要になると思うんです。これがないと思いつきで施策を打ってヒットしませんみたいな話になりがちなので、しっかりとビジネスの人と一緒に何が中心なのかを考えて、エンジニア側でもコアドメインに特定する部分がシステムレベルでどこなのか特定する必要があります。分散していればちゃんとコアドメインにどのようにサブモジュール化するのか、何かをしてそこに集めていくとかいう工夫が必要になってくるという話です。

point.2：技術的負債
ミノ駆動氏：
最初サービスがローンチしたときは小さいので可読性も悪くなくて、ソフトウェア工学的に低凝集な構造であったとしてもソースコード自体が大きくないので、関連し合うデータやロジックを探しにいくのは苦でもないと思うんです。ところが大きくなってくると、あちこちに分散し始めて触っているデータがどこなのか段々と分からなくなってきます。いよいよ技術的負債が開発の足を引っ張る状態に陥ってくるので、保守性にコストかけてリファクタリングをするといった対応が必要になってくると思います。

point.3：アーキテクチャ転換の選択肢
ミノ駆動氏：
僕も今まさにRailsアプリに対してDDDで取り組んでいます。ちょっとRailsの話になってしまうのですが、モデルと概念が1対1になっていれば良いのですが、あるモデルが複数の概念や意味を持ち始めて、本来であれば別のモデルに分けるべきところが1つのモデルに重合してしまっているものがたくさん出てくるんです。Railsウェイの御作法に則ってやる方法もあるのですが、データベースのリファクタリングのことも考えないといけなかったりするので、僕としてはビジネスロジックをデータベースに近しいところへ寄せたくないんですよね。なのでドメイン駆動設計のような感じでドメイン層を設けてそこにビジネスロジックを凝集、モデルはリポジトリみたいなデータベースを触るだけの責務にするみたいな。一例ですがこのようなことが必要になってくるのかなと感じます。

ytake氏：
いやーありますね。転換期はどうしても来るじゃないですか。それまではこれでよかったのに、これからはそうじゃないよというのが5年とかもっと早い時期に来てしまいます。Railsもそうですし、PHPだとCakePHPやLaravelとか色々あるのですがデータベースファーストな設計になってしまうんですよね。結果的にモデルと指すものが複数の見方を持っていて、こっちから見るとA、こっちから見るとB、でも俯瞰してみると何ですかこれみたいな（笑）。非常にわかるなという感じです。

point.1：サービス開発のコスト戦略の補足
ミノ駆動氏：
先ほど説明を忘れてしまった点として設計コストをかけすぎても機能開発を鈍化させてしまう側面があります。もちろんtwadaさんが仰られている、品質が高く保たれていれば品質と開発速度は両立するものであることも理解できます。
ただ、この軌道に乗せるまでに設計コストが必要で、品質と生産性の両立が図れるまで移行工数がかかるため機能開発が落ちないレベルで上手くコントロールする必要はあるなと。その辺りのバランスが難しいところでアーキテクチャレベルでどのように解決していくのか、どのようなスパンで移行していくのかを考えています。

ytake氏：
今回の趣旨と違うのですが、ここら辺は結構SREの役目と絡んでくる話ですね。SREって多くの人がインフラでいい感じにする人というイメージがあると思うのですが、SREってモノができてから保守運用でついてくれて、そこに対して何をもって品質が高いというのかジャッジするためにモニタリングやリファクタリングする判断がつくような数値の可視化などさまざまな活動をしてくれます。結構いる場所が違うけど向いている方向はみんな同じみたいな状態が築けていたりするので、この辺りは是非Googleから出ている『The Art of SLOs』で詳しく見てみてください。

point.2：技術的負債の補足
ミノ駆動氏：
5年目からという話でもないのですが、私の場合開発時にCode Climateという負債のメトリクス計測ツールを使っていて、できれば初めから可視化をしておいてもいいのかなと思います。技術的負債は本来あるべき理想とのギャップから生まれ、理想的な構造が分かっていないと全ての技術的負債が明らかにならないので、問題箇所の分析を目的とした理想構造の設計は5年をめどに実施してギャップ変化を見ていく必要がありますね。

point.3：アーキテクチャ転換の選択肢の補足
ミノ駆動氏：
僕が今まで遭遇した事柄なのですが、ある魅力的な機能があると、Aという用途以外でBやCの用途でも使いたいという要望が出てきます。用途に合わせて仕様を少し変更したいという要望が大量に発生し、その要望を飲んでしまうとあっという間にロジックが複雑になってしまうのです。
単に動けばいいシステムではなく機能拡張に耐えうる設計にしなければならず、どこが拡張ポイントになるのかという分析と拡張するためにどこを抽象化するのか、抽象化するためにインターフェースを切るのであればどういう仕組みにするのか。これらを決める設計が必要なのでどうしてもソフトウェア工学に基づいた設計スキルが必要になってきます。

ytake氏：
エンジニアの人から見ると、「まとまってるから、ここが同じだから切り出そうぜ」ということを抽象化と捉える人がすごく多いと思うんです。インタフェースも同じです。ある意味正しくもあるのですが、正しいインターフェースと抽象化は必ずしも結び付かなくて。抽象化というのはソフトウェア工学的にいうと流れてくるもの、世の中のものをデータとして捉えて表現する考えが根底にあるので、ちゃんと物事が何をしたいのかを聞いて、ここの見方は同じだから抽象として捉える必要はありますね。

ミノ駆動氏：
抽象化するにしてもインターフェースで切った結果、それが同じ意図のもとで抽象化できるものですよねと考えなければいけなくて、同じ意図であることを確認するためにはやっぱりビジネスサイドの人と話さないと分からないんです。
Twitterへ「商品の料金計算と注文数の計算は同じ足し算だからロジックを共通化しました」というネタを書いたんです。こんなことをしたら注文数の計算が変わった時に料金計算にも影響が出てバグりましたというおかしな事象が発生してしまいます。このネタは明らかに概念の違いが分かりやすい例ですが、ソフトウェア開発で難しいのは似て非なるものが大量にあって、そこの見分けを解像度高く分析しなければいけない点です。その目を持つには鍵は再三言っているようにビジネスサイドの人と話をすることかなと思います。

ytake氏：
僕もこの辺りの話はビールを例に用います。ビールを飲みたいと言っても種類がさまざまある中、ytakeさんが言っているビールはエビスらしいというある種の先入観で捉えてしまいがちです。でも飲みたいビールがIPA、クラフトビールとなるとコンテキストが合わなくなります。システムにおいても実現したいことがあってなくて、一方要求を聞いた人の誤った情報がどんどん広まってしまい結果システムとして不適切なものが出来上がってしまうケースがあります。
なので分からない単語であったり認識が違いそうだなと思ったらしっかりと聞きなさいとメンバーにはよく言っています。

ミノ駆動氏：
やっぱり些細な物事の違いをちゃんと見分けられれば、ソフトウェア開発において拡張性の高い設計ができる契機になると思います。皆さんそれぞれ趣味を持っていると思っていて、趣味だとAとBの違いを解像度高くを見分けられると思うんです。細かい違いを見分けられる能力を持っているのであれば、僕は拡張性の高い設計もできる素養を持っているとも思うんです。こういったものをソフトウェア開発に応用していけたらなと思います。

ytake氏が考える意識すべき点

point.1：先入観を捨てパラダイムシフトを恐れない
ytake氏：
先程までの話にあったように、ある時まで対応できていた方法から今後はこの方法でないといけないという危機感が迫ってきます。データベースなんかはいい例で、何億というレコードがきた時、今まで通りの設計だと取れないぞとかパーティショニングをしないといけないぞといったことが現実味を帯びてやってきます。それまでやってこなかったことをやる必要があるので従来の方法だけで対処しようとするとみんなが言う技術的負債にもつながりますし、ビジネスから見た負債にもつながりかねません。今までこうだったからというものは捨て去って、ちょっとテスト的に別の方法を検証してみようとすることが大切かなと思います。
また技術的な限界がビジネスの限界だったりもするわけで、次のフェーズに進みたいけどこういうことはできますかと問われて、今までやったことがないからできませんというコミュニケーションをとってしまうと物事が進まなくなります。先入観や原点主義を捨ててある程度パラダイムシフトをビビらずに取り組んでいく必要があるのかなと思います。

point.2：ソフトウェア以外の知識がソフトウェアをより良くする
ytake氏：
point1とも絡んでくるのですが、どういう構造が正しいかを認知するために自分達がやっている以外の要素を習得してみる、例えば遊びで違うコードを書いてみることなどは大切だなと。他の言語でやっているようなこと、他の領域でやっている手法で自分達がやっている構造に活かせるものって世の中に沢山あると思うんですよね。規模が大きくなるほど出てきて、キャッシングのテクニックなんかはまさにそうです。膨大な量を捌いているサービスでRedisに突っ込んでということはやってなくて、静的コンテンツを先に作っててそれを検索できるための仕組みを別で作ってみたいな今までとは全然違う方法を採用しているんですよね。ある領域では当たり前のようにやっていることも別の領域で流用するとこれだけ価値提供、UXを損なわずにシステム的な負債、インピーダンスミスマッチが大きいままみたいなことをせずにも良くなることがあります。そういうことを知ってソフトウェア設計、アプリケーションに活かしていけばいいなと思います。

point.3：継続的インテグレーション
ytake氏：
これはCI/CDのお話、アジャイルみたいなサイクル、ビジネス変化に併せてシステムも変えていこうぜという話まであるのですが、次のビジネスを支えるにはシステムも変わっていかねばなりません。システムを変えるためにビジネスをきちんと認知すべきで、機能拡張の有無を問わず昔綺麗に作れなかった部分を綺麗にしていくための工数をちゃんと取ることが挙げられますね
継続的に作ったら終わりではなく、中身も品質を上げるための活動をしていきましょうと。それを持ってアーキテクチャってこういう風にしていけばよかったよねと変えていくという、そういう活動が5〜10年すると貯まっているので少しづつ切り崩していかないといけません。

ミノ駆動氏：
どうしてもシステムを変えるとなると開発面でも心理的な面でもコストが高くなるので、アーキテクトが舵取りをする場面かなと考えます。舵取りは繰り返しになりますがビジネス的にどういう状況なのか理解しないとできなくて、アーキテクトはビジネス的にどうしていきたいのかを解釈 してそれをシステムのアーキテクチャに変換する。改めてビジネス連携を密にして、技術をどのように転換していくのかを考える必要があると感じます。

ytake氏：
アーキテクトをやる人は、自分達の知識やソフトウェア的な手法、ビジネスのアップデートをしていかないといけないですね。あとはユーザーを広義で捉えると、業務フローを支える内部システムを触っている人たちのことも考える必要があって、ここも俯瞰してバランスをとる活動をアーキテクトが行っていく必要があると思います。困っているところの改善に向けてちょっと背伸びをしてトライできるのであればやっていくべきですし、チームビルディングにもつながっていきます。このような活動は継続して行っていく必要がありますし、信頼関係が築けていると今後のビジネスをどうしていくのかという話に対して、ただ聞くだけのスタンスからどんどん開発者側の発案によって入り込めたりもします。利害関係者が増えるほど実現・優先しなければいけないところがあって、ちょっとできないことに少し背伸びしてチャレンジすることが自分達の限界をあげる、ビジネスの限界、より良い価値を届けていくということにつながるのかなと感じます。

ytake氏：
技術的負債にも、ビジネス的に追いついていない・手がかけられなくなって誰も手をつけられないなど2重の意味があったりします。それを度外視して突き進むというのではなく、パラダイムシフトを恐れずに現状を理解した上で最適な選択を取る必要があります。ただ今の時代で言われているWeb系の技術スタックは「これがいいぞ」と言っている人たちにとって最適なものだったりします。例えばMetaがいいと言っているものでも全ての会社にとっていいものではなかったりします。採用した背景・Whyを無視して新しい手法に変換することはアーキテクトの判断として非常に間違っていると思っていて、Whyの部分がマッチするのであれば取り入れるべきだなと思います。ビジネス側に変更を要求するような話に繋がりかねないので気をつけていきたいですね。

ミノ駆動氏：
なんかどうしてもこの技術を取り入れていきたいという妙な政治的な入れ込みがありますよね。やりたいことの目的に対して合致するのかを判断していかなければならないですね。

アーキテクトというキャリアのすすめと必要スキル

アーキテクトキャリアのおすすめポイント3つ

ミノ駆動氏：
ソフトウェアの開発する分野ってさまざまあって、私も今はweb系にいますが、3年前までは組込み系の開発に従事していました。アーキテクトはソフトウェア工学の知識を中心に扱う生業だと思うのですが、ソフトウェア工学って分野に関係ないんです。設計的にどうするかは分野によってどのようなアーキテクチャを採用して構成をどうするかは変わってきますが、今回取り上げている機能適合性や保守性をどうするのかという点は分野を問わず広く応用可能です。アーキテクトというキャリアを選択するとどの分野でも広く活躍する可能性が広がるのかなと思います。
またソフトウェア工学はコンピュータの黎明期から研究が続いてきたものの積み重ねで、オブジェクト指向型の設計などさまざまな変遷があっても結構長く使える知識となっています。対比的にフロントエンドのフレームワークの話を出しますが、ものすごく寿命が短く入れ替えが激しいのでとても知識のアップデートが難しいですよね。ソフトウェア工学も日々進化をしていますが、昔からある知識や考え方の積み重ねでスキルとして陳腐化しにくいなと感じます。
最後に経産省の統計にも出ているのですが、アーキテクトの成り手がいないんです。やる人がいないので設計が瓦解している開発現場が多いと思っています。ブルーオーシャンのキャリアだなと思いますし、社会では国家予算に匹敵するくらいの技術的負債が溜まっている状態ですので、設計に興味があるとか我々の今日の話がきっかけで1人でも多くアーキテクトが増えてほしいなと切に願ってます。

ytake氏：
今だとデジタルトランスフォーメーションと言われるものがあって、アーキテクトと呼ばれる人たちが活躍する場が多いと思います。電子帳簿法改正など大企業のみならず中小企業にもデジタル化の波が迫っている中でITに詳しい人がやはり少ない。いろいろな関わり方があると思っていて、ちょっと手を挙げて、DXをしたいと言っている企業に対してヒアリングやサポートを行いながらどう実現できるかを考えることで勝手にアーキテクトになるためのトレーニングが積めたりもすると思いますね。

ミノ駆動氏：
ちょっと手を挙げる、が非常に大切ですよね。遠慮するところではない部分だと思うので是非トライしてほしいです。

アーキテクトに必要なスキルとは？

ミノ駆動氏：
基本的なところとしてソフトウェア工学やソフトウェアの設計技法を抑えて頂きたいと思っているのですが、大学で情報科を出た人や新卒の方は大学の講義で習ったソフトウェア工学的な部分を大切にしつつ、働き始めてから設計関連の本を読んで実際に手を動かしながら技術として身につけてほしいなと思います。
2つ目は言語化能力ですね。説明スキルや共感スキル・交渉スキルなども列挙しましたが、ビジネスサイドの人と話す必要がありますし、どういう目的で何を伝えたいのかを言語化する必要があると思っています。
モデリングするためには未知の概念を掘り起こす力がとても重要で、技術的負債があって酷いコードだなと思ったときに大抵言語化されていない未知のものが潜んでいます。それが何か分からなかったりするのでビジネス側の詳しい人に話を聞きに行ったり、感じ取る力を強化するために例えば認知科学系の本で学習するなどして、未知のものを感じ取って言語化する力が大切になってきます。
最後にビジネス要求、要件定義と書きましたが、テクノロジーの本質って何かの能力を拡大縮小することにあると捉えています。ビジネスの強みをシステムでスケールアップしていくビジョンを実現するために要求をシステムに落とし込むことが大事で、テクノロジーでどこの強みを増幅させるのか、本質を見抜く力と増幅させるための知識が必要かなと思います。

ytake氏：
ビジネスの要求、要件定義というのは非常に大事だなと思っています。本質を見抜く、ソフトウェアを作る側にいる場合どのようにモデルを表現するのかに繋がりますが、それをやるということは要件として何を叶えたいか分かるはずで、よく耳にする”要件が決まっていない状態”ではなくて”自分達で要件を決めに行けるはず”なんです。コアドメインを認知してさえすれば、システムとしてこうすると枠が広がるぞというのが見えてくるはずでビジネスサイドの人と一緒に行うことで会社活動の豊かさにつながります。

Q&A

いきなりマイクロサービスにするのは吉or凶？

Q.モデルを作っていて、「これは最初からマイクロサービスアーキテクチャで作りたいよな～」て思うものなどがあると思いますが、実際には最初はモノリスで作ってから、徐々にマイクロサービスにしていくのがよくあるケースなのでしょうか？

ミノ駆動氏：
これは罠ですね。モデルってこのモデルがいいと思っていても、実際にものを作ってみて分析を進めると、こっちのモデルや構造の方がいいよねということがよくあります。先ほどytakeさんが仰られていたように最初作ったものは間違っている、という前提があると思うのですが、モデルは1回で正解には辿り着かず、何回もブラッシュアップを経て段々と成長し、成長した結果分化していくという流れになると思います。最初からマイクロサービスで行ったほうがいいのでは？という意見は個人的に結構危ないなと。モジュラーモノリスで作って、そこで回した結果このモデルは分化する、ここはもう十分マイクロサービスとして切り出せるという判断ができるのであれば切り分けてもいいのかなと考えます。

ytake氏：
マイクロサービスアーキテクチャにするぞ、という言葉自体正しくないと思っていて、基本的には”マイクロサービスアーキテクチャ化”なんですよ。何かからそれに進化するという意味にしなければならなくて。マイクロサービスアーキテクチャはモノをただ切り出せばいいわけではないんです。物理的に別システムになるということは信頼性が置けないということがついてきて、モデル云々以外の問題がすごく出てきて、それに対してメンバーの技術スタックで対応できるのかが問題として挙がってきます。今持っていないスタックが要求されるシーンが出てくるので、ミノ駆動さんが先ほど仰られていたモデルが不変に近い、あるいは再利用が可能な状態になって、チームの技術スタックで対応可能と判断して初めてマイクロサービスアーキテクチャ化に進めます。組織とチームがセットになって考えるべきことですし、分割したものを1つまとめることは非常に大変で手戻りにもなるので、まずはモノリスで作ってから段階的に持っていくのがベストだと思います。

ビジネスに興味を持ってサービスを一緒に作れるエンジニアになるには？

Q.アーキテクトに求められる「ビジネスを一緒に作る」について、ビジネスに興味を持たないエンジニアメンバーが多いと感じています。ビジネスやサービスを一緒に作れるエンジニアになるために、どのような課題をクリアしていけばよいか、何かアドバイスできることはないでしょうか？

ミノ駆動氏：
難しいですね…。弊社READYFORでは”乳化”のコンセプトを掲げてエンジニアリングとビジネスサイドの垣根を越えて混ざり合うように全社でやっていきましょうと進めていたりします。このようなビジョンを掲げて価値観を広めていくしか方法はないのかなと思いますね。

ytake氏：
色んな背景があるので難しいなと私自身も思うのですが、ちょっと疑問に思ったらちょっと言ってみるみたいな心理的障壁を越えることが最初なのかなと。いいモノづくりをするには使う人の心を分かっていないといけなくて、僕なんかはエンジニアに対して「早く陶芸家になりたい」とよく言っているのですが（笑）自分勝手なものを作ればいいわけではなく、例えばいいお茶が飲みたいという用途があれば、どういう茶碗であればいいのか調べたり詳しい人に聞きに行ったりすると思うんです。先程ミノ駆動さんも仰られていたように「こうしたらもっといいのに」という感情は自分がエンジニアでない立場やシーンで考えたら絶対にあると思っていて、それを開発においてやるかやらないかが課題をクリアするための第一歩かなと思います。

まとめ

アーキテクトキャリアの魅力や、今開発現場においてアーキテクトが必要とされている背景を掴んで頂けましたか。
お二方から設計手法、特にドメイン駆動設計に関する推薦書籍を提示いただきましたのでご覧ください。
是非ビジネスサイドの方と一緒により良いプロダクトを作っていきましょう。