• どういったスタイルのマネジメントが求められますか？
• 職位に対してどういった役割が期待されていますか？
• PMのペア体制とはどのようなものですか？
• ゆめみの開発マネジメントの特徴を教えてください
• ゆめみでPMを⾏う魅⼒を教えてもらえますか？
• PMは営業も⾏ったりしますか？
• PMとしての責任範囲を教えてください
• 所属人数・外部委託⽐率を教えてください
• PMではどういう経歴・特徴の⽅が（直近では）採⽤されていますか？
• ゆめみが求めるPMと典型的にマッチしないケース
• ゆめみのPMグループにおける課題
• アーキテクトではどういう経歴・特徴の⽅が（直近では）採⽤されていますか？
• 参考）ゆめみPMアンケート結果

どういったスタイルのマネジメントが求められますか？

職位に対してどういった役割が期待されていますか？

PMのペア体制とはどのようなものですか？

• 「ペア体制について」
• ゆめみの場合、全社的にレビュー体制やペアワークを推奨しています
• プロジェクトマネジメント体制としては、中規模以上のプロジェクトにおいては、PMを2名体制とするペアマネジメントを方針として採用しています（５年以上前から実施）
• その場合、メインPMとサブPMという役割分担をした上で体制を組みます
• 全てのプロジェクトにおいて完全に２名体制を敷いて効果的にできている訳ではないですが、可能な限りペアで行うという事を心がけています
• 理由としては３つあります
1. 一人に依存してしまうと単一障害点になってしまうため、平準化を進めていく
2. PMも色々なタイプがあって得意・不得意もあるので、カバーするサブPMが必要
3. PMもマネジメントチームに所属して５〜７名のPM同士が連携して、複数のプロジェクトをマネジメントしていくという方針であり、ローテーションを行っていく必要があるため

ゆめみの開発マネジメントの特徴を教えてください

