「これだけモデリング」と、「これだけじゃない要求開発」を聞いてきた！

６月２８日、要求開発アライアンスの
日経SYSTEMS４月号 要求開発特集企画 『執筆者が語るこれだけじゃない要求開発』
を聞いてきたのでメモメモ

---

■さらなるダイエットに挑戦する「たったの「これだけモデリング」」
・自己紹介

・再び「これだけ」モデリングの勧め
　こんなに強力なのに今一使われていない。なぜ？
　どのくらい役に立つかわかっていない。とくに上流で
　使いどことが間違っているのでは
　今でも忙しい。これ以上負荷を増やしたくない
　なくてもやてる。あえて必要ない
　敷居が高い、たくさん勉強しなければならない
　それぞれの場面に適したレベルの「これだけ」モデリングがある

・アジャイルではモデリングが不要か？
　アジャイルではモデリングが不要なのか
　間接コミュニケーション媒体としてのモデリング
　　ドキュメントによる役割間の情報受け渡し、チーム内情報共有は不要
　　少数多能エンジニアチームでは、単なるオーバーヘッドへ
　直接コミュニケーション媒体としてのモデリング
　　ナプキンモデリングは口頭伝達を超える
　　　言葉より手っ取り早くて正確に伝えるメモ的モデルは有効
　指向ツールとしてのモデリング
　　全体構造や複雑な構造を可視化して考える
　　手ぶらで下手な考えより図に起こして整理する

・損益分岐を突破するモデリング
　パフォーマンス
　　効果の高いところに集中して適用する
　コスト
　　ミニマムのレベルに抑えて学習コスト・ランニングコストを下げる
　　徹底的だんしゃり

・モデリングにおけるだんしゃりポイント
　　ダイヤグラムの種類
　　記法
　　利用シーン
　　目的
　　気軽に
　　ツールを使う

・ＵＭＬのダイヤグラム構成
　　１３種類
　　せいぜい４～６種類で十分
　　○ユースケース図、アクティビティ図、シーケンス図、クラス図
　　△パッケージ図、状態マシン図

・モデルによる業務とシステムの連携

・上流で使うのは、さらに限られている
　　ユースケース図：ビジネスユースケース図
　　クラス図：概念クラス図
　　アクティビティ図：業務フロー図

・ビジネスユースケース・業務フロー・システムユースケース
　業務とシステムはバラバラではだめ。

・システムユースケース
　　ユースケース記述
　　　　その中の機能一単

・クラス図
　　概念クラス図
　　（分析）クラス図
　　設計クラス図
　　データ設計図

・英検２級レベルで、１級レベルは使わない（通じない）

・モデリングのそもそもの使いどころ
　全体構造を捉える
　　業務の全体の流れや構造を知る
　　・業務全体、システム全体図
　複雑な部分を整理し、理解する
　　特に理解しにくいところを集中的に分析する
　　ホットスポット、考え方の難しいところ
　構造や動作を設計する、検証する
　　業務やシステムの中の主要動作を組み立てしみゅれーシィんする
　　　ワークフローやフレームワークで実現する
　　　As-IsとTo-Beを比較し、課題が化いけるされることを検証する
　抽象化して本質的な概念、構造、メカニズムを捉える
　　　共通性や根本原理に迫る
　　　　アナリシスパターン、汎用システム設計

・目的に合わせたレベルのメリハリモデリング
　　範囲
　　　業務・システムの中でモデル対象にする部分を絞る
　　粒度
　　　業務フローなどでしばしば問題
　　詳細度（粒度とややかぶり）
　　　詳細化過ぎるとかえって本質がみえない
　　抽象度
　　　根本原因までさかのぼる必要は、ほとんどない
　目的を考えるとおのずと適切なレベルが決まる

・小難しくない、萎縮させない
　モデリング原理主義（アンチパターン）に陥らない
　ユーザーを巻き込む：難しい記法は、メモなどで代用する
　ミニマムセットを設定する

・ツールを使う
　Excelや手持ちの汎用ソフトでは生産性が低い
　アナログ的アプローチもある程度ＯＫ
　何といってもastah*

・モデリングの目的をはっきりさせる
　　全貌の理解
　　詳細（複雑なもの）の理解
　　伝達
　　記録

　　スケッチ　　　　　何を書くか
　　設計書　　　　　　どの程度書くか
　　プログラム　　　　どう描くか

　　下記捨てる
　　中間生成物として使う
　　最終成果物として残す
　　保守資料としてメンテナンスする

・企業システムでさらに広がるモデリングビーズ
　　企業システムの疎結合課
　　　ドメイン分割→マイクロサービス
　　えんたープライズアジャイル
　　企業システムのＡＩ化

・古典的アジャイルとエンタープライズアジャイル
　　→要求開発とアジャイル開発の究極コラボ

・エンタープライズのＡＩ化
　ロジック
　固定ルール
-----インテリ---------
　経時変化する経験知：機械学習
　暗黙知　　　　　　：ディープラーニング

■開発に先立つ前さばきで要求の全体像をつかむ
・自己紹介

・本来の要求開発の使用用途
　ビジネス分析
　要求開発：
　　　準備（課題設定からゴール設定）→
　　　立案（現状分析）→
　　　デザイン（あるべき姿のデザイン）→
　　　シフト（システムが担うべき役割）→ＲＦＰとか
　システム開発

・なぜ、システム開発の前さばきが必要か
　技術要素が先行し、目的が明確でない
　要求があいまい

→けっこうわけわからない要件定義が出てくる

従来の開発対象
　会計システムの場合
　　お手本になるモノが存在

開発対象の変化
　　従来の開発
　　　参考となる実体が存在する
　　　開発対象のスコープが限られている
　　　システム化の選択肢が限られている

　　いまどきの開発
　　　参考となる実態が存在しない
　　　システム要求の自由度が高い
　　　システム化の選択肢が多い

・時間をかけずにポイントを押さえる
　ＦＰＭ（ふぁいぶぽいんとめそどろじー）rede編（りくあいあめんとでべろっぷめんと、要求開発編）
　ポイントをつかんで効率よくシステム化の土台作りをする

　プロジェクトの本体の目的を明らかにする
　　１．プロジェクトの前提を整理する
　　２．要求の全体像を捉える
　　３．ゴールを設定する
　　　　→１かげつだと、このていど
　立案フェーズ・デザインフェーズ
　　４．業務分析・新業務設計

　シフトフェーズ
　　５．システム要求の明確化


ポイント１：プロジェクトの基本情報を整理する
　プロジェクトを進めるうえでの前提条件
　　→プロジェクト定義書
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門
　　　　　→不明点は確認する

　ステークホルダーを確認する
　　→ステークホルダーリスト
　　　　　ＢＡＢＯＫ，ＰＭＢＯＫ：ステークホルダーリストをつくりなさい
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門


ポイント２：要求の全体像を捉える
・要求が漠然としていると感じる理由
　　ステークホルダーの立場の違い
　　人は自明なことは省略して話す
　　要求分析ツリー
　経営　　　業務管理者　　　システム要求
　
ポイント２：ゴールを設定する
・最終的に達成すべきゴールを設定し、ステークホルダー間で共有する
　システム化により得たい成果について、達成時期や、達成の判断基準を示す
　ゴール記述書
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門
　　定量的に表す

まとめ
・要求開発は時間をかけずにポイントをつかんで要領よく
・要求開発のステップをフルセットで実行するのではなく、ウィークポイントを効率よく整理する
・１００点は求めない