ざきの学習帳(旧 zackey推し )

日々の学びを書きます

モダン・ソフトウェアエンジニアリング 第1部・第2部を読んで / ソフトウェア開発における理論って?

今月から、モダン・ソフトウェアエンジニアリングを読み始めました。

全23章(4部構成)と少し長めの本のため、中間である第2部が終わった時点で、読書メモを書いておきたいと思います。

なぜ読み始めたか?

開発工程において、以下を知りたいがため、読み始めました。

  • 現代おける有効なプラクティス
  • チームとして作業を進める上での手法

どんな本か?

序盤で「ソフトウェア開発におけるプラクティスが溢れている」が課題として定義されています。

その課題を以下解決目的で作成された、OMG(Object Management GroupEssence)で標準化された、Essenceと呼ばれる共通基盤の記述(要はプラクティスや開発工程におけるのUML版みたいなもの)・利用方法を学べる本...と解釈しています。

  • あらゆるプラクティスを記述(可視化)→再利用可能にする
  • 似たようなプラクティスの大量生産による混乱と作成コストの削減を図る

Essenceについて

さらっと概要だけ知りたい方は、翻訳者の 角 征典 さんの登壇資料をどうぞ。


学び・気づき

第1部・第2部での主な学びです。
(というか、ほぼ7章の振り返りになります。)

他業界に比べて、ソフトウェア開発には理論が語られない

7章 理論のふりかえりにて、

ソフトウェアエンジニアリングでは、理論の話題が出てこない

という文脈がありました。

かいつまんで説明すると、以下な感じです。

自分は他業界の知見がないため「へぇそうなんだ」という所感ですが、確かに「この状況においてはこれがベストプラクティス」というのをよく聞きますが、「これが正しい」みたいな説明はあまり聞かない気がします。

(自分も、答える立場だったらベストプラクティスとか、要はバランスとか回答しそうです。)

なぜ理論が語られないのか?

理論の使用は、以下4つの条件を満たすこと。また、ソフトウェアエンジニアリングは実践的の部分が多いため、決定的な理論が持てないのではないか...と説明されています。

  • 対象となる現象を記述すること
  • テーマの「どのように」「なぜ」「いつ」を明記すること
  • すでに起きたことだけでなく、これから起きることを予測する
  • 予測に基づいて行動を支持(示唆すること)

そのため、理論ではなく、代わりにルールやガイドラインがその役割が担っているとのことです。(たしかに)

見解

ここからは自分の見解ですが...本書で記載されている通り、開発における不確定要素が多いため、理論が提唱できないのではないと、納得しました。

身近なものだと以下です。

  • 開発環境
    • 言語・フレームワーク・習熟度など、さまざまな要素で開発における環境は変わるし、適用するプラクティスも変わる
  • 要求の変化
    • ビジネスサイドも刻々と状況が変化し、ソフトウェアに求められるものが変わる

Essenceは記述的な理論を提唱する

ソフトウェアエンジニアリングにおける、理論を提唱するのが難しいことがわかりました。そして、この現状を打破する一歩目として、提唱されたのがEssenceとのことです。

本記事では詳しく書きませんが...Essenceはプラクティスや開発工程をUMLのように表現し、どの作業がどんな状況で、どんな到達点にいるかを明らかにさせます。これには、以下のようなメリットをもたらします。

  • 進捗可視化による、明確な状況把握
  • 引き継いだメンバーの状況把握

ただ、学習コストはもちろん、チームで利用するには、啓蒙と本書に記載されている目的を理解してもらう必要があります。

完走していないので、Essenceを採用した方がいいとまだ言い切れませんが、以下のような状況では、Essenceは有効な理論かと思いました。

  • メンバーの入れ替わりが激しい
  • メンバー数が多く、状況把握が難しい(または、問題が頻発している)

おわり

以上です。

完走したら、また続きを書きたいと思います。