専門性の罠

エンジニアにとって専門性はとっても大事なことのようですが、IT技術に関してはやや矛盾する性質もあるように思われます。その原因の一つには技術が完璧に公開されているという特性がありそうです。

今まで考えられていた手に職と言うと、習得に時間のかかる技術や知識を覚えること、という風に理解できます。

その技術は秘密の場合もあれば公開されているケースもあります。ただし公開されていると言っても大学にいったり図書館で専門書を調べる必要があるのです。

しかしITに関してはグーグル先生に聞けばたいていのことは教えてくれます。調べるコストが劇的に下がっているのです。

一方で新しい技術が次々に生まれてきており、さらに技術自体の細分化も並行して起きています。

こうゆう状況だとあまり1つの技術にこだわり、極めたとしてもその技術はすぐにみんながマネできる状態であり、飽きられれば世の中の主流から外れてマイナー化するリスクがあります。

さらに、いわゆる後進国のエンジニアが大挙して労働市場に参加してきている状況があります。

たとえば、私は以前ベトナムのPHPエンジニアと一緒にリモート開発をしたことがあるのですが開発言語やフレームワークの知識、利用方法に関してまったく問題はありませんでした。

というか私の方が使い方知らなかったりする。。。。

手に職をつけるメリットというのは、できる人が少ないことにより高い評価が生まれることから生まれるわけで、できる人が多ければ手に職をつけても評価されません。

整理するとこうゆうことです。

・情報収集コストが劇的に下がっている

・競争相手がグローバルになり増えた

・技術の回転が速くなった

よって専門性があることにあまり価値が置かれなくなっています。この状態では、ある領域の専門家になるよりは全体をほどほど知っている程度で、細かいところは専門家に任せるポジションになるのがよいと思います。

技術そのものではなく、それをビジネスのに展開する知識と経験を持つ人が価値を生む時代と言えます。

たとえばSEなんかでも、お客さんとの要件をまとめる上流SEなんてのはこの部類に入るのではないでしょうか?

日本語という障壁がまだまだあるので、外国人のエンジニアがお客さんと直接要件をまとめることは難しいと思います。

逆にプログラミングやデバッグなんていうのは、明らかに外国人とか人工知能に置き換えが進む職種です。

暗黙知と形式知という言葉がありますが、形式知というものは言葉で表現され、みんながその言葉を使って習得できる知識のことです。

一方で暗黙知は、言葉ではなく経験でしか獲得できない知識となります。知識と言うよりは直観、感性、経験に近い概念です。

今後の世界ではITに限らず、形式知というものは、ますます外国人か人工知能に置き換わっていくものだと考えてよいです。なので形式知の分野を極めても不毛な努力になるだけ。

我々は言語化できない、暗黙知を磨くべきです。

そのためには、個別の技術を突き詰めるのではなく、全体をまんべんなく理解しておくこと。

その上で形式知にできない分野に特化してスキルを磨くことが重要だと思います。

いまどきホームページを作っても客は来ません

WEBが世に広まってかれこれ20年近くになっても、タイトルのようにホームページさえ持てばお客さんが自動的にやってくると勘違いしている人がいたりします。

WEB業界の中にいると常識なことが、WEBとは無縁な人にとっては非常識な事例の典型です。

さすがに20代30代でこんな考えの方は少ないですが、40代50代になるとこうゆう人がまだ生き残っております。

ただ誤解を与えないように言うと、今から30年くらい前、WEBの黎明期であればこれは事実でした。

なのでその時代のニュースとか報道のまま、知識がアップデートされていない人なのかもしれません。

確かにあの時代。。。そもそものサイトの数が少ない時代でした。

検索などは使われておらずYAHOOなどのポータルサイトにあるディレクトリに登録されているWEBサイトをみんな見ていました。

なので普通の会社や普通のお店がホームページを作ってYAHOOに登録申請をし、認められればWEB経由でお客さんがじゃんじゃん来る時代は確かにあったのです。

でも、ご存知のとうり今は検索経由でのアクセスが中心となり、その検索順位は血で血を争うレッドオーシャンになっています。

単にホームページを作っただけでは検索順位100位以下。。。。人が来るわけないです。なんでSEOだの広告だのが使われているのですよ。

私はブログをキーに集客をしているので、こうゆう人から問い合わせが来ることはないのですが、年齢層の高い方とお話しすると、意外と自分の常識が通じないという事実を発見します。

まあ他人の知識の無さをバカにするのは簡単ですが、別の分野においては私の知識を圧倒していることもありますので、人の話は謙虚に聞きましょう。

あ、ホームページを作っただけでお客さんがじゃんじゃん来る、数少ないケースを思い出しました。

それは競合が一切存在しない領域です。例えば町に1件しかない耳鼻科とか、北海道には一人しかいない***マスターとか。

元々のニーズがものすごく高いところにWEBが結合すると、お客さんがじゃんじゃん来るケースはあるにはあります。

技術知識ではなく問題解決能力を見ましょう

