Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
多拠点開発の生産性を飛躍的に向上させるプロジェクト管理手法
Search
aketada
November 18, 2021
2k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
多拠点開発の生産性を飛躍的に向上させるプロジェクト管理手法
aketada
November 18, 2021
More Decks by aketada
See All by aketada
設計レビューのコツと心構え
aketada
0
21k
2つの300人日案件をオフショア開発した体験談
aketada
0
270
Quality First & Fastを実現するオフショア開発のポイント9選
aketada
1
2.1k
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.8k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
160
Believing is Seeing
oripsolob
1
140
How to Ace a Technical Interview
jacobian
281
24k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.3k
A better future with KSS
kneath
240
18k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
300
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
170
Game over? The fight for quality and originality in the time of robots
wayneb77
1
190
A Soul's Torment
seathinner
6
2.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
860
BBQ
matthewcrist
89
10k
Transcript
多拠点開発の生産性を 飛躍的に向上させる プロジェクト管理手法 楽楽精算 樋口朱理
樋口 朱理 2019年ラクスに転職し、オフショアを担当。 300人日規模の案件を2件経験。 ベトナムと日本の仲介役をしながらプロジェクト管理をする。 休日は子、犬、酒に専ら費やしている。 最近はプラレール何買うかいつも悩んでいる 株式会社ラクス 楽楽精算開発2課 オフショアチーム
リーダー 自己紹介
多拠点開発の生産性を 飛躍的に向上させる プロジェクト管理手法 複数拠点での開発を指す 外注やベンダー委託 ラクスでいうとオフショア開発
日本 委託先の国 オフショア開発って? • 開発業務を海外企業/現地法人などに委託すること • 人件費が安く労働力が豊富な国が主になっている 中国/インド/ベトナム/ミャンマー/インドネシア などなど •
コミュニケーションのミスや技術力不足による品質などの問題が生じやすい
多拠点開発の生産性を 飛躍的に向上させる プロジェクト管理手法 生産性を良くした話
生産性について 成果を出す上での効率 生産性 = <例>労働による成果:100人日 労働投入量:125人日 生産性:80% 人×時間の労働量 労働投入量 労働による成果
付加価値
結論 これは生産性が良くなったお話です 57.2 60.6 70.4 80.08 59 63.3 67.1 85.1
55 60 65 70 75 80 85 2018 2019 2020 2021 生産性(%) 年度 4年間の生産性 目標 実績 目標達成
多拠点開発の生産性を 飛躍的に向上させる プロジェクト管理手法 プロジェクトリーダー、プロジェクトマネージャー向けのお話
覚えてほしいプロジェクト管理手法3つ • ニュアンスはすべて言語化 • KPIでしっかり監視 • 「話す」機会を習慣化
ニュアンスはすべて言語化
多拠点開発における問題あるある 要求の認識齟齬
課題 • オーダーの受け渡しで認識齟齬が多い • 細かいニュアンスが伝わらない • 期待通りのOutputにならない うん、理解した エラーデータを 消してほしいんだな
理解した? エラーをチェック してほしい
要求の認識 成果物 仕様の確認 NG データを消す 大丈夫? OK Garbage-In Garbage-Out
原因 発注側が抽象的な要求をしている
はじめのオーダーが大事 • より正確な伝達を努める • ベンダーに忖度させない • NG「後出しジャンケン」「ちゃぶ台返し」 • はじめから高い要求水準を設定しない
アクション:確実に具体的に伝える 依頼テンプレートをRedmineで運用 ・背景 5W1Hで伝える ・効果 なぜ改修したいのか ・As-Is/To-Be ・前提/除外条件 ・変更箇所 ・性能・拡張性/運用・保守性/セキュリティ
・成果物 Report?Coding?
* 概要 / Outline ** #00000 で対応した集計方法を最適化する * オーダーが発生した背景・経緯 /
Background, History ** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ** 実際はAPI化した際にAPIを呼び出す回数でカウントを取りたい。 ** 現状だと正確にカウントが取れているわけではないため、YYYYYYYYYYZZZZZZZZの画面で「検索」を押したときにカウントを取るようにし たい。 * 理由 / Reason ** なぜ改修(修正)したいのか / Why we want to repair(fix) *** より正確なAPI呼び出しをする回数のカウントが取りたいため *** XXXXXXXXXXXXXXXXXXXXXXXXXXXX **** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ** 改修(修正)をしないことでどのような影響があるのか / What is the impact of not repairing(fixting)? *** API化検討に必要な情報が揃わず、API化されない * 実際の現状 / As-Is ** ZZZZZZZZZZZZに遷移する、伝票の「ZZZZZZZZ」ボタンでカウントを取っている * あるべき姿 / To-Be ** APIをコールする、ZZZZZZZZ画面の「検索」でカウントを取っている * 対応方針 / Policy ** YYYYYYYYYYSDK内にソースコードの埋め込みができるか調査する ** 可能な場合、修正する * 対応内容 / Content ** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX * 条件 / Conditions ** 前提条件 / Prerequisites *** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX *** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX * 変更箇所 / Scope ** YYYYYYYYYYZZZZZZZZZZZZ * 成果物 / Output ** Report ** Coding * バージョン / Version ** XXXXXXXXXXXXXXXX * 派生元ブランチ / Derived from branch ** master * 優先順位 / Priority ** High * 期日 / Dead Line ** 11/8 * 標準工数 / Hour ** Report:5人日 ** Coding:標準工数見積もり次第 h3. 内容 YYYYYYYYYYAPI化の対応のため、 ZZZZZZZZを利用しているカウントをする。 案1、案2のどちらでも可能です。 案1: * XXXXXXXXXXXXXXXXXXを押したときにログを出力する ** ログファイルから、ログを出力した回数を検索しやすい形にする ** 既存で検索しやすいログが出ていればそのままでOKです。 案2:* XXXXXXXXXXXXXXXを利用する XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXX * 上記のログを検索するスクリプトの実装案を考える * スクリプトの作成 h3. その他 * 工数 ** 調査:40h ** 実装・単体テスト:40h Before After
要求の認識 成果物 状況の確認 NG 大丈夫? OK Garbage-Inを解消 エラーをチェックする
要求の認識 成果物 状況の確認 NG 大丈夫? OK エラーをチェックする Garbage-Outは解消されない
要求の認識 成果物 状況の確認 NG 大丈夫? OK エラーをチェックする 仕様の確認に課題あり
KPIでしっかり監視
KPI 数字で日々の業務を監視 • 生産性 • 労働による成果:付加価値 • 開発稼働率 • 質疑応答の速度
1件3時間で回答 • レビューの速度 1件3営業日でフィードバック
案件別で監視する • D案件低くない? • 見積もりの見直し ⇒辛すぎた? • ベンダー側にヒアリング ⇒どこか難しかった?詰まってない? 案件
生産性 A案件 80% B案件 80% C案件 90% D案件 20% 労働投入量の比率で見る • 手が空いてる?忙しすぎる? もっと付加価値を出せる 忙しすぎると余裕がない ⇒バランシングが大事
KPIの利点 • 数字でプロジェクトの動向を観察できる • 予期しない報告が来ることが少なくなる • 状態の裏取りができる
「話す」機会を習慣化
状況の確認 大丈夫? OK 課題 • コミュニケーションの壁がある • 遠慮がある
大丈夫? OK 沈黙は金 何も言ってこないから 順調なんだろうな やべぇ 全然納期に間に合わねぇ そもそも仕様がわからない プロジェクト大炎上・・・ なんて言い訳しよう
とりあえず、黙っとこ
• 「嵐の前の静けさ」を警戒する • 発注者が本音を開示してこそ、ベンダーも本音を話す • ベンダーの本音を引き出す雰囲気づくりも大切 心構え
よくコミュニケーションをとる • 用がなくてもまず話す(雑談する) • 質問コーナーを設ける • 新鮮なうちにレビューする
要求の認識 成果物 状況の確認 エラーをチェックする 要求と状況の改善で成果物が良くなる OK 〆作業で必要なんだ ユーザーごとに違うんだよ なんでチェックするの?
結論に戻ります
結論 これは生産性が良くなったお話です 57.2 60.6 70.4 80.08 59 63.3 67.1 85.1
55 65 75 85 2018 2019 2020 2021 生産性(%) 年度 4年間の生産性 目標 実績 目標達成 覚えてほしいプロジェクト管理手法3つ • ニュアンスはすべて言語化 • KPIでしっかり監視 • 「話す」機会を習慣化
ご清聴ありがとうございました