勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

いまさら「マスターアルゴリズム」読んだ #デッドライン読書会

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第47回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。ずっとパタヘネ読んでた。

今回取り上げるのは「マスターアルゴリズム　世界を再構築する「究極の機械学習」」である。なお本来２週間で読み切りたかったのだけれども１週間延長して３週間で読みました。

マスターアルゴリズム　世界を再構築する「究極の機械学習」

マスターアルゴリズム　世界を再構築する「究極の機械学習」

Amazon
The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World (English Edition)

The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World (English Edition)

Amazon

原著が2015年ということでだいぶ古い本ではあるのだが、ビル・ゲイツがAI分野の必読書と言っていたという話もある。

というわけで読んでみたら大変面白い本であった。

「マスターアルゴリズム」の感想

まず先に言っておくと、簡単な本ではないと思う。本書では数式やコードは一切出てこないのでその種のスキルは無くても読めるが取り扱っている内容そのものは難しいからだ。
ちなみにわたしは現在仕事でAIを取り扱っているわけではない。ただし学生時代（90年代）にニューラルネットと遺伝的アルゴリズムを取り扱っていたことはあるのでベースの知識は少しある。また趣味でAI関連の技術書を読んだことはある。そういう前提で読んだ感想は以下の通り。

  • 数式やコードなしで、ステップ・バイ・ステップ式に、おそらく執筆時点の先端的なAI分野まで説明されるという本である
    • というか、説明できることがすごい。著者の教養がものすごい高い。すごい説明力が発揮されている
    • ネタバレになってしまうので書かないけど、何度も目から鱗が落ちるような比喩があった
    • また、ニヤリとするどころか爆笑してしまう文芸作品のパロディなども多数あって、楽しい箇所も多い
  • 著者はサイエンスライターではなく、第一線の研究者である。強い
    • そういう意味では終章付近の「どんな目的にでも適用できる究極のアルゴリズム＝マスターアルゴリズム」に関する議論は、著者の想定や予想となっている

本書を読むことで、機械学習の歴史と主要な技術の概略、理屈は理解できるようになる。少なくとも自分にとっては解像度が上がったように思う

参考リンク

さて、次は何を読もうか。最近オライリー系の本を読めていない気がするので、このあたりを候補にしたい

あとはこれも気になっている

要件定義ではHowじゃなくてWhatを語れという話

Professional Engineer Project Management Requirement Developments

ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ／ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれども、そういえばちゃんとまとめたことがなかったと思い、まとめてみることにしたという記事。

要件定義ではHowじゃなくWhatを語れ

どういう意味かというと、具体的にはこんなことを言いたいのだ。

  • いきなり要件定義段階で、構築予定ソフトウェアの画面など機能の話をするな
  • ユースケースもしくはそれに類する形で要求を整理しろ
  • ユーザーの要求を動詞で整理しろ

なお現代的にはユースケースより、ユーザーストーリーといった形で整理するのが良いかもしれない（これは読者の属するドメインによる）。

なぜHowを語るべきではないのか

要件定義でHow、すなわちソフトウェアの画面や機能を書いてしまうことの弊害はいくつかある。いちばんの問題は「それが要求ではない」という点である。またHow（機能）だけが一人歩きして、それを誰がなんのために利用するのかといった情報が失われてしまうという問題があると思っている。

名著「ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)」（残念ながら絶版である）では以下のような説明がある。

要求文書の中にインターフェイスを操作するユーザーの動きを記述すると、3つの問題点が出てきます。

  • 文章が不必要に長くなる。
  • 要求が不安定になる。つまり、ユーザーインターフェイス設計に対するわずかな変更でも、「要求」自体を変更しなければならなくなる（これはそもそも要求ではない）。
  • UI設計者の仕事を奪うことになる。UI設計者に仕事をまかすべきである。

「ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)」、第20章 個別のユースケースについてのメモ　メモ7：GUIを排除する、より

ソフトウェア要求に関する歴史的な経緯