• 初期リリースにおいては、期限が決まっている中で開発マネジメントを進める事が多いですが、一方でできる限り良いものを作るという事で、スコープの変更が開発中盤まである事もあります。
• したがって、アジャイル型請負開発とゆめみでは呼んでいるのですが、定められた期限までに品質高いものを納品する中で、コストも限られているため、QCD（Quality, Cost, Delivery）については制約条件として変える事ができないプロジェクトとなっています
• QCDの制約がある中で、S(Scope）として何をどこまで行うかという事を顧客やゆめみ社内のプランナー・サービスデザイナーと調整していく役割が期待されます
• 一方で、初期リリース後も継続したサービスディリバリーが必要なプロジェクトが多いです
• したがって、二次フェーズ、三次フェーズと大きなプロジェクトのピークが継続する場合もあれば、5名、10名とチームを固定的に確保して、チームのメンバーがいる中で良いものを作っていこうという形で、継続的にサービスディリバリーを行う場合も多いです。
• そのような継続的なサービスディリバリーを行う中で、一定成熟してくるにしたがって、PMの役割はスクラムマスターのような役割を期待されるプロジェクトもあります
• 以上から、所謂ウォーターフォール的な開発マネジメントというよりは、そういった基本的な開発マネジメントに加えて、アジャイル型請負開発・スクラム開発における開発マネジメントが求められるため、規模の大きさによる難易度というよりは、複雑性の高さによる難易度が高いプロジェクトが多いです
• 例えば、初期フェーズのアジャイル型請負開発においては、技術理解、仕様理解、設計理解があった上で、要求変更に伴う仕様変更がどのように設計に影響を与えた上で、技術的な負債にならないかどうかも理解した上で、スコープコントロールが必要となります
• もちろん、技術理解が深くなかった場合は、アーキテクトタイプのPMをサブPMとして入ってもらうなどの分担は可能ですが、最低限の技術理解は必要ですし、仕様理解、設計理解は確実に必要となります。

ゆめみでPMを⾏う魅⼒を教えてもらえますか？

• 開発メンバーと密に仕事を連携する為、モダンなWEB系開発技術理解を深める事ができます
• デザイナーとも連携する為、デザインについての方法論を学ぶ事もできます
• 例）人間中心設計やデザインシンキング
• 顧客と近い、対等な関係性で、B2Cの生活に密着したサービス・ものづくりを行う事ができます
• 複雑性が高いプロジェクトマネジメント経験を身に着ける事ができます
• ピープルマネジメントといった社外では通用しない管理職業務を行う必要がないです

PMは営業も⾏ったりしますか？

• 実施します
• 引き合いがあった場合には「往訪」「ヒアリング」「見積提案作成」「プレゼン」「契約調整」といった所謂「プリセールス」業務を行う事が多いです
• 場合によっては、顧客との契約交渉などのも行う事もあります
• 契約交渉などは本来はセールス担当の役割となっていますが、プロジェクトマネジメント担当兼セールス担当という兼務を行う事ができる人であり、兼務を行っても問題がないような体制がある場合は、専門的な職種としてPMを行っている人がセールス担当の役割を行う事もあります。
• 背景には、ゆめみの役割設計として、自分の得意や関心に合わせてキャリア設計や役割設計を行う事ができるという事もあります
• したがって、セールス担当の役割が不得意な人は、営業行為を行う必要性はなく、専門的な営業職の人の役割をお願いするといった役割分担が行われます

PMとしての責任範囲を教えてください

• 一般的な会社であれば、PMはマネージャーという職位において各種マネジメントを期待されると思います。実際にゆめみも過去そういう時代がありました
• 現在は、PMとしての責任範囲外のマネジメントの以下となります
• ピープルマネジメント
• 目標設定
• 人事考課
• 1 on 1の面談
• キャリア面談
• カウンセリング
• プロフィットマネジメント
• 開発部門などの一定のチームの売上・採算責任
• 各種予算編成
• 各開発チームのアサインメント
• ピープルマネジメントについては、人事評価を行わず給与自己決定により省略できています
• プロフィットマネジメントについては、プロジェクト単体の採算性として計画で定められた工数通りに実績を出す遂行責任は求められますが、採算性における結果責任を求められることはありません。結果責任の定義は下記を参照

• 値決めについては営業が行うという分担をしており、値引きについて採算性が下がったとしても、それを挽回する為の遂行責任はPMには求められません。PMは営業担当がいくら値引きしよとも、もともと見積もった計画工数通りに実績を出すことが求められます。これは、値引きをして受注率をあげた上で、採算責任を求められると、PMは本来品質担保に必要な工数を削ってしまって、高い品質を出すことができず、保守性や顧客満足が下がり、長い目で見れば、採算性が落ちるという原因と結果の法則が落ちやすい為です。
• したがって、ゆめみでは営業が値決めを行い、PMは採算管理として採算状況の可視化を行うことは役割として行いますが、採算責任を一切負うことはないとしています
• また、２０１９年４月からは、プロジェクトメンバーのアサインメントについても責任範囲外となっています
• 通常であれば、PMがプロジェクトに必要なメンバーをアサインするという役割を担います
• ゆめみの場合は、例えば、iOSチーム、Androidチーム、フロントエンドチーム、UXUIデザインチーム、インフラチームというように、細分化された職能毎のチームに分かれている中で、チームに対して、プロジェクトのリソース計画上求められるリソース依頼を行います。
• 依頼を請けたチームは、自チームのリソース状況を考慮して、最適なメンバーアサインをチームが自己完結して行う形になっています
• 一方で、各チームが完全自律して行うには、サポートが必要ということが分かり、現在は、リソースマネジメント担当という役割を設置して、iOS/Android/フロントエンド/サーバーサイドという職能毎の大きなグループ単位において、各チーム間のリソース調整を行なっています
• このリソースマネジメント担当の役割は、PMチームの中から選出されて、持ち回りで行うことが実施されています
• また、PMが開発で手を動かすことはありませんが、開発理解は必要となります
• 上記のプロジェクト構造は下記のような状態になっています

所属人数・外部委託⽐率を教えてください

• 所属人数は３５名となります（2021/10現在）
• 所謂請負で外部に委託している比率は５％未満となっております
• ゆめみのオフィスに常駐してもらっているSES・個人業主などのパートナー比率は全体に対して１０〜１５％の範囲でコントロールしています

PMではどういう経歴・特徴の⽅が（直近では）採⽤されていますか？

• 年代は30~40代が中心であり、シニアな人が多いです
• 経歴は様々ではありますが、大手SIer出身という方は現在は少ないです
• 大手出身の方へのゆめみの認知が低いという背景もあると思います
• 事業会社でB2Cのサービスを行っていたが、内製から外部委託に会社方針として切り替える中で、内製でのサービス作りに関わりたいという方
• 必ずしも、スマホのアプリケーション開発やWEB系の開発ではなく、組み込み系のPMをしていた人
• IT系の開発が強い会社でプロジェクトリーダーをしていた上で、今後PMの役割を担いたいとして、PM候補として入社された人
• 一人でアプリ開発からサーバー構築まで行っていてアーキテクトに強いが、チームとしての開発マネジメントや大規模なプロジェクトマネジメントが経験ないという事で入ってきた人
• 業務系のコンサルティング・開発を行う会社でよりWEB系、B2Cのサービスで開発エンジニアと近い距離で仕事がしたいと入社してきた人
• 大手BtoCメガベンチャー出身で豊富なプロダクトの開発マネジメントを行ってきたが、プロダクトマネージャーというキャリアはあるが、プロジェクトマネージャーという専門的なキャリアがないため、専門的な経験を身に付けられることができるゆめみに入社。

ゆめみが求めるPMと典型的にマッチしないケース

• 外部へ開発をアウトソーシングする事が多く内製開発のマネジメント経験が少ない
• 社内のピープルマネジメントなどをキャリア形成を軸として考えている
• ゆめみは経営方針としてピープルマネジメント業務を最小化しようとしている為
• 数十名以上の人数が多い大規模な開発マネジメントを希望される方
• ゆめみは１０名前後の規模が小さいが複雑性が高いプロジェクトマネジメントを行う為

ゆめみのPMグループにおける課題

• 明確な型や標準と呼ばれるものがなく、ナレッジが暗黙知として各PMに保有されており、ナレッジマネジメントの仕組み化ができていない
• PMの採用がうまく進んでいない時期もあり、その場合にPMに稼働が集中することがある
• PMの役割範囲が比較的広いため、PMへの心理的負担が大きい側面はある

アーキテクトではどういう経歴・特徴の⽅が（直近では）採⽤されていますか？

• 現在のアーキテクトは、WEB系のサーバーサイドの開発を一通り経験した上で、AWSを中心としたクラウドも含めたアーキテクチャの設計経験がある方が多いです
• また、WEB系の開発経験を、スタートから起算して１０年〜２０年といった経験期間があり、シニアな人も比較的多いです
• そのようなシニアアーキテクトは少ない状況です
• 理由としては、そう言ったシニア・アーキテクトは既にいる会社にとって代わりが効きにくいため人材市場では少ない事、及び最近のモダンなWEB系開発では、細分化された技術領域で専門分野を決めてキャリアを気づくため、全技術領域にまたがる経験を築きにくいという背景があります。
• 例えば、スマホ向けのネイティブアプリのクライアントアプリケーションに精通しているサーバーサイドエンジニア出身のアーキテクトはほとんどいないです
• 従って、ゆめみの場合には、ITアーキテクトと言えば、サーバーサイド出身のアーキテクト、明示的にアプリ・アーキテクトと呼べば、iOS/Androidの両OS、プラットフォームに理解があるアーキテクトを指す形として、専門分野を定めたアーキテクト採用を行っております
• その上で、直近についての入社された方については、ITアーキテクト候補として中期的にアーキテクトとして成長していただけるようなリード・サーバーサイドエンジニアという方を想定しております

参考）ゆめみPMアンケート結果

取締役が語る。ゆめみのPMってどんな人？｜ymm_kkaiho｜note

こんにちは。気がついたら取締役までになってしまっていたPMのkaihoです。 取締役と言っても、ゆめみの場合は プレチャレンジ取締役なので、他の会社の取締役の皆様に比べれば、社内的にも社外的にも大きな権力および義務があるわけではない（はず）なので、正直仕事の仕方とか人格が大きく変わるって程でもないです。はず。詳しくは こちら ...

note.com