エンジニアが見落としがちなこと

2008/8/18-1

過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。

製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。

1. 技術の凄さのみが戦局を決めるわけではない

「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。それは、正しい場合もあれば正しくない場合もあると感じています。最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。

そもそも「凄い技術」とは何なのかという部分が難しいです。その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。

2. 誰が言うか、誰がやるかも大事な要素

全く同じ事を言ったりやったりしても、誰が行うかで結果が全く異なる場合があります。

例えば、全く同じアイデアであっても、それを言う組織が個人であるか、実現可能性がある企業がいうかで全く捉えられ方が違ってきます。企業などの組織内であれば、部長が言うのと新入社員が言うのでは重みが全く変わってきます。

「何を言うか」も大事ですが「それを言ってどれだけの人を関心させられるか」に関しての閾値(threshold)は残念ながら平等ではなさそうです。

3. 技術的に最先端じゃなくてもニーズが強ければアピール可能

最近、「デジタルフォトフレーム欲しいんだ！あれって凄いよね。技術の進歩って凄いと思う」と言っている女性がいました。

デジタルフォトフレームを技術的に考えると、液晶/メモリ/表示ソフトぐらいまで単純化可能な気がします。そこに、超最新技術があるかと言われると、なかなか頭を縦に振りにくいです。 (中には○○という機能で××と連動！とかあるかも知れませんが。。。または、後述するように私が「凄さ」を単に知らないだけな可能性もあります。)

しかし、いわゆるnon-技術者な方々にとっては、そんなことはどうでも良いことです。安価に面白いものがあれば、それでいいのです。

4. 技術的な凄さは伝わりにくい

技術的な努力は、意外と伝わりにくいものです。特に、エンジニア側が「当たり前」と思っている事の中にこそ凄さがある場合には、アピール活動が全く行われないので「凄さ」が人知れず埋もれる場合もあります。

一方で、アピールをしたとしても、そのアピールを理解するための敷居が高すぎて理解してくれる人が非常に少ないかも知れません。

「技術的な話は伝わりにくい場合があるなぁ」と思う今日この頃です。

5. コスト削減や運用の「凄さ」

特定のアルゴリズムや手法やサービスに対する凄さが注目されやすい一方で、問題が発生しない無難な運用を実現できていることや、コストを削減した運用をできている事に対する「凄さ」は見落とされがちです。

何も問題が発生しない運用はほぼあり得ません。長期間の運用をしていれば、何らかの問題はほぼ必ず発生します。外から見て問題が発生していないように見えるのは、問題が発生してもバックアップ機能が自動的に作動したり、瞬時に問題の解決が行われているためです。

「問題が発生しているように見えない」という一見当たり前のような状態は、高い技術のうえに成り立っている事が多い反面、それが評価されにくいという問題は永遠のテーマなのかも知れません。運用などにも、やっぱり何か象徴的な何かが必要なんですかね。。。

大規模なバグが公知にならないというのも、これに似ているのかも知れません。

6. 手間がかかるとアウト

ちょっとした設定や、ちょっとした更新作業が必要になった瞬間、全てが駄目になる場合があります。

「全てを思い通りに制御できるように、可能な限り細かく設定できた方が嬉しい」という発想がありますが、この発想のために物事が複雑化し過ぎて、使い方がわからなくなってしまうこともあります。

ただ、細かく設定できるものの方が好まれる場合もあります。元々ターゲットが深くニッチな層である場合、マニアックなほどの細かさが好まれるのかも知れません。 (ただし、ニッチであれば細かい方が良いというわけでもなさそうですが。。。)

7. 早過ぎたら駄目

タイミングは大事です。その技術や発想が広まる前から取り組んでも、誰も理解してくれない場合があります。

一番乗りして大勝ちできるパターンがある一方で、早くやり過ぎたために他者へのヒントを作っただけということもあり得ます。

そして、「一番乗り」とは何かという問題もあります。「○○という分野そのものをゼロから作って一番乗り」という事例がある一方で「○○という分野において×という使い方や△というデザインを初めて採用」という少し範囲が狭い一番のりもあります。どちらかというと、後者の方が大きく成功する例が多いのではないかと感じています。

