事業性質とフロントエンドリアーキテクト関連の話
一旦、論の流れがキレイでは無いが細切れで書いて、ちょっとずつまとめていく。
前提
筆者の性質
技術の専門性: Web front-end
事業特性: WebにOpenなc向けサービス
SEO 検索エンジン最適化やWebPlatformApp Performanceが2020年代においては、より重要視されている。
会社フェーズ: グロースタイミング
hr.icon
事業特性と会社フェーズと時代から、Web Platform Appにおける課題は一定共通点がある
2010年代に勃興された、2020年代グロースタイミングのc向け事業におけるシステムは、2020年代におけるWeb front-end及びWeb Platform Appに求められる体験にgapが起きがち
2020年頃におけるに、グロースタイミングの事業におけるシステムは、技術的なトレンド、事業特性、ビジネス的なエコシステムの観点から、日本では、Ruby on Railsなどの当時のフルスタックフレームワークで運用されている事が多い。
2010年代における、c向けの事業開始時における、開発プラットフォーム Platformへの展開順序
webアプリケーションで試して→うまくいくと ネイティブ Native Appという流れで作る。
この流れに寄って起きること。
Ruby on Railsといった、フルスタックフレームワークでMVPを早く作る事が多い。
特に日本では、Ruby on Railsが多い。
初期開発時の特性
Front-endのViewとBackendから渡すデータが結合度 Coupling codeが高い方が、初期開発速度が早かった。
エンジニアが少ないので分業すら難しいことも多い。
Core Web VitalsやWebPlatformApp Performanceが2020年ほど、それほど求められていなかった。
需要はあったと思うが、チューニング以前の話であることが多かったのだと思う。
この頃にはない、少ないもの
一気に、Cross-Platform クロスプラットフォーム開発
Flutter
Backend、Frontend共に、同じ言語で作って、Backend、Frontendの垣根を減らす開発
TypeScriptベースで、Next.js、NestJS
現在グロースタイミングにおける、Ruby on Railsで運用されているシステムにおけるWeb front-endと2020年代におけるWeb front-end及びWeb Platform Appに求められる体験にgapがある。
色々参考情報あるので省略
Re: Rails を主戦場としている自分が今後学ぶべき技術について
余談
2010年~2020年は、B向けSassが急激に増えたことは注意したい
B向けの事業は、SEO 検索エンジン最適化やFCP First Contentful Paintが不要なこともあって、初期表示の遅い、SPA Single Page Applicationで良かったり、それほど対話的 InteractiveでないMPA Multiple Page Applicationで何とかなることも多い。
というか、PMFしてスケールするまで、そんなに丁寧に作る事ができないというのもある。
どの事業視点で、Web Platform Appの性質を述べているのか？本当にその事業で、その性質、技術要件は必要であるか？は意識したい。
要するに、事業特性や会社のフェーズによって、取り組める技術的課題は異なる。
あなたは、今、どんな技術的課題に取り組みたい？
hr.icon
事業特性は、エンジニア組織規模に影響する。
事業特性とエンジニア組織の規模の関係
エンジニア組織の年次計画とミッションツリー - nozayasu
↑及び、自身が働いてみて思ったこと
事業特性が、エンジニア組織規模に影響することは間違いない。
コンウェイの法則的な話に近いが、エンジニア組織規模が、システムのアーキテクチャに与える影響は大きい。
事業特性によって、エンジニア組織の規模が小さい場合
(ここイマイチだなぁ。事業特性によって、エンジニア組織の規模が小さいことで、やること多いのはなんで？規模が小さい分やること少なくなるんじゃないの？ちゃんと言語化してほしい。要するに規模が大きいほど、柔軟性が出るし小さいほど、柔軟性が出ないということだと思うが。)
やれることはたくさんあるが、リソースが無いことに陥りがち。
別に、大きな開発はビジネス側でリソース調整されるから別に問題ない。
ただ、小さなやれることもたくさんあるというのが結構むずかしいなぁと思っている。
真に解決すべきシステム資産の価値向上を見据えて、本当にやるべき優先度を言語化し、小さなやれることがたくさんあったとしても、システム資産向上の開発リソースの確保、推進、実行を行わないといけない。
hr.icon
エンジニア組織の規模が小さいほど、各開発メンバーのシステムアーキテクチャに対する影響度が大きくなるので、採用が重要
エンジニア組織の規模が小さいほど、ドメイン知識、既存システム知識のキャッチアップしやすさや、知識習熟度の不要さが重要
エンジニア組織の規模が小さいほど、各開発メンバーのシステムアーキテクチャに対する影響度が大きくなる
開発メンバーのベースの知識や考え方、レベルがシステムアーキテクチャに影響する
エンジニア組織の規模が小さければ小さいほど、開発組織全体の知識や考え方、レベルは、各開発メンバーの影響度が大きくなる。
したがって、エンジニア組織の規模が小さいほど、開発メンバーの採用が重要になる。
特に各専門のテックリード TechLeadは、各々が扱っているシステム資産の価値は、自身の知識や意思決定、行動に依存していることを意識したい。
日本の場合、安直にリストラ出来ないのでより重要
開発メンバーの採用がうまくいっていなかったり、時間がかかる場合の対処
イメージ
リソースが無いので、別の専門性の方に担当してもらう
リソースが無いので、業務委託の方に担当してもらう。
以下が重要
ドメイン知識、既存システム知識はキャッチアップしやすいか？
Documentation ドキュメント化されている。
一般的なシステム構成か？
ドメイン知識、既存システム知識の知識習熟度少なくても実装可能か？
システム 影響範囲が小さいか？
Test テスト Testingが充実しているか？
取り組むタスクの粒度が小さいか？
結局、タスク分解のリソースが必要なので、考えなくてもいいと思う。
hr.icon
会社フェーズにおける、開発優先度
グロースタイミングの事業におけるシステム資産とエンジニア組織規模
グロースタイミングの事業において、新規機能開発による短期的、中期的な事業価値の貢献を優先されることが多い。
同時に数年ものの、技術的負債 Technical debtを抱えているので、これをどう対処するかが重要。
技術的負債 Technical debtの解消が、事業価値にどう貢献するのか言語化して優先度を上げる必要がある。
余談: スタートアップタイミング
基本同様に短期的、中期的な事業価値やバリエーションを出す開発が必要だが、早く作って、MVPやPMFを作るのが重要
hr.icon
エンジニア組織規模と当事者意識 ownershipとリアーキテクト
リアーキテクトとエンジニア組織規模の関連性
エンジニア組織規模がでかいと、
冗長性がでる？
エンジニアの職種特性によって、メンバーの新陳代謝が高いことは、変わらない。
システム資産における当事者意識 ownershipとメンバーの継続年数？
システムリアーキテクトは、実行メンバーの当事者意識 ownershipを高めるというが、推進/実行を進めていくためには、そもそも当事者意識 ownershipが必要である。
このシステム資産における当事者意識 ownershipとはどのように醸成されるのか？
システムリアーキテクトを進めていくうえで、エンジニアに必要なもの
本人の性質や現場の状況によるが、時間で獲得するものが多い。
ドメイン知識
獲得方法
時間
変数
その人の知識
Documentといった知識パッケージ
既存システム知識
獲得方法
時間
変数
その人の知識
Documentといった知識パッケージ
当事者意識 ownership
獲得方法
時間
技術
設計レベル。
リアーキテクト実装者の技術
運用メンバーの技術
一時的にメンバーでない人にに技術を借りて実行してもらう事もできるが、運用観点を忘れてはいけない。
hr.icon
結論
以下の場合
グロースタイミングの事業におけるシステムを開発している。
事業特性によって、エンジニア組織の規模が小さい
システム資産の維持？のために以下を行うべき
事業価値の向上のための開発はまぁ出来て当たり前。
ただし、何でもかんでも出来ることを実行しない。
誰も見れていない、各専門のシステム資産の長期的価値を意識して、やるべきことを常に考える必要がある。
ビジネス、デザインの細かな要求と長期的なシステム資産の価値を天秤にかけて、行わないことを判断する必要がある。
真に解決すべきシステム資産の価値向上を見据えて、本当にやるべき優先度を言語化し、小さなやれることがたくさんあったとしても、システム資産向上の開発リソースの確保、推進、実行を行わないといけない。
エンジニア組織の規模が小さいほど、開発メンバー(特に各専門のテックリード TechLead)は、各々が扱っているシステム資産の価値は、自身の知識や意思決定、行動に依存していることを意識したい。
リアーキテクトと開発生産性について - Speaker Deck