Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロマネ視点のリスクマネージメントについて.pdf

4a420507dcd01a4de3fef97533391d09?s=47 2ca3
June 17, 2019
220

 プロマネ視点のリスクマネージメントについて.pdf

4a420507dcd01a4de3fef97533391d09?s=128

2ca3

June 17, 2019
Tweet

Transcript

  1. プロマネ視点のリスクマネージメントについて ネオス株式会社 小林司

  2. 自己紹介 * 名前:小林司 (jbug参加は3回目) * 1978年 千歳市生まれ 40歳、嫁*1、子ども*3、犬*2と生活 * 趣味:キャンプ、バドミントン、バスケ、特にレバンガ北海道 応援してます

    * 悩み:老眼、滑舌が悪い事 * Backlog歴:4年くらい * 経歴 不真面目な学生時代を過ごした後、札幌のシステム会社でエンジニアスタートする。 入社 1ヶ月 後に要件整理のため、数ヶ月東京に行く事になるが、途中でプロジェクトが変わって、なんだかん だで10年間 東京で過ごす。Web系を中心に活動後、札幌に戻りネオスに入社。現在はマネー ジャぽいのだけど、何でもやらされる人をやってます。
  3. ネオスの紹介 所在地
 本社    :東京都千代田区神田 札幌オフィス :6末に移転予定(北1条通りのヤマダ電機の近く) 
 連結従業員数
 240名くらい 札幌は20数名 


    設立
 2004年4月
 事業内容
 ソリューション事業
 コンテンツ事業
 デバイス事業
 弊社のBacklog利用状況 
 特別な理由がない限り、プロジェクト管理はBacklogを使います。 
 50以上のプロジェクトが動いている(自分が入ってるのだけで11あったので) 
 
 お客さんとのコミュニケーションでもBacklog使うケースが増えてます。(お客さん側が持ってる事も多い) 

  4. 本題

  5. プロジェクトが成功する確率 ってご存知ですか?

  6. 52.8% 出典:日経コンピューター

  7. 約半数のプロジェクトは失敗 と言われているわけです

  8. 失敗の定義 • 計画よりスケジュールが遅延する • 計画よりコストがかかる • 顧客満足度が低い 日経コンピューターの基準

  9. 当たり前ですが  失敗の原因(リスク)を早期に発見し 管理していくが大事 だとおじさんは思うわけです

  10.  聞いた話や実体験から こんな開発は危ない ケースを考えてみました

  11.   プロジェクトのゴールが曖昧だったり 共有されてなかったり

  12.   スケジュールが お客様に言われるがままに動く

  13.   アジャイルとは、いつでも 仕様変更できる事だと思っている

  14. 色々な決定が、先延ばしにされがち 「とりあえず」や「一旦」が多い

  15.   口頭やメッセンジャーのみの 情報伝達が蔓延している

  16.   言われたまま作る →ちょっと考えよう・・・本当の意図

  17.   進捗率が90%から進まなくなる →多少の想定外は想定してよ・・・

  18.   wikiがカオス 古い情報とか 似た非なる情報とか 共有=wikiに書く ではない

  19.   レビューの文化がない →プルリク使いましょ

  20.   プルリクを知らない なにそれ、新しい水ポケモンw みたいな

  21. 最近は流石に見なくなったが ソース管理がファイルサーバ

  22. こんな管理は嫌だ

  23. 原因追求すると 大部分の原因が

  24.   曖昧 にしてること

  25.   孫子の兵法にも 同じような話があります

  26. 敵を知り、己を知れば百戦危うからず

  27. みんな知ってると思うけど・・・意味  敵の実情と自分の実情を知っていれば負 ける事はない →プロジェクト運営も同じだよねーと おじさんは思うわけです

  28. 敵を知るとは・・・ プロジェクトのゴールを明確にする ・顧客が満足するものは何か ・営業観点でのゴールは何か ・お客様の利益と自社の利益と相反することの理解と対応

  29. 己を知るとは・・・ ・プロジェクト進行状態を明確にする ・不明確な事を明確にする ・失敗と改善案を明確にする 等

  30. 以上を踏まえつつ・・・  弊社の対策の 一部を紹介

  31. 口頭やメッセンジャーのみの連絡を禁止  全てチケット化する 口頭で聞いてくる人→教育する チケット化されるまで対応しない

  32. 方向性を曖昧にするの禁止  「とりあえず」「一旦」で 物事を決めるのは基本禁止 やむを得ない場合でも 「いつ決めるかを決める」

  33. 対応すべき事の明確化 1つの課題の中でも やることを明確にする →Backlogのチェックボックス機能活用

  34. チェックボックスの活用

  35. 作業の順番・期間の明確化 開始日と期日は必ず入れ ガントチャートで確認し 基本的に輻輳させない

  36. 作業の順番・期間の明確化

  37. 進捗遅れの早期発見 進捗率付きガントチャート確認

  38. API + python gantt→進捗率付きガント

  39. 問題の早期発見 朝会を実施 無駄に長くならないようにスタンディングで 話しやすい雰囲気を作り上げる 仕組みで解決する・・・ようにする

  40. 進捗遅れの早期発見 毎朝カンバンを確認

  41. API + Google スプレッド→かんばん

  42. 失敗の共有、改善 振り返り(KPT)を 定期的に実施

  43. Google スプレッド

  44.   まとめ

  45. まとめ  • 何事も曖昧にしない • Backlogで見え化する • 足りないものはBacklog APIで作ってしまおう

  46.   自分はBacklogを 見ない日はないです。 有難うBacklog!

  47.   最後に

  48. ネオス札幌の紹介 各種サービス開発・アプリ開発を行っています。 現在、約70名くらいのBPさんに常駐して頂いて、一緒に開発しています。 (開発メンバ、評価メンバ。個人事業主の方や会社単位 等 さまざま) サーバ開発(Python、Node、PHP、JavaScript等)やアプリ開発(iOS、Android) 優秀なエンジニアやプロマネができる方で常駐可能な方居ましたら 是非お声がけして下さい!!!

  49.  本日は大変ありがとうございました! 以上です