オントロジーとモデル理論に基づく
ソフトウェア開発の品質向上の実践
上流工程支援と下流工程技術の両立を目指して

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/なぜ、システム開発プロジェクトは毎回失敗するのか？
システム開発の現実「失敗から学ぶ」はウソ！ ← 統計調査の結果 !?
失敗した人が次に成功する確率は、初めての人が成功する確率と同じ！

間違った人材育成方針と技術ロードマップ
今、求人のあるJava/Web技術者は、20年前のCOBOL技術者 !?
アルファベットスープとパッケージ神話による人材流出・ノウハウ消失

マネジメント重視・技術者軽視の弊害
不具合の実態と間違った発注者・利用者へのアプローチ「鬼の婦長さん問題」と「まじめな皿洗い現象」

技術者が主体的に成長できる方法論と環境整備とは？
組織・人材・スキルの改善
枯渇するエース人材と少子高齢化によるダイバーシティ推進の重要性

ソフトウェア技術者の知情意：利用者（非専門家）の観点
可読性の高い図式と日本語文書
利用者に必要な文書を整備するだけで、調達から開発、テスト、検収、運用までを可能に !!
非専門家が、コピペ・穴埋めで記述・作成できるようになる。
ワインバーグの指摘：辞書と文法書で、外国語文学がスラスラ執筆できる、という幻想。

ソフトウェア品質を統制するためのAIST包括フレームワーク
下流工程技術を活用するための上流工程成果物の品質管理方法
先人の知見・経験を活用するためのオントロジーとモデル理論

1

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved自己紹介：はじめに、をかねて。

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/自己紹介を兼ねて70年代に指摘され、80年に取り上げられた
今も昔も、変わらない本質 !?

和泉憲明
産総研
国立研究開発法人・
産業技術総合研究所(旧・電総研)上級主任研究員

成功するプログラ
ミング
ブライアン L.ミー
ク， 永田 守男ほか
近代科学社 ; ISBN:4764900777 ;(1982/01)
3

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedオープンソースの幻想Βテスタ向けバージョン

リリース時期の問題

耐障害性

http://www.dashiblog.com/blog/archives/000140.html
http://weblog.cemper.com/a/200309/09-typical-project-life.php
パッチ適用後の状況
Coolな広告
２ちゃんねる炎上

高負荷時の挙動4

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

永田守男先生の教え：古くて新しい問題を解決する。
第3章 プログラム開発
3.2 検査とデバッグ
3.3 実行時の性能改善
第4章 特別な問題
4.2 大量のデータ
4.3 大規模プログラム
4.4 実行時間の長いプログラム
第5章 他の人々との関係
5.1 プログラムの文書作成
5.3 他人のプログラム

技術的な課題は、70年代に指摘されている？
「 『人の活動としてのプログラミング』 … プログラミングは単なるハードウェアの問題、ソフトウェアの問題ではないのだ。」、ワインバーグ@71「ソフトウェア技法をどう改善したら良いかという中心的疑問は、…、人間の問題に集中する。」、ブルックス@75

品質向上のために克服すべき課題は、どんな『人間の問題』なのか？
自治体の職員や地方の中小企業にはできても、他の民間企業や他自治体には無理なのか…!?
5

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

開発の現場は、なぜ、技術を活用できないのか？
事件（品質インシデント）は会議室で解決できない !?

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

下流工程重視の技術改善
アジャイルソフトウェア開発は銀の弾か !?
多くの下流工程集約型の方法論が登場
品質チェック(インスペクション)
要件定義
資料

設計
資料

ソース
コード

要件定義
資料

設計
資料

ソース
コード

要件定義
資料

設計
資料

ソース
コード

要件定義・設計・実装
要件定義・設計・実装

要件定義・設計・実装

要件定義・設計・開発・移行の適切なコスト配分は？
産総研のメトリックスでは、 ３：３：２：２
成果物量と想定スキルから稼働時間を算出

しかし、現実には、Δ：Δ：１０：０(移行は次年度？)
健全な開発PJ

現実の開発PJ

下流工程技術の発想

超開発の落とし穴要件定義 設計
開発
移行

要件定義 設計
開発
移行

要件定義 設計
開発
移行

要件定義 設計
開発
移行

移行コスト（時間・費用）は、運用保守費にマージ？
7

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