そもそも論で太古のソフトウェア要求は機能を中心に語られていたという。その後、ビジネスアナリストが「シナリオベース」の要件分析を始め、それが現代のユースケースやユーザーストーリーベースの要件定義に変化してきたと言われている。歴史を逆行すべきではないだろう。

アナリストは、ユーザー要求の引き出しに、長いこと、使用シナリオを使ってきた。この使用状況中心の観点をまとめたのが、要求モデリングへのユースケースアプローチである。さらに最近、アジャイル開発の支持者が「ユーザーストーリー」のコンセプトを導入した。ユーザーストーリーは、簡潔な記述でユーザーニーズを伝え、詳細を具体化するための話し合いの出発点となるものである。
ユースケースとユーザーストーリーはともに、要求引き出しのプロダクト中心の観点を切り替えて、ユーザーが何を成し遂げる必要があるかという話し合いに移すものである。ユーザーに、システムに何をしてほしいかと聞くものではない。このアプローチは、システムを使用してユーザーが実行するタスク、あるいはステークホルダーに貴重な成果をもたらすユーザーとシステムの相互作用を記述することを意図している。ビジネスアナリストがこれを理解すると、使用シナリオを実行できるようにするために、システムに実装しなければならない機能を導き出すことができる。また、その機能が正しく実装されたかどうか検証するためのテストにも役立つ。使用状況中心の引き出し戦略をとれば、他のどんな技法を使用するよりも、プロジェクトの多くのクラスのユーザー要求を深く理解することができる。

「ソフトウェア要求　第3版」第8章 ユーザー要求の理解、より

例外もある

なお、この原則には当然のことながら例外もある。「ソフトウェア要求 第3版」にも書かれているが、構築するソフトウェアのタイプによっては必ずしも該当しない。バッチシステムや計算集中型のシステム、データウェアハウスなどのアプリケーションや、組込システムやリアルタイムシステムである。これらのシステムはユーザとシステムの相互作用が要求の焦点ではないからである。

ソフトウェア要求　第3版

ソフトウェア要求　第3版

Amazon
ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

Amazon

「エンタープライズ設計」を再読した #デッドライン読書会

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第46回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。ずっとパタヘネ読んでた。

さて、パタヘネの呪縛から解き放たれたところで、今回取り上げるのは「Web世代が知らないエンタープライズシステム設計」である。

Web世代が知らないエンタープライズシステム設計

Web世代が知らないエンタープライズシステム設計

Amazon
実は5月頃に読了していたのだが、一緒にデッドライン読書会をやっている84zumeさんからの要望もあり再読したもの。いろいろな意見があると思うのだけれども、いろいろな意見を引き出してもらうような本だと思うので異論反論があるのは正しい読み方だと思っている。

「エンタープライズ設計」とは

さて、本書が取り扱っているエンタープライズ設計とは何だろうか。本書の「はじめに」冒頭では以下のように説明されている。

エンタープライズシステム、つまり企業情報システムを設計、開発、運用するための本質的で枯れないノウハウがある。例えば要件定義を含む業務設計やデータベース設計、運用設計などだ。

Web世代が知らないエンタープライズシステム設計、はじめに より

抽象的～。

私の解釈ではあるが、

  • 試行錯誤の（アジャイル開発的な）アプローチが取れない、もしくは取りにくい
  • 設計等については（最適かは別として）正解が存在して、それを満たさなければソフトウェア開発の失敗と見なされる

というのが、「エンタープライズ設計」の問題の中心だろう。「作ってみました、動かしてみてダメだったら修正します」が通用しない、企業ソフトウェアの設計に関する話である。

ただ「エンタープライズ設計」の要所はまだ曖昧で、体系化されていないのも事実である。
というわけで本書は、このあいまいな「エンタープライズ設計」ということに対して、一家言あるエキスパートがあーだこーだ言うエッセイ集という構成になっている。

対話する本

さきほどエッセイ集という表現をしたが、一定以上複雑な問題に対して識者が様々な意見を表出するというのは技術書の一つの形式である。有名なものだと以下のようなものがある。

