賢くなりたいトイプードルの日記

データサイエンス系の話をメインにしていきます

はてなブログでLaTexを使って数式を書く方法

LaTexで数式を表示させるのに30分くらい引っかかってしまったが、

  1. デザイン設定でMathJaxのCDNのリンクURLを読み込む
  2. 編集をMarkdownモードに切り替える
  3. 数式を書く

の順番でやっていけば良いことがわかった。

デザイン設定でMathJaxのCDNのリンクURLを読み込む方法

MathJaxのCDNリンクは

 <script>
MathJax = {
  tex: {inlineMath: [['$', '$'], ['\\(', '\\)']]}
};
</script>
<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js"></script>

をコピーして、ペーストすればいい。

どこにペーストすればいいかと言うと、

  1. ブログ管理画面の左サイドバーの「デザイン」をクリック
  2. 左サイドバーの「カスタマイズ」アイコンをクリックしてタブを切り替える
  3. リスト内の「記事」→ 「記事下」の入力欄にペースト

でOK。 これだけだとスマホで数式が表示されないので、 「デザイン」→ 「スマートフォン」→「記事上下のカスタマイズ」→「PCと同じHTMLを表示する」にチェック を行う。

編集をMarkdownモードに切り替える

こちらは以下の手順でできる

  1. ブログ管理画面の左サイドバーの「設定」をクリック
  2. 基本設定タブの、編集モードでMarkdownモードを選択

数式を書く

あとは記事内で

$$ \frac{1}{x} $$

などと書き、プレビュータブをクリックして

$$ \frac{1}{x} $$

と表示されていればOK

インラインで数式を書きたい場合は、\$と\$で囲えばOK。

てすと$\frac{1}{x}$てすと

てすと$\frac{1}{x}$てすと

beginで始まるものは、pタグで囲むと表示できた。

例：テイラー展開

