ビジネス側がやりたいこと
・組織が充分に成熟していない状態であろうとも上場をするという目標を達成したい
・上場審査を通過するためにメインの収益を安定、向上したい
開発者はビジネスがスケールするかどうか中身が見えている状態。だからビジネスサイドが見えていることと開発者が見えていることは根本的に異なり疲弊が生じる。
相手側に「これくらいやれるだろ」という意見や不満が生じる。
開発部の疲弊問題
→ビジネスサイドと開発部との接合点が近いことで組織の力関係が偏っている
こういう会社に入ったら
ドキュメント整備してシステム全体像を図式化、構造化して問題点を洗い出しする
政治（メンバーとして入ると良くないかもしれない）
開発者がやることは
・業務効率化
・アーキテクチャ再構築
・要件再定義・再設計・再実装
業務効率化
例：
カスタマーサポートが疲弊→プロダクト根本的問題を解決する、チャットボットを作る、Q&Aページを再編、構造化して問い合わせ前の解決を促進する、ビジネス問い合わせとカスタマー問い合わせを分離する。
開発者のシステム運用の手間を減らす。インフラ運用を減らす。手動でのデータ転記を自動に。
アーキテクチャ再構築
モノリスから責務が重そうなコアドメインを特定、分散化。データベースのレプリケーション。CQRSを適用、最適なアーキテクチャのトレードオフを考慮して選定し移行。
要件再定義・再設計・再実装
ビジネスサイドがプロダクト価値を向上させる観点やどうやればいいかがわからない場合は開発がヒアリングを主導しぐちゃぐちゃな要件定義を再定義し再編する。ドメイン知識が必要そうな部分をドメインエキスパート（一番詳しそうな人）にヒアリングしドキュメント化。
改善不能になる要因
アーキテクチャの問題と組織構造の問題とマインドの問題
コンウェイの法則→組織構造がアーキテクチャやシステム設計に反映される法則。
コンウェイの法則に加えてその場を支配しているマインドも力学に関与している。
例：
生産性とか言う前にまずやれ思考→業務を効率化したり生産性を上げるように仕組みを変えるなどという思考に至らず疲弊した社員で構成される。
残業をしていた方が評価される→効率化させたり、仕組みが変わったりすることは考えない方が得。仕事がいっぱいある方が得。効率が悪い方がお得。
上司に従順じゃない人は幼稚→マイクロマネジメントでメンバーが他責化・受け身思考化。どうしても社長やトップが幅を利かせてしまい、誰も提案がなされない組織になる。思考することは無駄っていうことになり、アーキテクチャ改善や業務効率をするための思考ができない。
部署ごとの力関係→選択肢を考慮できる部署が偏っている場合、その部署の先導でシステムがどうしても作られてしまう。営業優先だと営業の御用聞になり、システムは手続型の構造になり深い思考が反映されている抽象構造化されず、スケールしない。
上場をする際にベンチャーがぶち当たったシステム観点
セキュリティ監査
→認証・認可問題（管理者画面、画像の永久URL表示）、会計経理不整合
売上で大事なドメインがスケールしていない
0 件のコメント:
コメントを投稿