PG、SE、PMの役職の違いって何？
さて、まずは役割の重さでみると「PM→SE→PG」という流れになります。
PMからSEへSEからPGへという流れで仕事が下りていくのが一般的です。
私は現在PMとして案件に参画しています。
これから開発者になりたい！と思っているなら、
開発職としてあなたがどこを目指すのかということを考えておいた方が良いです。
なぜならそれぞれ業務内容に違いがあるからです。
「〇〇がしたい！」と思って、開発職についたのに全然できないのは悲しいことですから…(>_<)
ということで、そもそも開発職を分けているPG、SE、PMの役職の違いって何なの？というところから紐解いていきますね！
PGって？
PGとはいわゆる「プログラマ」のことです。
多くの方が想像する開発者というのは、ここに属します。
いわゆる黒い画面に呪文のようなコードを書いているようなイメージで表現されるのが、このプログラマーです。
上の画像のようなコードをガリガリ書いている感じです。
設計書を元に実際にプログラミング言語を活用して、コードを書いて機能を実現するポジションです。
プログラミング初学者の登竜門です。ほとんどの方がここから開発者デビューをします。
そもそも開発ができないのに全体を統括するって不思議な話ですからね。笑
ただ大企業とかだと、元請で外部に開発部分を委託している場合もあるので、全く開発したことのない方もいるようです…^^;
PGに求められる力
PGに求められる力は2つ。
- 設計書を元に分かりやすく、処理的にも無駄のないアルゴリズムでコードが書けること。
- 純粋なプログラミングスキル。
①も②も、やはり初学者とベテランのソースコードでは雲泥の差が出ます。
とりあえず動くコードが書ければ一応はPGと言えますが、可読性等も考えてソースコードが書けるようになると、よりレベルアップしたPGと言えるでしょう。
まぁ、とは言ってもそんな完璧なソースコードを書こうと思ったら並大抵な経験値じゃ事足りません。
私自身、ある程度は綺麗に書く自信はありますが、完璧かと言われれば、それはあり得ないという答えになります。
誰にとっても可読性や可用性が高いソースコードを書けるようになることがPGとしては最大の目標になるかと思います。
SEって？
SEはいわゆる「システムエンジニア」のことです。
意外とこのワードでPGのイメージを持っている方も多いかと思います。
業界では当たり前でも、一般的に見ればどれも同じような感じがしますもんね！
ただし、SEの業務内容はPGとは違う部分がたくさんあります。
そもそもPGが開発するための設計書を書くのはSEの業務です。
SEの業務内容を纏めると、以下の4つの工程が挙げられます。
- 要件定義。
- 基本設計。
- 詳細設計。
- テスト。
①要件定義では、顧客と打ち合わせを行いヒアリングをした上で顧客の望むシステムの形を明確にします。実現可能かどうかも含めて、顧客と打ち合わせていきます。
②基本設計では、システム設計を行います。機能や操作方法などの基本的な部分の設計を行います。
③詳細設計では、実装する予定の機能についてより細かく技術的要件等も踏まえて設計書を作成します。この設計書を元にPGが開発を行うことができるように記載します。
④テストでは、実際に開発が終わった段階で、作成した要件と照らし合わせて正しく動作するかを確認します。
SEに求められる力
SEに求められる力は3つ。
- 顧客の欲しい機能を汲み取れるだけのコミュニケーション力。
- 提案時に相手を不安にさせないだけの技術力。
- タスクを切り分けて管理する能力。
SEに求められる力はPGとは似て非なるものと言えます。
①まずは顧客との打ち合わせを行い、その中から本当に必要な機能を把握しつつ、その中で実現可能な機能に落とし込んでいくだけのコミュニケーション力は最低限必要です。相手のことを考えずに自分が思い描いた機能で納品するのはただの独りよがりでしかありません。
②技術力については、実際のところベテランPGのようなレベルまである必要はありません。顧客が求めている機能が実現可能かどうかを選定できるだけの技術力があれば十分です。
③タスク管理能力も必要です。なぜなら、SEが書いた設計書を元にPGが開発を進めていくので、それぞれの開発段階がどのような状態なのかを把握して進捗が遅れないようにする必要があるからです。
総じて、SEの最終目標は顧客にとっての最善を模索し提案ができ、設計・テストの後納品物で顧客を満足させることになるかと思います。
PMって？
PMは「プロジェクトマネージャー」のことです。
SEと似ている部分もありますが、大きく異なるのが責任の大きさです。PMの下でSEが機能レベル、非機能レベルなどに分野ごとに分かれて開発を行なっていきますので、全体をしっかり見る必要があります。
当然PGの状況や様子も踏まえて確認し、進捗が遅れているようなら開発の手助けに入ることもあります。イメージとしては全体の調整役と言えるポジションです。
PMの業務内容を纏めると、以下の5つです。
- 開発目的の落とし込み。
- プロジェクト計画の立案。
- プロジェクトの編成/管理。
- 評価/レビュー。
- 状況に応じて、調整人員に回る。
①まず、PMはSEが各機能に分かれて機能レベルの打ち合わせを始める前に、顧客との打ち合わせを行います。ここで話し合われるのは機能云々というよりは目的や優先順位、予算、納期等です。求められている開発要件に対して、顧客の予算や納期と照らし合わせて、「このシステムをこの納期までに実装するとなると現在想定している予算を100万円程オーバーする」等を顧客に伝えます。その上で、予算を上げるのか、納期をズラすのか、開発内容をより簡易的にするのかなどを打ち合わせて詰めていきます。
②上記打ち合わせを元に作業計画書を作ります。この計画書を元にSEやPGが作業をしていくので、細かい部分まで詳細に計画書を作成していきます。内容はPMBOKによれば以下のような事柄を書くのが一般的です。
- プロジェクトの目標(品質、コスト、納期について)
- 対象のシステム範囲、成果物の定義
- コスト/スケジュール/品質
- プロジェクトの体制
- コミュニケーション
- リスクと対策
非常に分かりやすく纏められているサイトがありましたので、紹介します。
「PM初心者でも出来る？プロジェクト計画書の作り方～無料サンプル付き！～」
③上記プロジェクト計画に盛り込む必要性と関わる人員の明確化のためにプロジェクト人員を編成して、その管理を行います。
④最終的なシステムに対して、プロジェクト計画で立てたプロジェクトの目標を元に評価、レビューを行います。
⑤状況に応じて、開発進捗が著しく遅れている時などは、開発者として実際の開発にも携わります。
PMに求められる力
PMに求められる力は3つ。
- 開発経験、IT技術、予算や人員管理に関する知識。
- ホスピタリティ。
- リーダーシップ。
①まずは全体を統括する上で開発経験、IT技術に対する知見が無いと、概算工数の算出ができず、開発コストの管理が行えなくなってしまいます。そのため、最低限ある程度の開発経験は必須になります。また、予算や人員管理の知識も持っていないと金額に係るコストについても想定できなくなりますので必須の知識と言えるでしょう。
②ホスピタリティも非常に大切です。プロジェクト内で火を吹いているグループが無いか、トラブルが起きていないかといったところにも気を配ることができないと、プロジェクトが崩壊してしまいます。
③プロジェクトのリーダとして、全体を引っ張っていく必要があるので当然のことながらリーダシップも必要になります。どうすれば、メンバーのモチベーションを上げられるか等を考えて色々な施策を行います。
ということで、それぞれのポジションについて纏めてみました。
偉そうに語ってきましたが、私は現在PMの卵として案件に参画中です。
正直、開発分野についてはある程度明るいですが、人員マネジメントや予算等のお金の関わる部分はまだまだ詳しくなく、当然ホスピタリティもリーダーシップも雀の涙ほどの力しかありません。
今は先輩PMの元、あれやこれや教えをいただきながら案件を進めています。
PMの業務範囲の広さに、半ば押しつぶされているyukilaboでした！