ずっと受けたかったソフトウェアエンジニアリングの授業1を読んだ

皆さんこんばんわ。
自粛生活も解除され先週はキャンプに行ってきました。
行きと帰りの電車で上司に「川﨑さんなら今週中に読み終わるよね」と渡された「ずっと受けたかったソフトウェアエンジニアリングの授業1」を読んだので個人的に刺さった部分の話でもしようかなと。

良いシステムを作るには「設計者と実装者の相互理解が必要」

いや、当たり前といえば当たり前なんですが設計の意図を知らずに実装すると、大体システムは微妙になります。実装者と設計者が同一人物であれば問題無いかもしれませんが、別の場合は設計の意図を理解しないと適切な柔軟性のあるモジュールを作れなかったり、別の作業者が作ったモジュールとの連携に支障をきたすモジュールを作ってしまう事があると思います。

そこで設計者は実装者に設計の共有すべきであり、実装者は設計の意図を設計者から引き出す必要があるということです。

要件定義の重要性

この本を読むまで自分が仕事でやっていた要件定義は要求分析でした。
要求定義では要求分析で洗い出されたビジネスプロセスにおけるユーザーの要求を、機能一覧やシステム化するスコープなどを要件定義書という成果物としてまとめ、依頼者との認識のすり合わせを行います。

「ちゃんとユーザーの要求を聞いて設計して実装したのに、なんで見積もりとずれるんや・・・」と思ってましたが、そりゃユーザーの要求だけ聞いて設計に入ってたら目先のものしか設計しないのでそうなりますね。

開発プロセスとその特性

「ウォーターフォール、アジャイルどっちも良いところがあるやん？」くらいにしか思ってなかった開発プロセス、結局アジャイルの中にはウォーターフォールが小さいレベルで入っているらしいです。つまりシステム開発のV字モデルはどんな開発プロセスでも必要になる基礎の「き」なんだという認識を得ました。

コミュニケーション・マネジメント

だんだん書くのが疲れてきました。国家資格の試験で耳タコだったPMBOK(Project Management Body of Knowledge)の話です。
システム開発においてコミュニケーションが大切だというのは重々承知でしたが、ステークホルダの定義も必要というのは新しい学びでした。

ステークホルダを認識することでこのシステムがそれぞれのステークホルダにどのような影響を及ぼすかを認識できます。また社内の担当者なども明確にできるので、○○のことはAさんに聞くといったことも定義することができます。

スコープ・マネジメント

これを知ったときは自分の脳みそにロンギヌスの槍が刺さりました。
システムの要件定義・設計の段階で明確に「今回の開発ではここまでやります」ということを定義することで、開発の範囲が明確になり機能レベルでの「やる・やらない」の意思決定が下しやすくなります。

要件定義で開発のスコープを決めておくことで、追加で開発をする際は追加の工数を正当に求めることもできるメリットもあります。逆に言うと要件定義で作業スコープを極小にしてしまうと、何をやるにしても追加の工数がかかるおそれがあります。

あとがき

自分の知識が薄い箇所だったので結構楽しく読めました。
amazonのレビューが微妙な本書は多分プロジェクトマネジメントガチ勢には向かないかもしれません。それとこの記事を書いてる過程で様々なベンダーの資料を読みましたが、言葉の定義がそれぞれ違いすぎて「もう何もわからない」状態になってました。IPAが正義や。

それと本書ではアーキテクトが

「システムを作るということはお客様の会社を創り、ビジネスの収益モデルを創ることと同じだ」と考えている

と書かれており、アーキテクト＝設計者＝SE？と考えていた自分的には「なるほどなぁ」と思いました。