あなたのプロジェクトのメンバーでこの人はなんでここにいるのだろう？と思える人はいませんか？
設計もプログラミングも出来ず、言われたことしかやらない、もしくは、言われたこともやらない、やれない人がシステム開発の現場には必ずといっていいほどいます。
なぜなのでしょう？
しっかり要員計画のもと確保されたメンバーではなかったのでしょうか？
目次
プロジェクトメンバーはどうやって集められるのか
大規模なシステムともなると、大量に技術者が必要となります。
プロジェクトマネージャーは、システム化を実現させるために、必要な技術を検討し、その技術を有する人材を確保する計画を立てます。
これが「要員計画」と呼ばれるものです。
まず、プロジェクトをまとめる「プロジェクトリーダー」、「サブリーダー」を選出し、OS系、ネットワーク系のインフラ技術を得意とするメンバー、サーバー構築やデータベース構築に強いメンバーなどを選出していきます。
基本的に、これらはシステムエンジニア（SE）が担当することが多いですが、以下の記事にも書きましたが、システムエンジニア（SE）やプログラマーという肩書きはあまり意味がないです。
そういう技術の経験が豊富という程度に考えてください。
そして、そのシステムはどの言語で実現するのかによって、その言語の経験者が集められていきます。
たとえば、Javaで開発を行うのであれば、Javaの経験者を募集することになります。
要員計画が失敗へと導く理由とは？
それぞれのスキルをもつメンバーが集められ、いよいよプロジェクトが開始されることになりますが、実は、この選び方にこそ、問題があると考えています。
その理由は２つです。
- スキルおよびその実務経験のみが採用基準となることが多い
- ユーザーの要望を誰ひとりとして認識していない
詳しく説明していきます。
スキルおよびその実務経験のみが採用基準となることが多い
一見、当たり前のように思えるスキル重視型。
なにも問題はないように思いますが、実は、外見と中身がかけ離れていることが多いということを問題としているのです。
たとえば、データベース構築の経験が５年あるSEは、当然経験者としての実績があるとみなされます。
しかし、これまでの現場では、設計ミスを連発し、耐久テストに耐えられないようなデータベースしか構築してこなかった。いつも周りの人のサポートがないと、ひとりではとても危なっかしくて任せられない。という人だったとしたならば、大丈夫かな？と思いませんか？
その人のこうした現場でのことは経歴書にはどこにも現れません。幸いにその人のことを知る人がいれば、この人は危険ですと忠告できるかもしれませんが、そうではない場合、あっさり採用されてしまいます。
また、Javaを３年経験しているという経歴をもつプログラマーAさんは、プロジェクトのプログラマーメンバーとしての募集にスキルマッチとして採用されていくことでしょう。
しかし、実際には、Java開発の案件でほとんど簡単なプログラミングしかしていなくて、その他はずっとテストを中心に行ってきた人であった場合、ほとんどJavaでプログラムを書いていなくても、実務経験３年としてみなされてしまうのです。
つまり、外から見える経歴と、実際の現場での実力が伴わないことが多いということです。
データベースであれば、Oracleマスターのプラチナを取得したメンバーがなりもの入りでプロジェクトに参画してきたとして、実際設計していく段階で、インデックスの考え方すら分からないということもよくあるのです。
実際、私がいた現場でも、こういう人がいました。質問しても、ちんぷんかんぷんなことしか答えだったり、逃げたりする人もいます。こういう人たちは、なぜここにいるのだろうかといつも疑問に思います。
しかし、外見と中身が違おうが何しようが、選出の段階ではなかなか見抜けないということなのです。
ですから、スキル重視にならざるを得ないということです。これをこのくらい経験していれば、大丈夫だろうという考え方になるのです。
ですから、ある意味博打のような要素があるのです。とても優秀なメンバーであればいいが、そうではない場合、愕然とすることでしょう。できるメンバーにしわ寄せがいくのは火を見るよりも明らかです。
そして、やっかいなことに、実務経験がない人は、いくら独学で自宅でコツコツと勉強をしたところで、実務経験にはならないのです。本当は、３年経験ある人よりも実力はついているかもしれないのにです。
ここにスクールで学ぶ意味がないことが分かります。実務経験がつかないのです。
外注先のメンバーであれば、この苦しみを味わったことがある人も多いのではないでしょうか？自分よりもできない発注先の社員SEなどが幅をきかせている現場は見苦しいです。フリーランスである私は、痛いほど味わっています。
では、どうすれば実務経験を積めるのか？
実務経験を積みたい技術、たとえばJava開発を行っている会社の社員になるか、フリーランスとして独立し、crowd worksのような、クラウドサービスで仕事をこなし、経験を積んでいくかです。それほど、経験を積むということは難しいことなのです。
おかしいですよね？
仕事を発注する側の社員は、いくらでも経験が積めるのに、外注の社員は、経験を積めないというのは。
経験を積む場が限りなく少ないのです。
つまり、単純なやったやらないの経験値ほど、経歴書に載っている情報ほどあてにならないのです。
それをきちんと見極められるしくみづくりができるプロジェクトは確実に成功することでしょう。それ以外は、ほぼ１００％失敗します。
ユーザーの要望を誰ひとりとして認識していない
致命傷だと思いませんか？
メンバーを選出する際に、ユーザーの困っていること、悩んでいること、つまり根本となるシステム化の目的を末端にまで伝えていないのです。
知っているのは、プロジェクトマネージャーや、よくてプロジェクトリーダーまでではないでしょうか？
そのほかのシステムエンジニア、プログラマーにはユーザーのことなど何も伝わっていません。
これでは、同じ目的のもと、ユーザーの困ったことを何とかしてあげたいと思えないのです。分からないのですから。
分からないから、プログラム自慢をするようになったりするのです。関心がずれているのです。
キックオフというような、システム開発開始時には、システム化の目的などほんのさわりを説明してくれる機会はあるかもしれません。
それでも、ユーザーが直接話をしてくれることなどめったにありませんし、全ての開発メンバーが集まって話を聞くということもありません。
本来であればプロジェクトリーダーが全ての開発メンバーにユーザーの目的を熱意をもって伝える義務があるはずなのですが。プロジェクトリーダーすら分かっていないことが往々にしてあります。
ユーザーは、なぜこれをシステム化したいと思ったのか、その背景やこのシステムを得ることでどのような効果があり、メリットがあるのかなんて、分からないのです。
分からない状態でも、「仕様」という神様が存在していれば、システム開発は出来てしまうのです。
これが最大のまやかしです。
そもそも、その仕様だけみても、なぜそういう仕様になっているのかが分からないからです。背景や利用するイメージが出来ていれば、自ずと仕様自体がおかしいと思うこともできます。どこか矛盾を感じたりすることもできます。
しかし、そうした背景などが分からなければ、仕様が神様になるしかないのです。
おかしいですよね？
どうすれば、開発メンバーすべてが、ユーザーの困ったことを理解し、それをなんとかしてあげたいと思えるようになるのか？
そこを解決したプロジェクトは、成功するしかないのです。
それができないから、あるいは気づいていないから、ほとんどのプロジェクトは失敗すると言い切れます。
スキルが必要なのは当然ですが、それ以前に、システム開発の目的をプログラマーの末端にまでしっかり浸透させる思考を持つことのほうが大事なのです。
カテゴリ：要員計画
