第41回 技術者は技術に専念。ただ、ビジネスにも興味は持て
岑康貴（＠IT自分戦略研究所）
赤司聡（撮影）
2009/11/24
 |
| 仙石浩明（せんごくひろあき） KLab 取締役 CTO 2000年、KLab 取締役CTOに就任。1995年以来、TCP/IPパケットリピータ「stone」や、Palm上の時刻表ツール「Time Table Viewer」などを開発・発表する。また、「gcd.org」を運営し、会員にサービスを提供している。 |
■「何もしないCTO」を目指して
KLab設立時から参画して、ずっとCTOとしてやってきました。もう9年になります。でも、仕事の内容はどんどん変わってきました。
最初は本当になんでもやっていました。プログラマ兼プロジェクトマネージャ兼システム管理者、という感じです。そこから少しずつ、「自分じゃなくてもできること」を部下に任せるようにしていきました。部下が育ってきて、「そろそろこの仕事を任せられるな」と思ったら、1つ1つ仕事を切り離して、渡していくということです。究極的には「何もしないCTO」になるのが理想です。
大きな区切りだったのは、データセンターのサーバで障害が起きた時に自動で送信される警告メールを、わたしが受け取らなくなったときですね。最初のころはデータセンターから連絡が来て、わたしが直接行って対応していました。でもそのうち、部下が育ってきて、自分が行かなくてもいいようになってきたので、任せるようになりました。最終的には、その連絡を受ける仕事自体、わたしから切り離しました。このときが一番大きな区切りだったと思います。
「何もしない」といいましたが、そうはいっても「やるべきこと」はたくさんあります。わたしはそれをどんどん見つけて、部下ができるようになったら任せていく、という繰り返しをしています。先日までは「研究開発部の部長」という仕事をしていたのですが、部下が育ってきたので任せました。今は「人事」の部分、採用や社内制度に関しての仕事をし始めています。
本当は、細かく制度を作るのは苦手なんですが、会社としてはやらないといけない。そうやって、そのとき「やった方が良いこと」を見つけて、やってみるというのがわたしの仕事ですね。
■「技術者にとっての社長」が考える「成長に役立つ会社」
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
わたしは、CTOは「技術者にとっての社長」になるべきではないかと思っています。技術者とは、根本のところではビジネスに興味が持てない生き物だと思っています。わたし自身がそうですから。究極的には、ビジネスがどう、経営的にどうという部分よりも、問題があって、技術的にどう解決するか、という方が好きなんです。でも、社長はそうではいけない。社長はビジネスのことを24時間、考えている。そうなると、技術者は社長に、根本のところで付いていけなくなってしまう。上層部がみんなビジネスのことしか考えていなかったら、技術者は付いてきません。そういう意味で、CTOが「技術者にとっての社長」としての役割を果たすべきなのです。
極論をいってしまえば、経営者は「もうかれば手段は問わない」わけです。だから時として、技術者がコストでしかないときもあるかもしれない。コストをいかに削減するかも経営者の仕事の1つですからね。だから、技術者は「良いように使われてしまう」可能性がある。スポーツ選手は、エージェントが選手の利益を最大化するように働きます。でも技術者にはそういう存在がいません。
しかし、技術会社としては、技術者が育たないのは致命的なわけです。だから、経営者と技術者の利害を一致させる必要があります。そこで、わたしはこの会社を「技術者の成長に役立つ会社」にしたいと考えました。「技術力」という、技術者にとっての資産を得られる会社です。これは会社にとっても、経営者にとってもいいことなんです。だって、技術者が育って、おまけにそれを外にアピールすれば、優秀な技術者が集まるようになるかもしれない。ヘッドハンティングに使うコストを削減できるかもしれない。
「技術者の成長に役立つ会社」にはいろいろな要素がありますが、まずいえるのは「成長を邪魔しない会社」です。技術者を育成するどころか、邪魔をしているケースが多い。邪魔をしなければ、優秀な技術者は伸びます。邪魔をするというのは、例えば「技術的に特定の分野で優れているのに、ビジネス的な視点やコミュニケーション能力を伸ばせという」とか。そんな邪魔をするんじゃなくて、優れている部分をどんどん伸ばしてもらえばいいのに、ついつい邪魔をしてしまう。
■「餅は餅屋」。だけど「ほかの餅屋の目利き」はできるようになろう
技術者は自分にとって最適な仕事を見つけるべきです。よく、プログラマからシステムエンジニアになって、そのあとプロジェクトマネージャになって……というキャリアパスが示されますが、わたしはそういう考え方は嫌いです。だって、プログラマとプロジェクトマネージャって、全然違う仕事ですよ。プログラマは機械相手、プロジェクトマネージャは人間相手で、そもそも向く方向すら違う。適性だって異なります。向いている方に専念した方がいい。これは私見ですが、プログラマとしての才能がある人がプロジェクトマネージャをやると、「プログラマの才能がマイナスに働く」ことすらあると思います。プロジェクトマネージャは大局からものを見なければいけないのだけれど、プログラマとしての才能にあふれている人は、細かい部分を見てしまいがちです。やはり、どちらかに特化した方がいい。
「餅は餅屋」です。プログラマなりプロジェクトマネージャなり、自分に向いている部分に特化した方がいい。ましてや、技術者にビジネスセンスを求めるなんて馬鹿げています。ビジネスは、技術者が片手間に考えて何とかなるような甘いものではありません。素晴らしい技術があればもうかる、なんてことはない。技術を使ってどうもうけるかは、ビジネスのプロが24時間、ビジネスのことだけを考えていなければ思い付かないでしょう。だから、それはビジネスの専門家に任せる。その代わり、技術の専門家は24時間、技術のことだけを考えていなければなりません。
ただし、ほかの仕事にも興味は持った方がいい。興味を持って、お互いにリスペクトし合うべきです。わたしは研究開発部の定例ミーティングで、よく会計の話をしていました。ほかの人が何をしているのか、興味だけは持ってほしいからです。それがないと、リスペクトすることすらできません。
役割分担をするということは、パートナー選びが重要になるということです。「餅は餅屋」ですが、「ほかの餅屋の目利き」ができないと危険です。技術の専門家は、ビジネスの専門家をパートナーに選ぶとき、「この人は経営のプロとしてどの程度か」ということを判断できる程度にはなっておかないと、何をされるか分かったものではありません。
「ビジネスが分からない」という技術者には、このことを強調しておきたいと思います。できるようになれとはいいません。でも興味は持ってほしい。そして、目利きができるようになってほしい。そうでなければ、もったいないですよ。
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
