システム開発におけるアーキテクトについて考える

アーキテクトとは

システム開発において、要件と照らし合わせ今の置かれている状況（要員、コスト、納期など）をもとに適切な設計をを選択し開発の標準・基本を作り上げる担い手

1点集中の深い知識より、幅広い知識を持ち変化に柔軟であり全員を引っ張っていく必要もあるためリーダシップがある人が適しているといわれている。

いいアーキテクトになるポイント

• 常に最新の技術を追いかける技術的な欲求が高い
• 優れたアーキテクチャパターンのメリット・デメリットをいくつも理解している人
• 最善 ≠ ベストではないことを理解している。
  • アーキテクチャは常に進化しておりその時に最善であってもいずれすたれてくる。
    　　最善を求めるとコストや労力に跳ね上がってくるが見合った成果が得られるのは一瞬。
  • ベストなものは最低ではなく変更が容易で進化していくことができるアーキテクチャ
• リーダシップをとりチームに取り組むべきビジョンを見せること

向かない人

• 確証バイアスに陥りやすい人
• 設計指針を遵守できない人（常日頃よりルールを守らない人）
  • ルールが悪いとしてルールを変えることに力を入れずに、ルールを準拠しない方向に傾く人
  • 遺脱した状態で放置するといずれ負債となって延々とシステム開発・運用に闇を持ちづづけることになる

NGパターン

時代はマイクロサービスでしょ！
⇒モノリシックにもいいものはあり、ケースバイケース

アジャイルじゃない？
⇒アジャイルは開発中のプログラマを幸せにする可能性は高いが、ビジネスにおいては幸せにならない可能性が高い。
　アジャイルで開発するべきではないフェーズ・要件で無理やりアジャイル開発を行い納期・コストが２倍になったとかはよくある話。
　納期が延びてビジネスが失敗すると会社にもプログラマも幸せではない。

とりあえずサーバレス構成で構築するとコスト安くなっていい！
⇒やりすぎると、各構成やサービスの構成がカオスになり、人の運用費用が増加して大変。。。

まとめ

アーキテクチャがシステム構成を決めるのではなく、ビジネス要件・システムの課題がアーキテクチャを決めるもの。
どうやってが優先されるのではなく、なぜから解決策（適したアーキテクチャ）を見つけるべき。

短いのでもうちょっと追記＆きれいします。。。