Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
プロジェクト
の基本
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.システム開発における受発注フロー
システムライフサイクル
企画 構築 運用 廃棄
保守
システムが価値を生み出すのは、運用フェーズ、だけ。
それ以外は、費用が発生するだけなので、そこのフェーズ
の費用は減らしたい。
費用はフェーズ全体で捉えなければいけない。
受発注フロー
広報
外部組織に依頼するときはこのフローを考慮すること。
現場以外のタスクも考慮すること。
営業 見積 発注 作業 納品 検収 請求 入金
営業、営業事務
購買
現場 経理広報

More Related Content

プロジェクトの基本