画面中心開発とパッケージによる業務ノウハウの消失
画面のレイアウト(UI)ばかり気にする傾向が…。

「画面を確認した方が早い」⇒ 実際、画面で何を確認しているのか？
インターネット (WWW)

http://www.volleytennisclub.com/

リクエスト(http://www.volleytennisclub.com/)
レスポンス

Webブラウザー<html><body>….
….
….
</body></html>クリック、クリック、選択。
クリック、クリック、入力。
…。

Webサーバー
Webページ(HTMLテキスト)8

2016-06-06(www.volleytennisclub.com)(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved例：高速開発手法によるシステムテスト成果物
業務知見が欠乏するとテストデータが貧弱になり…
最低限のデータがあると…

しかし、実際は、… (実開発のインスペクション資料参照)
9

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

上流工程支援と下流工程技術は両立しないのか？
従来のシステム調達
変化した要求

要件
業務担当

業務

これだけ書いておけば十分に開発が可能だ！

言葉が通じない後手にまわる

確認と変更管理

上流工程コンサル

仕様書

ｼｽﾃﾑ
必要な情報が書いていない！

運用

下流工程ベンダ

変更管理の原因分類• 間違い … ケアレスミス• 運用回避 … ミスの受入れ• 改善要望 … 設計確認漏れ• 制度改正 … 本当の変更
計算結果が
あわない！

データ抽出
情シス担当

10

2016-06-06

変換(移行)

構築したシステム(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

下流工程手法の落とし穴：上流工程ミスの実態
例：児童虐待対象の電話番号検索
対象の電話番号検索
効率が悪い！
担当者の要求：
履歴から対象を電話番号で検索 画面設計しました！
出力に電話番号が必要

電話番号でのキー検索
技術者の理解：電話番号を入力
対象を出力

設計修正してモック作成完了 !?

これからは、システムに業務をあわせる時代です！

年齢や性別での絞込み機能が必要
システムテストにて対応しました!!

乳児・幼児・男女での絞込み機能が必要
画面モックアップ現場を知らない
責任者

電話番号

思いが言えない
担当者

カナ氏名
漢字氏名

生年月日
入力

読み返せない文書11

2016-06-06

クリア

話を聞かないSE

使えないシステム(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

協働のための文書: 業務・システムの最適化のために !!
利用者と開発者の間でいかに効率的に知識を共有し作業を分担するか?
利用者同士の協働のための文書
業務一覧・業務マニュアルなど：利用者が作成

伝えたい内容開発者同士の協働のための文書効率がいいはず！
詳細設計書・データ定義書など：開発者が作成

伝わる内容

利用者と開発者との協働のための文書
業務フロー図・ユースケース記述など：利用者主導で作成 ← 発注に必要

利用者の観点モデル理論に基づいて、可読性の高い図式と日本語文書
利用者に必要な文書を整備するだけで、調達から開発、テスト、検収、運用までを可能に !!

職員可読性の高い
必要最低限の図式表現と図式表現・日本語文書とは？
読みやすい日本語文書 !?
共有＋共同編集12

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

AIST包括フレームワークの仕組み
添削可能な上流工程の成果物とは？

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

AIST包括フレームワークの技術的特徴『利用者』のための成果物の可読性
非専門の職員でも添削可能な業務フロー図とユースケース記述
業務フロー図ユースケース記述

決裁（調定・決済）のフローは、
特に、帳票を具体的に！
（一般には、○○情報などと丸めて標記する傾向が…。）

利用者による操作手番は、可能な範囲で、抽象的に！
（一般には、画面項目などを過度に詳細標記する傾向が…）

抽出
（詳細化）

業務のコンテキスト14

2016-06-06

機能のコンテキスト(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

業務フロー図の特徴：利用者主導開発のための文書
 『エンドユーザ（システム開発の非専門家）による可読性（添削と共有）』により『最新の開発方法論(Java, Web, UML, アジャイル)』へのトレーサビリティを確立！


実際の業務を正確に捉え、業務に依存する課題や効率化の範囲を正しく把握できる。
 利用者と受注者の共通の会話を成立 ⇒ 利用者が添削可能な成果物のひとつ。
 添付書類などを具体化した稟議決裁フローにより、帳票の迷子・みなし子を見つけ出し、システム化範囲の漏れ抜けや、実現機能の不足を洗い出すことが可能。

『誰』が作業するかを表す。
作業の『流れ』を表す。
システムを用いない『作業』を表す。

どの『システム』に対する作業かを表す。

『何』を利用して作業を行うのかを表す。
システムに対する『作業』
を表す。

15

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

システムユースケース記述の意義
画面遷移（プログラムの仕様）相当の部分を日本語で記述
職員は、業務内容（日本語による記述）に集中できる。
職員は画面遷移レベルで仕様を記述・確認。さらに、システムの受け入れ・検収にも！
改修は、ユースケース記述を「赤入れ」するだけ。

日本語記述の効果
職員による業務の改善や共通化の検討が可能に。
Cf: 画面による業務共通化は、「違いへのこだ
わり」が強くなるだけ！（阻害要因に!?）ユースケース数と開発規模の相関ユースケース単位で開発や改修の規模を概算で算出可能になり、開発ベンダと対等な立場に！
16

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

上流工程成果物を正確に読み解く添削可能な上流工程の成果物とは？

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

非専門職員による利用者主導開発の事前検証：
利用者が業務フロー図・ユースケース記述に注力することの効果
パイロット開発：児童相談所の障がい児施設補助関連事業役所
他都市の業務モデルが、別組織で再利用(容易に添削)できた！
ケースワーカが担当のため、ヒアリングなども困難で、かつ、ITの素養もない。

業務モデル（仕様書）の流用効果は、予算に換算すると… ！！

sample18

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved≪業務フロー図のサンプル記述≫[業務説明] 窓口で市外転入の申請を受け付ける
エビデンスが発生するタイミ
ングで『＋』マークを付ける。

A

スイムレーンをまたぐフ
ローでは、伝達手段を明記する。

システムに対する操作ではないため、手作業のアク
ティビティを用いる。

業務内容は、業務フロー図の備考、
業務ルール、概念モデル等から概要を把握できる必要がある。

■業務説明
市外から転入したとき、『転入届を出す人』(住民)と『窓口の担当者』(受付担当者)のやり取りが発生する。
住民が申請用紙に記入して、必要書類と一緒に窓口に提出する。

作業で利用するエビデンスを列挙する。
(c) 2012 National Institute of Advanced Industrial Science and Technology All Rights Reserved.

既に発生しているエビデン
スには『＋』を付けない。
19≪業務フロー図のサンプル記述≫[業務説明] 転入情報をシステムへ仮登録する
登録先である住記システムを明記する。

B
システムに対する操作は、システム操作のアクティビ
ティを用いる。

矢印の向きはデータの流れの向きと考える。（今回は登録なのでシステムを向いた矢印となる）
該当作業の主となる内容で方向を決める。

■業務説明
帳票等は、業務フロー上、生成されると必ず消滅する。

アクティビテイが消滅する
タイミングで『－』マークを付ける。

同一業務フロー図内でページをまたぐ場合は、次ページとの対応を明確にする。

(c) 2012 National Institute of Advanced Industrial Science and Technology All Rights Reserved.

窓口担当者が受け取った内容をシス
テムに登録し、その結果として作成された書類(入校票等)と一緒に届出者へ一部提出物を返却する。
このタイミングで登録されたものは、仮登録状態であり、住民票へはまだ反映されない。
国保・介護・年金通知は、以下の場
合このタイミングで戻すことになる。
⇒国保加入者又は介護資格者のうち、すぐに異動内容の反映が必要な場合

20

≪業務フロー図のサンプル記述≫[業務説明] 仮登録された転入情報を確認し確定させる
同一業務フロー図内でページをまたぐ場合は、前ページとの対応を明確にする。

■業務説明受付担当者が登録した内容を、審査対象者が確認し、完了登録する。
審査担当者が完了登録を実施することで、次の２つのことが実施される。
⇒転入情報を『住民票』へ反映する。
⇒『住基ネットシステム』へ情報を反映する。

C- 対象業務量が増加すると、業務内容（機能）が質的に変化する！2線式の窓口業務：「業務量で必要な機能が異なる」好事例！
外部システムとの連携も業務フロー上で表現する。

(c) 2012 National Institute of Advanced Industrial Science and Technology All Rights Reserved.

21

品質の良い成果物作成のポイント
品質の良い成果物作成のための「教育・セミナーの資料」の目次
成果物の『量』に対して、どのような『質』の管理（対策）を行えるか。
受注者が作成した大量の成果物を、一定のチェックの方法により、均質化を図るかがポイント。

記述の抽象度を上げて均質化することは、内容品質を失うことになるので、注意する。

成果物品質の向上のための１０の観点
成果物の書式に関する観点
1. 業務フロー図での条件分岐を明確にする。
2. 業務フローをつなげる。
3. 業務フロー図間のつながりを意識する。

成果物の記述内容に関する観点
4. システム運用関連業務の漏れを無くす。
5. 対象業務で扱われる帳票を明確にする。
6. 対象業務（検討対象範囲）を網羅する。
7. 作業担当者による記述粒度の違いを無くす。
8. 外部システムとの連携を明確に定義する。

成果物の関連資料に関する観点
9. 議事録を正しく作成する。
10. 業務フロー図の備考から業務ルールを抽出する（抜き出す）。

22

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

方法論 ＝ プロジェクト管理 × モデル理論

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

プロジェクトノウハウを形式知にするための知識基盤

どれだけの成果物をいつ（どのタイミングで）どの程度（正確に）作成・確認すると良いのか !?
⇒ 具体的にどのようなプロジェクト課題に直面するのか？
24

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

成果物のモデル理論に基づくトレーサビリティと成果物間の関連に基づく現場での役割分担
 成果物間の厳密な関連定義により、利用者（非専門家）は、業務フロー図・ユース

ケース記述に注力可能 に!?

25

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedプロジェクトノウハウを形式化するために：例１
詳細イベントと参照ドキュメントをマトリックスで管理
各種定義書と利用可能なテンプレートやガイド

工
程
ご
と
の
詳
細
な
イ
ベ
ン
ト

26

2016-06-06

調達や開発、移行などのノウハウが、各種のテンプレートとして蓄積・共有が可能になっている。
イベントや規約類を関連させ、
テンプレートやリファレンスと一緒に配布することで、校正・加筆がルーチンになる！
(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedプロジェクトノウハウを形式化するために：例２
成果物関係のチェックに関するツールとノウハウ
ユースケースと帳票類の関連を、機能群とデータ構造の関連により、抜け漏れと設計妥当性のチェック。
帳票からDBテーブル項目までのデータ階層

記
述
レ
ベ
ル
階
層
で
整
理
し
た
機
能
27

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedオントロジー技術を援用した
プロジェクト推進ノウハウの個別化
各種のプロジェクト標準に『魂』を込めるためのテンプレート・リファレンスの具体化

Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/オントロジーとは？

Boyack, K.W., Klavans, R., & Börner, K. (2005, inpress). Mapping the backbone of science.
Scientometrics.

概念定義（属性・属性値）＋概念階層「『機械(コンピュータ)』のための大量データの解釈定義」「『機械学習システム』のためのカンニングペーパー」『機械学習システム』が学習完了するためには，最低でも数千のサンプルが必要「『和泉憲明＠産総研』と『和泉憲明＠静岡大学』が同一人物である」は判定不可能「同じモノの定義(オントロジー)」を与えてデータ空間を圧縮する．
「何と何が同じか」の定義（オントロジーの基本は「同じ」の定義）
29

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

海外旅行にオントロジーがあると…．
機械処理の精度とその設計に好影響
氏

クラス
氏名

名前

名

氏名

便名

到着便

入国者

都市

発行地
パスポート

パスポート

ビザ

有効期限

番号

番号
ビザ

属性

30

2016-06-06

日付

番号
有効期限

(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved個別システム開発におけるドメイン固有概念の導入
語彙的・意味的に統制するための成果物基盤を単位として業務フロー図を作成 ⇒ 業務の可視化
 Lv.4ある業務を実施する際に、誰が、どのような順番で、何を使って作業するかを記号を用いて視覚化した業務の流れ図である。
データフローではなく，イベントフローと添付書類であることが重要！

実際の業務を正確に捉え、業務に依存する課題や効率化の範囲を正しく把握できる。
入出力参照、ではなく、決済のフロー 利用者と受注者の共通の会話を成立させるとともに、利用者が添削可能な成果物のひと
申請書類・添付帳票の明確化！
つである。
⇒ ノーカスタマイズのリスク対策
窓口方式、2線式、3線式が明確に！
 業務ルール、概念モデル、用語集などと合わせて業務を正確に表現できる。


作業の『流れ』を表す。

『誰』が作業するかを表す。

システムを用いない『作業』を表す。

『何』を利用して作業を行うのかを表す。

システムに対する『作業』を表す。

ガイドには、サンプルだけでなく、（オントロジー構築を想定した）用語統制に関するノウハウも !?

31

2016-06-06

どの『システム』に対する作業かを表す。

業務を整理して、業務フロー図を作成することが重要となる。システム規模が大きくなると業務フロー図を一緒にするのか分けるのかによって、フローの数が変わってくる。
(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

AIST包括フレームワークの個別化事例
成果物標準を機能させるために
成果物量の増大に起因した相互参照（内容整合性）に関する品質問題
大量の成果物・成果物間の相互参照（内部整合性）に関する誤りは、単純な存在チェックでは発見しづらい。
にもかかわらず、現場で運用されている標準・ルールの多くは「項目定義は正確に」「整合性を確認すること」のみ！

品質インシデントの実例
画面モックアップにてクリアボタン押下時にクリアされる項目が、画面項目定義書に記載のクリアされる項目から漏れている。
画面モックアップ
画面項目定義書（画面A）

画面A

・・・
■インタラクション

宛名番号

…

…

…

カナ氏名

…

漢字氏名
クリア
ボタン
押下時

画面上の宛名番号・カナ氏名・漢字
氏名を空白で表示する。

生年月日
登録

…

…

・・・

宛名番号・カナ氏名・漢字氏名をクリアすると記載されているクリア

画面モックアップでクリアボタンを押下すると、
宛名番号・カナ氏名・漢字氏名・生年月日がクリアされる。

ワインバーグによる1971 年の指摘：「 『人の活動としてのプログラミング』 … プログラミングは単なるハードウェアの問題、ソフトウェアの問題ではないのだ。」「ものの書き方を学ぶための一つの方法は書いてみることだが、それ以外にもう一つ、どういう種類の書きものについても、読んでみるという方法がある。」⇒ 機能しない多くの開発標準は、「辞書と文法書を与えればすばらしい文学が書ける」という思い込み !?
32

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

成果物品質のための作業統制を阻害する課題
課題要因の実例：年月日入力形式が不一致となっている。

画面モックアップを確認すると、様々な年月日に関わる入力項目が存在する
が、成果物標準としてのルールが不明確である。
成果物作成が統制されていない。 ⇒ ヒアリングや確認も統制されていない。
表示内容

成果物の種類

生年月日

項目の種類

画面項目定義書年月日

西暦

帳票項目定義書
画面モックアップ

選択式の入力項目
編集可能な入力項目
編集可能な出力項目

和暦
外部IF定義書
年度

どのような項目が頻出するかは、業務システ
ムによって異なる。

成果物の種類は変わらないが、利用頻度は業務システムによって異なる場合がある。
（ex.画面が多い、帳票が多い、等）

編集不可能な出力項目

各成果物の入出力項目の種類も、業務システ
ムによって異なる場合がある。

ルールが遵守されていない ⇒ 事前の指示が徹底されていない！
⇒ (どのみち)ヒアリングや成果物の作成・修正すると考え、不要なコストを浪費している !?
⇒ 『鬼の婦長さん』登場 !!
33

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

対策：プロジェクトルールによる成果物品質の統制
現実問題として…
通常、利用者・発注者は、画面モックアップの確認のみ。
画面項目定義は、基本、開発ベンダのための文書であり、全項目に関するヒアリングやチェックは困難！

対象業務領域のパターンとしての参照成果物の共有
入出力項目について整理し、テンプレート化・ルール化する。
成果物の種類
画面における年月日入出力のルール

表示内容
項目の種類

●生年月日
入力：和暦、西暦どちらの入力も可能
表示：西暦を併記して表示
昭和63年12月12日(1988年)

ルール●生年月日以外の年月日
入力：和暦、西暦のどちらの入力も可能
表示：和暦で表示
昭和63年12月12日●年のみの項目
入力：和暦、西暦のどちらの入力も可能
表示：和暦で表示
昭和63年「表示」は、照会・確認・完了画面での表示を指す。

≪補足≫
具体例として画面を取り上げたが、帳票についても同様なルールを適用している。
34

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

業務領域に特化したプロジェクト固有ルールの確立
具体例：画面設計ルールで統制を行った例
画面上の部品の配置は、ユーザインタフェース規約で定義をしているが、業務システムの特性に応じて、オリジナルのルールを逸脱しない範囲で業務固有の取り決めを追加すると、品質統制と作業量削減の両方に効果がある。
以下は、利用する業務（画面）の特性に応じて、業務（画面）と画面のボタン配置をパターン化した例である。
例：画面上のボタン配置の標準化
給与支払報告書（新規）画面、申告書等（新規）画面、
・・・

パターン1

課税対象者（完了）画面、支払者情報（完了）画面、
・・・

パターン2

対象者検索画面、課税資料検索画面、
・・・

パターン3

課税対象者（確認）画面、扶養・専従者（確認）画面、
・・・

確認

処理継続

対象者検索

戻る

戻る

検索

パターン4
前の対象者

 画面項目だけでなく、ボタンの振る舞いまで統制可能となるので、
 発注側のヒアリングや添削の負担だけでなく、 開発側の作業まで効率化！

次の対象者

確認

 ノウハウを業務固有のルールに•共通化と開発生産性向上•
規模圧縮と大量生産

上記と同様の例として、住所コードの出力形式や、画面入力項目が規定値・上限値を超えた場合の振る舞い、ユーザの権限有無に応じた画面の振る舞いルール、等があげられる。
35

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedオントロジー導入の効果
形式知化による成果物運用のスキル向上の例
内部レビュー後納税証明書（一般）の証明書発行要求時に、市・道民税証明（所得証明）・納税証
明・課税証明請求書を元に、請求者情報を特定し、賦課情報や収納情報を入手して画面でそれらの情報を確認する。
確認結果により、証明書の発行の可否を判断する。
賦課収納状況の確認を行う際に、同姓同名該当確認や同一法人該当確認・支店該当確認の実施を行うことがある。

一般的な成果物標準に基づく指摘後
納税証明書（一般）の証明書発行要求時に、市・道民税証明（所得証明）・納税証
明・課税証明請求書を元に、請求者情報を特定し、賦課情報や収納情報を入手して画面でそれらの情報を確認する。
職員が、画面に表示されるメッセージを確認し、証明書の発行の可否を判断する。
なお、賦課収納状況の確認を行う前に、同姓同名該当確認や同一法人該当確認・支店
該当確認により、納税義務者を職員にて確認する。

ガイド・規約の改善（プロジェクトルール化）に基づく赤入れ後
納税証明書（一般）の証明書を発行する際に、職員は証明書の発行可否を判断するた
めに、市・道民税証明（所得証明）・納税証明・課税証明請求書を元に、同姓同名・同一法人・同一法人の支店候補より請求者を特定し、税目・年度・税額・納付額未到
来額・未納額とともに、未納税目有の表示を確認する。
36

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedガイド・規約の発注者(職員)主導による改善
当初、策定されていた規約
5W1Hを正確に記載し、もれなく、曖昧なく、記述すること。

最終的に現場で運用されている規約 ？
下記の記載があるかを確認すること。
①どんな契機（タイミング・条件・目的－「いつ」「何のために」②何を入力・対象とし－「何を」③どのような操作・処理をして－「どうやって」④結果としてどうなるのか－「どうする（どうなる）」

等）で※「誰が」が主語として記述される※「何を」の部分では、入力帳票なのかDB参照なのか等も判別できるような記述とする。
※「どうやって」の部分は、入力帳票のどの部分を対象としているのか、DBのどの情報を対象としているのか、まで記述する。（どの部分、どの情報は概念モデルから）※動作の種類を『標準化』するほうがよい。
（業務フロー図のアクティビティの表記を統一しているのと同様のことを実施する）※意識してほしいこと。その動作が、登録することなのか、複数から選択することなのか、変換することなのか、など、どのような動作であるのかが明確になるようにする
37

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights ReservedおわりにNoriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

上流工程支援と下流工程技術を両立させるために !?
従来のシステム調達

利用者主導によるシステム導入

業務

要求
業務担当 要求業務担当

要求

共通の言葉の提供
確認機会の確保

確認
相互理解の勘違いだいたい正しい

情シス担当

システム

ｼｽﾃﾑ
情シス担当

39

仕様書

仕様書

ベンダ

ベンダ

システム

＜発生する様々な問題＞＜従来の問題に対する改善＞所管課の要求を満たさないシステムの完成
正しく開発したのに現新比較で異なる結果
瑕疵と変更が区別できずベンダーロックに成果物の品質向上による委託管理能力の改善
上流工程品質の向上による下流工程の効率化
成果物トレーサビリティによる最終品質の確保

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reservedまとめ：オントロジーとモデル理論に基づく
下流工程技術のための上流工程品質の向上アプローチ
実践フレームワーク（AIST包括FW）の提供：
情報システム開発に関する品質向上アプローチ
開発工程の生産性向上が、システム開発全体に好影響をもたらすための上流工程品質
各種のツール・パッケージと業務システムとの意味内容的なギャップを埋めるためのオントロジー

理論的アプローチ：
古くて新しい問題への対応
概念獲得とチームワーク、知的生産性向上に関する方法論（オントロジーとKM）

技術者の作業視点を重視
70年代からの技術教養を重視 … 辞書と文法書だけではフランス文学は執筆できない。

構成：
利用者・発注者のための情報システム開発における合意形成
生産性向上のための標準開発手順を、ドメイン固有知識で強化
モデル理論に基づいたトレーサビリティによる成果物記述法と品質チェックリストなど
非専門職員のための教育研修とノウハウ文書群

効果：
開発コスト削減と品質向上、現場力向上を同時に達成
利用者による仕様確認が可能となり、開発ツールの生産性が最大化されるため、発注者・受注者の双方に好影響が確立。
ドメイン依存のテンプレートと参照モデルを用いた『亜種開発』が可能となり、品質の統制も容易になる！
横浜市役所や札幌市役所で、開発費用の抑制効果を実証！（ただし、再委託構造を優先して、成果物間の関連を無視した役割分担をすると、…）

共通部分を、IT総合戦略室の「実践フレームワーク」として配布（予定）今後、多様な方法論のポテンシャルを活かすための枠組みとして！

40

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

付録１：品質改善とスキル向上の理論的背景- 質疑応答用のスライド -Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

AIST包括フレームワーク：上流支援と下流技術の融合
ホワイトカラーの知的生産性向上に関するノウハウ
ルーチン化・パターン化がカギ
知識集約型作業を、単純作業の繰り返しと、少量の試行錯誤に！

業務システム最適化計画の枠組みをソフトウェア研究の成果で強化
標準記法を数理モデルにより拡張、参照モデル開発に基づいて標準策定、プロトタイプ開発にてメトリックス計測と傾向分析（メトリックス分析）、
オントロジーにより品質向上のためのノウハウをガイドとして策定
標準記法と一般的ノウハウは、IT総合戦略室の実践フレームワークとして採用

成果物標準

プロセス標準

業務共通化と開発生産性向上のノウハウ

開発規模圧縮と大量生産のノウハウ

業務非依存のノウハウをプロジェクト固有のルールに作り込むスキル

盲目的な標準化・効率化でなくオントロジー技術によって用語などで成果物を統制し、経験知・ノウハウが分野固有のルールになり、実働可能に！

基盤技術
42

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

品質課題：図式仕様でさえ正確に読み書き出来ない !?
 概念モデル：ドメインを理解していることを確認できる１つの指標であるが、なか

なかうまく活用できていない。
人

状態を分類しているだ
けではダメ。

状態は状態遷移図で整
理する。

学生

組織

関連

関連クラスで記述すべき !?
助教

学生

状態遷移図上の遷移に対応するイベントの概念を整理する。

教授

イベント

ルール
イベントで扱われる情報は、帳票にあらわれることが多い。
⇒帳票ベースの概念抽
出は有効。

進学
退職

助教
イベントにはルールが紐付けられる。

教授

43

2016-06-06

就職

昇格
ルール

ルール
ルール

(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

システム開発におけるプロジェクト管理のスキル なぜ、プロジェクトは理想的に進行しないのか？
 全く同じプロジェクトは存在しないため、過去の知見(技術・経験)が役に立たない ??


多くの失敗プロジェクトは、理想的な状況を願望として計画してしまっている。

運良く作業内容が理解できても、次に、具体的な効率化の方策がわからない !?


品質改善やインスペクションが発注者任せになってしまう。

 フォアキャスティングとバックキャスティング
理想的なゴール
積み上げ的な想定

事前に不具合を除去できない！
経験知は蓄積されるか？

課題の抽出と分析
フォアキャスティング

避けられない課題
現実的な想定バックキャスティング

 開発プロジェクトにおける本当の課題：何に関する『現状分析』が重要なのか？
 知見(技術・経験) が生かされるかどうかは、プロジェクトの環境との相対関係で決まる。


ブルックス@75「ソフトウェア技法をどう改善したら良いかという中心的疑問は…、人間の問題に集中する。」

44

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

付録2：超高速開発手法への適用- 具体的な下流工程を想定すると？ -Noriaki Izumi Ph.D.
National Institute of Advanced Industrial Science and Technology (AIST) Japan
Email: n.izumi@aist.go.jp
URL: http://staff.aist.go.jp/n.izumi/

(超高速開発手法をツールとして採用した場合の)成果物関連図ツール技術をブラックボックス的に採用してしまうと、ラフな成果物間関連にとどまってしまう !?

46

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

高速開発手法とスクラッチ開発とのプロセス比較

成果物間関連がラフになると、ノウハウ共有は、ツールの操作スキルに隠蔽される !?

47

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

開発標準と標準プロセスの強化
開発規約*概要説明、*標準システム構成、*開発方針、*特定ツール
コー ディング規約、*テスト関連規約、*帳票関連規約、*自動テストツール規約

共通部品・共通機能*スタイルシート、*バリデーション、*メッセージ、*日
付・年齢計算、*排他計算、*その他（遅延金計算など、業
務的な難易度が高くて流用可能性の高いモノ）
各部品を構成する機能（メンテナンス画面、ログのダウン
ロード・移動、祝日計算、…）

テストツール関連
インストール手引、ツールガイド、サンプルテストケース、
ハンズオンテキスト、…

ドメイン依存の概念構造が重要!! ⇒ テストに直結 !?
48

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved

大規模システム開発のノウハウを移植
品質管理

システムテスト以降の連携テストや
データ移行・受入テスト*シナリオテスト仕様書01.xlsx, シナリオテスト報告書01.xlsx, *ユースケース仕様書01.xlsxの周辺を強化 !?
開発標準*redmineの登録状況の整理01.ppt, *redmineの登録状況の整理01.ppt, *テスト工程の作業の進め方について01.ppt, *テスト報告書の確認内容の整理01.xlsx, *ビジネスルール、システム連携を捉えた開発工程の進め方の整理01.xlsx, *基本設計補足補充・イテレーション開発の進め方について
04.ppt, *基本設計補足補充の進め方画面モックとは01.ppt, *業務フローの考え方の整理02.xlsx, *業
務フローテストの考え方の整理08.ppt,
ユースケース作成モデル/*共通テンプレート定義書の対象になるテンプレート03.xlsx
成果物チェックリストテンプレート*シナリオテスト（動くもの）チェックリスト01 .xlsx, *シナリオテスト用チェックリスト01.xlsx, *成果物
チェックリスト01.xlsx

成果物テンプレート
01.プロジェクト管理作業/, 03.総合テスト/, 04.運用保守作業の設計作業/, 05.移行方針設計作業/
06.移行作業/
01.移行計画/,システム移行手順書[システムID].dot, 移行計画書[システムID].dot
02.移行リハーサル/,タイムテーブル（移行リハーサル）[システムID].xlt, チェックポイント確認表（移行リハーサル）[システムID].xlt, 移行リハーサル実施シナリオ[システムID].xlt, 移行リハーサル
実施計画書[システムID].dot, 移行リハーサル実施結果報告書[システムID].xlt
03.移行本番/,タイムテーブル（移行本番）[システムID].xlt, 移行本番実施シナリオ[システムID].xlt, 移行本番実施計画書[システムID].dot, 移行本番実施結果報告書[システムID].xlt
07研修及び教育/, 08.運用保守の遂行準備作業/,
09.全体システムテスト/,全体システムテスト計画書[システムID].dot, 全体システムテスト仕様書[システムID].xlt, 全体システムテスト報告書[システムID].dot

システムが正しいことを確かめるための枠組み

成果物テンプレート定義書*共通テンプレート定義書03.docx
49

2016-06-06(C) 2016 National Institute of Advanced Science and Technology All Rights Reserved