アーキテクチャ考えるときに考えてる事

こじんてきめも

概略

アーキテクチャ = (プロダクトの特性 + チーム体制 + 個人的に死守すべしと考えるポイント + マネージャor要望者の優先課題 + チームのやりたいこと)

プロダクトの特性

たとえば、えんたーぷらいずなシステム構築なのか、BtoCなシステム構築なのか...

リクエスト数はどれくらいなのかとか、可用性は...とか

アーキテクチャを決める前段階で決まってる内容

チーム体制

長く一緒にやってる超優秀なエンジニアだけで構成されたチームなのか、このプロダクトのために緊急でかき集めたエンジニアなのか...など

アーキテクチャの立ち位置とかもこの辺に絡んでくる

個人的に死守すべしと考えるポイント

たぶん各自違うポイントがある（経験とか指向性とかで）

その中でも、これを守らないと絶対ダメだと考えるポイントのこと

過去の経験とかの積み上げとか、前回の反省とかが生きるところ

判断基準は、「これを守れないプロダクトなら作らない」と言えるレベルかどうか

マネージャor要望者の優先課題

優先度の高い課題があって、大抵はQCDのどれかの事が多いけどたまにそうじゃないものもある

その課題をちゃんと理解して認識しておくことが重要

チームのやりたいこと

たとえば、新しい技術を使いたいとか、新しい手法を使いたいとかそういうの

全く新規性の無いプロダクト開発はそれはそれでつまらないことも多いので

ただし、ここまでに出てきた物の中では優先度が低くなることが多いのと、判断をミスると基本的に大変な尻拭いも待ってる部分なので未経験なことを大量に入れるのは避けた方が賢明なことが多い

プロダクトの特性を大前提にして大枠の仕組みを決める

チーム体制を考慮して実装方法・サンプルの作成などで方向性を確定させる

（ここでチームのやりたいことも入れる

（代替があるので後回しにできるものは後から対応して行く

個人的に死守すべしと考えるポイントは全工程で守れるように気を配り続ける

割と早期にマネージャor要望者の優先課題が満たされているのかを判断する

判断した結果、満たされていない場合は調整 or アーキテクチャの見直しをする

大体出来た辺りで走り始めつつ

後回しにした物を色々追加していく

昔はアーキテクチャって言っても単純だったのに、どうしてこんなに増えたんだろうなぁ〜って思ってふと考えたら、プロダクトの特性が凄く多岐にわたることに気がついた

突然流入する100req/sの更新処理を多いと思うか少ないと思うか、準リアルタイムでのデータ同期がどれくらいあるか...という世界かなぁ〜

クラウドの前だったらサーバ費用がかかりすぎるって言って考えなくて済んだのにｗ