この種の書籍は「対話する本」である。ゆえに、読者は全ての内容について肯定する必要もないし、反論をしても良い。そういった反応をしながら読むのが良いだろうと思っている。そういう意味では「Web世代が知らないエンタープライズシステム設計」という本は「エンタープライズアーキテクトが知るべき16のこと」というタイトルの本だと思っても良いと思う。

感想：Web世代エンジニアの問題は何か

さて、本書の表題は「Web世代が知らないエンタープライズシステム設計」であるが、ではWeb世代エンジニアの問題とは何だろうか。
本書を読んで私が理解・共感したのは以下の点である。

  • ソフトウェア構造の抽象的な分析（モデリング）の軽視もしくは不足がある
  • ユーザー中心設計と、実装技術周辺に着目しすぎている

この辺りに関して筆者が懸念しているのが、昨今のドメイン駆動設計（DDD）の盛り上がりである。エリック・エヴァンスが提唱したDDDはもともと、「適用分野に関する知識」を対象のソフトウエアに組み込むための、モデリングを核とする汎用的な枠組みだった。言ってみれば当たり前の指摘ではあったのだが、実装技術ばかりに注目しがちな技術者に良いアドバイスになると筆者も共感したものだ。　ところが日本におけるDDDは、いつの間にか「オブジェクト指向プログラミングの現代的なスタイル」とみなされてしまう。その過程で「適用分野に関する知識」の重要性は、そういった知見を持つ「ドメインエキスパート」との協働の必要性にすり替えられた。　適用分野の専門性がなくても、それを有する専門家と協働すれば良いソフトウエアが出来上がる──こう考えているとしたら幻想である。

Web世代が知らないエンタープライズシステム設計、第2章 本当は怖い「プログラミングの学び過ぎ」、実装オジサンを避ける必須知識はこれだ　より

ユーザーヒアリングは現場の生の意見を聞く場だが実社会は矛盾と不条理にまみれたカオスである。カオスをフィルタリングして語れるユーザーがいればよいが、真面目で有能なユーザーであればあるほど、あらん限りの例外事象をあげ、システム側の担当者はけむに巻かれてしまう。　そこに何事にも手を抜かないことを取り柄としているシステム開発会社のエンジニアが登場するとメリハリなくすべてをシステムに落とし込もうと頑張ることになる。さてどんなモンスターが出来上がるのだろうか

Web世代が知らないエンタープライズシステム設計、DX時代にUI偏重は危険、ユーザーヒアリングのまんま設計するな！　より

このあたりの問題意識についての共感は多いのではないか。
また逆に、「オジサンはわかっていない」という反論もあるのだろう。ただ、そういった意見を考えることも重要だと思う。興味があったらぜひ手に取って読むとよいだろう。

関連記事

本書では技術継承についての言及もあるのだけれども、それについて興味があれば過去に書いた以下の記事をどうぞ。
agnozingdays.hatenablog.com

パタヘネを読む４（付録Ａ、Ｂ） #デッドライン読書会

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第45回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

さて、ここしばらくずっと取り組んできた通称パタヘネすなわち「コンピュータの構成と設計　MIPS Edition　第6版　上」の印刷された部分を読んでいくシリーズもいよいよ4スプリント目である。というわけで、付録Ａ、Ｂを読んだというか目を通した・・・

コンピュータの構成と設計　MIPS Edition　第6版　上コンピュータの構成と設計　MIPS Edition　第6版　下

ちなみに本書の恐ろしいところは、印刷されていない付録が大量にあるというところだ。付録部分もキッチリと翻訳されていて面白そうなのだが、たぶんもう1冊分くらいあるぞ。これはおいおい読んでいきたい。

パタヘネ全体の感想

一般的には難しすぎる本だと思う。読んだ自分を褒めたい。大学の授業でサポートとプレッシャーを受けながら学びたい本。

