システムエンジニアの会社に就職して、長い年月が経ちます。
大きい会社なので、色々な職種があります。
私は入社当時、システムエンジニアを希望していました。
一般的な職種なんだろうけど、それとは別に開発（設計）部署というのもありました。
まぁ、製品を作る部署ですね。
ソフトウェアを作る。で、それを営業が顧客に売ってくる。
汎用的なソフトですね。
いわゆるオフィス製品とか、メール。
など。
それに比べて、システムエンジニアは、顧客先に行き、顧客の要望を聞き、それに応じてシステムを作る。
当然、顧客と常に会話する必要があります。
しかし、私が配属されたのは設計部署でした。
- 最初は嫌だった設計部署
- 人事の人に聞いてみたら
- 過酷な労働環境だが
- 設計部署で見についた品質に関する認識
- 念願のシステムエンジニアに
- 大型プロジェクトに参加
- プレイングマネージャーに
- 何を持ってスキルを証明するか
- 今後目指すべきところ
最初は嫌だった設計部署
正直不本意でしたね。
なんで希望が叶わなかったのか。
システムエンジニア（顧客のシステムを作る）を希望したのに。
設計部署は、なんか閉じこもって黙々と、スケジュールに追われ作るという、なんか地味なものを想像していました。
まぁ、実際配属されると、地味ではないにしろ、顧客が見えず、これ使ってくれてる顧客はいるのかなって感じで作業するというのは、想像通りでしたが。
辛いという点で言えば、やはり品質とかにはめちゃくちゃ厳しかったですね。
そりゃ、汎用的なソフトというと、本当にどんな人が使うかわかりません。
マニュアルでも、しっかりとわかるように書かないと、質問ばかりくるようになってしまうし、ミスがあれば、問題となりますからね。
検査部門にテストを依頼するのですが、そこで不具合が出たらまた大変。
当然その不具合の対応はしますが、同じような不具合がないかを徹底的に調べます。
不具合が見つかるということは、まだ外に出せる品質に達していないということになるので、設計部署は必死こいて再度テストをします。
新人の頃は、検査部門に出してから一週間ぐらいは、本当に心配でよく眠れませんでした。
電話がかかってくるとビクッとしたりして。
人事の人に聞いてみたら
しかし、ある時人事部の人に、システムエンジニアを希望したのに、設計部署に配属されたことについて聞くと、設計部署が非常に重要な部署だという話を聞かされました。
要するに、そこが原点だというのです。
当然、会社として製品を世の中に出すんだから、品質は最高でなくてはならない。
その製品を作る人間も、いい人材でないとならないと。
たまたまプログラミングが好きだったこともあり、新人研修期間にプログラミングがよくできたということで、どうやら配属先が希望とは違ったようです。
その人事の方が言うには、設計部署の人間は、今後システムエンジニアにもなれるし、営業にもなれる。
選択肢が一番広いのが設計部署だと。
過酷な労働環境だが
昔は、今のような働き方改革と言うのはありませんでした。
だから、夜の9時から打ち合わせというのも、日常茶飯事でした。
徹夜だって、普通にあったし。
夜、吉野家の牛丼弁当をみんなで買いに行ったことも、本当に頻繁にありました。
製品開発は、当然スケジュールが決められていて、いつまでに開発して、それをいつ検査に出すか。
だから、スケジュールを日々意識して、作業していました。
なんでか知らないですが、定時で帰るということが本当になかったですね。
たまに夜明るいうちに帰ると、なんか外の雰囲気が違って見えて、少し興奮したりしてました。
しかし、そんな労働環境でありながら、なんででしょうか。
それが苦痛かという、実はそれほどでもなかったりして。
プログラミングの世界というと、特殊な気難しい人が多いようなイメージがひょっとしてあるかもしれませんが、実は、そんなこともなく、みんないい人が多いです。
困っていると助けるし、冗談も言うし。
休日はみんなで集まってテニスしたり、スキーに行ったりしたし。
徹夜もみんなでするので、ひとりぼっちで寂しく残ると言うのはありませんでした。
ブラックではないので、残業代もきちんと出ました。
時にピークの時なんかは、毎月ボーナスかっていうこともありました。
そんな時は、使う時間もないので、数ヶ月後にわっって驚いたりもしましたね。
設計部署で見についた品質に関する認識
あとで書きますが、設計部署で身についたことは、技術というよりは品質に関する考え方ですね。
品質をどう作り上げていくか。
製品の品質はどうあるべきか。
いろんな人が使うと言うことは、思いがけない使い方をすることもあると言うことです。
フールプルーフという言葉があります。
これは、操作を知らない人が使っても、ソフトが壊れないように作ると言うことです。
製品では、これを徹底します。
ソフトが世に出て、そのソフトに不具合があると、これは社外事故となり大変なことになります。
リコールみたいなもんですね。
メールソフトだと、重要なメールが途中でロストしてしまった。なんて。
困難あったら、企業のイメージは台無しですよね。
品質については、本当にもう、石橋を叩いて渡る。叩きすぎて壊さないか心配になるぐらい、気を使いました。
この頃は、本当に設計部署のこのプレッシャーが嫌で、転職を考えてましたね。
この業界では、昔は35歳定年説というのがあり、35歳ぐらいを目処にマネージャーなんかにならないと、技術的についていけなくなる。みたいなものがありました。
当然最近はないですよ。
50歳を超えて、現役のプログラマーなんてザラにいますからね。
優秀な方々が。
念願のシステムエンジニアに
技術力が自分でもついたなって思い出したのは、実際はシステムエンジニアになり、顧客のシステムなんかを作り出した頃ですかね。
10年ほどずっと製品開発をしてきて、まぁ、あることをきっかけに顧客のためのシステムを作りシステムエンジニアになりました。
以前書いた、顧客先のニーズにあったシステムを作るというものです。
同時に、それまでは、C言語とかC＋＋言語だったのが、Java言語になり、Webシステムでのシステム開発になりました。
製品開発時は、オフィスのように、インストールしてそこでソフトが動くというものでしたが、今度はサーバがあり、クライアントはブラウザというシステム構成が多くなりました。
時代的にもそういった構成に変わり始めた頃だったと思います。
C＋＋とかは、結構高いソフトウェアを購入し、開発してたんですが、Javaは全てがフリーでした。
自宅のパソコンに開発ツールをダウンロードし、家でプログラミングができるんです。
これは本当に嬉しかったな。
ネットにも繋げて、情報もネットで探すこともできるようになり、情報が無限にあるような錯覚をしましたね。
わからないことは、ネットで調べる。
まぁ、最初の頃は情報も少なかったんですがね。
しかし今は情報が多い代わりに、調べにくくなりましたね。多すぎて。
この頃は、本当にいろんな勉強をしました。
セミナーにも行ったし、雑誌に記事を投稿したりもしました。
資格もこの頃一番取得したかもしれません。
会社の報奨金で、10万以上貰ったのもこの頃でしたね。
本もたくさん買いました。
今はなき、「DBマガジン」もよく読んでましたね。
この頃に技術的なスキルを身に付けれたと思います。
大型プロジェクトに参加
少しづつですが、大きなプロジェクトにも参加するようになりました。
プロジェクトリーダーも結構数多く経験しました。
プロジェクトが大きくなると、各コンポーネントも大きくなり、そのコンポーネントリーダーも数名の部下を持つという感じになります。
コンポーネント単位に交渉する顧客の窓口も異なったりすることもあり、直接お客との会話も普通にあります。
ここで、少しづつプロジェクト管理についても学ぶようになります。
スケジュールはもちろん、お金の計算や、人の配置も考えますからね。
システム開発の原価って、ほとんどが人件費ですから。
いかに人をうまく動かすかが、大切になります。
いい技術者がいいマネージャーになるかは、全く別と言ってもいいかもしれません。
技術スキルがなくても、いいマネージャーというのは結構いますからね。
もちろん、技術スキルがあるマネージャーなら、結構協力だと思いますが。
プレイングマネージャーに
技術スキルがあるマネージャーは、プレイングマネージャーとして結構重宝されます。
そりゃ、技術的な会話もお客さんとは必要になる時もあるし、価格やスケジュールについても会話しないとダメだし。
技術的な会話になると、「すいません、詳しい担当者呼んできます。」じゃ、顧客も大丈夫かってなりますからね。
「それなら、こういうやり方で実現することができますよ。」って提案できれば、信用度も上がります。
会社の規模にもよりますが、最近では、このプロジェクトの規模や各社の役割も変わってきていて、プレイングマネージャーが必要とされる場面が多くなってきました。
俺、管理しかできないわ！っていうマネージャーは、どちらかというとお荷物になりつつあります。
ここで、設計部署、システムエンジニア時代のスキルが非常に役立ってきました。
前に技術スキルがなくても、管理が上手い人もいるという話をしましたが、管理工数だけで潤沢にもらえるプロジェクトは少ないです。
したがって、そのような人は、複数のプロジェクトを掛け持ちすることになります。
しかし、プロジェクトマネージャーの掛け持ちは、基本的には良くないと言われています。
ちゃんと見えないからです。
だから、ある程度は、管理以外の作業もする必要があります。
レビューや資料作成なんか。
何を持ってスキルを証明するか
これはやはり技術スキルがないとなんともなりませんからね。
私がよく言っているのは、この業界のシステムエンジニアやプロジェクトマネージャーは、「アイドルの女優」と一緒だと。
要するに、「言ったもん勝ち」だと。
でも、それじゃダメだろうって。
じゃ、どうするか？
私は、資格をとれ！って言いたいのです。
資格。
IT系の資格は色々あります。
情報処理資格、PMP、ベンダー系資格（Oracle、Javaなど）。
これをとって、証明するんですよ。
上記の資格って、結構難しいです。
そんなに簡単に取れる資格ではありません。
後輩の中にも、多くの人が、情報処理資格の登竜門である応用技術者試験でも取るのに偉い苦労しています。
基本情報は、これはスクーターと同じレベルで、資格を受けるための最低限の資格です。
資格を取得するための勉強をすることで、本当にスキルがつきます。
もちろん、資格をとってない人でも優秀な人はたくさんいます。
でも、本当にもったいないなって思いますね。
資格とっている人には、警察バッチのようなものを発行して、胸に挟んで見せつけたいとおもいますよ。
ちなみに私は、情報処理試験資格の中でも、難しいとされる高度情報処理を3つ持っています。
あとPMPも持っています。
やはり、エンジニアとしてはそれを証明するものがないと、説得力がないとダメだと思いますから。
今後目指すべきところ
今は、複数のプロジェクトを管理しています。
本来、複数のプロジェクトを兼任するのはダメなんですけどね。
しかし、それは仕方ないと。
大きいプロジェクトもあれば、小さなプロジェクトもあります。
このプロジェクトをどう回すか。
きっちりと利益を出さないと失敗となります。
あと、品質が悪いとこれも失敗です。
あと、納期に間に合わなければそれも失敗です。
要するに、コスト、品質、納期。
この3つを全て達成しないとダメですから。
では、それをどう実現するか。
人を信じて、人を動かす。
人を信じて、人に任す。
その責任は、マネージャーである自分がとる。
自分で動こうとすると、もう溢れますからね。
そもそも、マネージャーが忙しいプロジェクトは、危ないプロジェクトですから。
それはうまく人を動かせているところは、うまく行ってるんです。
チームを作る、チームを育てる。
PMBOKでもチームビルディングとして、重要視されていることです。
ここをしっかりとやっていけるようにしたいと思いますね。
