Notes

新作作文vol.4 2022/4/17
---
※まだ説得を諦めないなら…

前提 2項↓

◆品質/納期/コスト/XXX のツマミの絵
→4/15のミニマムへのスコープ変更で、また比重は見直す予定か？

◆今期と今後のスコープでのレベル感のギャップ・共通化是非

※将来を見据えて〜、といつものように言い出したら

(必要十分路線推し、での意見)
→マイクロサービスなので、今後の業務アプリと造りや実装レベルが違っても問題はないはず
→共通リポジトリに切り出さなかった場合、資源の物理的な共用はできないが、ロジック(論理)・ノウハウの再利用はできる
→共通化した場合、今後の開発での共通部の機能更新に影響を受けてしまう(全うにやるなら、リリース済みアプリの再試験や改修が必要となる)
→逆に、今回無理して今後のスコープのレベル感・共通化思想に合わせるメリットは？
・次期フェーズが楽になる(資源・方式の流用)
・今期と今後のアプリの造りの統一感(→別になくてもいい)
・他には？
→そもそも次期は本当に来る？(やりたい話があるとしても、ここまでのこの調子では…。初回コケたら次はないのでは？？)

---

本題↓

◆基盤充足度、コスト・期間、難易度
→アプリ基盤に対するFJとして想うニーズはどこ？(Season1/それ以降)
（使える期間・リソース等の条件で、目指すべきところは変わってくるはず）

※ 以下は大まかなイメージ。実際はタスクそれぞれ、もしくは中項目に対してどこまでやりたいかを意識合わせすべきかと思います。

※以下の2項は3～5段階程度の表にできる。
※細かい内容は斜め読みで雰囲気だけ見て貰えれば。

◆···基盤充足度、コスト・期間、難易度

【施策・効果・具体例】
◆低
・プロジェクト雛形作成
・サードパーティライブラリの選定・利用設定
・あとは各開発者で自由に実装

◆中:オブジェクト指向など
共通的に行う処理・周辺機能を利用する為の処理、等の単純な部品化
・低レイヤー処理の分離・隠蔽・一元化による
・業務実装の簡素化/工数削減/技術的負担軽減
・可読性/メンテナンス性向上

各処理層の分離による
・各クラスの役割の明確化
・再利用性の向上

実装ガイドライン策定による
・構造/挙動/品質の均一化

周辺技術(FW、O/Rマッパー、その他ライブラリ)の機能利用・設定変更等による実装効率化
・各種ライブラリのメソッド利用・アノテーション利用・設定値変更
・それら機能の挙動検証・選定
・実装ガイドラインへの盛り込み


◆高:アスペクト指向、基底処理・FW改変など
AOP+基底処理
・横断的関心ごと・低レイヤー処理のさらなる分離・隠蔽による業務ロジックの簡素化・汎用化
→ロギング、認証・認可、例外処理など

・Baseクラス、Interceptorクラス、Pointcut/Advice/@Aroundアノテーション、等々の利用による業務ロジックや特定層処理の前後処理実装機構作成
・始端・終端(Controller到達以前/以後)/Controller層/Service層/DAO層の特定メソッド実行/外部アクセス層等へのアクセス時、特定タイミングでの例外発生時、等の自動的・半強制的なロギングや共通処理の埋め込み
・認証・認可/リクエスト妥当性チェック/バリデーションチェック
など

・業務ロジック外/ミドルウェア/利用ライブラリ/外部サービス等で発生する各種既定例外
+ 業務都合で定義する独自定義例外クラスの実装
+それらを包括して業務ロジック外でまとめて処理する例外処理機構の考案・実装(数段階でのHandlerやFilterクラスによる例外捕捉・処理)
+ 後述のログ・メッセージ出力
+例外→HTTP Status CodeへのResolverクラス実装
+エラーレスポンス情報の業務的粒度検討・変換機構実装(画面へのエラー情報や、HTTPヘッダ+ボディ(JSON)の設定)

・依存性注入(DI)による画面やコンポーネントの抽象化・汎用化
→現行AbLibraryの画面や機能の設計思想はDI色強めと思われる。今回この観点のそこまでの踏襲は目指さない

・FWやライブラリの標準挙動への制御追加・改変によるセキュリティ対策等の充足(SpringFrameworkやSpringSecurityのServletFilterChainへの追加処理差込みやオーバーライド)

