野球とPM

プロジェクトの中でもいろいろと人によって向き不向きがある。
分かり易くたとえると、野球の「バッティングピッチャー」「先発」「中継ぎ」「リリーフ」に近い。

多分、会社の中でのポジションってあると思うのだけど、

一番多いのは「先発完投型」タイプ

プロジェクトの立ち上げ(案件獲得も含む)をする「バッティングピッチャー」タイプ

プロジェクトが火を吹いた時に呼ばれる「火消し（リリーフ）」タイプ

「先発」は出来るけど5回以降はだめな「生粋先発」タイプ
(プロジェクトの最後のツメが甘いタイプ)

とにかくよく分からないけど一時的にプロジェクト(案件)を切り盛りする「中継ぎ」タイプ

ちなみにオイラの場合は、試合前の「バッティングピッチャー」& 「リリーフ」が性に合ってる。
だから「先発完投型」ではないし、そうなろうとも思わない。

結局システム開発って「チームプレイ」なんだけど
「プロジェクトの中で自分のポジションを確立して、自分の役割を果たす」
っていう見極めは大切だと思う。

最近気に入った本

新しい知識や、ネタを手に入れるために
技術的な本岳に限らずいろいろな本も読む事にしている。

最近気に入ったのは「フェルマーの最終定理」
数学の歴史や、フェルマーの最終定理がどうやって
証明されたかを、綴ったノンフィクション。
数学の知識がなくても面白く読める様になっていて、
読み物としての完成度も高い。

フェルマーの最終定理 (新潮文庫)/サイモン シン

￥820
Amazon.co.jp

役割と役職

前の記事で書いたけど、
結構日本の場合「役割が変わる＝出世する」みたいな
システムのところが多かったりする。

もちろん「PLが出来る」ってのは
「人をまとめあげて引っ張っていく」という意味では
SEの下にPGが数名ついてSEが指導しながら開発をしたりとか
PLの下に多数のSEやPGがついて開発部隊をうごかしたりとか
っていう意味において「立場が変わる」っていうのは分からなくはない。

でも、PLやPMは出来ないんだけど
「設計をやらせるとどんな物でもきっちり設計を行える」とか
「めちゃんこ複雑なプログラム(アルゴリズム)を考えて作れる」って
よくいるよね。

でも会社によっては「次はPMの勉強しなさい」って
必ずと言っていい程言われる。
今まで聞いた中でツライ話は、
「PMできないなら出世がないよ」って言われる話........

おいらとしてはPGやSEでも真のスペシャリストに
なる道があってもいいと思うんだけどなぁ～
なかなか最初はいいんだけど経験年数がたつと
日本では評価されないんだよね、今のところ..........

PGとSE

システムエンジニアー（SE）とプログラマー（PG）の違いって
人によって使い方が曖昧だったりする。

よく「SEになりたい」って話を聞くけど
SEって何かよく分かってない人が多いし、
詳しく話を聞くと「それってただのPGじゃん」
ってな話によくなる。

おいらの会社にはSEって役職は存在せず
あえてSEとして役割を分ける時は
「プログラムの設計ができる人」
って言う違いしかない。
# 多分一般的にも間違っていないはず.......

大きな会社だと明示的にSEっていうポジションが
存在するけどベンチャーみたいな小さな会社だと
ポジション的にはかなり曖昧なケースが多い。
大きな開発会社だと、最初はPGで会社に入って
PGの経験積んで設計のやり方だとかを覚えて、
SEになって、プロジェクトの数をこなしていくうちに
PL（プロジェクトリーダー）になって開発部隊を
引っ張る様になり、更にお客さんとも話す様になり、
PLで経験を積んだ後、PM（プロジェクトマネージャー）になる。
っていうある意味、出世(?)街道（上下関係）的なものが存在する。

これって個人的には「純日本的」なシステムだと思う。
おいらの感覚だと
「優秀なプログラマー　＝　優秀なプロジェクトマネージャー」
であるとは限らないと思うんだけどなぁー

アメリカとかだと生涯プログラマーって人も当たり前にいて
「役割が変わる ＝ 出世する」ような仕組みにはなっていない。

役割分担

最近、情報処理系の勉強をしている大学生や専門学生と
話す機会が多かったので、彼ら(彼女ら)からよく
「SEとプログラマーって何が違うんですか？」とか
「PM(プロジェクトマネージャー)って何が出来ればなれるんですか？」って
聞かれるのでその辺の話を書いてみる。