本書はわたしのような普通のソフトウェア開発に関わる人間にとっても、必読書とはとても言い難い。後輩や同僚に勧めることもないだろう（自慢はするかも）。先人たちの知恵と工夫で、本書に書かれているような基礎を知らなくても平均的なソフトウェア開発をするのは難しくなくなったのだ。

とはいえ、それはあくまで平均的なソフトウェア開発の場合であって、特にパフォーマンスを中心としたシビアな要求やトラブルが発生した際には本書で学んだ知識が活用されることはあると思う。また、新技術に触れる際にも本書の知識は大きく役立つだろう。

とはいえ、難しい。
hak & tomzohちゃんねる の動画が更新されて、復習できるといいなぁ……

今回読んだ範囲の感想

A. アセンブラ、リンカ、SPIM シミュレータ

B. 論理設計の基礎

次回

これでパタヘネを読むシリーズは終了である。次は読む本は何にしますかね（そろそろ、秋の情報処理技術者試験が近くなってきているのだけれども）

おっさんエンジニアの放送大学教養学部に入学記録5（3年目前期終了）

Study

2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。3年目前期が終わったので感想をまとめておく。

目次

3年目前期に履修した科目

何度か書いたけれども卒業を目標にしていないので、半期に2科目受講＋1科目聴講を目安にしている。前期は情報処理安全確保支援士の勉強も並行していたので聴講はパスしたけど、今期は元のペースに戻した。というわけで合計3科目を学んでいたことになる。
放送大学に入学した目的は人文系の教養力アップなので、芸術系、哲学系、文化人類学系を中心に選ぶようにしている。

西洋音楽史（’２１）

西洋音楽史〔新訂〕 (放送大学教材)

  • ラジオ講座なので映像はなし。講義の中で、さまざまな楽曲の紹介もされる。テキストには譜面が提示されることも多く、譜面を眺めながら曲を聞いてゆく。楽譜が読めて良かった。
  • あらたな良い音楽に出会うというより、知っている様々な楽曲、作曲家、ジャンルについて背景を深く知っていくことを目的とした内容となっている。これが個人的には良かった。知識の解像度が上がった。
  • 範囲については古代ギリシャから19世紀末までがカバーされている。
  • もともとクラシック曲を聞くことも好きだったけれども、より楽しめるようになってよかった。

レジリエンスの諸相（’１８）

レジリエンスの諸相―人類史的視点からの挑戦 (放送大学教材)

  • レジリエンスというテーマで分野学科横断的な講義が集められていて、知的好奇心が満たされる良い講座だった。私は科目履修しているのでテキストも読みながら受講したが、テキストが無くても十分に学べそうな印象。興味がある人は放送でチェックしてみると良いかもしれない。
  • エンジニアリングの領域でも、ビジネスでも「レジリエンス」という単語はよく耳にするし、場合によっては重要なテーマになることもある。この「レジリエンス」とは何かということについてよくわかる。様々な学問分野において、レジリエンスの定義はさまざまであるということ、そして研究ではどのように考えられているのかを把握できるのが良い講義だった。
  • 一番なるほどと思ったのは、災害時のレジリエンスモデル（フレームワーク）で、これはもう少し整理してブログに書いておきたいところ。いろいろな応用が効きそう。

心理学概論（’１８）

心理学概論 (放送大学教材)

  • この科目のみ、履修ではなく聴講（テキストだけ購入して講座を視聴のみ）したもの。放送大学の「心理と教育」コースの導入科目である（私が所属しているのは「人間と文化」コース）。
  • 導入科目ということで学生が今後どの分野を学んでいくか判断できるように、心理学の各分野を紹介していくという構成なのだが、これが自分にとっても大変に良かった。
  • 仕事においても、さまざまな場所で「心理学」的な要素は大きく関わってくる。エンジニアの立場で身近なのはメンタルヘルスの問題である。またそれ以外にも心理的なバイアスだったり、教育・育成という話も関わってくる。そういった身近な心理学的な話題が、実際には学術的にどう取り扱われているのかということが総合的にわかる講座だった。
  • 文化心理学の説明は特に興味深かったので、ブログ記事を別に書いていた。

