技術と管理のどちらをとるか

この問題で悩む技術者は３０代前半に多くみられます。

「このまま技術を磨き、極めていきたいが、社内でのポジションや年収を
考えるとマネージャに移らざるを得ない・・・。しかし、技術から離れると、
転職も難しくなる。転職しないのと転職できないのは大きな違いだ。
転職しないのはいいが、社会で通用しないスキルになるのは避けたい。」

もっともな悩みだと思います。

当社においては技術と離れる管理者のスキルパスはありません。
逆になぜ一般に管理者が技術と離れると言われるのか私には疑問です。

当社のプロジェクトマネージャの仕事は、技術をベースとする仕事です。
日々の仕事では一定量の勉強・研究時間を取ります。

「技術の力で事業を組み立てる。」技術者の方には、そんな管理者を目指して頂きたいと
思います。

お客様視点であること

私たちはお客様視点で事業を進めることを最も大切な事と位置付けています。

たとえば開発の提案の仕方
設計承認の段取りや稼働時のサポートまで考えて提案書を作ります。
後でお客様に無理をさせるようでは失格。お客様視点で望ましい進め方を
いつも考えて提案する集団でありたいと思います。

たとえばシステムの実現方式設計。
最新技術の適用より常にシステムの安定度を最重視する実現方式を

設計するよう心がけています。
最新技術の投入を要求されるお客様でも、最大の安定度を確保することを
必須としているのは当然ですし、
最新技術を避けるお客様も、暗黙には最新技術をITベンダーがマスターしていて
ITベンダーのよく練られた提案に対してジャッジしたいと期待しているのだと
思います。

ところで、最近では社内ルールもお客様視点で検討するようになってきました。
私たちの社内の制度やルール作りはまだまだこれからです。
常識にとらわれることなく、お客様視点で独自の制度・ルールを作って
お客様価値（＝私たちの価値）を追求していきたいと思います。

ActiveXコントロールについて

少し古い技術ですが、企業システムではまだActiveXコントロール(※1)が使われていますし、
新たに開発されることもあります。

ActiveXを使うシステムはどこかデコボコ感があるともいわれますが、
企業システムにおいては、あらたなシステムを作るよりも、
いかに過去のソフトウェア資産を有効活用するかが大切です。
（いうまでもなく、企業に大切なのはシステムの変革ではなく、ビジネスの変革・・・）

そんなニーズを反映してでしょうか、現在においてもActiveXをつかって
ブラウザベースのシステムとそうでないシステムの連動を図ったり、
本来ブラウザで行うべき範囲を超えて特殊機能を実装することが多いようです。

ところでWindows VistaではActiveXの動作が大幅に制限されます。
今後のActiveXのメンテナンスはWindows Vista対応が肝になりそうです。

※1:ActiveXコントロール
　HTMLのOBJECTタグで指定されてIE上で動作するプログラム。
　Webサーバーから自動ダウンロードが可能で、ブラウザの制約を超えて
　OSネイティブのコードを実行することができる。

　応用例：
　　・ローカルの特定ファイルを読み取って送信する。
　　・ブラウザの操作で、ローカルPCのプログラムを実行する。

　　　つまり、スタンドアロンのプログラムでできたことをブラウザベースのシステムで
　　　行うことができます。

　補足：
　　ブラウザがActiveXコントロールをダウンロードするとき、
　　実行するかどうかの問い合わせを示すメッセージが表示されます。
　　出所のわからないActiveXは実行しないのがセオリーです。

<< PR >>
コンポーネントデザインはActiveXコントロールの開発を請け負います。
他社ベンダー開発のメンテナンスも可能です。
使用ライブラリはMFC,ATLの両タイプに対応可能です。
マルチスレッドやプロセス間通信を駆使した設計についてもご相談ください。

何で勝負するか

システム開発は大規模になると、頭数で勝負しがちです。

もちろん理由があるので、これを否定するわけではありませんが、
私たちは頭数ではなく中身の濃さで勝負したいと思います。

システム開発のプロジェクトは失敗しやすいといわれます。

見積のミス、設計のミス、品質管理のミス、整理するとほとんどは
上級技術者の不足が原因であることが多いのではないでしょうか。

何かと会社規模を拡大したくなるのが常ですが、
私たちは中身の濃さを維持しながら成長していきたいと思います。

料理長は料理が得意

料理の世界における料理長は、オムレツ１つとっても誰よりもプロですよね。

わたしも起業して少しずつ規模を拡大していますが、プログラミングには携わ
り続けようと思っています。

システム開発はプログラミングだけではなく、プロジェクト管理という
重い命題があるので、一般的にはプロジェクト管理者はプログラムは組みません。

でも、コンポーネントデザインは、プロジェクト管理者も社長もプログラマでありたいのです。
その理由は次の２点です。

・管理者が技術を本当に理解してこそ、お客様に高度な技術が提供できる。

・若い社員の苦労を理解するには、その作業に加わるのが早道。

設計を始めたころは、設計のできるプログラマと自己紹介していました。

最近では、会社を経営するプログラマでしょうか。

誤解が多いので、最近ではあまり口にすることは減ってしまいましたが・・・。

※プロジェクト管理もちゃんと勉強してます。念のため。

お客様の信頼が経営資源

私たちは売上げ拡大や利益率に走るのではなく、

何社かのお客様とじっくりお付き合いして信頼される存在でありたいです。

お客様にとってシステム開発は得るものも大きいですが、

その品質や運用後の問題点が見えにくいことから、

常に失敗のリスクと隣り合わせで、お客様には勇気のいる仕事だと思います。

システム開発は信頼に足りるだけの仕事を常に提供できるかどうかが最も大切な要素です。

私たちは信頼されることで、次の課題を相談していただける。

そんな集団であり続けたいと思います。