【2026年版】プロジェクトマネジメント実践論｜現役エンジニアが語る！～チームでモノづくりをする時のコツとは？～

奈良女子大学でのプロジェクトマネジメント実践論の講義資料です。

Transcript

1. ©MIXI 2026.05.22 株式会社MIXI minimo事業部 喜多 功次 プロジェクトマネジメント 実践論 現役エンジニアが語る！～チームでモノづくりをする時のコツとは？～
2. ©MIXI 2 2 ⾃⼰紹介 喜多 功次 • ⼤阪出⾝ • 2012年にNAIST（奈良先端科学技術⼤学院⼤学）卒、 株式会社ミクシィ（現MIXI）⼊社 • SNS 「mixi」などいくつかのサービス開発を経て、 現在はサロンスタッフ直接予約アプリ「minimo」の開発
3. ©MIXI 4 4 今⽇お話しすること その① 実際のスマートフォンアプリやWebサイトの開発現場での経験から、スムーズにプロ ジェクトを進めるためのコツや⼼がけについて紹介します。 あくまでも⼀⼈のエンジニアから⾒た個⼈の意⾒です。 体系的な学問としてのプロジェクトマネジメントの話はほとんどありません。
4. ©MIXI 5 5 今⽇お話しすること その② 今回は特に、プロジェクトを進める上で重要な要素として、「コミュニケーション」 を中⼼にお話しします。 MIXIはコミュニケーションの場を提供するSNS「mixi」や友達と協⼒プレイ（マルチ プレイ）を楽しめる「モンスターストライク」、⼦供の写真を家族に共有できる「家 族アルバム みてね」など、コミュニケーションの場と機会を創造する会社です。 もちろん、開発現場でのコミュニケーションも⼤切にしています。
5. ©MIXI 6 6 ⽬次 • プロジェクトについて ◦ 対象となるプロジェクトについて認識を揃える ◦ コミュニケーションの⼤切さを紹介 • コミュニケーションの難しさ ◦ どうして難しいのか、その背景について • 具体例で学ぶコミュニケーションのコツ ◦ 失敗事例を元に、どうすれば良いかを学ぶ • おまけ：常に学び、進化し続ける ◦ AIによる開発現場の変化
6. ©MIXI 「プロジェクト」について
7. ©MIXI 8 8 プロジェクトとは ＞ 基本的に集団で⼤がかりに実⾏するもの 逆に⾔うと、⼀⼈でも、⼩さなことでも、⽬標と計画があればプロジェクトになる。 例：レポートの提出、就職活動、ダイエット（⽬標と計画があれば） 仕事でのプロジェクトは、集団で⼤がかりなものが多い。  プロジェクト（英語: project）は、何らかの⽬標を達成するための計画を指す。  基本的に集団で⼤がかりに実⾏するものを指す。 wikipediaより（ https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88 ）
8. ©MIXI 9 9 なぜ集団（チーム）でプロジェクトを進めるのか • ⼀⼈で進むよりもより遠くまで⾏くため ◦ ⼈数が多い⽅が（基本的には）早くプロジェクトが進む ◦ 個々の専⾨性の違いを活かす ▪ 全てが得意な⼈間はいない ◦ ダブルチェック（レビュー）は⼤切
9. ©MIXI 10 10 プロジェクトの進め⽅ 課題 企画 デザイン 開発 QA リリース UI/UX 設計 要件定義 調査 データ分析 実装 テスト 検証 効果測定
10. ©MIXI 11 11 上流と下流のコミュニケーションが⼤切 • 開発やQAのフェーズで仕様の漏れや齟齬があった場合、再度企画やデザイナーと の調整が発⽣する • 可能な限り早く気づいて修正する必要があるが、上流⼯程担当者のみで完璧な仕 様を作ることは難しい ◦ 役割、経験の違い • 互いに適切なコミュニケーションを取る
11. ©MIXI 12 12 ⼈数が多ければ多いほどプロジェクトは早く進むか？ イエス‧‧‧とは⾔い切れない。 ⼈数が増えると会議や伝達ミスも増え、合意形成にも時間がかかる。 コミュニケーションの効率を上げないと、⼈が増えたのに遅くなる可能性も。 しかし、サービスが成⻑した時や、 より⼤きな挑戦のためには増員は避けられない。
12. ©MIXI コミュニケーションの難しさ
13. ©MIXI 14 14 経験‧⽂化の違い 「会議の議事録取っといて」 会社A ： Wordで書いて全員分印刷して各⾃のデスクに配布 会社B ： Googleドキュメントに書いてSlackでURLを共有 会社C ： オンライン会議で全⾃動でAIが議事録を⽣成してカレンダーに貼り付け    （もはや議事録は⼈の仕事ではない） 同じ⾔葉でも⼈によって受け⽌め⽅が異なる
14. ©MIXI 15 15 興味関⼼の違い 「キーワードを⼊⼒して検索できるようにしたい」 企画 ： 売上にどのぐらい影響するだろうか デザイナー ： どういう画⾯にしたらユーザーは使いやすいだろうか エンジニア ： 検索の仕組みや条件（and/or）どうしようか QA ： 0⽂字で検索したらどうなる？検索結果が⾒つからない場合は？ 役割によって考慮するポイントが異なる 多様な視点があるからこそ、より良いものができる
15. ©MIXI 16 16 みんな違ってみんな良い 違うからこそそれぞれの強みを活かして分担できる。 何がどう違うかを理解し、適切なコミュニケーションを取ることが⼤切。 まずは具体化するために質問をする。 実際にその仕事をしてみるのも⼿。
16. ©MIXI 17 17 ⼤切なマインド：HRT 謙虚(Humility) 世界の中心は君ではない。 君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 尊敬(Respect) 一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう。 信頼(Trust) 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば、仕事を任せることができる。 『Team Geek』Brian W. Fitzpatrick、Ben Collins-Sussman 著、角 征典 訳、オライリー・ジャパン、2013年、p.15 より引用
17. ©MIXI 18 18 逆に ⾔うべきものを⾔わないのもNG。 もちろん⾔い⽅には気をつけた上で、サービスを良くするために本当に必要なのであ れば厳しいことも⾔う必要がある。 ちょっとした質問を躊躇する、ようなことはないですか？
18. ©MIXI 具体例で学ぶコミュニケーションのコツ
19. ©MIXI 20 20 例１ （企画） 売上を10倍にする新機能を 考えたぞ！！ 1ヶ⽉でリリースしよう！！
20. ©MIXI 21 21 例１ （企画） 売上を10倍にする新機能を 考えたぞ！！ 1ヶ⽉でリリースしよう！！ どう考えても半年はかかり そうな複雑で⼤規模な機能
21. ©MIXI 22 22 例１ （企画） 売上を10倍にする新機能を 考えたぞ！！ 1ヶ⽉でリリースしよう！！ どう考えても半年はかかり そうな複雑で⼤規模な機能 （デザイナー‧エンジニア） 無理でしょ‧‧‧
22. ©MIXI 23 23 例１：どうしてこうなった 実は売上が低調で3ヶ⽉以内に売上を倍増させないとサービスクローズ。 短期間で⼤きく出て⼀発逆転するしかないことを企画しか把握していない。 背景が伝わっていないので、他の⼈たちがついてこれない。 認識が共有されれば、厳しい条件の中で⼯夫できないか全員で前向きに議論できる。 情報が全員に共有されていない、と⾔うのはよくある。 途中からJoinしたメンバーに、 過去の経緯が共有できていないことも。
23. ©MIXI 24 24 例１：どうすればよかった （当たり前だが）必要な情報を共有する。 何を共有すべきかの取捨選択や共有⽅法の⼯夫も必要で結構難しい。 ⼤きなプロジェクトで何から何まで全てを共有すると、あるメンバーからすると不要 な情報が多すぎる。 全員に今すぐ共有すべきものか、関係者だけで話し合えばいいのか、興味のある⼈に だけ届けばいいのかなど、共有のレベル感も様々。
24. ©MIXI 25 25 例１：共有⽅法の種類 ⽴ち話、会議、チャット、メール、ドキュメントなど。 ⼩さなチームであれば常に全員で会議することも可能だが、基本的には必要なメン バーだけで話し合うことになる。 どの⼿段でも、参加していない他のメンバーのために経緯や決定事項をドキュメント 化しておき、各⾃が必要な時に知りたい情報に辿り着けるようにする。 AIのためにも情報を残すことが⼤切。
25. ©MIXI 26 26 例２-Ａ （デザイナー） デザインの確認お願いします！ ここの⽂章が分かりにくいですね このボタンはもっと⼤きい⽅がいいです （デザイナー） まだラフなんでそんな具体的なところまで 考えてないんだけど‧‧‧
26. ©MIXI 27 27 例２- B （デザイナー） デザインの確認お願いします！ そもそもユーザーって何に困ってるの？ この施策の効果ってどのぐらい？ （デザイナー） もう完璧にデザイン仕上げたのに このタイミングでそこ‧‧‧！？
27. ©MIXI 28 28 例２：どうしてこうなった 何を確認すればいいのかの認識がズレている。 確認お願いします、だと何を確認するかを相⼿に委ねてしまっている。
28. ©MIXI 29 29 例２：どうすればよかった 認識を揃える、期待値を調整する。 現状のステータスと何を確認して欲しいのかを伝える。 背景や経緯などをまとめたドキュメントも⼀緒に伝える。
29. ©MIXI 30 30 例２：認識の違い 昨年、依頼者と確認者の認識を揃える例として、卒論や修論を指導教官に⾒てもらう 時の話をしました。 学⽣からすると指導教官は⼀⼈だけど、指導教官からすると学⽣は10⼈ぐらいいるの で、再提出時には前回の指摘と修正ポイントを添えると良い。 でも、奈良⼥⼦⼤では指導教官あたりの学⽣数が⾮常に少なく、そもそもこの問題が 発⽣しにくい構造。 これがまさに「認識」の違い。
30. ©MIXI 31 31 例３ （企画） 〇〇機能を作ろう 仕様はこれで〜 （デザイナー） 画⾯のイメージは〜 ここにボタンを〜 （エンジニア） ‧‧‧
31. ©MIXI 32 32 例３ （企画） 〇〇機能を作ろう 仕様はこれで〜 （エンジニア） 課題と施策がずれてる ここの仕様が⽭盾している ボタンの配置が分かりづらい ⼯数多すぎて無理 もうちょっと整理してから持ってきて （デザイナー） 画⾯のイメージは〜 ここにボタンを〜
32. ©MIXI 33 33 例３：どうしてこうなった 指摘は事実としては正しい。 しかし、正論かどうかよりも、それでプロジェクトが前に進むかどうかが⼤事。 批判するだけになっていて、改善に繋がらなければ意味がないし、雰囲気を悪くして プロジェクトが後退する可能性まである。 悪化するとユーザーではなく厳しい発⾔をする⼈のことを考えた企画が出てくる。
33. ©MIXI 34 34 例３：どうすればよかった 意図や理由を聞く なぜかを聞くと職種や⽴場による視点の違いがわかったりする 前提となる条件について共通認識ができていない、など 単純な考慮漏れや⾒落としの場合も ⾔い⽅の⼯夫 NG：これは使いにくそう、OK：こうすればもっと使いやすくなりそう 思いつかない場合はそれも伝えると良い ⾃分もいいやり⽅は思いつかないですが、ちょっと使いにくそうじゃないですか？
34. ©MIXI 35 35 例３：⼯数について ⼯数=その作業に必要な期間 前提として、⾃分の専⾨分野でも、事前に⼯数を予測することは⾮常に難しい。 経験のない他職種の⼯数の予測はもっと難しいので、難しさを説明することが⼤切。 ⼀番⼤事なことは、仕様をシンプルに保つこと。（シンプルイズベスト） ただ削るのではなく、サービスのコンセプトやユーザー層、課題や⽬的などから、何 を重視して残すべきかを考える。
35. ©MIXI おまけ：常に学び、進化し続ける
36. ©MIXI 37 37 AIによる開発現場の変化① • AIの進化 ◦ 去年は半分以上AIがプログラミングしていると紹介 ▪ 今はほぼ100% ◦ エンジニアは⾃分の専⾨分野ではない領域の開発にも挑戦 ◦ ⾮エンジニアが⽇常的にプログラミング • そのうちAIが⼈間同⼠の間に⼊ることで今回話したことを考えなくて済むように なるかもしれない ◦ さすがにリアルタイムの会議だと難しい
37. ©MIXI 38 38 AIによる開発現場の変化② プログラミングなどの「作業」はAIに任せる ⼈間の仕事は判断や調整 HRTなどのコミュニケーションへの向き合い⽅がより⼀層⼤事になる 特に、多様なメンバーを動かし、納得感を持ってプロジェクトを進める「泥臭いコ ミュニケーション」は⼈間にしかできない
38. ©MIXI 39 39 まとめ • プロジェクトを進める上でコミュニケーションは重要だが難しい ◦ なぜ難しいのか、違いを理解し、どうすれば良いかを考える • 良いコミュニケーションの⼟台は「HRT」の精神 ◦ ⾔うべきことは⾔いながらも、質問や伝え⽅を⼯夫しましょう • 常に学び、変化に対応しつづけよう ◦ AIの活⽤などプロジェクトの現場も常に変化しています 今回のお話が、今後の皆さんのプロジェクト活動の⼀助となれば幸いです。
39. ©MIXI