来期（3年目後期）の予定

以下を履修予定

うーん、あと実は数学関連の科目も見たいのだけど、10月に情報処理技術者試験も受ける予定なので、それ以降にスタートするかなという感じ。

これまでの記録

  1. おっさんエンジニアの放送大学教養学部に入学記録4（2年目後期終了） - 勘と経験と読経
  2. 若手が育たないとか言っている暇はもう無い - 勘と経験と読経
  3. コンフォートゾーン外の学びの為にエンジニアが放送大学に入学してみた - 勘と経験と読経
  4. アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了） - 勘と経験と読経
  5. おっさんエンジニアの放送大学教養学部に入学記録2（1年目後期終了） - 勘と経験と読経
  6. 教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
  7. おっさんエンジニアの放送大学教養学部に入学記録3（2年目前期終了） - 勘と経験と読経

パタヘネを読む３（第５章〜第６章） #デッドライン読書会

book Professional Engineer

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第44回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

さて、前回、前々回に引続き。通称パタヘネすなわち「コンピュータの構成と設計　MIPS Edition　第6版　上」を読んでいく。1スプリントで2章ずつ読んでいく計画で、今回は3スプリント目である。
コンピュータの構成と設計　MIPS Edition　第6版　上コンピュータの構成と設計　MIPS Edition　第6版　下

パタヘネ第５章〜第６章を読んだ感想

超難しい。読んでいるというより「目を通している」という感覚。
前回、前々回同様、各章の末尾の演習問題はスキップ。
hak & tomzoh - YouTubeで復習したい。

５章 容量と速度の両立：記憶階層の利用

  • 基本的にはメモリの話。改めてコンピュータに関するメモリの話を総合して見てみると、様々なレベルの抽象化によってコンピュータの性能が確保されているというのがよくわかる。
    • 具体的にはキャッシュ、仮想記憶、そして仮想マシン。
  • いわゆるオープン系アーキテクチャにおけるVMのサポートはまだ発展途上というのは、あまり意識していなかったので興味深い話だった。

残念ながら、デスクトップおよびPCをベースにしたサーバーのアプリケーションでVMが検討されるようになったのは、ごく最近のことである。そのため、デスクトップやサーバーの命令セットは、仮想化をほとんど考慮に入れずに開発された。x86アーキテクチャに加え、ARMv7やMIPSなどのRISCアーキテクチャも、例外ではない。
（中略）
1970年代のIBMメインフレームやVMMと同じくらい21世紀の仮想マシンが効率的になるためには、どのくらいの期間がかかるだろうか。いずれも興味深い点である。
（5.6 仮想マシン より）

６章 クライアントからクラウドまでの並列プロセッサ

  • 出だしからロマンチックな章！

コンピュータ・アーキテクトはコンピュータ設計上の見果てぬ夢、黄金郷（エルドラド）を長く追い求めてきた。それは、既存の小型コンピュータを多数接続するだけで、強力なコンピュータを実現するという発想である。
（6.1 はじめに より）

Mooreの法則の鈍化、Dennardのスケーリング則の終了、Amdahlの法則に基づくマルチコア性能の実際的な限界が相まって、性能およびエネルギー効率を改善するのに残された道はドメイン固有アーキテクチャ（DSA）しかないという考えに、業界の主流は傾いた。
（6.7 ドメイン固有アーキデキチャ より）

このように極端に大規模なWSC（ウェアハウス・スケール・コンピュータ）は、1970年代のスーパーコンピュータの原題の子孫である。したがって、Seymour Crayは今日のWSCのアーキテクトの父と言えるだろう。
（6.8 クラスタ、ウェアハウス・スケール・コンピュータおよびその他のメッセージ交換型マルチプロセッサ より）

  • この章を読むと、FPGAの勉強も必要という気がちょっとだけしてくる（本章ではPFGAはほとんど扱われていないが、次のスプリントで読む付録B章で扱われているようだ！）