・メッセージ/ログ/チェック処理機構/例外処理/基底クラス/部品/アプリ周辺サービス間での高度な連携による、運用性向上（監視性・追跡性）まで意識した仕組づくり
ex)メッセージコード体系化+適切なタイミングでのログ出力→CloudWatch・Datadog等でのログ集約/フィルタリング条件設定による運用監視・自動通知
(ローカル環境でのデバッグや、テスト環境での再現試験など行わずとも、通知や運用環境のログを見るだけで、いつどこでだれがなにをどのように操作したかや障害発生箇所が明確に特定できる）

---
【メリ/デメ】
◆ 基盤充足度 0〜30%
・基盤担当を割り当てる程でもなく、その分業務実装やその他にリソースを割ける
・品質や造りが各業務実装担当者の技術力・協調度などに左右され、各機能の要件次第で負荷・難易度も上下する
・小規模開発(拡張予定も無いアプリ)、高スキル技術者によるチーム編成、短納期案件などではこれが最適な場合も

◆ 基盤充足度 40〜70%
・基盤タスクの負荷・工数をある程度抑えつつ、業務実装もある程度の統一感を持って開発できる
・基底の仕組みに深く関わらない部品化・共通化は、最初に着手した業務実装担当者などに委ねることも可能
・中規模前後の開発で諸々のバランス調整をしつつ採用できる

◆ 基盤充足度 80〜100%
・基盤タスクの負荷・工数が高く、業務設計/実装時期より早期の準備期間が必要となる
・業務実装メンバに高い技術理解や周辺知識を要さず、業務で実現したい事柄のみに注力して開発(設計/実装/試験)が出来る、業務実装がシンプルになる
・品質の安定
・大規模開発であるほど効果を発揮

---
◆見積値について
・あくまでも記憶の中から引っ張ってきた参考値
・隣のPJからの部品流用(自PJ向けにカスタマイズはした)や、過去PJでの経験・思想の応用(物理的にソースや資料が見れる状態)
ありきでの数字

追記メモ
・アプリ/環境/運用等に依存する外出しすべき設定値の選定・方式検討(各種プロパティファイル/Dockerファイル/ECS環境変数/その他外部機構、など)

---
◆所感 ※ほぼ嫌味…気分を害すなら全スルーも可。。

・スコープ変更以前のように、しのごの言わずとりあえずモノが出来ていった方が安心なら、スケジュールの見通しの心配だとかリスクの提言やそれに伴う路線変更の提案だとかに時間を使わず、計画・リスク管理は全てお任せして、ご指定どおりの方針でモノ作りだけ進めますけど、そっちがいいですか？(勝手に引かれた無謀な計画に責任なんて持ちませんが。)

・Fさんで言う非機能/アプリ基盤って、自分たちが計画/管理/想像しきれてない諸々の面倒ごと全部を放り込める魔法のシュレッダーのようなモノ、というイメージで合ってますか？

・基盤のこういった裏方的な努力によって、業務の設計/実装/試験の難易度/品質/工数/規模などは大幅に変動するわけだが、脳死で【業務のkstep換算】主体で顧客交渉するようなベンダーでは、これらをやるコスト/体制/期間は用意出来ないのでは？(やればやるほど安売りされて、負担ばかりこちらにのしかかる搾取構造のようなもの。高スキル技術者ばかりを必達で求められるのも似たような話)
→基盤分のkstepを含めているとしても、規模よりも1行1行の密度が濃いという実態に見合ったコスト感は出てこない。やるなら難易度に応じた係数(かなり高めの想定)を掛ける、ぐらい？
→業務機能いくら、でしか顧客と話が出来ないのであれば、基盤で浮く分を業務規模から差し引いて安売りすべきでないのでは？(業務規模に基盤分のコストを分散して積むor基盤がなかった場合の実装規模とすべきでは？)
→もしくはその辺に理解を示さない上で、かつ理想ばかり押し付けてくるベンダー配下では、基盤は作らない・請けない、が正解？(余計な説得工数もこちらのPM/PL/PG全域に対してかなり掛かっている)

・こういった諸々の負担・不条理が横行する新規開発・刷新系案件と、その点では比較的安定したエンハンス系案件の受注額は、同じ【人月いくら】の基準なのか？
→であれば、リスクばかり高く、新規案件や基盤開発は割に合わない、と感じる