https://www.wantedly.com/companies/company_8774554/post_articles/325506#_=_
株式会社 ONE WEDGE でメンバーに助けられつつ、毎日を過ごしている村上です。
ある開発案件でちょっと思うところがあって、今日は私が社内のメンバーにいつも口酸っぱくして言っている「アーキテクチャ」についてお話ししようと思います。PR隊に「もうちょっと CTO らしくシステム寄りの話もしてよー」と言われたってこともあります。。
アーキテクチャとは･･･
コンピュータ・アーキテクチャ（英: computer architecture）は、コンピュータ（特にハードウェア）における基本設計や設計思想などを意味する。アーキテクチャ（建築）には、単に「建築物」以外に、設計や様式という意味があるが、それから転じて、コンピュータ分野においても使われるようになった。「設計思想」などと意訳されることもある。技術者や研究者の用語としては（企業ごとの用語の違いにもよるが）「方式」という語が使われることもある。
Wikipedia日本語版より引用させて頂きました。
システムを作るとき、ひとりで作るのであれば個人の設計思想の下で自由に作られると思います。
では、チームを組んで複数人で作るのであればどうでしょうか。あなたの会社やチームではどうでしょうか。
誰かが書いたコードをコピペする？各人が好き勝手書く？MVC？あれオワコンでしょ。
私がアーキテクトという役割で働く以前、結構色々な現場を渡り歩いてきましたが、よーーーく考えてみると意外とちゃんとしたアーキテクチャが存在しないまま、なんとなく、基本設計の機能単位で誰かが書いたコードと似たようなコードを書いている現場が多かったような気がします。
プログラムは書いたとおりに動きます。そして書いたとおりにしか動きません。プログラムの集合体であるシステムもまた然り。つまり、システムは理路整然としていることが求められ、そして論理的でなければなりません。
あなたが真似ているコードは理路整然とした論理的な設計思想をバックグランドとして書かれていましたか？あなたはその設計思想を汲み取り、その設計思想に従ってコードを書いていましたか？
たいていの場合、“No”ではないでしょうか。
アーキテクチャ（設計思想）が存在するシステムの場合、俯瞰したシステムアーキテクチャ図でシステムの概念が説明できるはずですが、残念ながらそうではないプロジェクトにおいては、設計思想なんて微塵も存在しないなんちゃってコピペコードの集合体であるシステムであり、それを俯瞰して説明できるアーキテクチャ図が描けないはずです。
「このコードを参考に書いてみて」
全体を俯瞰する資料ではなく、この言葉が最初に出てきたら危険信号です。
建築物と同じくシステムは設計思想があるべきだ
システムというものは構築するときには建築物と同じと私は考えます。
/assets/images/6704646/original/dbd0e546-ce94-41ca-aba9-b4aae929ec83?1621020880)
きちんとした地盤調査を元に、適切な土台を構築し、そしてその上に構造物を構築する。構造物は適切な建築手法で適切な建材を使って人が使いやすいように作られなければならない。
システムに置き換えると･･･
きちんとした技術調査を元に、適切なインフラを構築し、そしてその上にシステムを構築する。システムは適切な開発手法で適切なフレームワークを使って人が使いやすいように作らねばならない。
建築はきちんとした構造計算を元に作られるわけで、そうでなければとんでもない事故に繋がります。システムもきちんとしたキャパシティプランニングやアーキテクチャ設計があってこそだと考えます。
私が考えるアーキテクチャとは
偉そうなことはいいません。特に優れたアーキテクチャではないです。
システムは、機能面で垂直に分断する垂直分散型、レイヤー面で分断する水平分散型、このふたつのアーキテクチャに集約されると考えています。
垂直分散型はリファレンスとなる部分をひとつ作ってしまえばあとは似たように作るだけなので開発の初速が速いです。ですが、いわゆるコピペコードが量産されやすい。
対して水平分散型は、システムをアーキテクチャレイヤーで分断してパーツとしてくみ上げるので初速は遅く、開発の後半にならないと開発速度が上がりません。しかしながら、各レイヤーごとのインタフェースが固定化されるので変更や改良に圧倒的に強くなります。
具体的に説明すると、水平分散型のアーキテクチャは最下層にOSやRDB外部サービスとの通信を受け持つレイヤーとし、その上に業務ドメインを抽象化したレイヤー、さらにその上は業務ドメインに特化したレイヤー、最後にフロントアプリケーションに対してAPIを提供するレイヤー･･･こうやってシステムを層に別けて、各レイヤーは下位のレイヤーのパーツを組み合わせて構築します。下位レイヤーでなにをやっているかは気にせず、とにかくインタフェースだけ着目して構築します。下位レイヤーがやってくれないことは自分でやるのではなく下位レイヤーにやってもらえるよう、APIを増やします。そうやってレイヤーごとに抽象度を分断して徐々に抽象度に変化をつけながらシステムを構築するところが重要です。
抽象レイヤーを挟むことにより、最下層の変更が上層部に対する影響が少なくなり、また最上位の変更は下位レイヤーに影響を及ぼしません。つまり、システムは変化に強くなるのです。
こんなことは、知っている人にとっては当たり前のアーキテクチャな訳で今更ドヤ顔で説明するのもおかしな話ではありますが、残念ながら色々な現場を渡り歩いてきてこういう設計思想をきちんと踏襲しているシステムが圧倒的に少ないのが事実です。
システムというものは構築期間より運用期間の方が圧倒的に長いのを忘れてはいけません。どういうことかというと、開発は１年だとしてもその後システムが運用される期間は数年レベルで運用されるということです。お客さまのビジネスは日々変化しているため、システムはどうしても変更に晒されます。
これを考えると構築のしやすさよりも改良のしやすさに着目しなければならないと考えています。
つまり、垂直分散より水平分散の方が運用に耐えられるシステムとなり得ると考えられます。たとえ開発初期における構築速度が遅くとも。
ONE WEDGE ではどうやっているか
ONE WEDGE では CTO である私が目の届く範囲で各プロジェクトについてあらゆる技術的なフォローアップをしています。私は天才でもないしキレ者でもないけれども、業界20年の経験で色々な観点からチェックやアドバイスをすることができます。
ONE WEDGEでは沈黙はNGです。常に雑談をし意見を言い合い助け合う文化ができています。5分悩んで結論が出ないことは全て私に質問するように常日頃徹底してもらっています。さらに、わからないことがあればそれぞれ尖った知見を持つエンジニアがサポートする体制が整っています。
そして、なにより私がPLメンバーやPMメンバーにいつもいつもいつもいつも「アーキテクチャ」をきちんと定義するよう言っています。
エンタープライズアーキテクチャや AWS Well-Architected アーキテクチャなど色々あるけれど、教科書通りではなくメンバーのスキルやお客さまに納品するシステムに合わせて ONE WEDGE 流にアレンジしたアーキテクチャを定義するようにしています（教科書通りにやると頭でっかちになって失敗するのだ）。
可能な限り、水平分散を意識し各レイヤーごとに分断して経験があるエンジニアが低レイヤーの構築を、まだ日が浅いエンジニアが高レイヤーの構築を行うことにより、経験の浅いエンジニアはI/Fの作り方や思想を学びながら構築を行い、経験のあるエンジニアはより深く設計に拘りながら低レイヤーの実装を行うことができます。もちろん、低レイヤーの設計や実装には私も目を光らせアドバイスを行っています。
そうやって設計思想を持ったシステムであるからこそ、 ONE WEDGE で構築したシステムは堅牢だしお客さまの要求の変化にもいち早く「こんなこともあろうかと･･」と言いながらサラッと対処できるのです。
アーキテクト不在のチームで成長できるか
これを読んでいるあなたのチームにアーキテクトはいますか？
アーキテクト不在のチームで成長は期待できない。プログラマーとして頭打ちになるでしょう。断言します。
良きアーキテクチャには思想があり、設計、構築、運用、拡張において様々な勉強すべき点がみつかります。アーキテクチャ不在や、アーキテクチャを定義するアーキテクトが不在のチームではその学ぶタイミングを逃します。それで10年後20年後の自分の姿を想像できますか？
今はできなくてもいい。来年できるようになるから。
- 入社半年で要件定義から納品まで完璧にこなすメンバー
- 未経験入社で入ってきて泣きながらプログラムやっていたけど今ではあらゆるプロジェクトのヘルプをして活躍するメンバー
- SESから戻ってきて半年でAWSインフラのプロフェッショナルになったメンバー
- 同じくSESから戻ってきて複数プロジェクトをぶん回す敏腕PMになったメンバー
- 「やりたい」と言って自分でメキメキ勉強してたった１年で社内のデザインを一手に引き受けるUXデザイナーメンバー
ONE WEDGE での１年は、他社さんの３年分の濃密さだと思います。「そりゃ案件が死ぬほどあるようなブラック企業だからでしょ」って思われても仕方ないけど、そうではありません。
私が技術責任者として常に気をつけているのは「適材適所」に人材をアサインするように心がけています。誰もが持っている向き不向きをきちんと見極めそしてアサインすれば人は自ずと成長すると考えているからです。ブラックだからではなく、やれるところにやれる人を柔軟にアサインする。これが ONE WEDGE の開発体制なのです。
これを読んでいるあなた。次に成長するのはあなたかもしれません。
/assets/images/6704648/original/28cc63cc-fe25-4486-8ce7-dd874b409cbc?1621020952)
/assets/images/5220002/original/a88411a5-2ad9-4c4e-a3ed-e90c879cb7c2?1593419247)
0 コメント:
コメントを投稿