<p>
\begin{eqnarray}
f(x) &=& \sum_{k=0}^{\infty} \frac{f^{(k)}(a)}{k!}(x-a)^k \\
&=& f(a) + \frac{f'(a)}{1!} (x - a) + \frac{f''(a)}{2!} (x - a)^2 + … + \frac{f^{(k)}(a)}{k!} (x - a)^k + …
\end{eqnarray}
</p>

\begin{eqnarray} f(x) &=& \sum_{k=0}^{\infty} \frac{f^{(k)}(a)}{k!}(x-a)^k \\ &=& f(a) + \frac{f'(a)}{1!} (x - a) + \frac{f''(a)}{2!} (x - a)^2 + … + \frac{f^{(k)}(a)}{k!} (x - a)^k + … \end{eqnarray}

おしまい

Flutterに入門

C++ dart firebase Flutter java javascript

Flutterをとりあえず環境構築したり触ってみた。今の理解はこんな感じ

  • Dartという言語が強くて、iOS・Androidに対応
  • ゲームにはあまり使われてないっぽい
  • IDEとしてAndroid Studioがよく使われる
  • cocoapodsというrubygemを使ったりする
  • flutterはSDK（開発フレームワーク）
  • Googleのやつ
  • flutterとgo言語は連携すると強くなるらしい
  • firebaseがよく使われるっぽい

知りたいこと

参考文献

ホットリロードとは

（https://flutter.dev/docs/get-started/test-drive）

Flutter offers a fast development cycle with Stateful Hot Reload, the ability to reload the code of a live running app without restarting or losing app state. Make a change to app source, tell your IDE or command-line tool that you want to hot reload, and see the change in your simulator, emulator, or device.

Flutterは、ステートフルホットリロードを備えた高速開発サイクルを提供します。これは、アプリの状態を再起動したり失ったりすることなく、実行中のアプリのコードをリロードする機能です。アプリのソースに変更を加え、IDEまたはコマンドラインツールにホットリロードすることを伝え、シミュレーター、エミュレーター、またはデバイスで変更を確認します。

要するに、一回雷マークを押せば、毎回デバッグボタンをクリックしなくてもシミュレータやエミュレータに変更が反映される機能のこと。

ネイティブのARMコードにコンパイル？

（https://forest.watch.impress.co.jp/docs/news/1334821.html）

ARMアーキテクチャは消費電力を抑える特徴を持ち、低消費電力を目標に設計されるモバイル機器において支配的となっている。本アーキテクチャの命令セットは「（基本的に）固定長の命令」「簡素な命令セット」というRISC風の特徴を有しつつ、「条件実行、定数シフト/ローテート付きオペランド、比較的豊富なアドレッシングモード」といったCISC風の特徴を併せ持つのが特徴的だが、これは初期のARMがパソコン向けに設計された際、当時の同程度の性能のチップとしてはかなり少ないゲート数（約25,000トランジスタ）で実装されたチップの多くの部分を常に活用する設計として工夫されたもので、回路の複雑さを増さないという方向性だというように見れば、CISC風の特徴というよりむしろRISC風の特徴とも言える。このような設計が、初期の世代の実装において、（性能の割に）低消費電力、小さなコア、（RISCとしては）高いコード密度といった優れた特性に結びつき、広く普及する原動力となった。

要するに、Flutterはネイティブアプリに対してエネルギー効率が良いARMアーキテクチャを使うということ。

2D-GPU-accelerated-APIs ?

Android 3.0（API レベル 11）から、Android 2D レンダリング パイプラインはハードウェア アクセラレーションをサポートしています。つまり、View のキャンバス上で行われる描画オペレーションはすべて GPU を使用します。ハードウェア アクセラレーションを有効にするために必要なリソースが増えるため、アプリの RAM 使用量が増えます。

https://developer.android.com/guide/topics/graphics/hardware-accel?hl=ja

IntelliJプラグイン & IDEデバッグ？

AppCodeもAndroid Studioも根っこはIntelliJです。

IntelliJ IDEA（インテリジェイ アイディア）とは、2001年にチェコにあるJetBrainsが開発したIDEのことです。

IDEとは、プログラミングするときに必要な機能を1つにパッケージングしたソフトウェアのことです。

IntelliJは、Javaの開発をサポートするために作られたIDEです。

Javaで最も人気なIDEは2016年までEclipseでしたが、現在はIntelliJがシェアを抜いています。

IDEがintegratedというのは、エディタ上でデバッグができるから。

IntelliJがもともとJAVAの開発をサポートすることが目的で、Android Studioの根幹はIntelliJだから、Android StudioにはJAVAが必要なんだろうと、とりあえず理解

JAVA？C++ ? JavaScript ?

Flutterは主にC++とDartとの2つの言語によって記述されている。

エンジンとしてC言語とかC++を使っていて、DartがJavaScriptの後継言語を目標として他の言語の良い点を参考に開発された言語だから、書き方はJavaScriptに似ている。void main()とか@overrideとかが出てくるから、ちょっとC言語とかJAVAっぽくもある。AndroidStudioを使うから環境構築にJAVAのセットアップしとかないといけない、みたいな感じととりあえず理解。

Flutterの構成

スタック

flutter.io

Flutterは大きく分けると、OSに近い方から

  • Embedder
  • Engine
  • Framework

の3つの層になっています。

アプリ開発者が触るのは基本的に最上層のDartのみです。EngineやFrameworkなどOSに近い方は、画面に何をどのように表示させるかというところなど、パフォーマンスに関係しています。

ちなみにFlutter Webについては、Dart言語をJavaScript言語に変換してブラウザ上で実行しているため、Flutter Engineは利用しておらず、全く仕組みが異なります。

Flutter Engineの役割は簡単に説明すると以下の通りです。

ちなみに、Embedder部分の役割は各種プラットフォーム上で動作させるための繋ぎ込みのAPIが定義され提供されています。この部分をプラットフォーム毎にポーティングします。

Flutter Engineは4スレッドで動作します。Flutterの公式ドキュメントの中では、Flutter Engineのレイヤではスレッドという表現を使わずに、Task Runnerという表現を使っています。実際のスレッド自体の作成や管理は下のレイヤのEmbedder (後述のプラットフォーム依存部分) で対応しており、そこから提供される枠組みの中でTask Runnerを動かしています。

そして、Engineには以下の4つのTask Runnerが存在し、Flutterアプリケーションが動作する土台の機能をshell(Linuxなどのコマンドのshellではなく、グラフィック機能を提供するシェル)として提供します。

Flutterは、各プラットフォーム上で基本的に以下の4スレッドで動作します。

スレッド (タスクランナー) 名用途
Platform Task Runnerいわゆるメインスレッドで、ユーザ操作やネイティブからのメッセージをハンドリングし、その他のTask Runnerとの受け渡しをするスレッド
UI Task RunnerDart VMが実行されるスレッド。Flutter Engineに渡すLayer Treeを生成するまでを担当する、Dartのコードが動くスレッド
GPU Task RunnerGPU処理に関わるつまり、Skiaを利用してOpenGLやVulkanなどでGPUを利用して最終的に描画する処理に関わるスレッド
IO Task Runner画像ファイルのデコードなど、I/Oアクセスを伴う時間がかかる処理を行う専用のスレッド

図示すると以下の様になります。

Flutterアプリ開発の全体像

ネイティブアプリ開発には

を使います。クロスプラットフォームのフレームワークは

などがあります。

Flutterは、dartという言語で書いていきますが、dartは

であり、独自のレンダリングエンジンを使っています。（C++）

Flutterには多くのWidgetが用意されており、大きく分けて二つあり、StatelessWidgetとStatefulWidgetです。

アーキテクチャは四つあり、

画面ごとにモデルがあるというのは、画面とモデルがセットになっているということ。

たとえばこんな感じ

クリーンなアーキテクチャとは、プロジェクトの成長に合わせて理解しやすく、変更しやすいようにプロジェクトを編成することを指します。これには意図的な計画が必要です。大規模プロジェクトを保守性を保ちながら構築する秘訣は、ファイルまたはクラスを他のコンポーネントとは独立して変更できるコンポーネントに分割することです。

https://pusher.com/tutorials/clean-architecture-introduction/

ドメイン駆動型 + オニオンアーキテクチャなどが知られていますよね。

Providerは、完全な依存関係インジェクションソリューションです。一方、ScopedModelは、ModelクラスとnotifyListeners()を使用して、反応性という点では同じ機能を提供します。Providerは依存関係インジェクションソリューションであり、非常に強力なプロバイダタイプを備えており、例えばストリームの管理のような定型的な処理を行うことができます。

スコープモデルは、特に依存性注入のためのget_itと相まって、依然として強力です。私がやったように、古いアプリではScopedModelを使い続け、今後はプロバイダを使うということもできます。特にScopedModelに欠けていたものを知っていれば、それはとても素晴らしいことです。

https://www.reddit.com/r/FlutterDev/comments/brz0nu/scoped_model_vs_provider/

環境構築

（https://www.youtube.com/watch?v=kpvVENfDCRc&ab_channel=Flutter%E5%A4%A7%E5%AD%A6）

環境構築の流れとしては、

  1. Flutter SDKをダウンロード
  2. パスを通す
  3. Android Studioをダウンロード&プラグイン導入
  4. Androidエミュレータ（Androidの仮想デバイス）をダウンロード
  5. Xcodeをダウンロード
  6. iOSのシミュレータをダウンロード

そして、AndroidエミュレータとiOSシミュレータにビルド、デバッグ、開発。

❯ flutter --version
Flutter 2.2.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision f4abaa0735 (6 weeks ago) • 2021-07-01 12:46:11 -0700
Engine • revision 241c87ad80
Tools • Dart 2.13.4

とりあえずFlutterプロジェクトを立ち上げたらこんな感じのツリー構造になっている。

アプリ名フォルダ直下のlibフォルダにmain.dartがあり、これを見てみると、

import 'package:flutter/material.dart';

// Flutterアプリが起動すると、下記のMyAppクラスをもとにそのWidgetツリーを解釈してUIが表示される
// voidはただ処理をするだけで「何も値を渡すことができない」ことを明示している
void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
　// overrideアノテーションでStatelessWidgetクラスのbuildメソッドを上書き
  @override
  Widget build(BuildContext context) {
　　 // MaterialAppはこのアプリ全体の根本（Scaffoldは一つのぺージの根本）
　　 // 根本部分でMaterialAppを返してマテリアルデザインのアプリを作る
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // ①
        primarySwatch: Colors.blue,
      ),
　　　 // home にStatefulWidgetを継承したMyHomePageを指定。これがアプリ起動直後に表示されるページ
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
　// コンストラクタ（superで親クラスのコンストラクタを呼び出す）
  MyHomePage({Key? key, required this.title}) : super(key: key);

　// ②

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

// Stateは状態を保持・更新する機能と、
// StatelessWidgetと同様にbuildメソッドでWidgetツリーを返す機能がある
// buildメソッドを持つのがStatefulWidgetではなくStateとなっている理由は、
// StatefulWidgetを継承したWidgetを扱いやすくするため
class _MyHomePageState extends State<MyHomePage> {
  // このようにクラスのフィールドとして状態を保持する
  int _counter = 0;
　// 更新

　// _counter++; を実行して値の更新し、それをUIに伝えるためにsetStateで囲む
　// Flutterフレームワークに対する「次の画面更新タイミングで今のStateの状態を元にUI更新せよ」という命令
  void _incrementCounter() {
    setState(() {
      // ③
      _counter++;
    });
  }

　// このbuildメソッドの結果はUI全体に相当する
  @override
  Widget build(BuildContext context) {
    // ④
　　// Scaffoldはこの全体の根本（MaterialAppはこのアプリ全体の根本）
    return Scaffold(
      appBar: AppBar(
        // ⑤
        title: Text(widget.title),
      ),
      body: Center(
        // ⑥
        child: Column(
          // ⑦
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: Icon(Icons.add),
      ), // ⑧
    );
  }
}

コメントアウトした①〜⑤のところには英文が書いてあったので、訳してみました。

① アプリのテーマ部分。'flutter run'コマンドでアプリを起動されて、ブルーのツールバーがあるアプリが表示される。それから、アプリをシャットダウンすることなく、下に書いてあるprimarySwatchをColors.greenに変えて”ホットリロード”すると、カウンターが0に戻ってない、つまりアプリが再起動していないことがわかる。

②このウィジェットはアプリのホームのページ。ステートフルとは、見た目に影響を与えるフィールドを含むStateオブジェクト（以下に定義）を持つことを意味する。このクラスは親（ここではAppウィジェット）から提供される値（ここではtitle）を持ち、これはStateのbuildメソッドで使用される。Widgetサブクラスのフィールドは常に "final "を前につける

③このsetStateを呼び出すと、Flutterフレームワークに、このStateに何か変更があったことを伝え、更新された値を表示に反映させるために、以下のビルドメソッドを再実行させます。setState()を呼び出さずに_counterを変更した場合、ビルドメソッドは再び呼び出されないので、何も起こらないように見えます。

④このメソッドは、例えば上記の_incrementCounterメソッドのように、setStateが呼ばれるたびに再実行される。Flutterフレームワークはビルドメソッドの再実行を高速化するように最適化されており、ウィジェットのインスタンスを個別に変更するのではなく、更新が必要なものを再構築すれば良いようになっている。

⑤ここでは、App.buildメソッドで作成したMyHomePageオブジェクトから値を取得します。App.buildメソッドで作成したMyHomePageオブジェクトの値を取得し、それを使ってappbarのタイトルを設定しています。

⑥Centerは、レイアウトウィジェットです。1つの子を受け取り、親の中央に配置します。

⑦Columnは、レイアウトウィジェットでもあります。子のリストを受け取り，それを縦に並べます．デフォルトでは，子の水平方向の大きさに合わせて自身の大きさを調整し，親と同じ高さになるようにします．
デバッグペイント」を実行すると（コンソールで「p」を押すか、Android StudioのFlutterインスペクタで「Toggle Debug Paint」アクションを選択するか、Visual Studio Codeの「Toggle Debug Paint」コマンド）、各ウィジェットのワイヤフレームが表示されます。
カラムには、自身のサイズや子の配置を制御する様々なプロパティがあります。ここでは、mainAxisAlignment を使用して子を垂直方向にセンタリングしています。Column は垂直方向に配置されるので、ここでの主軸は垂直軸になります（交差軸は水平方向になります）。

⑧この末尾のコンマは、ビルドメソッドの自動フォーマットを整えるためのものです。

環境構築でのエラー

エラー1： AVD Managerの▶︎ボタン（Launch this AVD in emulater）を押したら「Unabel to locate avd」

（解決策）

「File」→「Project Structure」→出てきたウィンドウ左側の「Project」で、「Project SDK」の欄を確認。「＜No SDK＞」となっていて、SDKが設定されていないので、プルダウンからSDKを選択し、決定します。「Android API ##（番号） Platform・・・」を選択してapplyしてOKすると、エラーが表示されなくなる

エラー2： エミュレータを選択したら「emulator error running multiple emulators」

（解決策）

.android/avd/端末名.avd/直下の3つのファイルを削除（cache.img、hardware-qemu.ini.lock、multiinstance.lock） 

「ユーザのための要件定義ガイド 要件定義を成功に導く 128 の勘どころ」をまとめてみた

IPA WBS システム プロジェクトマネジメント 要件定義 設計

システムの設計に関わり始めたので、独立行政法人情報処理推進機構（IPA）の無料PDF 「ユーザのための要件定義ガイド 要件定義を成功に導く 128の勘どころ（2019）」をとりあえず読んでみた。

すぐ使えるように自分用にまとめておく。

こんな内容と対象者の本です。

はじめに

「ステークホルダから要求（What）を漏れなく抽出し、内容を見極め、新たなビジネスやシステムを創造する要件として定義する」という、要件定義の取り組みの重要性がますます増加してくる。

顧客とのつながりによる協働を重視し、IoT やビッグデータ、AI などの比較的新しい技術を活用する「攻めの分野」では産業の垣根を越えて異なる分野の機器やシステムが連携し、目的に応じた「最適な組み合わせ」を導き出して新たなサービスを提供することが求められ、ベンダ企業とともに協力して、多様なデータを収集、蓄積、解析してサービス化するサイクルを廻すことが重要であるが、攻めの分野においては要求のすべてが開発段階で明らかになっていないことが多く、IT システムにはサービス開始してから徐々に明らかになっていく要求への対応が常に求められる。使ってみて初めて分かる本来の要求を要件として的確にシステム化し、迅速にサービスとして市場へ提供し続けることが課題になる。

基幹業務に必要なデータの転送・蓄積・処理を中心とする従来の「守りの分野」では開発完了後に長期間を経過し、システムを構築する際に使用したハード・ソフトや技術が時代遅れになっていった（レガシー化した）システムが増加している。守りの分野における課題であるレガシー化の解消には、開発完了後の長年の保守で蓄積された「業務仕様の理解不足」などによる再構築の難しさという問題がある。下流工程においてコスト超過や稼動延伸などが発生する大きなリスクになるにも関わらず、モダナイゼーション（システム再構築）の実施前にそれを予測することは難しい。いかに安全確実にレガシー化を解消するかはユーザ企業、ベンダ企業が協力して取り組むべき優先課題であり、上流工程においてリスクを明らかにして、対策をユーザ企業とベンダ企業が合意し、ユーザ企業の経営層を含めてリスクヘッジすることが重要になる。

経済産業省が2018 年に公開したデジタルトランスフォーメーションを推進するためのガイドライン （以下、本ガイドでは「DX 推進ガイドライン」と記す）では、DX を「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。」と定義している。

既存 IT システムについて、「DX を実行していくに当たっては、データを収集・蓄積・処理する IT システムが、環境変化、経営・事業の変化に対し、柔軟に、かつスピーディーに対応できることが必要である。」と述べる一方で、その現状について「老朽化・複雑化・ブラックボックス化した既存システムが、DX 推進のための足かせになってい
る。」と述べている。このような状態の既存システムを刷新し、DX にシフトしていくためには、自社の情報資産を正確に把握しなおし、最適な再構築手法を選択することが必要になる。

「ユーザのための要件定義ガイド」および「システム再構築を成功に導くユーザガイド」はDX の 2 つのポイントである「デジタル時代に対応した新たなビジネスモデルの構築」と「DX 実現を困難にしている既存 IT システムの再構築」に強く関連している

第一章 背景

ITシステムは効率化ステージから競争力強化ステージに変わろうとしている。

  1. 置き換えステージ　紙や口頭でのやりとりをITへ
  2. 効率化ステージ　社内事務を効率化
  3. 競争力強化ステージ　売り上げ向上などの競争力強化に積極的活用

各企業がこれからも競争力維持・強化して生き残っていくためには、「デジタル時代に対応した新たなビジネス・モデルの構築と価値の創造」および「DX 実現を困難にしている既存 IT システムの再構築」を行う必要がある

479のプロジェクトを対象に工期遅延の理由を担当者にアンケート調査した結果、工期遅延
の理由の 50％以上が要件定義の問題にあることが分かった。また、同じ調査の中では、予算オーバーや品質不良においても要件定義の問題が原因の多くを占めることが指摘されている。

既存システムが巨大・複雑化しているために、すべての仕様を明確にすることが困難になってきている。また既存システムのドキュメントが陳腐化していたり、業務知識を持っている人が業務部門にすら居なくなってきている。

個別サイロ型システムを全体統合システムに変更するには、システムの刷新が必要であり、多くの費用と期間が必要となるため、全体最適化より各事業部の最適化が最優先され、合意形成が困難を極める。

システム部門は硬直したシステムを柔軟なシステムに刷新したくても、費用、期間も膨大で予算が通らず困っている。

「デジタル時代に対応した新たなビジネス・モデルの構築と価値の創
造」では
・お客様が本当に欲しい価値は何なのか
・お客様のエクスペリエンスとは何なのか
・ビジネスにどういう価値を作るのか
・ビジネス・モデルを変えるために、データをどのように活用すれば良いのか
・デジタル技術を用いて、どのように価値創出に貢献できるのか
などを考えることがベースにある。これは DX 以前の従来の要件定義そのものであり、要
件定義は普遍であることを示している。
「新たなビジネス・モデルの構築と価値の創造」においても要件定義が重要であることを
意味している。

既存システムの刷新に必要なプロセスの一部を以下に示す。
・既存システムの調査・分析
・情報資産の仕分（機能分割・刷新、機能追加、機能縮小・廃棄、現状維持（塩漬け）な
ど）
・再構築目的やビジネスリスクの明確化
・再構築手法の選択、再構築リスクの明確化
・現行業務知識不足への対応
・品質保証（業務継続性の担保、テスト）の検討
・再構築計画と見積り
このように、既存 IT システムの再構築においても上流工程が重要であることを意味している。

要件定義では、以下の 3 つのことを意識して行う必要がある。

１「経営や業務に貢献する要求を見極める　」

いざ要件定義を終えてみると当初の狙いが達成できていない要件定義になっているこ
とがある。上記民法改正にもあるように、契約の「目的」達成を期待できるシステムを作っ
たかどうかが問題になる。また、経営層や業務部門のすべての要求を実現できるわけではな
い。経営層や業務部門との合意形成や積極的な経営層、業務部門の参画などが要件定義には
求められる

２「要求を実現する新しい業務を作り上げる」

多くの場合、経営者の IT 投資の意図は、ビジネスプロセスのチェンジである。新しいビジネスプロセスを明確に定義し業務運用までつなげるのも要件定義の仕事である

３「要求仕様を「抜け」「漏れ」「あいまい」なくシステム開発につなげる」

システム開発の失敗の原因の多くが要件定義にある。その中で
も、要求仕様の決定や漏れが一番多い。要求仕様に抜け・漏れがあったり、あいまいであっ
たりしている。システム開発工程で発覚し手戻りを起こしている。手戻り負荷は、発覚が遅
ければ遅いほど指数的に大きくなると言われている。

非機能要求は、重要なビジネス要求、利用者要求として捉え、経営層や企画部門、利用部門などが上流工程から検討を進めないといけなくなっている。要件定義のパワーの 95％が機能検討にさかれ、非機能の検討は画面レスポンスぐらいという例もあり、非機能の検討が設計工程から検討され、予算やインフラが決まった中で後手に回り苦労するという悪循環になることもある。

上流工程で、非機能としての要求を明確にすることを目的に IPA は「非機能要求グレード」を公開している。非機能要求グレードはインフラを決めるための要求を中心として上流工程でまとめるべきことを列挙してくれている。非機能要求すべてをカバーしているわけではないが、上流工程で決めなさいという示唆は重要であり多く利用されている

要件定義の進め方に工夫が必要になる代表的な3つの場面を挙げる。

  1. 再構築時の要件定義（現状の可視化や理解、変える変えないの判断などを工夫する必要）
  2. 本当に役立つ要求が分からない（重要な要求の見極めやリリースしてから評価するなど、リーンスタートアップやアジャイル開発を前提とした要件定義の進め方が必要）
  3. アイデア創出（デザイン思考や UXアプローチなどアイデア発想アプローチを取り入れた要件定義を実施するなどの工夫が必要）

第二章 要件定義の問題認識

システム開発の超上流フェーズを進めるにあたって気を付けるべき17のポイント

原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則[4] ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則[5] 多段階の見積りは双方のリスクを低減する
原理原則[6] システム化実現の費用はソフトウェア開発だけではない
原理原則[7] ライフサイクルコストを重視する
原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則[12] 表現されない要件はシステムとして実現されない
原理原則[13] 数値化されない要件は人によって基準が異なる
原理原則[14] 「今と同じ」という要件定義はあり得ない
原理原則[15] 要件定義は「使える」業務システムを定義すること
原理原則[16] 機能要求は膨張する。コスト、納期が抑制する
原理原則[17] 要件定義は説明責任を伴う

経営者が意識すべきこと

システム化検討の際に経営者に最も実施していただきたいのは、最上段から見た
判断である。
• 自社を取り巻く経営環境はどのように変化していくのか、
• それに先手を打って競争力をつけるためには自社の商品サービスをどのように
変えていけば良いのか、どこの誰に買ってもらうのか
・顧客、販売店、株主、銀行、協力会社、従業員などの期待は何で、どのように対
応すべきか
これらの項目を最も正しく理解し展望をもっているのが経営者である。

業務部門、情報システム部門から多額の投資を必要とするシステム化提案が提出
されてきた場合には、以下のような考慮ができるのが経営者である。
• 今すぐ実行すべき課題なのか、新しい技術が登場してきて別の方法で解決され
ることは予想できないか
• 自社がなすべき課題の中で、今回のシステム化提案は最優先すべき課題か
• 提案内容は現状の改善にこだわり過ぎていないか、予算をもっと大きく与えれ
ば、もっと素晴らしい方法が提案できるのではないか
• このシステム化を実施するとして、システム化前に解決しておくべき課題はな
いか
• できあがったシステムを使いこなすためには業務部門の運用レベルを向上させ
ておく必要がないか
• 期待する効果を出すためには、何をする必要があるのか
• 効果を出す責任者は誰で、このプロジェクトにどの程度参加しているのか

業務部門が意識すべきことは以下の通り

  1. 経営や業務に貢献する
  2. ビジネスプロセス改革、改善
  3. 業務部門のリーダーシップ
  4. 現行業務、システムの理解
  5. 合意形成
  6. 仕様変更が生じた場合を想定した予算確保

システム部門が意識すべきことは以下の通り

  1. 既存システムの状況の明確化
  2. ベンダ企業の選定
  3. システム部門のパラダイムシフト
  4. プロジェクトマネジメント

ベンダが意識すべきこと

  1. ユーザ企業課題解決貢献
  2. 見積もり
  3. 要求仕様の凍結（要件定義のアウトプットである要求仕様の細部が決まらないとか、仕様が変化し続けるといった仕様未凍結の問題が起こらないようにするために、要件定義の完了時点で要求仕様が凍結できるようにする）

要件定義の問題は以下のように分類される

「現行業務やシステムが分からない」といった『現状把握の問題』
「真の問題・課題が抽出できていない」といった『問題課題抽出の問題』
「経営要求が不明確」「経営に貢献する要求にならない」といった『ゴール明確化の問題』
「要求間の整合性がとれていない」といった『要求の体系化の問題』
「要求に基づき新らたな業務としてうまく具体化できない」といった『要求の具体化の問題』
「要求が膨らみ、捨てる判断が難しい」といった『優先順位付けの問題』
「各ステークホルダに対し要求の合意形成が難しい」といった『要求の交渉の問題』
「成果物に抜け・漏れ・あいまいが存在する」といった『要求の仕様化の問題』
「要件定義の不具合を抽出しきれない」といった『要求の検証の問題』
「システム化仕様が経営や業務にどう貢献するか分からない」といった『妥当性確認の問題』
「要件定義前の構想や企画が不十分」「開始前に必要なステークホルダが洗い出されていない」といった『立ち上げ時の問題』
「要件定義で何をどこまで実施すれば良いのか分からない」といった『要件定義プロセス計画の問題』
「そもそも開発スコープがあいまいである」といった『スコープ定義の問題』
「要求件数では開発規模の膨らみが分からない」といった『見積りの問題』
「要件定義ドキュメントの品質の確保方法が分からない」といった『品質計画の問題』
「要件定義の体制が不十分である」といった『体制・チームビルディングの問題』
「要件定義の契約形態がバラバラである」といった『契約の問題』
「コミュニケーションが不十分である」といった『コミュニケーション計画の問題』
「リスクを把握できていない」といった『リスク認識の問題』
「要求調整・規模調整のコントロールができない」といった『要求・スコープコントロールの問題』
「要件定義の品質を監視できない」といった『品質の監視の問題』
「コミュニケーションがうまくいっているか分からない」といった『コミュニケーション監視の問題』
「課題やリスクが放置される」といった『リスクの監視の問題』
「ドキュメント間の整合性がいつの間にか失われる」といった『トレーサビリティ管理の問題』
「要件定義完了時期に未決定要求が残る」といった『要求評価の問題』
「要件定義の完了を判断できない」といった『完了判断の問題』
「要件定義ドキュメントのサンプルや書き方のコツが欲しい」といった『要件定義ドキュメント記載上の問題』

第三章 要件定義の全体像

企画工程では、一般的に経営上のニーズ、課題を実現、解決するための新たな業務の全体
像と実現に向けたシステム構想を立案する。この工程では、システム化構想を具現化するた
めに、運用や効果等の実現性を考慮したシステム化計画、プロジェクト計画を具現化し、ス
テークホルダの合意を得る。

要件定義工程では、企画工程で立案したシステム化計画をインプットに、ステークホルダ
のニーズ、要望、課題を分析し、利用者や他のステークホルダが必要とするサービスを提供
するシステムに対する要求を定義し、ステークホルダと合意して、要件とする。

基本設計（外部設計）では、要件定義で合意した要件をシステムの技術的要件やソフトウ
ェアの構成要素の要件に詳細化する。

要件定義の問題カテゴリマップ

ビジネス要求定義、システム化要求定義の主要タスク例

要件定義の手順はプロジェクトの内容によって大きく変わるので、こうでなけれ ばならないというものはないが、ここでは基幹業務システムのスクラッチからの再構築プロジェクトの場合を参考までに示す。(なお、この例は4カ月で要件定義を行 う例を示している。)

1カ月目
最初の 1 カ月はビジネス戦略からのビジネス要求や現行業務の改善要求、ならびに現行システムからの改善要求などを集めて、その要求の要因や原因を調べたりす ることに主眼を置いている。また、新システム向けに採用する最新の技術や製品の採用可否を検討したりすることを行っている。

2カ月目-3カ月目前半
2 カ月目に入って、要求から要件への絞り込みを行って、To-Be のモデルや To-Beの業務フロー、To-Be の業務処理定義を主にユ―ザ主体に作成している。それと同時に、システム側では、新システムの機能要件や非機能要件を検討して、新技術や新製 品の技術検証を行っている。

3カ月目後半-4カ月目
3 カ月目半ばに入ってからは、これまでに検討された To-Be の業務フローや To-Be業務処理定義書、ならびに新システムの機能要件、非機能要件の検討結果をもとにし た新システムの機能一覧や新システム機能定義書の作成を実施している。また、デー タモデルや稼働環境の実現可能性の検証を行い、新システムの実現可能性を担保す るようにしている。他には運用要件や、データなどの移行に関する要件や課題を整理 し、また設計の標準化を徹底するように準備している。

その上で、開発・運用費用を概算で見積もり、投資効果を分析し、現新比較表をも とに、経営側への説明の準備を行っている。

この WBS（Work『作業』・Breakdown『分解』・Structure『構造化』）のすべての作業を実施しなればならないわけでもなく、実施するとして も概要レベルの内容にとどめても問題ない場合もあるので、表を参考にテーラリングして、自プロジェクトの WBS を作成されたい。

第四章 ビジネス要求定義（BR）における問題と解決の勘どころ

「BR.ビジネス要求定義」では、大きく3 つのサブプロセスに分けて作業を行う。

  1. 「BR1.ビジネス要求の獲得」... 現状業務、システムの把握をした上で、それらの問題、ならびに解決すべき課題を抽出し、目指すべきゴールとその手段を抽出する。
  2. 「BR2.ビジネス要求の分析」... 目指すべきゴールを実現するために必要な要求の体系化や実現手段の検討をする。また、体系化した要求、ならびに実現手段をもとに要求の優先順位付けを行い、対象とする要求の範囲、ならびに優先順位をステークホルダで合意する。
  3. 「BR3.ビジネス要求の文書化」... 合意した範囲の要求についてその体系と内容、実現手段を文書化する。

要件定義の入り口として複数の人が業務を共通理解し、他の人に伝達していけるようにするためには、現行業務や現行システムを可視化し、把握することから始める必要がある。

第5章 システム化要求定義(SR)における問題と解決の勘どころ

「SR.システム化要求定義」では、大きく 2 つのサブプロセスに分けて作業を行う。まず、
「SR1.仕様化」において、「BR.ビジネス要求定義」で文書化した要求を機能面、非機能面の
両面で分析し、文書にまとめて仕様化する。続く「SR.2 確認・評価」では、作成した文書の
記述内容が構造的、意味的に正しいかどうかをレビューを通じて検証する。また、ビジネス
要求に照らし合わせて、ステークホルダが期待している初期の要求を満たしているかどう
かをステークホルダと確認する
「SR.システム化要求定義」における課題のカテゴリマップを図 5.1 に示す。

第6章 要件定義マネジメント(RM)における問題と解決の勘どころ

「RM.要件定義マネジメント」では、大きく 4 つのサブプロセスに分けて作業を行う。ま
ず、「RM1.立ち上げ」において、要件定義工程前に策定した構想・企画を確認の上、当該プ
ロジェクトを進める上でのステークホルダを特定する。そして、当該プロジェクトの成果に
対する責任の所在を明確にすべく、成果のオーナーを選定し、オーナーより要件定義工程を
開始する認可を得る。続いて、「RM2.計画立案」において、プロジェクトの目標達成に向け、
プロジェクトのスコープを定義し、プロジェクト計画を精緻化した上で、体制の構築、立ち
上げを行う。また、「RM3.監視・コントロール」において、プロジェクトの進捗やパフォー
マンスを監視し、計画の変更が必要な事柄を特定し、適切に変更を行う。最後に、「RM4.終
結」において、要件定義工程の成果を評価し、当該工程の完了を判断する。
「RM.要件定義マネジメント」における課題カテゴリマップを図 6.1 に示す。

第7章 要件定義の主要ドキュメント作成(DD)の勘どころ

「DD 文書記述」では、4 章、5 章で用いた成果物も含め、要件定義で作成する 36 の主要
な成果物をここに集約し、各ドキュメントの記載項目とサンプルドキュメント、作成時の留
意事項などを提示している。
成果物の課題領域を、「DD.1 ビジネスコンセプト」､「DD.2 ステークホルダ」､「DD.3 要
求分析」､「DD.4 データモデル」､「DD.5 ビジネスプロセスモデル」､「DD.6 相互作用モデ
ル」､「DD.7 コミュニケーション」､「DD.8 各種一覧」､「DD.9 インターフェース」､「DD.10
データ定義」､「DD.11 機能・データ整合性検証」､「DD.12 非機能要求」、「DD.13 運用、移
行、総合テスト」の 13 に分類し、それぞれの作成の勘どころを提示している。
「DD 文書記述」における課題カテゴリマップを図 7.1 に示す。

おわりに

本書は、システム構築の上流工程における重要プロセスである要件定義を適切に実施す
ることにより、それに続く開発プロジェクトの失敗を減らし、構築するシステムに対する品
質要求に応え、対象システムにより実現されるビジネスや新たなサービスに、より高い価値
をもたらすことをガイドすることを目的として作成した。本書では、この「適切に」という
言葉を、システム化の目的を達成するための要求を誤りなく選択し、そこから新たな価値を
創造するビジネス要求を過不足なく定義し、システム化要求定義に抜け漏れなく展開する、
そして、これらのプロセスを初期の計画どおりの QCD で実施できるようマネジメントする
こと、と定義してノウハウを記載した。
ノウハウは、要件定義の現場でよく発生する問題点を起点に、各問題が発生した際にどう
対処するか、発生させないためにどうするかなどにつき、問題と解決の勘どころを対応させ
る形式で記載した。発生する問題は、現場の有識者の経験から特に重要なものを選択してい
る。
ただし、要件定義において発生する問題は、このガイドに記載したものだけではない。む
しろ、まだ本書に記載されていない問題の方が多いと思われる。また、ガイドに示した勘ど
ころについても、本書とは異なるご意見をお持ちの方も少なくないと想像する。これについ
ては、みなさまの経験をもとに補完・訂正して、ご自身の作業環境でのより良い要件定義の
あり方として改善していただければ幸いである。また、本書に追記すべきノウハウをお持ち
の方も多いと思われる。本ガイドの今後の成長のために、そして今後の要件定義をより実り
のある活動にするために、ぜひお手持ちのノウハウをお寄せいただきたい。
IT の役割は"Support Business"から"Do Business"へと変化してきている、と言われ始
めてからもう何年も経過している。このような状況においてビジネスの変化に対応した情
報システムを構築・運用をするためには、今後、ますます要件定義の品質が重要になって
くる。システム構築の手法は IT の進歩と歩調を合わせて常に進化し続けており、要件定
義において作成する具体的な成果物の種類や記載内容も同様に変化し続けることが予想
されるが、本書に示したさまざまな事項は、要件定義の勘どころとして今後も普遍性を保
ち続けると考える。本ガイドがみなさまの要件定義の実施における道標として少しでも役
立つことを願う。