「第9回要求シンポジウム」に「モダナイゼーション型の要求合意の課題とプロジェクト事例の紹介」の途中から行って、そのあとの山本修一郎先生の話を聞いてきたのでメモメモ
※表題の件が知りたい人は、最後の水平線から見てね！
■モダナイゼーション型の要求合意の課題とプロジェクト事例の紹介
(途中から）
要件定義しない→モダナイゼーション
SoE
SoR
→SoRに向かっている？
・カイゼンはイノベーションではない
・イノベーションはSoEだけではなく、SoRもある
モダナイゼーションもSoRだけではなくSoEもある
・業務を分かっている人も少なくなってきている
→この画面にこう入れるという理解
システム全体も分からなくなってきている
ドキュメントが残っていない
・モダナイゼーションの手法
日経System ２０１４年１２月号
※会場で言っていなかったこと
２０１４年の１２月号の図１には、９つの手法しか
載っていない。あれを２、４、３に分けた根拠は、
P32の３段落目からの文中の内容によるものと
思われる。ちなみに、その文中の記述と、９つの手法
は、こんなかんじ
・開発規模が大きくなる手法
リビルド＊
リプレース
・モダナイゼーションの中核技術
リライト
ラッピング
リインターフェース
リホスト
・その他（分類名称なし）
リファクター
リドキュメント
リラーン
＊リビルド：機能仕様から作り直すことを指す。
いわゆる「リビルド」とは違う
--------
事例 自動変換ツールでリライト（など）
ポイント
・変換ツールを過信しない
・テスト仕様書、テストデータ
・リライトで予算取れるか？
実際には複合
業務が１００％なくなることはない
現行踏襲をどこまで→現行業務を成立させる
現行可視化
人を育てることを同時にできる
テスト方法の合意形成
■IoT時代のITイノベーションとITモダナイゼーションの課題
・要求合意が代わらないということは無い
・従来：線形モデル
モダナイゼーション：クローズドループ（組織の中で合意すればよい。収束する）
イノベーション：オープンループ（収束しない）
現実＝リニアの部分＋クローズドループの部分＋オープンループの部分
→適切にマネジメント
・アーキテクチャ駆動モダナイゼーション
馬蹄モデルと呼ばれる
・REMICS
既存システムをクラウドへ
・価値が達成されているか
・DoDのITモダナイゼーション
質疑応答は聞いてこなかったので、
山本先生の使っている「モダナイゼーション」の定義と
一般に言っている「モダナイゼーション」の定義がちがっているため、
山本先生のいう「もっと戦略的にモダナイゼーションを考える」というのが、
見えにくかったと思う。
勝手に以下のように解釈した（山本先生の言いたかったこととは違うかも？）
まず「アーキテクチャ駆動モダナイゼーション」では、
現行のベースラインアーキテクチャから
目標のターゲットアーキテクチャへの変換プロセスを、
以下の３種類にわけている
・ビジネスアーキテクチャでの変換：ビジネス変換
ビジネスモデルそのものが変わる。
お客さんから見て、ビジネスが変わっている
いわゆるイノベーション
・情報システムアーキテクチャの変換：論理変換
ビジネスモデルは変わらないが、業務フローは変わっている
お客さんからみたら同じビジネスだけど、社員のやり方が変わっている
BPRなんかがこれに当たる
従来の開発が、これ
・テクノロジーアーキテクチャの変換：物理変換
業務フローは同じだが、システムの中身は変わっている
社員のユーザーからみたら同じだけど、動いているプログラム等は変わっている
いわゆる「モダナイ」は、これ
つまり、
モダナイゼーション→従来の開発→イノベーション
は連続的な枠組みで、
「誰から見た時、そのシステムは変わっているか？」
で分類できる。
ということは、これらは同じ評価基準で評価できる。
具体的に言うと、その開発（モダナイや開発、イノベーション）を行うと、
どれだけの投資が必要で、その投資を行うと、利益が出るかどうかで評価できる。
その結果、「モダナイ」にするより、いっそのこと、そのシステムを捨てて、
新しく情報システムを作り直したほうがいいなどという選択肢も有り得る
（社内システムでオンプレから、クラウドに移すようなときに有り得る）
この辺の評価判断が必要というのが、「戦略」にあたる。
それと、自動生成は今、単純に自動生成するというより、構文解析まで
行って自動生成するケースも有る。この場合、自動化率は高くなる。
※表題の件が知りたい人は、最後の水平線から見てね！
■モダナイゼーション型の要求合意の課題とプロジェクト事例の紹介
(途中から）
要件定義しない→モダナイゼーション
SoE
SoR
→SoRに向かっている？
・カイゼンはイノベーションではない
・イノベーションはSoEだけではなく、SoRもある
モダナイゼーションもSoRだけではなくSoEもある
・業務を分かっている人も少なくなってきている
→この画面にこう入れるという理解
システム全体も分からなくなってきている
ドキュメントが残っていない
・モダナイゼーションの手法
日経System ２０１４年１２月号
※会場で言っていなかったこと
２０１４年の１２月号の図１には、９つの手法しか
載っていない。あれを２、４、３に分けた根拠は、
P32の３段落目からの文中の内容によるものと
思われる。ちなみに、その文中の記述と、９つの手法
は、こんなかんじ
・開発規模が大きくなる手法
リビルド＊
リプレース
・モダナイゼーションの中核技術
リライト
ラッピング
リインターフェース
リホスト
・その他（分類名称なし）
リファクター
リドキュメント
リラーン
＊リビルド：機能仕様から作り直すことを指す。
いわゆる「リビルド」とは違う
--------
事例 自動変換ツールでリライト（など）
ポイント
・変換ツールを過信しない
・テスト仕様書、テストデータ
・リライトで予算取れるか？
実際には複合
業務が１００％なくなることはない
現行踏襲をどこまで→現行業務を成立させる
現行可視化
人を育てることを同時にできる
テスト方法の合意形成
■IoT時代のITイノベーションとITモダナイゼーションの課題
・要求合意が代わらないということは無い
・従来：線形モデル
モダナイゼーション：クローズドループ（組織の中で合意すればよい。収束する）
イノベーション：オープンループ（収束しない）
現実＝リニアの部分＋クローズドループの部分＋オープンループの部分
→適切にマネジメント
・アーキテクチャ駆動モダナイゼーション
馬蹄モデルと呼ばれる
・REMICS
既存システムをクラウドへ
・価値が達成されているか
・DoDのITモダナイゼーション
質疑応答は聞いてこなかったので、
山本先生の使っている「モダナイゼーション」の定義と
一般に言っている「モダナイゼーション」の定義がちがっているため、
山本先生のいう「もっと戦略的にモダナイゼーションを考える」というのが、
見えにくかったと思う。
勝手に以下のように解釈した（山本先生の言いたかったこととは違うかも？）
まず「アーキテクチャ駆動モダナイゼーション」では、
現行のベースラインアーキテクチャから
目標のターゲットアーキテクチャへの変換プロセスを、
以下の３種類にわけている
・ビジネスアーキテクチャでの変換：ビジネス変換
ビジネスモデルそのものが変わる。
お客さんから見て、ビジネスが変わっている
いわゆるイノベーション
・情報システムアーキテクチャの変換：論理変換
ビジネスモデルは変わらないが、業務フローは変わっている
お客さんからみたら同じビジネスだけど、社員のやり方が変わっている
BPRなんかがこれに当たる
従来の開発が、これ
・テクノロジーアーキテクチャの変換：物理変換
業務フローは同じだが、システムの中身は変わっている
社員のユーザーからみたら同じだけど、動いているプログラム等は変わっている
いわゆる「モダナイ」は、これ
つまり、
モダナイゼーション→従来の開発→イノベーション
は連続的な枠組みで、
「誰から見た時、そのシステムは変わっているか？」
で分類できる。
ということは、これらは同じ評価基準で評価できる。
具体的に言うと、その開発（モダナイや開発、イノベーション）を行うと、
どれだけの投資が必要で、その投資を行うと、利益が出るかどうかで評価できる。
その結果、「モダナイ」にするより、いっそのこと、そのシステムを捨てて、
新しく情報システムを作り直したほうがいいなどという選択肢も有り得る
（社内システムでオンプレから、クラウドに移すようなときに有り得る）
この辺の評価判断が必要というのが、「戦略」にあたる。
それと、自動生成は今、単純に自動生成するというより、構文解析まで
行って自動生成するケースも有る。この場合、自動化率は高くなる。
アクセス
トータル
ランキング
