現役ソリューションアーキテクトが語る〜失敗しない新規事業開発のはじめ方〜 に参加しました。簡単に所感をまとめます。
所感
「魅力的なものを素早く」「無数にある選択肢から成功パターンを探る」「課題への検討と選択を繰り返す」といったところはまさにアジャイルの考え方なのかなと思いました。
自分の場合、規模は小さいものの要件定義から設計、開発、保守運用までやってきたので多少は勘所があるかもしれないけど、わりと自己流なのと、多くのベンダーが関わるような案件はあまりやったことがないため、そのあたりのノウハウは知りたい。
要件定義の「やることを決める≒やらないことを決める」は大事。全体を俯瞰したり将来を見据えて QCDS のどれを優先するか (どれを落とすか) を的確に判断できるようにしないと。
以下、メモから抜粋。
レジャー施設の着券業務とそれを支える技術
- ITデバイス普及
- ITベンダー増
- さまざまな技術スタック
- 選択肢が広い
- 新規事業を始める際の課題になりえる
- 過去
- 安定重視
- 既存の成功パターンに乗る
- 現在
- 魅力的なものを素早く
- アップデート前提
- 選択肢から成功パターンを自ら探す
- 日々の進化が必要
- 個々のスペシャリスト
- それぞれの専門性が高まる
- 相互のコミュニケーションの難易度が高まる
- ソリューションアーキテクト
- 歯車役
- 全体最適化
- 上流工程
- 現場課題をビジネス目線に置き換える
- ビジネスにどのような影響があるか
- 新規事業開発を成功に導く3つのメソッド
- 確実性
- 一貫性
- 安定性
- 確実性
- 正しい選択を繰り返す
- 不確定要素による選択肢の広さ
- リターンとリスクの定量化
- 選択の先にある未来を想像する
- 過去の成功体験に囚われないように
- 一貫性
- フェーズの隙間で情報が欠落する
- 隙間を埋めるアウトプット
- 背景やビジネスインパクトなどを立てる
- 安定性
- リスクの早期発見
- 突発性リスク
- リスク観点や課題を想定したプロジェクト計画
- 受け入れ課題 → モックによる事前説明会
- 性能課題 → 負荷テストなど
- 変更/追加に伴うリスク
- 影響範囲の見極めを誤るリスク
- 変更管理
- 優先度可視化
- バックアッププラン
- ワーストケース
- 疎結合設計
- 影響範囲を見極めやすくする
- 失敗パターンから学ぶ
- トップダウン構想
- 制約と非機能要件
- ボトムアップ構想
- ビジネス構想に対してリスクと課題を積み上げてどこまでできるか決定する
- スピードが損なわれる
- 確実性を求められるプロジェクト
- トップダウン構想
- 理想像を業務フローレベルまで作成
- 段階的リリース+成長を目指す
- 制約と非機能要件
- やることを決める
- やらないことを決める
- 費用対効果の低い機能は実装しない
- 制約を定める
