ライティングソフトウェア 読書メモ
ソフトウェアアーキテクトの仕事は「システムデザイン」と「プロジェクトデザイン」の2つ
システムデザイン
システム分割は「 変動性に基づいて分割せよ 」
機能別分割、ドメイン別分割を行ってはいけない
典型的なレイヤ分割は「リソース」「リソースアクセス」「ビジネスロジック」(エンジンとマネージャーから成る)「クライアント」「ユーティリティ/インフラ」から構成される
「反復的にデザインし、漸進的に構築せよ」
プロジェクトデザイン
プロジェクトの成功にとって、「システム開発を行う資金や時間の計画が健全である」ことは、「システムデザインが洗練されていること」よりも根源的な要素である。
アーキテクチャを構築した後に、時間/コスト/リスクのトレードオフを勘案したプロジェクト案 (プロジェクトデザイン) を複数用意し、マネジメントに提示することまでがソフトウェアアーキテクトの責務
プロジェクトデザインをする上で出てくる主要な要素: #プロジェクトネットワーク 、クリティカルパス、フロート、人的資源配置、コスト、(プロジェクトネットワークの) 圧縮、リスク指数算出、スケジュール弛緩、SDP (= Software Development Plan) レビュー 個人的に気になったこと
価値検証的なアジャイル開発の「インクリメンタルに機能を開発して市場に投入して価値検証する」スタイルとの整合性をどう取るか?プロダクト開発とプロジェクト開発のスタンスの使い分け?
#スクラム のプロダクトバックログは、「ユーザーストーリーを構築する」ように書き出す、と言われるが、プロダクトバックログアイテムを機能とすると、本書の言う「機能ではなくコンポーネントごとに開発していく」進行とは真逆のように聞こえる しかし、 #スクラムガイド に立ち戻ると、 #プロダクトバックログ は「プロダクトに必要だと思われる変更すべて」とあるので、実は相容れないものではない * のではないか?という気がしている。ユーザーストーリーマッピングを元に機能リストを洗い出し、ソフトウェアアーキテクトがシステムデザインを描き、プロジェクトデザインを SDPレビュー を経て確定させた上で、プロダクトバックログを構築して消化していく 本書でも、「プロジェクトプランは条件を守るために絶えず見直されるもの」というアダプティブな態度は明記されてる。プロダクトバックログの並び替えの根拠の一つとしてプロジェクトプランの見直しを位置づけられるのかもしれない?
本書における人的資源配置の原則は「瞬間的には1人の開発者が1つのサービスを担当する」という仕組み。「1つのサービスを複数の開発者が担当すると作業コストやコンテキストすり合わせコストがかかる」「1人が瞬間的に複数サービスを担当してもコンテキストスイッチが高く付く」が背景。 #ペアプログラミング についても触れられているが、「作業している1ペアが1人の開発者に相当する」という考え方。もっと本質的な #モブプログラミング とはコンセプトが大きく違う中で、どう "良いとこ取り" をすればよいだろう? 本書でプロジェクトデザインのメソッドとして紹介されているプロジェクトネットワーク図の作成やリスク値、フロートの算出などを既存のツール (Jira や Nulab Backlog, Clickup など) で実現するにはどうしたら良いだろう?