プロジェクトの基本

2015/1/13

DMM.comラボ勉強会資料

今回の勉強会の目標

1.プロジェクトとは何か理解する

2.プロジェクトの運営体制について理解する

3.失敗したときにどうするか考える

さらっとやるつもりが30ページを超えました。飛ばし気味でいきます。

ボードゲームやったことあります？

Wikimedia: ColonsDeCatane_Lyon_01

ゲームには勝利条件がある

● 勝利条件を満たせば「勝ち」● そうじゃなかったら「負け」

Wikimedia: Pike_and_shot_model

さて、あなたのプロジェクトの勝利条件は？

● これがはっきりしてないプロジェクトは危ない。

● 勝利条件が複数あって、どっちが正解かわからないケースもあったりする。。。。。

Wikimedia: Yokoyama_Norihiro,_Japanese_jockey

プロジェクトとは？

プロジェクトの3要素

● 期間● リソース(ヒト、モノ、金、情報)● スコープ、品質

基本中の基本

どのぐらいの期間で、どのぐらいのお金をかけて、何を作るか

すべてのプロジェクトはこの定義がある。この定義がされていないものはプロジェクトではない。

プロジェクトでないもの: 日々の運用業務、日々の営業業務、など

プロジェクトの勝利条件

● 期間● リソース(ヒト、モノ、金、情報)● スコープ、品質

プロジェクト完了時に、決めておいたこの3要素を満たせてれば勝ち

プロジェクトのボーナス

● メンバー間で成功を分かちあう喜び● プロジェクトオーナーからの感謝● 自分のミッションをこなせた満足感● 個人およびチームの成長、レベルアップ

プロジェクトをやるとボーナスが得られる

ボーナスGETとプロジェクトの成功は違う！！

失敗してもボーナスはある

プロジェクトの3要素は

誰が決めるの？

プロジェクトの3要素はオーナーが決める

プロジェクトオーナー

プロジェクトチーム

プロジェクトマネージャー

依頼

プロジェクトの3要素を決めて依頼する

プロジェクトの3要素を満たすようにプロジェクトを推進する

コンサルタント、監査人は何をするか

プロジェクトオーナー

プロジェクトチーム

プロジェクトマネージャー

監査人

正しく実行できているかチェックを依頼

コンサルタント

プロジェクトの3要素作成等を依頼

監査

ディレクター、プロデューサーって？

● プロジェクトマネージャー、の代わりに、ディレクター、プロデューサーがいるケースもある。

● 映画やテレビ業界等では、ディレクターとプロデューサーがいるのが普通

● チームが大きかったり、外部との調整が必要だったりする場合、責任範囲をディレクターとプロデューサーで分担する。

● ウェブ開発においては、プロデューサーの役割をオーナー側が担うケースもある。

役割 立場 責任を持つもの 責任を持たないもの

プロジェクトマネージャー プロジェクト責任者 期間リソース品質、スコープ

プロデューサー 経済的な責任者 期間リソース

品質

ディレクター 品質面の責任者 期間品質、スコープ

リソース

プロデューサー、ディレクターがいる体制1

プロジェクトオーナー

プロジェクトチーム

プロデューサー

依頼

プロジェクトの3要素を決めて依頼する

ディレクター

立場的には、プロデューサーの下にディレクターが来ることが多い

プロデューサー、ディレクターがいる体制2

プロジェクトオーナー

プロジェクトチーム

プロデューサー

依頼

プロジェクトの3要素を決めて、リソースの手配を行なう

ディレクター期間と品質に責任を持ってプロジェクトを推進する。リソースの追加はプロデューサーに依頼する。

リソースを手配した上で、期間と品質を定めて依頼

営業、部門長の立場は？

プロジェクトオーナー

プロジェクトチーム

営業、部門長

依頼

プロジェクトの3要素を決めて依頼する

プロジェクトマネージャー

営業や部門長は経済的な責任を負う＝プロデューサー的立場

大変です、オーナーがいません！！

● たまにオーナーが良くわからないこともある● 複数団体の共同プロジェクトとか● 税金を使ったプロジェクトとか● 実験プロジェクトとか● オーナーが責任を取りたくなくて隠れてるとか

プロジェクトを中止する権限を持ってる人が真のオーナーです。

これで勝てる？？？

オーナーが欲しいものを

作るのは難しい。。。。

オーナーの決定が遅れると

完成までの時間が遅くなる

体制を変更してみる

プロジェクトチーム

プロジェクトマネージャー

プロジェクトの

3要素を一緒に決めよう！！

何か問題があったら

すぐにフィードバックしよう！！

プロジェクトオーナー

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

http://www.agilemanifesto.org/iso/ja/

アジャイル宣言の背後にある原則

一言で言うと

オーナーとプロジェクトチームとの

相互のリスペクトがとっても大事

http://agilemanifesto.org/iso/ja/principles.html

相互リスペクトがないと酷いことになるので注意

価値観が違ったら分離するほうがお互い幸せだよ

アジャイル開発で良くある誤解

プロジェクト体制とか3要素とかそんなものを決めなくても、アジャイル開発とかDevOpsとかでみんなで走りながら考えれば、なんとなくうまくいくんじゃね？？

アジャイル開発もDevOpsも、価値観を共有することで、決め

るべきものを迅速に決めたり、必要に応じて迅速に変更した

りするための手法。

決めるものはちゃんと決めないと走れません。

仮説でも良いので決めるものは決める！！

うまくいきません

頑張っても

負けちゃうこともあるんだよねえ

「敗軍の将を処罰するのは容易い。

だがそれでは、敗戦の理由と様子と

対策を知ることができない。

シギクトクは諸将の前で戦いの様子

を詳しく語らなければならない」

チンギスハン

古代ローマでは敗戦を喫した将軍は、

高確率で次の戦いでも軍団長として

取り立てられた。理由は「戦って負け

たからには、その敗戦の相手を他の

誰よりも知っているだろう」というも

の。実際にその機会を生かして雪辱を

果たすケースも多かった。

敗戦の原因究明はとても大事

転んでもタダでは起きない！！

Wikimedia: Daruma_dolls

失敗を罰する弊害

1.失敗の隠蔽、責任転嫁が横行する2.プロジェクトのゴール設定が下がる

1.同じ失敗を繰り返す2.チームが成長しなくなる

ただし悪いことはちゃんと処罰する

ローマでも仲が悪い友軍を助けに行かなかった将軍は処罰されている。（罰金刑)私情で判断は戦場ではやってはいけない行為。

プロジェクトをうまく回すためには

努力して、経験して、考え続けよう

1.セオリーはちゃんと勉強する2.沢山のプロジェクトを経験する3.うまくいくように考え続ける

ググって真似してOK、ではない。経験は力にもなるが足枷にもなる場合もある。なぜならば同じプロジェクトは一つもない。自分の頭で考え続けるのは大事。

ゲームでも一緒

おしまい

おまけ（時間があれば）1.システム開発時に考慮すべきシステムのライフサイクル2.システム開発における受発注フロー

システムライフサイクル

企画 構築 運用 廃棄

保守

システムが価値を生み出すのは、運用フェーズ、だけ。

それ以外は、費用が発生するだけなので、そこのフェーズの費用は減らしたい。

費用はフェーズ全体で捉えなければいけない。

受発注フロー

広報

外部組織に依頼するときはこのフローを考慮すること。

現場以外のタスクも考慮すること。

営業 見積 発注 作業 納品 検収 請求 入金

営業、営業事務購買

現場 経理広報