エンジニアの評価基準に関して、ちょっと勘違いしている人が多いのでここで整理しておきます。

業界内ですらそうなのですが、どうも技術知識の豊富さや最新技術に精通していることが、エンジニアのレベルの高さだと勘違いしている人がいたりします。

特に流行のAIとかブロックチェーンのような技術を身に着けていればその人は優秀とされたり。。。

んなわけないですよ!

確かに最新の技術を身に着けている方が、技術的に有利ではあります。ただ技術は技術でしかなく、それがどう使われるかが重要なんです。

例えば、あなたが大きな病気にかかって医者に行くとしましょう。ところで医者に行くのは最新の治療法を受けたいからですか?

違いますよね。病気を治してもらいたいからです。

最新の治療法が優れていることは多いと思いますが、実は保険がまだ効かないとか、副作用があるとか、まだ適用例が少ないとか、必ずしも最新の治療がベストとは限りません。

あなたが抱えている病(問題)を適切に解決してくれる人がいい医者なんです。

そしてそれはエンジニアでも同じ。

あなたにやりたいビジネスがある、何か解決したい課題があって、そのためにITシステムが必要な場合、予算と納期とサイトの目的を総合的に判断して最善の提案をしてくれるエンジニアがこそが、あなたにとってのいいエンジニアです。

ぶっちゃけ使う技術とか関係ないんです。自分の問題を解決してくれるのかどうかだけ気にしてください。

特に悪質なのが、顧客の無知をいいことに、最新技術の実験場にさせられるケースです。まあ、うまく行けばいいのですが、トラブルがあった場合

「いや、これはまだ技術的には完成されて無くって・・・」

などという言い訳は絶対に聞かないようにしましょう。技術的に完成されてないものを選択する時点で、そいつはダメなやつです。

医者だったら医療過誤で裁判になりますよね。

とはいえ、素人の私にエンジニアの評価なんて難しいよ!誰かやってくれないか?というご要望がありましたら、私の方でお受けしますので、是非ご連絡くださいませ。

自分の欲しいものが見えていますか?

ITシステムの開発にはトラブルがつきものですが、その中でも一番ありがちなトラブルが、仕様変更というものです。

要するに、「やっぱこれ違うわ!」ということ。

特に仕様変更が納期の直前だったりすると大騒ぎです。既に完成品が出来ている段階で違うと言われても困りますわ。

小さな会社とか、個人事業主なら泣く泣く仕様を変更することも多いのですが、企業対企業なら裁判沙汰です。

例えば注文住宅を建てるときに、引き渡しの直前に「やっぱこれ違うわ!」と言い出すことはなかなか起きないと思うのですが、なぜIT業界ではこんなことが多発するのでしょうか?

それはITシステムというものが、使ってみなければわからないという性質があるからです。

もちろん、作る前に仕様書とか、プロトタイプとか、エンドユーザにイメージをつかませるための対策をしますが、これもエンドユーザ次第なところがあります。

注文住宅であれば自腹を切るので、建築士の説明やらイメージ図とか見取り図を熱心に見たり聞いたりするとは思いますが、システム開発では基本会社が金を出しますからね。そりゃテキトーになりますわ。

で、いざモノが出来てきて使ってみたら、関係各部署からクレームが上がってきて「やっぱコレ違う!」となるわけです。

なお、システム開発では仕様変更が大前提で見積もりをしているため、実際の作業日数の3割~5割増しの見積もりをすることが一般的だったりします。特に初めてのお客さんはリスクが高いのでバッファを高めに乗せます。

結局、自分の欲しいものがよくわかっていないままに仕事を発注するから、高い金額を支払わなければならないわけですね。

これからシステム開発を外注する方は、くれぐれも、作りたいものがわからない状態のまま開発会社を探さないことです。バッファだらけの見積もりしか出てきません。

とまあ、エンジニアの立場から書いていますが、発注側の立場からしたら、じゃあどうすればいいの?という声が出てきそうです。

実はこの疑問に対する答えは出ていて既に使われています。

その答えとは、設計段階ではエンジニアを客先に常駐させて、そこの社員さんと同じくらいのレベルまで業務を理解させてから開発を行う。

という手法です。要するに設計者をお客さんと同レベルになるまでお勉強させようということ。

これはとても有効な方法ですが、1点問題があって、コストが高くなるということがあります。なので大きな開発では多用されますが、小さな案件ではちょっと無理だったりします。

逆に、案件が小さい場合は、とりあえず先に作ってしまってから変更を随時していくという手法も多用されます。WEB系の企業ではこれをアジャイルとかプロトタイピングとか言いますが、これはプログラミングが早い人がいる前提で、かつ発注者とエンジニアの間の関係値も良くないとうまく回りません。

でもこれなら、素人のあなたでもチャレンジできる方法だと思います。

もちろんエンジニアとの信頼関係があって初めてできるものなんで、客だからと横柄だったり、他の会社との相見積をとって価格交渉しようとしたら絶対無理だと思います。私も含めてエンジニアは、そうゆうめんどくさい客とは仕事をやりたがらないものです。