７月２６日、要求開発アライアンスの
夏は開発スタイルを再考する！
にいってきた。その内容をメモメモ
（表題の話は、後半）
■ビジネスまで最短距離のモデリングを考える
～中規模以上のシステム構築で効果を上げるために～
・今日話したいこと
俊敏な開発が求められている
→アジャイルに行く？行かない
→ウォーターフォール？評判悪い
→アジャイルとウォーターフォールは対立関係にある？
→準備段階でのモデリング、顧客フィードバック指向
・ウォーターフォールＶＳアジャイル
それぞれの至高のメッセージは何か
ウォーターフォール
大勢の人がアツ間得られる前に準備を済ませるほうが経済的！
アジャイル開発
顧客（市場・ユーザー）からのフィードバックを最速で取り入れなさい！
・開発手法の４証言
システム規模
大 小
顧客からの ＹＥＳ ？ アジャイル開発
じんぞくな
フィード ＮＯ ウォーターフォール なんでもＯＫ
バック
？：探すべきは、ここの解
・メガプロジェクトって知ってますか
プラント建設の工程：ウォーターフォール
ＦＥＬ（フロントエンドローディング） IPA
インダストリアルメガプロジェクト
テストを取らないと、次の工程にいけない
ＦＥＬ
ゲート１：ビジネスケース
ゲート２：スコープ
ゲート３：実行開始できるか
背景にあるコストの考え方
リスクや不確実性：下降していく
変更リスク ：上昇していく
アジャイル開発との対比
ＸＰの場合
一定の条件がある場合、変更コストはフラットに近い
変化を受け入れよ→程度問題？
大規模化に伴い、変更コストは加速度的上昇する
最適解は、２つの極端の中間に
つまり、どんなプロジェクトにも適切な準備＞０が必要である
・もっと準備のことを語ろう
準備のことを語るのは恥ずかしくない
準備こそ、語り、継承されるべき
実装を急ぐことが経済性に優れている、キャッシュフロー上好ましいという議論は誤り
コストが大きければ負のキャッシュフローが生まれる
準備の例
エンタープライズアジャイル手法における準備
ＲＵＰ
ＤＡＤ でぃしぷりんどあじゃいるでりばりー
SAFe
政府ＩＴ調達における「準備」
ＲＵＰ／ＵＰ（統一プロセス）
要求分析、アーキテクチャ、ベースライン設計
方向付け：要求分析・要件定義 要件：ビジネス要件
推敲：アーキテクチャ、ベースライン設計
ディシプリンド・アジャイル ２．Ｘ Scott W.Ambler/Mark Lines
方向づけ 構築 移行
推敲がないのは、固定的に考えてほしくないから
コンテキストに合わせてプロセスモデルを選択してほしい
SAFe（Scaled Agile Framework)
一回は離陸させないと・・
政府ＩＴ調達における「準備」
要求分析
アーキテクチャ・ベースライン設計
要件定義からＲＦＰをつくってしまうのは・・・
・何を準備するのか
準備の定番は要件定義
要件のＦＩＸを待ていたら仕事がなくなる
開発環境の変化：要件と並行・先行してアプリに適したやりかた
クラウドネイティブな開発やPaaSへの期待
準備の中心はＷＨＡＴからＨＯＷに移り始めている
ＨＯＷ：ベンダーロックイン？→ＯＳＳで問題をクリア
・ＨｏＷの準備≒（広い意味の）プラットフォーム選定・構築
アーキテクチャベースライン
各種設定・オプション選択
モデリングツール
ＵＭＬ
ＥＸＣＥＬ
ＤＢ
要求定義言語
要求（メタ）モデル
要求・実装変換手法
初期要求モデル（機能・非機能）
創意と信頼の土壌
・アーキテクチャベースラインとは何か
ある種のメタモデル
・機能とシステム要素との関係を洗い出す
・要求実装変換手順
工程を作る
ＨｏＷを上流化：つなぎを明確化
・どうすれば仕様の不連続点を回避できるのか
・プラットフォームに制約された要求モデリング
顧客価値モデル
実装価値モデル
・ショッピングサイトの例
・ますます重要になるＩＴアーキテクトというロール
資質としては
知識
責任感
人や組織に働きかける
■ソフトウェア受託開発の変化と未来
新しいビジネスモデル・ワークスタイル・マネジメント
・自己紹介
・戦術としてのアジャイル、アジャイルのための戦略
環境の中でアジャイルに取り組む
→目標・現場・戦術・意識的
アジャイルになるように環境を作る
→結果・経営・戦略・無意識
Don't just do Agile Be Agile
・アジャイル開発と受託開発
なぜ、アジャイル開発は失敗するのか
ウォーターフォールとの違いは
メソッドか、マインドセットか
アジャイルはなぜ繰り返すのか
すべて作ろうとするから失敗する
おおきくしない・作らない
１００この機能を作るのなら、ウォーターフォールの方が早い
１０こづつつくって、５０こでやめる
受託では１００個つくらないと・・
・受託開発に潜む問題「ディフェンシブな開発」
発注者と受注者でのゴールの違い
使う価値よりも、要件定義に従う
詰め込む要求と計画を守る対立
生産性が低いほど、高くなる見積もり
ビジネスモデルの構造的欠陥
→ボンクラ集めたほうが儲かる
・ディフェンシブな開発がもたらすもの
受託開発ビジネスの本質は保険屋
人月見積もりと成果物責任のねじれ
多重請負の見積もりによるバッファ
使いにくい使われないシステム
誰も幸せになっていないのでは？
世界は変わらない？→「世界」は、変わっている
・世界の変化
ＵＢＥＲ
あずまま（ベビーシッター予約）
企業を取り巻く状況と重要性を増すソフトウェア
ＵｂｅｒやＡｉｒＢｎｂなどのＩＴ企業の登場
既存のマーケットを根底から覆す
ＩＴの利用からＩＴを前提
・これからのソフトウェア開発に求められること
要件の予測は困難で日々変化する
ユーザーが使い始めてからスタート
システムの完成は目指していない
小さく初めてから大きく育てたい
事業の成長を支えるパートナー
→内製：社内にエンジニア
・受託開発に求められる顧客ニーズの変化
事業の成長に合わせて回収したい
長期的視点と経営視点を持つこと
内製は開発者の採用と育成が困難
従来の害虫は高額で柔軟性が低い
新たなニーズに対する受託開発
・納品のない受託開発
月額低額で、開発と運用を続ける
顧問としてすべての工程を担当する
働く時間でなく、成果を提供する
ビジネスの成長をＩＴでささえていく
コンサルティング＋開発
・メリット
要件定義をしなくてもよい
仕様変更はいつでもできる
直接エンジニアに相談してもよい
作らない提案をしてもらえる
お客様の問題解決が仕事
・やっていないこと
ドキュメントはいっさい作りません
訪問しません
営業担当はいません
納期を死守する約束はできません
圧倒的な費用対効果を実現
・ＡｓＭａｍａ
エンジニア０人
ソニックが技術担当
・コモンプログラマという新しい職業
プログラミングで問題解決をする
コンサルタントができる開発者
ソフトウェアすべてに責任
事業成長を支える
難しいから価値がある
・通勤のないワークスタイル
社員の半数が地方から働く
・リモートチームという働き方
仲間と一緒に働くリモートワーク
雇用関係・長期的関係で共に働く
個人の結果でなく、チームの結果
・リモートワークの誤解を解く
顔を見ながらの打ち合わせはある
場所は離れても同じ時間帯に
・オフィスRemotty
同僚の顔や様子が見えて声がかけやすい
自分用に書きこめる場所があって、気軽に発言できる
独り言が流れる
・リモートワークのメリット
生産性のアップ ９時からスタート、会議室の予約要らない
給与格差はない
場所に縛られずに採用できる
選びたい場所と仕事と仲間の両立
オンとオフの小口化ができる
・管理のないマネジメント
社会の変化、テクノロジーの深化
単純労働から再現性のない仕事へ
指示・命令のマネジメントは不適
ナレッジワーク
管理しないが生産性が高い
なにも管理しないと生産性が一番高い
金タイ進捗業務管理しない
役割分担はあるが指示命令はない
上司はおらずセルフマネジメント
ビジョンはあるが売り上げ目標はない
自己組織化された
・業務文章のない組織戦略
属人性を重視
チームを重視
中間管理職を置かない
兼務を推奨（会社に組織図がない）
ヒエラルキーで支配しない
・ピープルファーストの人事戦略
案件あり木で採用せずに人ありき
人材の採用まで長い時間をかける
コア・コンピタンスは採用と育成
仕事の評価と報酬は連動させない
良い社員と良いお客様をつなぐ
ソニックガーデンを支える経営モデル
ストックビジネスだけに集中する
太い客より細い客をたくさん持つ
キャッシュフロー
イノベーションのための部活
お金を稼ぐより時間を稼ぐ
腕を磨くと人月さがる
コンサル：腕を磨けば
遊んでたから、新規事業になった
・管理なくても経営はある
ビジョンを考えて伝えていくこと
率先して変化を起こしていくこと
現場での実体から制度にすること
人に依存しない仕組みをつくること
仕組みで勝って人で圧勝する
・受託開発の未来に向けて
来るべき社会の変化
少子高齢化人口構造の変化
量に頼らず価値を出せる仕事とは
世界に新しい価値を生みだす仕事
誰かの難しい問題を解決する仕事
価値ある仕事へのシフト
・これからの仕事
ナレッジワーク
リモートワーク
ライフワーク
パラレルワーク
一人ひとりの多様性を大事にする
・アジャイル企業の目指すポジショニング
予測型計画重視ー適応型結果重視
ＶＳ
大人数ー少人数
従来型の企業
アジャイル企業
・アジャイル経営宣言
変化への対応
個人の自主性
持続的な顧客価値
社員の幸せ
