「点と点を線にする」全体像を考えてのアーキテクト

「点と点を線にする」全体像を考えてのアーキテクト

with コメントはまだありません
architect_header

夏です。ビールが美味しい季節になりましたね。
ポケモンを探して暑い中街を練り歩いて、渇いた喉に冷たいビール。最高です。
一緒にポケモンを探したい方。おいしいお酒を飲みたい方。お問い合わせフォームよりお誘いください。
 
お酒が好きなワタシですが、いつもお酒を飲むことばかり考えている訳ではないのです。
記事を書く機会をいただいたのでちょっとばかしマジメなお話しでも書いてみようと思います。
 
エンジニアのみなさん、イキナリですがちょっと考えてみてください。
お客様から「新しいアプリを作りたい」と相談をいただいたときに、どのようなご提案をされていますか?
※ ユーザ企業の方は「未来を描く」から読んでいただけると幸いです
 
きっと様々な角度からお客様の「ビジネスの発展性」や「実現したいこと」etc…について悩みご提案をされていることだと思います。
そのなかで今回は「アーキテクト」についてちょっとだけ触ってみたいと思います。

そもそも「アーキテクチャ」って

機能要件や非機能要件を満たす為にミドルウェアの設定をしたり、ビジネスロジックを書いてみたり。日々苦労されていると思います。
しかしそれらはすべて「アーキテクチャの設定」であったり、「アーキテクチャ上で動作するロジック」だったりします。
私は「アーキテクチャ」とは顧客要求にこたえるための「構成要素」だと認識しています。
例えば「どの言語にしようか」や「サーバの構成はどうしよう」、「ミドルウェアはどのようしようか」などがすぐに思い当たると思います。
 
アーキテクチャの選定方法はいくつもあると思います。
顧客要件を満たすための手段がいくつも思い当たるのと同じことで、どのアーキテクチャを選定するかは「手段の一部」でしかないからです。
大切なのは「目的を見失わないこと」であると考えています。

「アーキテクチャ」と「アーキテクト」の違いって

「アーキテクト」と聞くとなんだかハードルが高いコトの様に聞こえる方もいらっしゃるかもしれません。
しかし気付かないうちに関わっていたりすることもあります。
例えば、
 

  • どの言語にしようか
  • サーバの構成はどうしようか
  • ミドルウェアはどうしようか
  • ログはどうしようか

 
など、部分部分でのアーキテクチャ選定としてのかかわりです。
ではアーキテクチャの選定に関わる方々皆様が「アーキテクト」なのでしょうか?
私は違うと考えています。
「アーキテクチャの選定に関わる」ことに加えて、「全体像を把握」し、「その選定に責任を持つ」役割が「アーキテクト」なのだと考えているからです

「点」だけで考えた絵はピカソの絵

ひとつひとつの要件に対して答えることができるアーキテクチャ選定ができたとしましょう。
しかしそれで問題は無いのでしょうか?
もしかして個別最適な構成になっていく可能性があります。
 
個別最適をしすぎるあまりに1要件として縦軸でのレベルは高くとも、横串で横軸で見た時にレベル感の違いや個別要件のつなぎの部分に隙間が空いていたりして隙間が生まれる(ポテンヒットになっていたりする)ことはないでしょうか?
また、横軸で見るからこそ生まれてくる最適化もあると感じることがあったりします。
そこで目的を見失うことなく。また、全体的にバランスの取れた構成を考えられる視点も必要となります。
個別個別で素敵な絵を描けたとしても、全体的にまとまりがない状態では「ピカソの絵」の様になってしまいイビツな構成になってしまう可能性があったりします。
そうならないためにもアーキテクトには「バランス感覚」も求められることの一つになり得るのではないでしょうか。
 
顧客からの要件が「実現したいことの点」だったりします。
それらの点と点を結んで一つの線にしていく。
そしてその線を結んでいくことで大きなカタチを形成するのだと思います。
アーキテクトはその「点」を見ながらも「大きなカタチ」を意識して、いびつな構成にならない様注意を払いながら選定する必要があります。

未来を描く

そのシステムは作って終わりではありません。
作った先にお客様が業務を行い、我々が保守・運用を行い。新たな機能を実装し。など未来があります。
 
仮に、今流行りの技術があるとします。
エンジニアとしては取り入れたいと思うかもしれません。
しかし「流行っているから」という理由だけでは選定理由にはなりません。
 

  • 誰がメンテナンスをするのか
  • 他に同様のことを実現するアーキテクチャは存在するのか?(もしも存在しているがまだ流行っていないだけならば、そちらを選定する可能性は無いのか
  • 流行っているか特殊な実装をしすぎているために、切り捨てることはできるのか(運命を共にする覚悟はあるか)

 
など検討事項は多岐に渡ると思います。
 
そのシステムや選定したアーキテクチャにどのような未来があるのか。それも考えて行く必要があると思います。
流行っていない枯れた技術だった場合、あとどれくらい延命するのかも検討の一部になり得ると思います。

まとめ

タイトルにしました【「点と点を線にする」全体像を考えてのアーキテクト】についてイメージいただけたでしょうか?
簡単にまとめると
 

  • 顧客からの要求にこたえるための「構成要素のひとつひとつ」が「アーキテクチャ」
  • 「アーキテクチャ」を選定することが「アーキテクト」のミッション
  • 選定したアーキテクチャに対し責任を持つ
  • アーキテクチャを選ぶ際にはいろいろな観点が必要
    • 点の意識
    • 線の意識
    • 全体の意識
    • 選定したアーキテクチャの未来やシステムの未来を意識

 
ビジネスロジックとして作りこんでしまってもかまいませんが、作りこむ工数以上にテスト工数がかかってきたりするなど、機能的にはいくつも手段がある中でその方法を選択するが故に膨らんでしまう工数があったりもします。
やはりできる限り工数は押さえておきたいところですので、そうならないようなアーキテクト選定やそれをメンバに伝える義務があったりするのだと思います。

ポケットモンスター・ポケモン・Pokémonは任天堂・クリーチャーズ・ゲームフリークの登録商標です。
宮越
Follow 宮越:

スタートアップの開発チームのマネジメントを経て入社 。 ソリューションアーキテクトとしてシステム化のコンサルティングから開発基盤の実装など幅広く対応する 。 収入の大部分は酒代に費やされる。