感情タグBEST3
Posted by ブクログ
やってみないとわからないものの、実態の流れに沿った形で、想像できるレベルの仔細さが良かった．
実例を用いたケースで照会していくのは良いが、オンライン(EC)のパン屋(toC)というのがピンとこなかった．大きな企業で扱うtoBケースが例となっていればよかった．
読者の前提としては、DXプロジェクトの対比として出される基幹系(情報系)システム開発プロジェクトの一連を経験してないと想像できないかもしれない．また、DXの２種：新商品・サービス系DXと事務系DXのうち、前者が対象となっている．
Posted by ブクログ
積読になっていたけど今更ながらに読んだら、2020年に業務で悩んだことと繋がって納得する部分が多くあったので、良書だったんだなぁと今更ながらに思ったりした。
Posted by ブクログ
各種dxプロジェクトにおける大事な考え方を整理してくれている良著。
メモ
・pmに求められる3つの行動
aiなど最新技術の使い方を理解する
競合類似事例を常に把握しておく
要求課題を積極的に整理提案する
・サービスの企画とは以下の3つを明確化すること
顧客は誰か、どんな課題を解決するか、何を使って解決するか
・アジャイル開発を成功させる条件
システム開発規模が大きくない
高品質が求められるシステムでない
プロダクトオーナーがいて意思決定できる
スキルの高いエンジニアが確保されている
・部分的なアジャイル
企画から要件定義、設計から実装は導入可能な部分。
・タスクフォースを組織し、縄張り争いやお見合いを防ぐということ
プロダクトオーナーを置くことにより素早い意思決定と製品サービスの整合性確保を行う。
・構想フェーズで決めること
サービス企画
サービス要求定義
事業戦略・計画
次フェーズ計画
・サービス企画プロセス
何をするかから定義。保有技術があればそれによって解決しうる顧客や課題を定義。
仮説は質的量的に評価する。
利用者規模推定。インタビューや生の声から質的にも仮説を具体化。
サービス案絞り込みの評価基準例
想定効果＝課題解決度合い
コスト、実現難易度
・サービス要求定義プロセス
アイデアを具体化。どのような機能をつけるか、業務は何が必要になってくるのか
ユースケークの整理。どんな人のどんなユースケースが想定されるのか。対象者はいつ何をするのか。利用シーンを具体化する。フロー図を作成してみる。そこからサービスの要求項目が決まってくる。さらにはシステム機能やデータ一覧を作成。その後の事業計画策定時の定量化にもつながる部分。
システム構成図を作成し、俯瞰的にみられるようにしておく。
・事業計画、戦略策定プロセス
3c4pなども活用し、収益性や優位性構築していくための計画をたてる。
システム構成図や機能一覧から開発コストを洗い出し、見積を行う。
さらに、初期費用回収時期、顧客獲得数などマイルストーンや目標をたてつつ、収支計画をたてていく。
・フェーズ計画作成。プロジェクト計画書の作成
サービス企画、スコープ、開発フェーズ、スケジュールをおりこむ。
要件定義。作業、役割分担、体制、リスクと対応方針、マイルストーン、管理計画
・pocについて
規模が大きい場合はpocを行ってから要件定義を行う。要件定義が無駄にならないようにするため。
・poc計画書に記載すべき内容
目的、目標
スコープ
実施内容
システム・環境
準備実施作業
体制役割
スケジュール
管理運営方法
・スコープはサービス全体のどの部分をpoc検証するかを示すもの。図示がおすすめ。
・実施内容はどんな検証を行うかをまとめるもの。
・準備実施作業は関係者のタスク。データの抽出条件、データ依頼、連携環境構築、モデル構築など。
・ですとマーケティングはpocよりも先に行う。仮説やサービス案が変わったら利用する技術も変わりうるため。
・新サービス開発の要件定義で必要な作業
フロントエンド機能要件定義
業務要件展示も管理機能要件定義
ai機能要件定義
バックエンド機能要件定義
非機能要件定義
・構想フェーズで広げた風呂敷を、要件定義では一定度とじていく。具体化とともに。
・非機能要件定義
可用性要件 継続稼働をどこまで担保するか、冗長性含む。
性能拡張性要件 アクセスユーザー数、レスポンス要件。サーバーダウンしないよう。
セキュリティ要件 なりすまし、認証機能など
・デザインは即断体制をつくる。改善点一覧でリリース判定。
デザイン確定に向けた現場責任者を明確にし権限委譲する
トンマナを現場責任者とデザイナーの間で合意する
全てのデザインを現場責任者が確認し、デザイナーとの間で合意する。
・
