久しぶり・・・
前回のエントリーが10月1日だったので、一ヶ月ちょっと空いてしまいました。
・・・いえ、2013年10月1日なので、1年以上ぶりのエントリーです。。
まあ、でも今回の空白期間中、特に消息確認や問い合わせ、およびクレームの連絡はなかったので、そもそもこのブログの必要性に疑問を感じておりますが、、、、
好きの反対は嫌いじゃないんですよね。・・・無関心です。
さて、この1年の間、アベノミクス？の影響から株価も大きく上昇してますね。
我がIT業界も企業のシステム設備投資が増えているので、開発現場では技術者不足がおおきな問題となっております。弊社も微力ではありますが少数精鋭エンジニア集団として、少しでもお客様のご期待に応えられればと思っておりますが・・・
いかんとも人手が足りません。。
我々のシステム開発の現場では、開発システムのボリュームを人工という考え方で表したりします。
これは、人月（や人日）という計算方法で、一人のエンジニアが一ヶ月（一日）かけて開発する作業量をベースにして、それが6ヶ月で完成するシステムであれば、6人月のボリュームという考え方です。
ちなみに、6人のエンジニアで一ヶ月で完成させても同じく6人月ですが、
残念ながらもっともポピュラーなウォーターフォールモデルの開発手法では、そうはいきません。
また、たとえばある開発プロジェクトに6人の開発エンジニアがいたとして、
その6人がまったく同レベルのスキルということはあまりありません。
俗に優秀なエンジニアはそうでない人と比較して10倍も生産性が違う、などと言われたりします。
そうでない？人が20日（1人月）かけて書くコードを、優秀な人は2日で書いてしまえたり、
（※単純作業の量ではなく、思考時間を含めてです）
そもそも書きあげたコードの出来栄え（性能）が何倍も違ったりします。
ただただ与えられた仕様で動くだけのプログラムは、本を見れば誰でも書けちゃうもんです。
与えられた仕様に潜む問題を念頭におき、汎用性・可変性の高いコーディングができる人が、優秀なエンジニアなのです。 （私はそうでないエンジニアでした。苦笑）
なので、今のビジネスモデルを継続するとして、人手を増やすという規模の拡大が難しいのであれば、一人当たりの生産性をあげて対応するしかありません。
お客様としてもそうでない？可能性のある人を増やすよりも、
２～３人前の仕事を一人でやってくれるエンジニアに担当して貰った方が圧倒的にリスクを押さえられますし。
このご時世、当面目指すのはそこかなー、などと考えているうちに一年経ってしまいました。。
次回は年内にもう一本書く！という低いハードルを設定して、本エントリーを終わります。
↓↓↓ ご意見・ご感想、遠慮なくお願いします！！<(_ _)> ↓↓↓
投稿者 Taka : 2014年11月10日 13:45