今から書く事はあくまでもオイラの周りでの話であって
世間一般的なプロジェクトの常識に合ってない部分も有るかもしれないので、
そのつもりで............(^^;;;;;

同じ会社のメンバーだったり社外の人だったり、
プロジェクトの中にはいろいろな人がいますが、
プロジェクトの中でよくある役割は以下の様なものだと思う。

1, 営業
2, PM (プロジェクトマネージャー)
3, PL（プロジェクトリーダー）
4, SE（システムエンジニア）
5, PG（プログラマー）
6, テスター

1, 営業
　っま、その名の通り営業です。
　お客さん(エンドユーザーor親請け会社)に対して
　「仕事ないですかー」とか「こんなシステムいかがですかー」って
　話を持っていく人。

2, PM (プロジェクトマネージャー)
　営業がとって来た仕事(プロジェクト)を円滑に進める為の人。
　オイラの会社の場合、主にお客さんと話をしながら要件をまとめたり
　PLがあげてくる現場からの要望に対してお客さんと調整を行う人。
　又、プロジェクト全体(お金や人員、進捗)を管理して社内やお客さん
　との調整も行います。
　オイラの会社は明示的に「営業」って職の人がいないから
　営業で仕事とって来たらそのままPMってパターンが多い。
　技術的なスキルより、交渉や調整、コミュニケーション能力が
　非常に重要な仕事で、システム開発の時はお客さん的視点で
　物事を考えてプロジェクトを見る事が多い。

3, PL(プロジェクトリーダー)
　開発の現場を仕切る人。
　オイラの会社の場合はPMと一緒にお客さんの所に言って技術的な観点から
　提案やとりまとめをします。
　おいらの会社的には、システム全体の構成(アーキテクト)をやるのも
　PLの仕事です。後は、社内の開発の現場を取り仕切ります。
　開発部隊内の細かい役割分担等の体制、進捗をPMへ報告します。
　開発の現場でのPMとの違いは
　PMは「お客さん的視点(ビジネス的視点)でシステム(サービス)を考える」で
　PLは「技術的視点でシステム(サービス)を考える」って事かな。
　(もちろんPLもお客さん的視点をある程度持っておいたほうがいいのは
　言うまでもないですが.....)
　求められるスキルは主に「コミュニケーション能力」、「分析能力」
　そして「技術的知識(経験)」かな。
　技術的ノウハウが必要な理由は簡単で、技術的にある程度押さえていないと
　現場のエンジニアと話ができない上、お客さんの要望を技術的視点から分析
　できないからです。

4, SE（システムエンジニア）
　簡単に言うと「プログラムの設計が出来る人」
　PMやPLがまとめて来た仕様やシステム構成を元にどうプログラムに
　していくのか画面やプログラムの構成（テーブル定義やクラス設計等）
　を考える事が出来る人。
　ちなみにオイラの会社ではSEという言葉を使う事はほとんどない。
　あくまでも「設計ができる人」と呼んでいます。

5, PG（プログラマー）
　「設計が出来る人」が設計した画面やプログラム構成のドキュメントを
　見ながら、その通りにプログラムを書く人で実装から単体テストまでを
　担当します。ただおいらの会社の場合、事細かに実装の指示を出す
　(出せる)事は少ないので、ある程度、設計やアルゴリズムを考えれるだけ
　のスキルが必要。
　後、新人の様に事細かに実装の内容を指示をしないとプログラムを書けない
　人の事をあえて「コーダー」と分けて呼ぶ事があります。

6, テスター
　オイラの会社では結合テスト以降のテストを行う人。
　海外ではテスト専門の会社が有る程独立した役割だと思うのだが、
　日本ではPGがそのままテストする場合が多い。
　テストでバグを発見し、バグの再現手順までを洗い出した上で
　開発部隊へ報告し、開発部隊からFixの報告が有ると、デグレも含めて
　バグがなくなっているか確認を行います。
　余談だが、オイラの会社の場合、開発部隊へバグの報告があるとPLが
　報告されたバグを確認しある程度問題を切り分けて、
　適任な担当者をアサインしバグの修正作業を行います。
　
まぁざっと書いてみましたが、
実際には、ここまできっちりとした役割分担で作業が行える保証はないし、
お客さんや案件の種類等で体制もかわるんだけど、
おいら的視点で一般的な説明するとしたらこんな感じかな。
# 賛否両論いろいろとあるとは思いますが......m(_ _)m