大手ユーザー企業に入ってマネジメントでやってみたこと
•
0 recomendaciones•345 vistas
Scrum Fest Osaka 2020 #京都トラック での登壇資料です。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (13)
Similar a 大手ユーザー企業に入ってマネジメントでやってみたこと
Similar a 大手ユーザー企業に入ってマネジメントでやってみたこと (20)
Más de Takuya Kitamura
大手ユーザー企業に入ってマネジメントでやってみたこと
- 1. ⼤⼿ユーザー企業に⼊って マネジメントでやってみたこと Scrum Fest Osaka 2020 #京都トラック 1 2020.06.27 北村 拓也
- 2. 2 ⾃⼰紹介 北村 拓也 （Twitter : @chipstar_light） 転職２回 1社⽬は中堅SIerに⼊社。⾃社プロダクトのPMと課⻑を兼務。 2社⽬はベンチャーのコンサル会社で技術導⼊コンサルと受託開発。 現在は⼤⼿メーカー所属 2017年6⽉にキャリア⼊社 IoT・AIブームに乗っかりIoTサービス開発に従事 IoTサービス開発プロジェクトのマネージャー兼同製品開発組織の課⻑ コミュニティ活動 京都アジャイル勉強会（#京アジャ）運営のお⼿伝いしてます。 時々JAWS-UG関連のコミュニティに出没します。
- 3. 3 プロジェクトマネジメントと組織マネジメント • プロジェクトマネジメント • プロジェクトとは、”独⾃のプロダクト、サービス、所産を想像するために実施する有期 性のある業務” • 限られた期間の中で結果を出す • ゴールに直接つながらない取り組みは可能な限り削ぎ落とす • 組織マネジメント • 組織（課／部／会社など）は基本的にできるだけ⻑く存続させる事に価値が置かれる • 中⻑期的な視点でゴールを設定し、⼈の育成や制度の改⾰を⾏う • 両者は時間軸の観点で性質が異なる • 適⽤すべきプラクティスも異なる
- 5. 5 プロジェクトの概要 • ⾃社で作っている機器をIoTを使ってサービス化するシステムの開発プロジェクト • 機器メーカーのため、組み込みではない⼤規模サービス開発のノウハウが乏しい • サーバーレスアーキテクチャやモダンフロントエンド技術など最先端への取り組みへの挑戦 IoTプラットフォーム エッジ デバイス 機器 機器 機器 機器 インターネット インターネット エッジ デバイス アプリバックエンド アプリフロントエンド インターネット PMチーム（3名） エッジソフトチーム（10名） IoTプラットフォームチーム（10名） アプリバックエンドチーム（10名） アプリフロントエンドチーム（10名） 統合テストチーム（10名） システム構成 プロジェクト体制
- 6. 6 タイムボックスによる反復型プロセス • 不確実性の⾼いプロジェクト＆期間の⻑いプロジェクト • 計画は”⼀度決めたら変えずに死守するもの”ではなく、”状況に応じて⾒直すもの”と定義 • 定期的に計画を⾒直すタイミングを設ける • 問題の有無に関わらず、マネージャーの介⼊タイミングを図りやすい。 全体計 画 イテ レー ション 計画 開発 振り返 り 全体計 画⾒直 し リリー ス バッファを持 たせた粗い計 画 イテレーション（1ヶ⽉） 少しづつ⾒積 もり精度向上 させる 1ヶ⽉の詳細 計画 1ヶ⽉の実績 を振り返り
- 8. 8 Feature単位の⾒積りと計画 • フェーズ単位の計画ではなく、機能単位の計画を⽴てる • Function単位の計画ではなく、Feature単位の計画を⽴てる 機能 N⽉ N+1⽉ N+2⽉ N+3⽉ ログイン機能 商品検索機能 商品購⼊機能 レコメンド機能 機能 N⽉ N+1⽉ N+2⽉ N+3⽉ ログイン機能 商品検索機能 商品購⼊機能 レコメンド機能 基本 設計 詳細 設計 実装 テス ト 設実テ 設実テ 設計/実装/テスト 設実テ 機能 N⽉ N+1⽉ N+2⽉ N+3⽉ 通信モジュール 商品⼀覧画⾯ 購⼊決済画⾯ メール送信部品 機能 N⽉ N+1⽉ N+2⽉ N+3⽉ ログイン機能 商品検索機能 商品購⼊機能 レコメンド機能 設実テ 設実テ 設計/実装/テスト 設実テ 設実テ 設実テ 設計/実装/テスト 設実テ
- 9. 9 振り返り • メトリクスを使った振り返り • Feature単位の⾒積もりと実績の差 • チームメンバー単位の予定⼯数と実績⼯数の差 • 割り込みや計画時に想定外の作業の量 • テストで発⾒された不具合の件数とその内容 • 気合と根性で頑張るではなく、根拠に基づく改善を⾏える • 定量化した数値で評価する事で、納得性を得やすい
- 10. 10 動くソフトウェアで進捗を管理する • Feature単位で進捗を確認する • 全体計画ではどのイテレーションでどのFeatureを開発するのかを決める • イテレーション計画にて、Featureを詳細タスク化し⽇々のスケジュールに落とす • 進捗はイテレーション単位で確認する • 具体的には、イテレーションの終わりに完成したFeatureのデモを実施する • デモを⾒て期待した動作が得られていたら完成とし、進捗した事とする • 定性的な指標で進捗を管理しない • ガントチャートの進捗やドキュメントの完成報告ではなく、動くソフトウェアで確認する • Feature単位で計画すると、個々のFeatureが完成したタイミングで顧客視点での動くも のが確認できる
- 11. 11 テストの⾃動化 • 回帰テストの効率化 • Feature単位の反復型開発を進めると、初期開発機能のデグレが気になる。 • ⼀度リリースして終わりのシステムではないため、効率的なデグレ確認が必要。 • E2Eテストの⾃動化 • ステークホルダーにも費⽤対効果がわかりやすいE2Eテストをターゲットにする • E2Eテストでは効率が悪い部分は、モジュール単位のテストに取り組む • 強い意志を持って遂⾏する • これまでのどのプラクティスよりも導⼊コストが⾼い • やりきるまで効果が⾒えにくい
- 12. 12 継続的インテグレーション • イテレーション毎に機能を完成させるには、チーム内での早期結合が必要 • チーム間の統合もイテレーション毎に⾏う • 技術領域が幅広いため、Feature別チームではなくFunction別チームになっている • Featureとして統合する専⽤のチーム（統合テストチーム）を設ける • 仕組みが整うまではCI環境（パイプライン）構築の専⾨部隊を設ける エッジソフトチーム IoTプラットフォームチーム アプリチーム 統合テストチーム イテレーション#1 実装#1 実装#2 実装#3 実装#1 実装#1 統合#1 実装#2 実装#2 実装#3 実装#3 統合#2 統合#3 イテレーション#2 イテレーション#3 イテレーション#4
- 13. 13 今後の取り組み • イテレーションの期間を短くする • 振り返り／統合など各種のフィードバックサイクルが１カ⽉では⻑い • 良かった取り組みをクローズアップした振り返り • 定量的なメトリクスを⾒ると悪い部分がフォーカスされがち • Functionチームではなく、Featureチームにする • メンバーの多能⼯化 • 顧客価値の検証を中⼼にした開発プロセスへの⾒直し • 市場に出すまでに時間をかけすぎており、フィードバックサイクルが遅い • もっと⼩さく、もっと早く
- 15. 15 組織の概要 • 社内の特定分野のIoTシステム開発を担っている部隊 • 中途⼊社のため、⾃分とメンバーはお互いに⾯識がない状態からのスタート 課⻑ 係⻑C 係⻑B 係⻑A 主任B 主任A 主任C 主任D 主任E 主任F 主任G メンバー２名 メンバー４名 メンバー2名 メンバー2名 メンバー3名 メンバー３名 メンバー２名
- 16. 16 1 on 1 • ５つの⽬的 1. メンバーとの信頼関係づくり • 旧時代の飲みニケーションの代わりのオフサイトコミュニケーション • コミュニケーションは質よりも量が⼤切 2. 困っている事や業務をブロックしている事のヒアリングと排除 • 普段の業務中では難しい、相談しやすい場作り • 1on1は⾃分のためではなく、部下のためである • 相談する事で協⼒が得られる事を体感してもらう事が⼤切 3. ⻑期的なキャリアイメージのすり合わせ 4. 直近の⽬標設定と達成に向けた⽀援 5. 組織のミッションやビジョンの浸透 • ⽉に１回１時間、係⻑、主任クラスと実施 • 係⻑、主任にはメンバーとの1on1を依頼し、状況をシェアする
- 17. 17 ⼈材ポートフォリオ • 組織に必要な⼈材の分布を確認するツール • ⼤きくマネジメント型⼈材とエキスパート型⼈材の軸で分析 • エキスパート型には企画・開発・試験など様々な専⾨性が含まれる • この図のどの当たりに⾃分がいるかをプロットしてもらう マ ネ ジ メ ン ト エキスパート（専⾨性） 係⻑相当 主任相当 課⻑相当 サポート が必要 ⼀⼈で 対応可能 ⼈に教える 事ができる 全体を デザイン できる • 多くの⽇本の⼤⼿企業では、キャリアはマネー ジャーになるというパスのみ • マネジメントを伸ばさないと昇給昇格が⾒込めなくなって いく • この事実を受け⽌めるところから始める • ⾃分はどの⽅向に進みたいか希望を聞く • 必ずしも全員がマネジメント型に進むわけではない • 1on1を通して議論する • 議論した⽅向に向け⽬標設定する Aさん Cさん Kさん Lさん Jさん Dさん Eさん Fさん Hさん Iさん Gさん Mさん ⾼い ⾼い 低い
- 18. 18 スキルマップ • メンバー毎に業務に必要な技術レベルがどこにあるかプロットしたもの • ドメイン毎にいくつかのマップを作る • ⽬標を可視化し1on1を通してフォローする • 数値の厳密性や他者との⽐較に着⽬しない • 数値による評価ではなく、あくまで個⼈の⽬標管理として⾒てもらう • マネージャーは俯瞰して組織に⾜りない技術を分析する 組み込み バック エンド フロント エンド CI 運⽤ 開発チーム マネジメント プロジェクト マネジメント 組織 マネジメント Aさん 3 4 ↑ 3 ↑ Bさん 4 1 ↑ 3 ↑ 1↑ Cさん 2↑ Dさん 1 2↑ ↑ Eさん 1 1↑ 1↑ Lv1:サポートがあれば対応可能 Lv2:１⼈で対応可能 Lv3:⼈に教えることができる Lv4:全体をデザインできる
- 19. 19 今後の取り組み • 1on1の1回当たりの時間を短縮して、頻度を上げる • メンバーと細⽬にコミュニケーションをとれるように マネジメ ント型 クリエイ ティブ型 エキス パート型 オペレー ション型 • 2軸から4軸の⼈材ポートフォリオにする • マネジメント／エキスパート／クリエイティブ ／オペレーションの４軸に • 参考：クレイア・コンサルティング https://www.creia.jp/service/s-psreform/4725 • マネジメント以外の⽅向性を広げる
- 20. 20 まとめ