記事の概要
今回の記事では、プロジェクトを管理するにあたっての開発経験の重要性と開発未経験者が経験を積む方法について解説しています。
みこみこ
ジン
太田フランクリン
0ミリ社長太田フランクリンシステム開発に関して事前に決めてあるステップのことを「開発工程」と呼びます。
一般的には、システムを作るにあたっての提案、要件定義、運用・保守、に至る作業工程を意味します。
「Project Management Office(プロジェクトマネジメントオフィス)」は、プロジェクトマネジメントの支援を行う部門・組織を意味する言葉で、頭文字を抜き出して「PMO」と略して呼ぶこともあります。
PMOは、プロジェクトのマネジメントを行うPM(プロジェクトマネージャー)の活動を支援する部門や組織のことを指します。
特に、プロジェクトの規模が大きくPMが自力でプロジェクトを管理することが困難な場合にPMOが必要となってきます。
PMOとPMは、プロジェクトの成功を目的としてプロジェクトの円滑な進行と品質管理を行う、といった点では共通していますが、PMがプロジェクトメンバーの選定・案件受注・品質管理・進捗管理・コスト管理など様々な業務を行う一方で、PMOはPMが正確に意思決定できるようサポートに回ったり、適切な進行が行えるよう推進や管理などの業務に従事する点で異なります。
PMOの業務は、対応範囲を個々のプロジェクトに絞り、PMだけでは対応できないほど詳細な把握・管理を行う場合もあります。
PMOはプロジェクトによって参加の仕方が異なり、プロジェクトに一名だけ参加してプロジェクト全体の進行をサポートする場合もあれば、プロジェクトに何名かで参加してPMに加えて事業部長やチームリーダーのサポートを各々行う場合もあります。
PMOの役割には、
- PMOアドミニストレーター
- PMOエキスパート
- PMOマネジャー
があります。
PMOアドミニストレーターはプロジェクトの進行を円滑化する事務業務を担当します。情報収集・情報共有・データ管理・会議のセッティング・予算管理・勤怠管理といった業務を引き受けることで、PMはプロジェクトの統括に集中しやすくなり、プロジェクトメンバーは各々の業務に従事しやすくなります。
PMOエキスパートはプロジェクトのさらなる前進を目的として、ルール策定・プロセス改善の他、プロジェクトに有効なツールの開発や調達・プロジェクトに参加するメンバーの育成や教育も担当します。
PMOマネジャーはPMに近く、マネジメント全般を幅広く担当し、具体的には他のPMOのマネジメント・PMOメンバーの勤怠状況管理や教育・PMO組織の予算管理などを行います。
PMOの導入には、PMの負担を軽減しプロジェクトの意志決定速度を向上させる利点がありますが、その一方でプロジェクトへの参加人数が増えることによるコミュニケーションの質や量の確保が課題となります。
みこみこ太田フランクリン少し辛口ではありますが、現場でリアルに起こりがちな話なので是非聞いて頂ければと思います。
みこみこ太田フランクリンジン太田フランクリンPMOっていうのはジン君も言った通り、プロジェクトマネージャーとかメンバーとの調整をしたりプロジェクトの全体的な進行のサポートをしたりします。
「プロジェクトを成功に導くぞ！」というのがPMOの役割です。
ただし、今日のお題目にもある通り、開発行程経験の無いPMOだと予期せぬトラブルに遭遇してプロジェクト全体が遅延もしくは頓挫しかねないので、今日はそのお話をしていこうと思います。
具体例もありますので、開発経験無くてPMOやってる方とか、開発経験は無いけどPMOやってみたいと思ってる方は是非ご覧になってください！
開発工程の経験が無いPMOが直面しがちな困難はどのようなものか？
具体的なプロジェクトの計画を立てる際の困難
太田フランクリン1つ目は、開発工程の経験が無いと具体的なプロジェクトの計画を立てられないんです。
どういうことかというと、プロジェクト計画の策定は成功の鍵を握る重要なステップになるんです。
例えば、僕達が海外遠征に行く時まず何しますか？行先をどこかの国に設定します。
次に、飛行機の手配をしたり宿泊するホテルの予約をしたりします。
太田フランクリンただ、ここで開発工程の経験が無いと現実的に計画行程を立てることは難しくなってしまいます。
太田フランクリン例えばとあるクライアント企業に「新しいECサイトを立ち上げる」という案件があるとします。
そこでお客さんからの要望で新しいユーザー認証機能を作ってほしいという要請が上がります。
もし開発行程経験の無いPMOがいた場合、「1週間で完了できます」と軽はずみに言ってしまう可能性があります。
日本語で言うところの電子商取引、「Electric Commerce」の頭文字を取ってECサイトと呼ぶサイトは、電子的な手段での商取引を行うサイトのことです。ECサイトには、物販を行うサイトに加えて何らかのサービスを提供したり契約手続きを行えるサイトも当てはまります。
実際の例として、映像コンテンツの有料配信を行うVODサービスや楽曲等のダウンロード販売サイトが挙げられます。
みこみこ太田フランクリンいざ受注して開発が進んでいくと、認証方法ってGoogleとかFacebookとか色々あるとか、セキュリティとかしないといけないとか色々な行程漏れが発生するんですよね。
最終的に1ヶ月以上かかってスケジュールに影響があったって話があります。
太田フランクリン開発工程の経験があれば防げた事例です。
開発行程の経験がないPMOがお客様からの要望を受け取って安易な判断でOKを出すとプロジェクト全体に影響が出てしまいます。
太田フランクリンジンそれをその場で見てて、「開発経験が無いのは嫌だな…」と。転職のきっかけになりました。
太田フランクリンやっぱり身近にそういう人がいたんですね。
システムエンジニア(SE)は、情報システムの設計・開発・試験を行う技術者のことを指します。
狭義の意味では、ソフトウェアの開発に関わる技術者の中でもプログラミング以外の業務にあたる人々あるいは職種を指します。
和製英語であり日本固有の概念でもあります。
ジン太田フランクリン正確なタスク管理ができないのが問題で、特に技術面の課題は不確定要素が多いんです。
そのリスクが顕在化してしまうとスケジュールへの影響が非常に大きい。
「割り当てる」という意味の英語「assign」は、カタカナ書きで「アサイン」となります。
カタカナ表記の方はIT・外資系の企業でよく使う傾向があります。
太田フランクリンもし&PMOに開発経験があれば、現場にフレームワークを下ろしたりエンジニアからヒアリングができたりしてそういうリスクは防げるはずですが、開発行程の経験が無いと間違った判断をしてしまいかねない。
アプリケーションを効率的に開発することを目的として用意する土台のことを「フレームワーク」と言います。
フレームワークを基本とし必要に応じて新しい機能を追加実装していく場合は、最初から自力で全て開発する場合に比べて開発工数を相当短縮できるという利点があります。
みこみこ0ミリ社長みこみこ太田フランクリンPMOはプロジェクトのアサイン権、どのポジションにどのエンジニアを入れるかとかアサイン権を権力として持つことが多いですが、このエンジニアのスキルセットと求められてるポジションを適切に把握できてないと間違ったポジションに間違ったエンジニアをアサインするとか結構あるんです。
業務の遂行にあたって欠かせない知識や技術や経験を組み合わせたものをスキルセットと呼びます。
太田フランクリンもちろんJavaScriptとJavaが全然違うということは皆さん知ってると思いますが、PMOが技術領域と求められてるスキルセットを把握しないままアサインすると、後々こんなことやったことないってメンバーから言われたり、全く知らない業務をやらされたメンバーから不満が来たりして、プロジェクトの破綻を起こしかねないです。
JavaScriptは、ブラウザに動きのある要素を加えるプログラミング言語です。
実際の用例としては、ポップアップ画面が出てくる、アニメーションが躍動している、入力フォームが置いてある、などといった動的なWebページの実装が可能になります。
Javaはサン・マイクロシステムズが開発したプログラミング言語で、ネットワーク環境での利用を念頭に置いた仕様が特徴で、強力なセキュリティ機構やネットワークに関する豊富な機能を搭載しています。
ジンアサインされて大変な思いをしました。
自力じゃできませんでした。
C#は、「.NET」というフレームワークを扱うことを目的として、Microsoftが2010年に開発したプログラミング言語です。
実際の活用例として、アプリケーション開発、ゲーム開発、VR、AR、システム開発、などがあります。
C++は、C言語を基本としてオブジェクト指向などの要素を加えたプログラミング言語です。ビャーネ・ストロヴストルップ氏が1979年に1979年に開発して以来の歴史があり、アプリケーションやソフトウェアの開発、ゲームの開発など多岐に渡る活用例があります。
ジンそのまま進むんですけどアサインされた僕はC++キツいってなって大変でした。
システム開発などのプロジェクトに取りかかる前に、必要になる機能や要求を決定する作業のことを「要件定義」といいます。
みこみこジン
太田フランクリン理想は求められているスキルセットやフレームワークとかを経験のあるエンジニアにあてがうことですが、そこの理解が曖昧だとそんな感じでC++の案件にC#を入れちゃうような大胆な採用をする人もいます。
エンジニアからすると全然違うんです。
このように正確なプロジェクトの計画を立てる上で開発工程の経験が無いと難しいところがありますね。
発言のまとめ
.・技術的知見が無いのでタスクを正確に見積もることができない
・技術的知見が無いので間違ったフレームワークを採用してバグを引き起こすおそれがある
・技術的知見が無いのでエンジニアのスキルセットを理解できず不適切なアサインを行うおそれがある
開発工程未経験のPMOが正確にプロジェクトの計画を立てることは困難で、
- プロジェクトにかかる日数の計算や、開発工程の把握など、タスクの見積もりを正確に行うことが困難です。
- タスクに適さなかったり、開発チームが対応できなかったりするなど、間違ったフレームワークを選定してしまう危険があります。
- メンバーのスキルセットやタスクをよく理解していないため、スキルセットの性質と合わないタスクをメンバーに割り振ってしまうような間違ったアサインをする危険もあります。
具体的な作業指示や報告も困難になる
太田フランクリンみこみこ太田フランクリンPMOに求められている役割はチームに対して明確で詳細な作業指示を出すことです。、
開発工程を理解していないまま指示してしまうと行程が曖昧になっちゃったり、メンバーへの指示とか*外部への報告も曖昧で、薄い内容になってプロジェクト全体の遅延を引き起こしかねないおそれもあります。
みこみこたまに何も開発工程やったこと無い方もいますよね？
太田フランクリンみこみこ現場にすごくできる人がいて、居るだけのPMOみたいな…。
太田フランクリン例えばPMOがお客さんから要望を受けて、「ユーザーがログインできるようにしてください」とエンジニアに指示するとします。
でも一言でログインできるようにしてと言われても、エンジニアからすると色々な疑問が出るんですよ。
どのようなログイン方法がいいのかとか、認証方法もいっぱいありますよね。
どのデータで認証させるか、メールアドレスとIDなのか、ユーザーごとの固有の情報で認証させるのか、セキュリティ対策もどうするのか。
要望一つで色んな解釈ができるんですよ。
そういった疑問が出てきてしまう、エンジニアからすると。
もし仮にそこで既に設計書があったり作るだけだったら百歩譲っていいんですけど、それが無い場合かつPMOが開発経験特に無くてベストプラクティスな提案ができない場合、もはやこうなるとエンジニアが一つ一つ仕様を決めないといけなくてPMOのバリューが出ないわけです。
指示だけ出してエンジニアからの質問にも答えられない、「お客さんに聞いてきます」とか。
設計書とは、システム開発において、「システムをどういう形で作っていくか」を記した資料のことを指します。
システム開発には、開発を進める際に重要な計画を立てる「設計」という工程があります。
方法の中で最も善いものや事例として最も良いものをベストプラクティス（Best Practice）といいますが、ベストプラクティスは「業界標準」を意味する場合もあります。
みこみこジン太田フランクリン結論、こうなってしまうと開発者の作業工数をすごく奪ってしまい、プロジェクト全体の遅延に繋がってしまいかねないかと思います。
みこみこジンチームのサブリーダー的ポジションの人で、その人は技術力があるわけではなくひたすら伝書鳩みたいな人でした。
みこみこジンエンジニアが何か作ってお客さんに渡したら、違うって言われてやり直しでした。
意外と起きることです。
太田フランクリンみこみこ太田フランクリン具体的にこうなると技術的なコミュニケーションの障害になっちゃってます。
PMOに求められる役割ってチームのコミュニケーションのハブになることで、例えばAPI設計についてPMOがまとめなきゃいけないケースはよくあるんですよ。
APIは微妙な位置の実装で、フロントエンドとバックエンドがあってそれを繋ぐのがAPIという手段なんですけど、PMOはフロントとバック両方のエンジニアの意見を聞きながら、統一的な仕様を決めることを求められることが多いです。
PMOはフロントエンドとバックエンドの技術をある程度把握してないといけないんです。
責務範囲っていうのもそれぞれの立場だと決めきれないのでPMOが決めるよう求められます。
技術的な観点や知見が無ければエンジニアに丸投げすることになって、PMOに求められる潤滑なコミュニケーションが果たせなくなっちゃいます。
勉強しないといけないし、自分自身にエンジニアとしての開発経験が無いとそういうポジションで動くのは難しいですね。
WebシステムやWebアプリケーションなどの中で、ユーザーが直接触れる箇所を「フロントエンド」と呼びます。
ユーザーはフロントエンドの視認や操作を通じてシステムを使用できます。
APIは、あるソフトウェアを別のソフトウェアの機能に接続できる仕組みです。
APIを用いることで様々なソフトウェアやプログラムを連携させることができます。
元々はアプリケーション毎に備わる独自のAPIを用いて連携を図っていましたが、インターネット上でWebブラウザを利用するWebサービスが広まった今日では、マイクロサービスという各種Webサービスの組み合わせからなるWeb APIに人々の注目が集まっています。
ユーザーは任意にAPIを利用でき(リクエスト)、APIからの応答(レスポンス)を得てソフトウェアやプログラムの連携が可能となります。
ユーザーがAPIの利用を図る度にリクエストが出て、ユーザーの期待に反する結果となってもレスポンスは返ってきます。
例として、ECサイトでのクレジットカードによる決済ができる機能をユーザーがAPIを介して利用した場合、ユーザーはクレジットカード運営会社の用意しているAPIに対してカード番号などの情報を含むリクエストを発信し、その結果決済の可否を示すレスポンスがユーザーの元に届きます。
APIを利用するにはアプリケーションの開発が必要なため、プログラミング言語への知識がある程度無ければなりません。
APIを利用するにはアプリケーションの開発が必要なため、プログラミング言語への知識がある程度無ければなりません。
APIに用いるプログラミング言語には、
- C
- Visual Basic
- Ruby
- Java
- Python
などがあります。
APIの利用にあたって提供元の提示する仕様に関してもアプリケーション開発の知識を前提とする場合が多いため、IT知識を持つ専門職なくしてAPIを用いるアプリケーションの開発は困難となります。
みこみこ太田フランクリンみこみこ希望単価が80万とか90万とか。
太田フランクリン議事録書くだけなら40～50万が相場になります。
みこみこPMOの中でも支援型と管理・指揮型って大きな乖離があって、その乖離に気付かずにPMOは稼げるって思ったらあれれ？と…。
開発経験無いんだ私、それで単価が100万落ちちゃうと。
太田フランクリン他には進捗報告の場で遅延の原因を具体的に説明できないんです。
PMOのミッションの一つとして定量的な報告があります。
お客さんに対してプロジェクト全体はこうで進捗はオンスケなり遅延で特定の機能は開発が滞ってる、とか何らかの報告をする義務があります。進捗率80%とか。
その時に遅延が起きてる理由も併せて報告する必要がありますし、むしろお客さんから絶対質問来ます。
そこで開発経験があれば、機能Aの中でバグが起きましたがスケジュール内で解決する見込みです、とかそういった観測やエンジニアとしての経験込みで具体的に説明できますが、開発工程の経験が無いと何の報告もできなくてすごく薄い報告になっちゃいます。
そうなると具体的な報告ができないだけでプロジェクト全体像の可視化ができてなくて、クライアントから不審がられるんです。
メンバーも自分達の取り組みを報告してくれないPMOに不満を抱いて、コミュニケーションの阻害要因になっちゃうかなと思います。
何でこのプロジェクトが遅れているのかを定量的かつ正確に説明するのは中々難しいんですけど、そこがPMOに求められてる役割です。
開発経験が無いと問題の具体化が難しいですし、PMOは務まらないと思います。
英語の「on schedule」をカタカナで書いた「オンスケジュール」を略した「オンスケ」は、主に作業や計画の進捗が予定した通りのペースで進んでいることを伝えるもしくは確かめる場合に用います。
みこみこ太田フランクリン開発経験が無いと具体的な作業指示や報告ができず、プロジェクトのお荷物と言っても過言ではないです。
発言のまとめ
・仕様の伝達が不明確になり作業工数を奪ってしまうおそれがある
・具体的な進捗報告ができずクライアントにしんようされなくなったりエンジニアから不満が出るおそれがある
開発工程未経験のPMOは、メンバーに具体的な作業指示ができず、クライアントに具体的な報告ができません。
- 仕様の伝達が不明確なため、エンジニアがクライアントの要望に適する仕様を自力で検討しなければならなくなり、PMOの意義が薄れます。
- クライアントに対するプロジェクトの進捗の説明も不明確になってしまい、クライアントからは信頼されず、メンバーからは報告義務を果たせない人物として不満を抱かれてしまいます。
クライアントからの信頼も得られなくなる
太田フランクリンクライアントとの打ち合わせで求められるのは、技術的な背景を踏まえた提案です。
コンサルタントの領域と被りますが、クライアントの要望に的確に答えるには開発工程の経験が無いと難しいです。
具体的にどういう問題があるかというと、不適切な提案をしてしまいます。
僕の知り合いの現場であったんですけど、クライアントが既存のCRMを活用して新しいマーケティング機能を追加したいとのことでした。
PMOに開発経験が無くて、システムの調整やインフラの制約とかを無視して可能だと返事しちゃいました。
議事録に残ってやることになったんですけど、いざPMOが決めた方針で開発を進めてくと結果としてはシステム全体のアーキテクチャの見直しが必要でこんなことやると思ってなかったと。
エンジニアからすごく反発が来て大規模なリファクタリングをしないといけなくなった、ということがあったらしいです。
結局プロジェクトの予算をさらに取ることで終わりはしましたが、クライアントからするとできると言ったのに何故できなかったのかということでPMOは信頼を失いました。
PMOはプロジェクトの顔なので信頼を失うとクライアントとの関係も悪化しました。
ソフトウェア開発の中で、プログラムの動作を保持しながらソースコードの改善を行う作業を「リファクタリング」といいます。
リファクタリングには、ソフトウェアの機能は変えず、プログラムの書き方を以前より分かりやすい形に改められるという利点があります。
CRMには顧客の情報の有効的な活用を目的とする基本的な機能があり、
- 顧客情報の管理
- 顧客分析
- デジタルマーケティング
- カスタマーサポート
が挙げられます。
顧客情報の管理に関しては、CRMで扱えるものは氏名・電話番号・メールアドレスなどの基本的な情報に限らず、購買履歴・クーポンの取得状況・キャンペーンの応募状況・サポートセンターへの問い合わせ履歴なども該当します。こういった詳細な情報は取得できる場所やツールが複数にまたがる場合が多いものの、複数のシステムとの連携によりCRMを用いたデータの一元的管理が可能となります。
顧客情報の分析は、購買履歴などの詳細な情報をCRMで管理・蓄積し、顧客の趣向や購買行動の傾向を知ることで実行できます。さらに顧客情報の分析を活かしてマーケティング戦略や経営戦略を立てることも可能となります。
デジタルマーケティングの面でも、年齢・性別・居住地・商品の購買履歴といった顧客の情報を管理・分析することで顧客のニーズに適合する的確なアプローチや情報提供が可能となります。例えば顧客のポイント取引情報を通じた購買行動の分析を基に、クーポン配信などの会員向けサービスが実施できるようになります。
カスタマーサポートに関しても、商品の購買履歴や顧客からの問い合わせ内容などの情報の蓄積を活かし、商品購入後やサービス提供後のアフターケアの際の顧客からの問い合わせへの対応の質とスピードを向上させることが可能となります。
ジン太田フランクリン太田フランクリンPMOが新しくクライアントに対してデータベースの説明をする必要があったんですね。
基本PMOはクライアントへの説明義務があります。
エンジニアが取りまとめてた方針をPMOがクライアントに説明する場面で、PMOが既存の設計の重要性を説明できないままお客さんに話しちゃったみたいで、クライアントは既存の設計のままでいいって判断してしまったことがあります。
本当はPMOが既存の設計を変えて新しくしないと開発が進んだ時にバグの温床になったり品質が下がったりする、ってちゃんと伝えないといけなかったんですけど上手く伝えられませんでした。
当然クライアントは納得しなくて、設計は変えず今の設計のままにしようという指示が出ました。
結果はテスト工程でたくさんバグが出てプロジェクトが遅延しちゃったんですけど、もしPMOがリスクを踏まえた説明をちゃんとできてれば結果は違ったかもしれません。
クライアントに理解してもらえるまでエンジニアの言葉を代弁するのもPMOに求められてると思います。
ジンUATは、対象となるシステムやソフトウェアがユーザーの要求を満たしているかどうかを確認することで、ユーザーがそのシステムやソフトウェアを受け入れるかどうかを判断する際の基準になります。
緻密なテスト設計を基に丁寧なテストを行えば品質面ではある程度正確な結果を得られますが、テストケースが多くなることでコストに関してはかさんでしまうことになり、またUATに十分な時間を割く余裕がない場合も往々にしてあります。
そのため、UATの実施にあたっては、可能な限り精密なテストを行うが、可能な限りテストにかける時間は短くする、といった方針で優先度を吟味していくことが重要となります。
リスク管理を念頭に置いたUATの実施を考える場合、
- 重要な機能を優先する形でのテスト
- 仕様を変更した機能やその周辺機能を優先する形でのテスト
- 実際に運用する環境において実際に扱うデータを使ったテスト
といった条件を満たすことが重要となります。
重要な機能を優先する形でのテストを実施する必要があるのは、全種類の機能を丁寧にテストする時間的な余裕がない場合が多いためです。システムやソフトウェアの基幹となる機能や決して不具合を出してはならない機能などを定め、ユーザーなど関係者と合意形成することが必要となります。またどのような条件でテストを実施するかを決めることも必要で、重大な漏れ抜けのないことを確認できるかを前提に、通常の利用状況や定期的なイベント日などを条件に選ぶ場合が多くなります。重要な機能を通常通り使っていたところ誤作動さらには致命的な事態にまで発展するリスクを軽減させることを前提としています。
仕様を変更した機能やその周辺機能を優先する形でのテストを実施する必要があるのは、開発途中での仕様変更を行った場合に設計変更が既存の設計部分に対する考慮漏れや対応漏れを起こしかねず、また仕様変更に対応していないバージョンをリリースしてしまうおそれもあるからです。仕様変更に関する不具合を軽減させることを前提としています。
実際に運用する環境において実際に扱うデータを使う形でのテストを実施する必要があるのは、開発元がテストを行った際の環境やデータが実際の環境やデータと異なる場合が多く、リリースするにあたって環境を移行する処理漏れが起こりやすくなってしまうからです。
疑似環境でのテストと実際の環境でのテストを別に考え、疑似環境と実際の環境の差異に着目しながら処理漏れのリスクを軽減させることを前提としています。
発言のまとめ
・システムの調整やインフラの制約を無視した不適切な提案をして大規模なリファクタリングに労力を割かなければならない事例があった
・クライアントに対して、既存の設計ではバグが頻発したり品質が低下するおそれがあると伝えられず、設計を変えなかったためバグによりプロジェクトが遅延した事例がある
開発工程未経験のPMOは技術的背景に基づいた提案を自分からはできません。
- システムの調整やインフラの制約を考慮しないような、技術的に無理のある不適切な提案をしてしまいかねません。
- クライアントに対してエンジニアの提案をうまく伝えられず、クライアントが提案を却下した結果プロジェクトの遅延を引き起こすような問題が発生した事例もあります。
こうしたことでクライアントから信頼されなくなる危険があります。
問題解決を即座にできない
太田フランクリン例えばクライアントから要望変更があった時、開発経験のあるPMOなら即座に技術的な影響を分析して対応策を提案できるんです。
具体的には打ち合わせの場でクライアントが新しい機能Aを追加するとどのぐらいコストがかかるかって聞いてきた場合、開発経験があれば機能AだけじゃなくてBやCにも影響あるとか工数は数十日規模になるとか分かるんですよ。
お客さんに素早く変更管理の判断お願いできるんですよね。
開発経験が無いと1回持ち帰らないといけないし、対応が遅れて影響が広がりかねません。
さらにエンジニアには見積もり作業もお願いしないといけないのでその間他の作業は止まっちゃって、プロジェクトにも支障が出る可能性があります。
クライアントからの印象も悪くなります。
窓口だと思ってたPMOが毎回話を持ち帰ってるとこのPMO話進められないのかと思われちゃうので、お客さんの要望に早いレスポンスで対応できることが開発行程の経験がある人の強みだと思います。
このように開発経験が無いとクライアントからの信頼も得にくくなっちゃいます。
ジン発言のまとめ
・技術的知見が無いので、クライアントの要望に対して迅速な対応ができない
・エンジニアが見積もり作業を担当するためプロジェクトの進行が遅れる
プロジェクトを進めるうちに元の計画と異なる事態が起こった際に、開発行程未経験のPMOは対応が遅れてしまう危険があります。
- クライアントに新しい機能を追加したいと言われた際には、プロジェクトの変更による技術的影響が及ぶ範囲や作業にかかる日数などを自分の経験から導き出せません。
- クライアントからの問いかけがあるとPMOは毎回話を持ち返らざるを得なくなり、迅速な対応ができない相手としてクライアントに不信感を抱かれかねません。
- 事態に対応できないPMOに代わって、作業にあたるはずのエンジニアがクライアントへ返答する危険もあります。
開発経験を積むにはどうすればいいのか？
実際にエンジニアの経験を積める案件に入る
太田フランクリンみこみこそれでも単価はどうにかしたいと…。
太田フランクリン例えばプログラミングを学んでも実際開発案件に参加することでプロジェクトの流れや具体的な技術的背景も理解できます。
とはいえいきなり本格的な実装とか設計をするのは難しいので、最初は簡単なテスト案件とか運用監視とか未経験でも入りやすい開発系の案件から入ってって少しずつ上流に上ってくのがいいと思います。
みこみこ太田フランクリン未経験の分野の知見を得るためには単価的には目を瞑る必要がある場合が多いです。
支援型で月40～50万の人がエンジニアとして入る場合は月30～40万くらいからスタートすると思います。
未経験のエンジニアが最初に案件に入るとそのぐらいの相場です。
みこみこ発言のまとめ
・未経験者も入りやすい開発系の案件に入る
・新しい知見を得る代償として単価が下がることは覚悟する
未経験者が開発行程を経験する方法には、実際にエンジニアとして参加できる案件に入ることが挙げられます。
- 開発案件に参加することで、プロジェクトの進め方や技術的背景を学べます。
- 未経験者として比較的入りやすい案件から始めると無理なく経験を積んでいけます。
- PMOが開発案件に参加する場合、単価はしばらく下がるものの、PMOとしての業務や単価に直結する知見を新しく得られます。
開発工程のPMOの案件に入る
太田フランクリン経験が無いから経験できるところに入るっていう。
ただし、キャッチアップはめちゃくちゃ大変になっちゃいます。
できないことをやるので、そもそも採用される確率もすごく低いです。
たとえ入れても常に勉強しないといけないぐらいキャッチアップが大変だっていう前提付きです。
「追い付く」、「遅れを取り戻そうとする」などの意味を持つキャッチアップ(catch-up)という言葉は、「業務に関する情報を把握する」、「業務遂行に必要なスキルを習得する」などといった意味で使うこともあります。
みこみこ太田フランクリン例えば議事録しか書いたことのない人がいきなり開発行程のPMOに入る場合、お客さんからするとそんな人にお金払いたくないですよね。
お試しで入ってみる場合は単価が据え置きになることが多いです。
キャッチアップ前提なので、自主学習としてシステム開発の本をたくさん読んだり、案件資料をちゃんと読んだり、不明点をプロジェクトメンバーやエンジニアに聞きに行ったりするような能動的な動きが取れないといけません。
みこみこ単価が下がるのは嫌ですけど…。
太田フランクリン例えば公務員からエンジニアになった方、今はフリーランスのエンジニアとして月90万の案件に入れてるんですけど、未経験からエンジニアになった時に給料かなり下がったらしいです。
このように何か未経験の領域で能力を身に付けようと舵を切った場合、単価とか給料の点では下がることが多いです。
でも数年後、もしかしたら1～2年後ぐらいには、元の給料かそれより多めに貰えるような成長曲線が描けることはよくあります。
成長曲線は、努力量や費やした時間と実際に達成できた成果・収入などの成長を並列して示す曲線です。
努力量や時間を横軸、成長の要素を縦軸にする形を取ります。
みこみこ太田フランクリンみこみこ1年間で言ったら1000万近くの年収になるんですね！
1000万を10年貰ったら1億円。
でも支援型PMOなら月40～50万で年間500万、10年で5000万。5000万も乖離がありますね。
太田フランクリン勉強期間は単価を下げる必要があります。
ジン僕はそれなりに努力してきたからその結果が得られたので、誰しもがそうなるとは思わない方がいいんじゃないかと。
太田フランクリンこれも知人の話ですが、他業界の営業からPMOのフリーランスに転身したんですよ。
営業時代は会社でNo.1も取ったことあるらしくてインセンティブもあって月収50万超えてたみたいです。
サラリーマンで50万とか結構すごい、年収600万ぐらいですよね。それも新人～2年目とか。
その時の強み、お客様との折衝の腕を活かしてフリーランスのPMOになったんですよ。
でもなったはいいけど案件探してても中々オファーが無いんです。
PMOは狭き門なので未経験かつ開発経験無しだと難しいところがあります。
特にその方の条件で厳しかったのは単価60万以上で探してたことですね、気持ちは分かりますけど。
未経験のPMOで60万は厳しいってことで、その方は&単価を下げてでも開発工程の案件に入ることがマスト&だと気づいたんですよ。それで一旦単価を40万まで下げて開発工程のPMOとして入りました。
そこでその方はPMOとしてのタスクだけでなくエンジニアと一緒に開発もしたらしいんです。
いわゆるプレイングマネージャーとしてプログラミングのキャッチアップとか求められてる以上の稼働をしたから相当負荷がかかったとは思います。
その結果クライアントの方からも技術的な背景を持つPMOとしてすごく高い評価を受けて、市場価値が向上して今では単価100万前後の案件に入れるようになったとのことです。
良いキャリアを歩んだパターンですね。
インセンティブ(incentive)とは「やる気が起こるような刺激」や「動機付け」といった意味を持つ言葉です。
発言のまとめ
・自力でのキャッチアップを前提に開発工程のPMOの案件に入る
・採用される確率は低くなる
開発工程未経験者が開発工程を理解するPMOになる方法として、開発工程のPMOの案件にそのまま入ることも考えられます。
ただし、
- 案件に採用される確率は低くなります。
- 単価が上がることはまずなく、多くの場合下がります。
- PMOとしての業務と並行して、システム開発の自主学習や案件資料の熟読など激しいペースでのキャッチアップをこなさなければなりません。
人的投資の重要性
みこみこ株っていうのは上がったり下がったりするもので、よく分かってない人は上がった下がったって言って慌てがちですが、知識があればいずれ上がったり下がったりすることは分かるから、それを見据えて投資しないといけないんですね。
ある意味フリーランスは投資的な視点が要るので、目の前の単価が下がったことだけじゃなくて長期的なポートフォリオとして考える必要があるんですよね。
経験やスキルを分かりやすく示すために実績をまとめたものを「ポートフォリオ」と呼びます。
太田フランクリンみこみこ太田フランクリンその時に自分の仕事がなくなるのはキツいと思います。
みこみこ太田フランクリン
みこみこでもこの後月100万になるとすると2年ぐらいで元取れますよね。
太田フランクリン
ジンみこみこ0ミリ社長うちでは厳しいですって言うしかないです。
太田フランクリン方法はいっぱいあるじゃないですか、プログラミングスクールもいっぱいあるし、僕達みたいなエージェントもいっぱいいるんで、自分に合った開発工程の経験を身に付ければいいかなと思います。
みこみこ発言のまとめ
・投資的な視点を持って長期的なポートフォリオを考える
・勉強期間で下がった単価は上流の管理型PMOとして活動するうちにペイできる
・プログラミングスクールやエージェントなどの活用も可能
開発工程の未経験者が開発工程の経験を積める案件に入るかどうか検討する際は、
- 短期的な単価が下がっても、長期的に活かせる技術的知見の獲得を優先する大きな視野が大切です。
- 1～3年など、ある程度まとまった期間は開発工程の案件に集中することが重要です。
本記事のまとめ
PMOは開発経験者であることが望ましく、
その理由としては
- プロジェクトの正確な策定が可能で、
- メンバーやクライアントに対して具体的な情報を提供でき、
- 技術的背景に即した適切な提案をすることが可能で、
- プロジェクトに変更があった際には迅速な対応ができる
といったことが挙げられます。
開発工程未経験者が開発工程の経験を積むには、
- 実際にエンジニアとして参加できる案件に入り、
- 開発案件のプロジェクトの流れや技術的背景を学んでいくことで、
- 一時的な単価は下がってもPMOとしてのキャリアを築くにあたって重要な知見を得る
といった方法があります。
太田フランクリンみこみこ単価下がりたくないからPMOになりたいって人は開発工程やった方がいいし、目先の単価が気になる人は正直単価も中々上がらないし長いキャリアを築くのも難しくなってきます。
皆さん自身であるというとこで、そこのお手伝いを僕らはしてます。
太田フランクリン普段はPMOに向けた情報発信だけじゃなくて、エンジニア向けのITコンサルタントだけどフリーランスになってみたい、とか色んなITに関するご相談・ご支援を承っております！
本日の動画は以上です！
おすすめ記事
コメント