逆に、遅すぎても駄目です。参入が遅すぎると、既に勢力図が出来上がった後になってしまうかもしれません。また、凄い勢いで特許を取得されまくって、ペンペン草も生えないようなフィールドに成り果ててしまっているかも知れません。

8. アテンションがあるか無いか

やったことに対してどれだけ注目を集められるかも、実は重要な要素です。折角凄い技術を詰め込んでも、ユーザが増えたり、認知されたりしなければ失敗プロジェクトになってしまうかも知れません。

9. 大量のユーザを抱え込めたという「凄さ」

「あんなの技術的な新しさ無いよ！力技でやってユーザ抱え込んだだけだ！」という発言を耳にすることがあります。

技術的に新しくなかったとしても、「力技」を実現できたというところと、それによる「ユーザ数」という成果は実は凄いことだと思います。

誰がが大量のユーザを抱え込んだ時、その大量のユーザを自分の所に誘導するのは並大抵ではありません。ちょっとした技術的優位では、見向きもしてくれないかも知れません。

そこにユーザが発生して、常駐しているという事実そのものが大きなアドバンテージになっている場合も多いです。

10. 技術があればコンテンツは集まる？

「凄い技術を集めたものを作れば、コンテンツは出してもらえるに違いない」という発想に出会う事があります。

コンテンツを集めるのは、技術とは多少違ったベクトルになるのではないかと思う今日この頃です。

11. アテンションの集め方を誰が考えるのか

エンジニアとしては、最高の出来を実現することに集中しがちです。例えば、アテンションの集め方などはマーケティング人に完全お任せという場合もあります。しかし、エンジニアというフィールドにいる人のアテンションが目的である場合、エンジニアの方がアテンションが存在している場所や公表する時の「ツボ」を心得ているかも知れません。

一方で、エンジニアはエンジニアのフィールドしか知らないため、アテンションの集め方を多人数で議論する時には双方の歩み寄りが必要そうな気がします。

12. UIは大事

私のまわりには、「kenel内部以外には興味が無い」「ライブラリAPI以上は任せた」という発想のエンジニアは意外と多いです。確かにここら辺の内部構造で性能は大きく変わります。内部構造の優劣によって動作の機敏さなどに大きく影響を与える場合があります。

しかし、結局ユーザが使うのはUI部分です。 UIの概観や動作によって判断される割合の方が、内部構造よりも評価される割合が高いのではないかと感じています。

一方で、議論はUIよりも内部構造の方が盛り上がる事があります。正解が明確ではないUIよりも、論理的に議論がしやすい内部構造の議論が楽しくなるからかも知れません。

わかっちゃいるんですが「UIって難しいよねー」「絵描くの苦手なんだよねー」となる事が多いようです。

13. セキュリティに関しての懸念は伝わらない

「○○ってやれば××ができてしまう」「△と■を合わせると●が暴かれてしまう」などのセキュリティ的な懸念は技術者にも伝わらないことが多いです。

良くあるのが「そんなこと言ったら何もできないだろう！」「そんなネガティブな事を言うなんて技術者としての心意気が足りない」「いいがかりだ」などかも知れません。脆弱性情報を追っかけたり、公表された情報を解析して手元で色々楽しんだりしたことがある人と無い人で考え方が結構違うような気がします。自前で色々遊んだ人の方が一般から見て、ネガティブだったり、後ろ向きだったり、慎重な意見を言うような気がしています。

極端なところでは、昔ファイアウォールを導入しようと提案した時に「そんな甘い考えでエンジニアが務まるのか？自分のPCは自分で守ってこそだろう！」と集中砲火を浴びるという事例がありました。今の常識から考えるとあり得ない話ですが、その頃はまだセキュリティの概念が今とは違っていました。

それとは別に、自分のやっているテーマに対してのセキュリティ面での難問が発生するかどうかもわからない場合、「セキュリティに関しては別途考えます」で終わるというパターンもあります。研究発表で、私が多用した逃げです。

最後に

色々書いてしまいましたが、結局は立場や状況によってケースバイケースな気がします。

思いつくところを色々書いてみましたが、結局は「わかっちゃいるけど難しい」系のリストになっるかも知れませんね。。。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！