アーキテクチャ検証は開発者のレベルに合わせる必要はないよって話 #アジャイル開発日記3日目

こんばんは〜〜
今日もお疲れ様でっっす！！
早速知見をアウトプットするぞい！

アーキテクチャ検証めんどくさいよね？

うん。ちょっと言葉足らずですね。
一見楽しいけど、やっぱり難しいし時間かかるよね。

・フロントエンドのフレームワークどうする？
・バックエンドのフレームワークどうする？
・AWSにする？それともAzure？
・DBは？Oracle？Postgres？それとも....
・IDEは？VSCode？InteliJ？それとも...
・SaaSなに使う？Lambda？AzureFunction？他にも...

「え...？そんな難しいですか...？」
っていうあなた。

こっからですよ。。。（にやり）

下記のことも含めてアーキテクチャの選定/検証だよ

・なんでAWSにしたの？うちMicrosoftと仲良いんだけど
・Vue.js？Agularじゃだめなの？
・認証認可はどうするの？
・環境設定ファイルの管理方法は？
・プロジェクト構造は？
・社内セキュリティに準拠できる？方法は？
・てか難易度高そうだけど本当にスピードでるの？
     etc....etc....etc....

これらは二つにグルーピングできます。
開発者視点のものとオーナー視点のものです。

オーナーないしマネジメント層は、本当にそのアーキテクチャで価値のあるプロダクトが継続的にリリースできるかを気にしています。

実際に自分が実装するわけでないので不確実性が高く心配になってしまうんですね。本当は自分の手のひらで部下を動かしたいけどできない時代。

だから色々と気になる。口を出したくなる。根拠を求める。

解決方法は三点。
① 圧倒的な説得力で納得させる
② 不確実性が高いことを認識させる（アジャイルマインドの醸成）
③ （最後のまとめで提案するよ）

①ができる人はなかなかいないんじゃないかな。
かなりの経験と相手の思いを汲み取るマインドがないと難しい。
僕も国内最大手のSIer企業に勤めているが①をできるひとは100に1人もいない認識だ。なので優秀なコンサルを外注するケースが多い。

重要なのは②だ。マネジメント側やオーナー側もアジャイルマインドを醸成しておくのは、アジャイルプロジェクト発足には不可欠だ。

今回のアーキテクチャで開発者が本当に滞りなく実装できるかは分からない。だが、それの限りないサポートをするのがオーナー/マネジメント/アーキテクトの役割であることを認識してもらう必要がある。

なので開発しながら軌道修正していこうでいいのだ。
変に固執する方がシステム的負債を抱え込む懸念がある。

ここでいう負債は、セキュリティの低下や運用保守のコスト増、変更容易性の低下、バグの温床等々のことを指す。アーキの選定をミスしても開発が進み後戻りできない状態になるのはアジャイルの意味をなしていない

開発者側の視点では、技術的な不安からくる弱音だ。
つまり責任転嫁的な考えでアーキテクトにケチをつける。

なんともかっこ悪い。。。
がこれが現実。言えるだけ立派で思うだけの人も多い。

そしていざ開発が始まると
詰まる！！めちゃめちゃ詰まる！！
サーバー側にAPI立てたのに、謎のステータスコードがでてクライアント側から叩けなくて、数時間モブプロで試行錯誤したが、結果はクラウドのコンソールのたったひとつの設定ひとつだった。。。
みたいなことは茶飯事である。
（ここで、うんうん。と頷いてくれることを密かに期待....）

解決策は二点

① チームにひとり今回の技術にマッチした人材を置く
② 今回の技術を一気通貫したCRUDサンプルアプリを事前作成する

高スキルな人材だけを集めることはほとんど不可能である。
（資金が潤沢であれば別であるが、、）
なので上記の①と②が必要。
これらはor条件である必要もないと思っているので
ちゃんとまとめます。。。

まとめ（提案）

アジャイルプロジェクトでスプリント開始前に以下を準備しておこう。

※オーナーのマインドが醸成されていることが前提
STEP1  アーキテクチャ選定
STEP2  上記についてオーナーと仮に握る
　　　（不確実性があることは認識させる）
STEP3 開発チーム2割だけ集めて採用した技術で
　　　 CRUDサンプルアプリを作成する
STEP4 サンプリアプリの実績から再検討の機会つくる
STEP5 上記アプリの作成に携わったメンバーをテックリードとして
　　　 ペアプロやモブプロで慢心してもらう
STEP6 ★★ 開発START ★★

どうでしょうか。このステップを踏めばより不確実なものを確実に近づけ、開発者の潜在的不安の解消に繋がると考えました！！

はい。確証はございません！！！（ドヤ顏）

全然想像の範囲内ですが、実際に今チームの中に今回の技術に強い方がいて本当に助かっています。環境系で悩むのが一番テンション下がりますからね。。でも頼りっぱなしはダメなので自己研鑽も含めみんな技術向上のための行動を率先しています！！

楽しくみんなが開発を続けてできたプロダクトと
苦しみながら一部の人が頑張ってできたプロダクトでは
前者の方が魅力あるものになると思いませんか....???

今日はここまでです。
よく分からないことや、ここは違うだろ！っていうポイントあったら是非コメントくだーーーいっお願いします（土下座）

オーナーのアジャイルマインド醸成方法はまたの機会に記事にします！
このことの重要性を謳った記事はこちらです。