サービス開発を始めるにあたって考えたこと

どうやったらスムーズに開発ができるか。プロジェクトマネジメントには様々な考え方や手法があるがどれをどのタイミングで活用すべきか。迷いそうなので今私が知っている手法と経験から進めてみることにします。

Why-How-What, インセプションデッキに関心があるのでそれを踏まえつつプロセスを整理してみます。

Why-How-What

私が一番理念として置いているのが Why-How-What なのでこれを大前提にする。 https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=ja

何か価値を出したいからサービスを開発するし、価値を出すから使ってもらえる。ではどんな価値を出したいのか。 Why、理由、目的、信念。これをきちんと決めていく。

インセプションデッキ

ささっとできるものならいいですが、そうでもないならばプロジェクトがどういうものかぼんやりしないよう、インセプションデッキを組んで全体像を整理します。

https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

開発プロセス

多分どこかで見直しますが現時点で考えてるのはこんな感じの順番

目的の認識合わせ
方針の決定
大まかな実現方法の決定
期間とコアチームメンバーの決定
QCDS バランスの決定

目的の認識合わせ

プロジェクトの Why を全員で共有する。
代表者だけが認識していると他の人は違う目的で動く可能性がある
- 後半になって全く違う方向性で開発が進んでしまう恐れ
インセプションデッキ: Why Are We Here? を埋める

方針の決定

目的を達成するにあたって何を重視していくか等
サービスの特徴
サービスの魅力
インセプションデッキ: Elevator Pitch を埋める

大まかな実現方法の決定

決めた方針に対してどういう手法を取るか。基本的にはおよそ決まってるとは思うが他のアイデアはないか念押し確認。認識共有。後からもっといい実現方法が出てきたり、設計が終わった頃合いにチーム内で実現方法の認識ズレが発生するのを防ぐ

手書きでもデザインモックでもなんでもいいのでサービスイメージを添えたい

期間とコアメンバーの決定

プロジェクト規模を確認する。実現方法が決まっていればおよその規模感を図ることはできそう。例えば1ヶ月ぐらいでやるのか、3ヶ月ぐらいでやるのか。例えばAチームの7人でやるのか Aチームの7人の他、Bチームの◯◯に詳しい2人が参加してやるのか。

たいていズレるだろうが規模感の認識を持つことを主点とする。「ディレクターは1ヶ月でできるぐらいにしたいと思っていたのにエンジニアはいつの間にか2ヶ月ぐらいの規模感で設計していた」とか「当然Dさんはプロジェクトに参加するのだろうと思っていたのに他のプロジェクトに参加していた」とかが起きないように。

QCDS バランスの決定

実現方法、期間、コアメンバーがおよそ決まったら QCDS で何を重視するか判断する材料は揃っていそう。主に確認すべきことは下記。Quality, Cost はそうそう調整するような要素として挙がらないのが経験上。 Quality は(金銭関係のシステムで)ミスできない、といったものはあるがCDSに影響を与えるのかまだ疑問。

納期は調整できるか
- できる場合はその条件, 程度
- できない場合はその理由
ファーストリリースでの最低限はどのあたりか

続き

続く。

yensaki’s blog

必要なものは締め切り

サービス開発フローのメモ