次回

次の2週間は、付録の２章を読む予定。心折れずに完走できるのだろうか……

  • A.アセンブラ、リンカ、SPIMシミュレータ
  • B.論理設計の基礎
    • FPGAも含まれる

データフローダイアグラム（DFD）は要件定義では有用ではない

Professional Engineer Requirement Developments

タイトルは言いすぎかもしれないけど、最近のソフトウェア開発においてDFDを書くことはあまり合理的ではないという話（例外はある）。最近DFDについて相談されたので調べたり考えたりしたことを書く。

データフローダイアグラム（DFD）について

構造化分析モデルの一つで（調べていてびっくりしたのだけれども）トム・デマルコが1979年に書いた「構造化分析とシステム仕様<新装版>」が初出のようだ。えっ、まじか。この本は読んでません。

要件定義の信頼できるテキストである「ソフトウェア要求　第3版」の説明を引用するとこんな感じ。

DFDは、システムの変換プロセス、システムが操作するデータや物理的なモノの集合（ストア）、プロセスとストアと外界の間のデータやモノのフローを明らかにする。データフローモデリングは、システム分析に対して機能分解アプローチをとり、複雑な問題を段階的に詳細化していく。これは、トランザクション処理システムや他の機能集約型のアプリケーションに有効である。
（「ソフトウェア要求　第3版」 12.4 データフローダイアグラム　より引用）

すでにここでも注目すべき記載がある。「トランザクション処理システムや他の機能集約型のアプリケーションに有効である」である。つまり、そうではないアプリケーションの分析には向いていないということだ。

DFDの問題点

（この本もちゃんと読んでいないのだけど）「ユースケース導入ガイド―成功する要求収集テクニック」ではDFDには以下の問題があると指摘している。まあユースケースを推奨する本に書かれていることではあるのだけど。

  • DFDは技術者にとっては便利だが、ユーザを混乱させる傾向がある
    • システムとユーザーの責任の境界線があいまい
    • ユーザーが読みこなすのに十分な量以上の情報が含まれる

要求リストと同様に、DFDは要求分析者の道具箱から取り除くことをお勧めします。DFDは、この時点では必要ない多くの技術的要素を要求ダイアグラムに導入してしまう。DFDは、ユースケースや、UML（Unified Modeling Language）のクラス図、シーケンス図、ステートチャート図、アクティビティ図に置き換えることができます。
（ユースケース導入ガイド―成功する要求収集テクニック）

まあ実際にDFDを扱ったことのある人であれば、わりと同意できる内容だと思う。DFDはある種の問題に対しては有効な分析手法だが、一般的なソフトウェアの要件定義には極めて不向きなのである。しかしそれに気づくのは往々にして大量のDFDを書いた後なのだが。

現代的な要件定義ガイドのモデル成果物にはDFDは掲載されていない

無料で入手できる要件定義ガイドとしては、IPAが公開しているものがある（PDFがIPAのサイトからダウンロード可能である）
ユーザのための要件定義ガイド第2版

このガイドが取り扱っている要件定義ドキュメントの体系にもDFDが存在しないことを確認すべきである（なお正確には業務フローを表現する手法としては紹介されている）。
というわけで、現代の一般的なソフトウェア開発の要件定義においては、DFDを書くというのは悪手であると言えるだろう。

DFDを書くべきケースはあるのか？

冒頭で紹介した「ソフトウェア要求　第3版」では「トランザクション処理システムや他の機能集約型のアプリケーションに有効である」とあったので、ある種のシステムにおいてはDFDが有効な場合も存在する。自分の経験では、以下のようなシステムの検討においては有効だと考える。

  • ユーザーのユースケースがほとんど存在しない自動化システム
  • データウェアハウスに類する、ETLのようなデータパイプラインが主たる機能である

そんなシステムばっかりではないので、やっぱり基本的にはDFDは書かない前提にしたほうが良さそう