プロジェクトの基本

プロジェクト の基本 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要素を満たせてれば勝ち

プロジェクトの勝利条件 ● ● ● 期間 リソース(ヒト、モノ、金、情報) スコープ、品質 プロジェクト完了時に、決めておいた この3要素を満たせてれば勝ち

プロジェクトのボーナス ● ● ● ● メンバー間で成功を分かちあう喜び プロジェクトオーナーからの感謝 自分のミッションをこなせた満足感 個人およびチームの成長、レベルアップ プロジェクトをやるとボーナスが得られる ボーナスGETと プロジェクトの成功は違う！！ 失敗してもボーナスはある

プロジェクトの3要素は 誰が決めるの？

プロジェクトの3要素はオーナーが決める プロジェクトオーナー 依頼 プロジェクトマネージャー プロジェクトチーム プロジェクトの 3要素を決めて 依頼する プロジェクトの 3要素を満たすように プロジェクトを推進する

コンサルタント、監査人は何をするか プロジェクトの3要素作成 等を依頼 プロジェクトオーナー コンサルタント 正しく実行できているか チェックを依頼 プロジェクトマネージャー 監査人 監査 プロジェクトチーム

ディレクター、プロデューサーって？ ● ● ● ● プロジェクトマネージャー、の代わりに、ディレクター、プロデューサーがいるケー スもある。 映画やテレビ業界等では、ディレクターとプロデューサーがいるのが普通 チームが大きかったり、外部との調整が必要だったりする場合、責任範囲をディ レクターとプロデューサーで分担する。 ウェブ開発においては、プロデューサーの役割をオーナー側が担うケースもあ る。 役割 プロジェクトマネージャー 立場 プロジェクト責任者 責任を持つもの 期間 リソース 品質、スコープ 責任を持たないもの プロデューサー 経済的な責任者 品質 ディレクター 品質面の責任者 期間 リソース 期間 品質、スコープ リソース

プロデューサー、ディレクターがいる体制1 プロジェクトオーナー 依頼 プロデューサー ディレクター プロジェクトチーム プロジェクトの 3要素を決めて 依頼する 立場的には、 プロデューサーの下に ディレクターが来ることが多い

プロデューサー、ディレクターがいる体制2 プロジェクトオーナー プロデューサー 依頼 ディレクター プロジェクトチーム プロジェクトの 3要素を決めて、 リソースの手配を行なう リソースを手配した上で、 期間と品質を定めて依頼 期間と品質に責任を持って プロジェクトを推進する。 リソースの追加はプロデュー サーに依頼する。

営業、部門長の立場は？ プロジェクトオーナー 依頼 営業、部門長 プロジェクトマネージャー プロジェクトチーム プロジェクトの 3要素を決めて 依頼する 営業や部門長は経済的な責 任を負う ＝プロデューサー的立場

大変です、オーナーがいません！！ ● ● ● ● ● たまにオーナーが良くわからないこともある 複数団体の共同プロジェクトとか 税金を使ったプロジェクトとか 実験プロジェクトとか オーナーが責任を取りたくなくて隠れてるとか プロジェクトを中止する権限を持ってる人が 真のオーナーです。

これで勝てる？？？

オーナーが欲しいものを 作るのは難しい。。。。

オーナーの決定が遅れると 完成までの時間が遅くなる

体制を変更してみる プロジェクトの プロジェクトオーナー 3要素を一緒に決めよう！！ 何か問題があったら プロジェクトマネージャー プロジェクトチーム すぐにフィードバックしよう！！

アジャイルソフトウェア開発宣言 http://www.agilemanifesto.org/iso/ja/ 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

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

アジャイル宣言の背後にある原則 http://agilemanifesto.org/iso/ja/principles.html 一言で言うと オーナーとプロジェクトチームとの 相互のリスペクトがとっても大事 相互リスペクトがないと酷いことになるので注意 価値観が違ったら分離するほうがお互い幸せだよ

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

アジャイル開発で良くある誤解 プロジェクト体制とか3要素とかそんなものを決め なくても、アジャイル開発とかDevOpsとかでみんな で走りながら考えれば、なんとなくうまくいくんじゃ ね？？ うまくいきません アジャイル開発もDevOpsも、価値観を共有することで、決め るべきものを迅速に決めたり、必要に応じて迅速に変更した りするための手法。 決めるものはちゃんと決めないと走れません。 仮説でも良いので決めるものは決める！！

頑張っても 負けちゃうこともあるんだよねえ

「敗軍の将を処罰するのは容易い。 だがそれでは、敗戦の理由と様子と 対策を知ることができない。 シギクトクは諸将の前で戦いの様子 を詳しく語らなければならない」 チンギスハン

古代ローマでは敗戦を喫した将軍は、 高確率で次の戦いでも軍団長として 取り立てられた。理由は「戦って負け たからには、その敗戦の相手を他の 誰よりも知っているだろう」というも の。実際にその機会を生かして雪辱を 果たすケースも多かった。

敗戦の原因究明はとても大事 転んでもタダでは起きない！！ Wikimedia: Daruma_dolls

失敗を罰する弊害 1.失敗の隠蔽、責任転嫁が横行する 2.プロジェクトのゴール設定が下がる 1.同じ失敗を繰り返す 2.チームが成長しなくなる

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

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

努力して、経験して、考え続けよう 1.セオリーはちゃんと勉強する 2.沢山のプロジェクトを経験する 3.うまくいくように考え続ける ググって真似してOK、ではない。 経験は力にもなるが足枷にもなる場合もある。 なぜならば同じプロジェクトは一つもない。 自分の頭で考え続けるのは大事。 ゲームでも一緒

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

システムライフサイクル 企画 構築 運用 廃棄 保守 システムが価値を生み出すのは、運用フェーズ、だけ。 それ以外は、費用が発生するだけなので、そこのフェーズ の費用は減らしたい。 費用はフェーズ全体で捉えなければいけない。

受発注フロー 広報 広報 営業 見積 発注 作業 営業、営業事務 購買 納品 検収 請求 現場 外部組織に依頼するときはこのフローを考慮すること。 現場以外のタスクも考慮すること。 入金 経理