本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、＠IT自分戦略研究所 編集部おすすめのコラムを紹介する。あなたのエンジニアとしての成長に役立つ内容であれば幸いだ。 ■コンピテンシーとは何か スキルスタンダード研究所の高橋秀典氏による『Road To IT-Engineer / ITエンジニアの生きる道』。今回は「企業の人材育成計画と個人の自己実現」について。 企業の人材育成の目標は「ビジネス目標達成に貢献する人材を育てること」。個人は「職場で自己実現」を求めるが、企業の人材育成と一致するとは限らない。 そこで重要となるのが「コンピテンシー」だ。高橋氏はコンピテンシーを「自分の置かれている状況を認識し、相手の期待を把握した上で、それに応える行動をとる能力」と定義する。 ■突然の倒産 元外資系ITマネー

世の中の意見として、「○○という言語を使っている開発者たちはロクにスキルも持ち合わせていない」「こんなヒドイソースを書くのは○○使いだ」というような、特定の言語に対しての攻撃的意見が存在します。特に目にしやすいのは「Visual Basic」に対してかな、と個人的には見受けられます。もちろんほとんどの方が「悪いのは言語ではなく、それを使っている開発者」というのを理解していらっしゃるので大丈夫だとは思いますが、「実際は……？」というと、あながち非難されるのもそれほど外れてはいないかな、というところではないでしょうか。 一昔前、オープン系が流行りだしたころはCOBOLが槍玉にあがっていたと思います。汎用機やオフコンからPCへとプラットフォームを変化させはじめたあたりです。このころを覚えている方ですと、旧来のファイルレイアウトをそのままRDBに載せてみたり、特に理由もなくEnterキーを押さない

「今日は大事な話があるからまだ帰らないでくれ」 急ぎの仕事を終えた同僚が、早く退社しようとしたら社長にとめられた。その時の言葉が気にかかった。 やがて17時ごろ。初老の男性がやってきた。 全社員が集められ、そして彼の口から終わりが告げられた。 「突然ですが、この会社は本日をもって事業を停止、わかりやすくいうと倒産することになりました。このたび、管財人として……」 その後のことは、よく思い出せない。 最後に「本当に、もうしわけありませんでした……！」と深々とあたまを下げる社長の姿は、どこか遠くのできごとのように現実感がなかった。 29歳になって数日の冬のことだった。 冬のボーナスどころか、今月の給料さえ出ないことにまだ気づいていなかった。 ・ ・ ・ ＠IT自分戦略研究所をご覧のみなさま、はじめまして！ このたび＠IT自分戦略研究所 エンジニアライフに寄稿させていただくことになりました46（

エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方 人材育成を突き詰めていくと、どうありたいかというゴール（To Be）と、現状（As Is）とのギャップを、いかに効率よく埋めていくかということになります。それに企業と個人の視点が加わり、複雑な対応となっていくわけです。対象は人であり、考えるのも人であるかぎり、単純な話ではありません。 ■人材育成の目的と理解 筆者がITSSやUISSに関わっていて強く感じることなのですが、多くの企業は本来のゴールを見ずに、目の前のことにフォーカスしてことを進めようとするきらいがあります。例えば、ITSSといえばITSS導入を目的にしてしまいます。 口では色々それらしく並べても、結局ポリシーも使命感も希薄で、短絡的な動きをしているように見えます。数は少ないですが、本格的な人材育成に取り組んでい

オーストラリアにおける最新のデータ利活用は、地理的・社会的背景に根ざした独自のアプローチが際立っている。広大な国土に低密度の人口が点在するという特有の状況下で、政府や企業はデジタルインフラ整備とデータ活用を推進し、リモート地域や先住民コミュニティのニーズに応えるための取り組みを強化している

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 ■ 何をもって方針を決めるか 要件 開発コスト 設備コスト ランニングコスト パフォーマンス 保守性 スケーラビリティ 技術者のスキル（教育コスト） FWなど過去の資産（しがらみ） などのファクターがあります。 当たり前ですが、最も重要なのは【顧客の要件】です。 下の2つは【開発会社の都合】といえます。 アセンブラとCとか、C++とJavaなどは、顧客の要件と、その他の条件とのトレードオフで下の2つを無視しても決まりやすい。JavaかRubyかといわれたら、その他の条件の差は小さいので、【開発会社の都合】が効いてくるでしょう。 APサーバで処理するか、DBサーバで処理するかについては、下の2つ以外はDBサーバに軍配が上がります。つまり、顧客にとっては（自分達でメ

いま勤めている会社の中で問題になっているのですが、最近の潮流としてターゲットとなる開発言語を知らない設計者が増えてきているという話題があります。酷い場合には、言語のみならずプラットフォームであるOSやネットワークの基礎すら知らない人というのも目にすることがあります。このあたりは「人材の空洞化・ドーナツ化」などとよく言われていることだと思います。 要件定義から概要設計の中において、言語を知らなくとも構わない部分が存在しますので、個人的にはOKだと思っています。ですが、今回のような点が話題にあがる環境ですと、言語に大きく依存する部分まで設計してしまおうという状態ではないでしょうか。要件定義をほとんど行わない状態で概要設計を行う、概要設計と詳細設計の区別がついていない、GUIのデザインだけでAPを実装させる（時間的な都合はわかるのですがね……。人のことは言えないですが）など、落ち着いて考えれば酷

SEとして仕事をしているとけっこう出合うことがあるのが「ローカル用語」。特にユーザーはユーザーの社内で通用する言葉で話してきますし、わたしたちIT業界側もこの業界でのみ通じる言葉を使って話してしまうことはよくあるのでは、と思います。 このような場合、聞き手から「それはどのような意味ですか？」と聞いてくれればまだいい方で、ほとんどは華麗にスルーされているのではないでしょうか。そうして後々で問題になりやすい、と。 わたしはかなりスルーしてしまう割合が高く、後々になって聞きなおすことがいまだになくなりません。分からないことを素直に聞くことができればいいのですが、自分の中の何かが邪魔をしているんですね。恐らくは、変な見栄ですとか、プライドなのだと思うので、いつかばっさりと捨ててしまいたいものだと感じています。 しかし、人と人とが話をする場面において、もっと怖い場面というのは他にあります。それは「同

さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手SIerです。私はその3次請け業者の面談を受けました。技術的に高度なことを矢継ぎ早に質問されてたいへんな面談でしたが、とりあえず合格したようで、来月から来てくれといわれました。 現場に行くと、大部屋に100人以上の人が机を並べていました。官公庁がユーザーであるせいか、空調が高めに設定してあって（いわゆる「クールビズ」です）やたら蒸し暑い。部屋の途中に衝立があって、向こうは2次請けの会社が入っている。私がついた担当SEは、その2次請け会社の人たちにたいへん気を使っていました。ほとんど鼻息をうかがうくらいです。衝立のそのまた向こうに衝立があって、その向こうには元請会社が入っているようですが、こちらはもう“殿上人”のような扱いで