ITエンジニアがアイデアを生産することについて

全工程共通

エンジニアはサラリーマンではなくビジネスマン!アイデアの大切さについて

みなさまどうも。「あったらいいね!」シリーズでブログを書き続けている加賀美(カガミ)です。前回まででITエンジニアの①守(ひたすら教わった通りを実践する時期) ②破(教わったままの方法以外を模索する破壊の時期)の2点についてお話したので、今回は「離(自分なりのスタイルを確立する時期)」の点についてお話したいと思います。

加賀美自身は驚いた、とあるエンジニアが書いたDB定義書

さて、ごく一般的なエンジニアの上達の道として、「守・破・離」といった流れを踏むだろうと書かせて戴きました。そして、今回のブログタイトルは「ITエンジニアがアイデアを生産することについて」です。このことは「離」のお話とどのような関係があるのでしょうか?

答えの前に、加賀美自身が驚いたある体験談を書かせて戴きたいと思います。

RDBを扱う開発エンジニアであるなら、誰しも一度は『DB定義書』といったものを見たことはあるかと思います。

よくあるパターンなのがExcelを用いた、1シートに1テーブルの情報を載せたドキュメントです。
しかし、もしかしたらみなさまの中には組込エンジニアの方々もおられるかもしれないので、念のためサンプルイメージをお見せ致します。

上図は、ネットで見つけたDB定義書のフォーマットに、カガミが適当にそれらしい値をいれたものになります。こういったフォーマットは、よくあるパターンだと思います。

そして、私がとある現場で遭遇したDB定義書は、これに対しこのような変更をしておりました。

どうでしょうか、違いがわかりましたでしょうか!?

実はこれ、先ほどの定義書の左側に「テーブル名」が入っているんです。
主な変更点はそれだけです。

けれど、これ、開発や保守・運用する上ではとっても便利なんです。
この場合、例えばこんな使い方ができます。

上図で、左から2番目の「論理名称」、すなわち『論理カラム名』が『顧客CD』という値でフィルターされていることに気づかれましたでしょうか?

このような、テーブル名も含めたDB定義書の場合、Excelのオートフィルターで、同じカラム名を使用したテーブルの一覧を抽出することができたり、各テーブル名とプライマリーキーだけの一覧を抽出することなどができるんです。

「だから何?」とお思いになられるかもしれませんが、これ、保守開発とかするときなど、システムを分析する際などに大変役立つんですよ。

エンジニアのみなさん!経験を積んで、アイデアを積極的に出して行こう!!

さて、ここまで読んだみなさまは本ブログをどのように感じられましたでしょうか。

そして、今回、「離」のタイミングで敢えて『エンジニアがアイデアを出すこと』の話題を持ち上げたのは、カガミ自身は保守・運用の経験が多いからなんです。今からその理由を書きたいと思います。

システムの保守・運用って、エンジニアのお仕事は科学の上に成り立っているハズなのに、『なぜそうなのか意味は良く分からないけど、手順を一つでも変更すると、とんでもないことになるかもしれないから、ひたすら昔から教わった内容で行こう』みたいなことが多いですよね。

しかしシステムは様々な処理と様々な処理が相互に複雑に影響しあっておりますので、うかつに我流を通すことが危険であるのは事実です。

そこで、『守・破・離』のシリーズの最後に、エンジニアが自分のアイデアを出すことについてお話させて戴きました。

経験を積んだとしても、私のような、ごく普通の凡人エンジニアにとって、教わったこと以外の手順を踏むことは危険であるかもしれません。

しかし、例えばお客様先で渡されたプログラム仕様書なり基本設計書なりのフォーマットや、市販で売っている書籍に書いてある内容をよく吟味して、『ここはおかしい』とか、『ここはこうした方がより良い』など、アイデアを出すことはとても重要だと思います。

そして、そういった提案は、他のエンジニアとの差別化につながる可能性がございます。

別に特許を取れ、と言っているわけではありません。
けれど、仕事というモノは、ただ教わった内容を手順通りに順守することや、決まりきった規則の枠の中でパズルゲームみたいなものをひたすら組み合わせるだけではつまらないと思います。

もちろん、ITのお仕事は一通りマスターするまでの学習期間が長いです。
ですが、エンジニアとして円熟してくると、かつて素晴しいモノと思えた教科書などにもツッコミどころがあることなどに気づいたりできます。

どのエンジニアの方も、まずは『教わった通りに実践すること』が大事だとは思いますが、そういった嗅覚を磨くためにも、ぜひアイデア帳などを持って戴けたらと思います。

これは言わば、お笑い芸人の『ネタ帳』です。
未来に大きな樹となる種が、そこに潜んでいるかもしれません。

結びに

今回はQAエンジニア、開発者、ネットワークエンジニアなどを問わず、ITエンジニアがアイデアを出すことについて書かせて戴きました。

加えて、失敗を恐れるなとも世間的には言われておりますが、『守・破・離』の流れとして、まずは基礎固めが大切な事、次に教わったことをマスターし、それから自分なりのスタイルの確立をすることの大切さを書かせて戴きました。

新たなアイデアが産んだプロダクトは『創造的破壊』等とも言われておりますが、そういったアイデアは押しなべて地道な下積み時代を経たのちに現れるような気が致します。

もちろん、お笑い芸人のオリエンタルラジオのように、デビューしてすぐに売れっ子になるエンジニアもいるかもしれません。

しかし、人生は短いようで長期戦です。
そして、お笑い芸人は学歴など関係なく、笑いのために常にネタを考えております。

我々エンジニアも、常にアイデアを出すことに敏感でありたいものですよね。

それでは、今回は以上となります。
最後までお読み戴きありがとうございました。














みなさまに、今日も良いことありますように!!

タイトルとURLをコピーしました