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
2.1k
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
280
Quality First & Fastを実現するオフショア開発のポイント9選
aketada
1
2.2k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Optimising Largest Contentful Paint
csswizardry
37
3.9k
GitHub's CSS Performance
jonrohan
1033
470k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
The Pragmatic Product Professional
lauravandoore
37
7.4k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
270
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
420
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
66
57k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
650
Ethics towards AI in product and experience design
skipperchong
2
330
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でしっかり監視 • 「話す」機会を習慣化
ご清聴ありがとうございました