追記
第3部以降も読み終わりました、感想はツイートへ
全部読み終わった
— ざき@どんどんドーナツどーんと行こう (@zucky_zakizaki) 2020年8月16日
第3部以降は、Essenceをベースとして開発工程にどう適用させていくか、プラクティスをどう合成するかのお話だった
スクラムやマイクロサービスアーキテクチャの開発における適用方法まで乗っていて、イメージしやすかった
ほんへ
今月から、モダン・ソフトウェアエンジニアリングを読み始めました。
- 作者:Ivar Jacobson,Harold “Bud ”Lawson,Pan-Wei Ng,Paul E. McMahon,Michael Goedicke
- 発売日: 2020/05/29
- メディア: Kindle版
全23章(4部構成)と少し長めの本のため、中間である第2部が終わった時点で、読書メモを書いておきたいと思います。
なぜ読み始めたか?
開発工程において、以下を知りたいがため、読み始めました。
- 現代おける有効なプラクティス
- チームとして作業を進める上での手法
どんな本か?
序盤で「ソフトウェア開発におけるプラクティスが溢れている」が課題として定義されています。
その課題を以下解決目的で作成された、OMG(Object Management GroupEssence)で標準化された、Essenceと呼ばれる共通基盤の記述(要はプラクティスや開発工程におけるのUML版みたいなもの)・利用方法を学べる本...と解釈しています。
Essenceについて
さらっと概要だけ知りたい方は、翻訳者の 角 征典 さんの登壇資料をどうぞ。
学び・気づき
第1部・第2部での主な学びです。
(というか、ほぼ7章の振り返りになります。)
他業界に比べて、ソフトウェア開発には理論が語られない
7章 理論のふりかえりにて、
ソフトウェアエンジニアリングでは、理論の話題が出てこない
という文脈がありました。
かいつまんで説明すると、以下な感じです。
- 他業界(学問)では、理論を元に語られる
- 光学、回路理論、心理学、組織論、国際関係論、etc...
- ex. 電子工学の マクスウェルの方程式 - Wikipedia など
- ソフトウェアエンジニアリングでも、理論が提案されているが、議論されることが少ないし、何が正しいか統一した答えは帰ってこない
- 過去に提案された理論
自分は他業界の知見がないため「へぇそうなんだ」という所感ですが、確かに「この状況においてはこれがベストプラクティス」というのをよく聞きますが、「これが正しい」みたいな説明はあまり聞かない気がします。
(自分も、答える立場だったらベストプラクティスとか、要はバランスとか回答しそうです。)
なぜ理論が語られないのか?
理論の使用は、以下4つの条件を満たすこと。また、ソフトウェアエンジニアリングは実践的の部分が多いため、決定的な理論が持てないのではないか...と説明されています。
- 対象となる現象を記述すること
- テーマの「どのように」「なぜ」「いつ」を明記すること
- ex. 認識論 - Wikipedia
- すでに起きたことだけでなく、これから起きることを予測する
- 予測に基づいて行動を支持(示唆すること)
そのため、理論ではなく、代わりにルールやガイドラインがその役割が担っているとのことです。(たしかに)
見解
ここからは自分の見解ですが...本書で記載されている通り、開発における不確定要素が多いため、理論が提唱できないのではないと、納得しました。
身近なものだと以下です。
- 開発環境
- 要求の変化
- ビジネスサイドも刻々と状況が変化し、ソフトウェアに求められるものが変わる
Essenceは記述的な理論を提唱する
ソフトウェアエンジニアリングにおける、理論を提唱するのが難しいことがわかりました。そして、この現状を打破する一歩目として、提唱されたのがEssenceとのことです。
本記事では詳しく書きませんが...Essenceはプラクティスや開発工程をUMLのように表現し、どの作業がどんな状況で、どんな到達点にいるかを明らかにさせます。これには、以下のようなメリットをもたらします。
- 進捗可視化による、明確な状況把握
- 引き継いだメンバーの状況把握
ただ、学習コストはもちろん、チームで利用するには、啓蒙と本書に記載されている目的を理解してもらう必要があります。
完走していないので、Essenceを採用した方がいいとまだ言い切れませんが、以下のような状況では、Essenceは有効な理論かと思いました。
- メンバーの入れ替わりが激しい
- メンバー数が多く、状況把握が難しい(または、問題が頻発している)
おわり
以上です。
完走したら、また続きを書きたいと思います。