IT業界を明るくするためにエンジニアがマネジメント以外でやるべき3つの事
自身の経験より、IT業界を明るくするためにエンジニアがマネジメント以外で
やるべき3つの事として、以下を挙げます。
「理解」の後、現場に「適用」するっていうのがキモで、
これがかなり難しいです。
arclampのエントリからいただきました。
ですが、注意できることはあります。
それがアーキテクチャに関するコミットです。IT業界ではプロジェクトマネージメントが注目されていますが、
アーキテクチャがちゃんとしてないのにマネージメントしても、
これっぽっちも、まったく、すっかり意味がありません。正しくチームやアーキテクチャが分割されていなくては、
マネージメント(ついでもテスト)もへったくれもありません。
例えばですが、今すぐ使えるのであれば以下のようなものがあります。
- 3層設計(プレゼンテーション、ビジネスロジック、パーシステンス)
- O/Rマッパー
- DIコンテナ
- 単体テスト
- コードメトリクス(スタイルチェッカー)
- 様々なEffective Java的コツ(Enumとか)
- IDE
未来を見ればSOAは有望株でしょう。サービスを切り口に
アーキテクチャが分割できると、データによる連携に比べてかなり
緩やかな分割が可能になります。
僕はSOAを開発手法として考えています。「TOYOTAで考えた、見える化の本質」
http://www.arclamp.jp/blog/archives/000864.html
これらは私がブログで主張してきた事でもあります。
また、SE時代は上司にも
「燃えるプロジェクトをなくすには、標準化がキモだ。
つまり、次プロジェクト以降も使えるドキュメント/コンポーネントを
資産として作成していく事。それを実行するために、
アプリケーション/インテグレーションアーキテクトを戦略的なアサイン
をもって育成すべきだ。」
とずっと主張してきました。
プロジェクトマネジメントはアーキテクチャをしっかり策定している事が
前提の話であり、日経コンピュータの編集者もベンダの上層部も
このあたりがあんまりわかっていないから、わかりやすい
マネジメントの記事に飛びつくんじゃないかなーと思います。
逆にアーキテクチャに関する話は「Javaworld」などの雑誌が
詳しいです。
マネージャはマネジメントの本は読んでも、「Effective Java」は
読んでいないし、「オブジェクト開発の真髄」なども
読んでいません。
これは完全にツボを外しているような気がします。
だから、プロジェクトが燃えるのでは?
一方で、そこをきっちり行っている企業もあります。
たとえば、フューチャーアーキテクトは標準化をうまく適用し、
コンポーネントを全社的にうまく流用しているようです。
http://www.future.co.jp/service/tech/compo.html
標準コンポーネントを増やせば、バグの発生率も減らせますし、
バグの改修時間も短く済みます。拡張も容易なはずです。
そして、次回以降のプロジェクトにいくつかの資産が活かせ、GPは上がり、
バグ数も抑えられるはずです。
ただ、現場のマネージャがこのあたり、どこまで理解できているかは
疑問です。
なぜなら、上記の理屈は、
がないと理解する事が難しいのではないかという思いがあるからです。
また、標準コンポーネントをつくる事に対しては、コストがかかる事と
スキルをもったリソースが必要である事の2点が壁としてあり、
往々にしてその場しのぎのコンポーネントが作られがちです。
経験上、マネージャは旧来の構造化プログラミングの考え方を
している人が多く、オブジェクト指向な頭ではないような気がします。
(もちろん、マネージャなのにプログラミングレベルで若手と話が
できるとんでもないスーパーエンジニアも部内にはいました。)
よって、そういった若手を育成する方向がベターだと思います。
そして、その育成を早めるためにその道のプロフェッショナルと共に一度
仕事をする事。
例えば、豆蔵はそういったコンサルテーションを行っています。
http://www.mamezou.com/service/sds.html
マネージャが方向づけをしたアサインを心がけていく事と
組織としても中長期的な観点から一時的なコストを容認し、
戦略的に各々のプロジェクトを進めていく必要があると思います。
arclampの鈴木さんのように、最新のテクノロジを柔軟に吸収し、
ガンガン現場に適用していっているエンジニアが最前線に増えれば
IT業界ももっと明るくなっていくと思います。