エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

[対談]ひがやすを×和田卓人×Yoshiori(1/3) 「プログラマー35歳限界説」との上手な付き合い方って何だろう?

タグ : 35歳限界説, SE, TDD, Yoshiori, ひがやすを, キャリア, コーディング, スキルアップ, スペシャリスト, テスト駆動開発, ドワンゴ, プログラマー, プログラミング, 和田卓人, 業界有名人 公開

 
プロフィール

株式会社電通国際情報サービス
比嘉康雄(ひが やすを)氏 [@higayasuo]

国産OSS『Seasar』シリーズやJavaフレームワーク『Slim3』開発を主導してきた、アルファギークの一人。電通国際情報サービスに勤めるかたわら、さまざまな技術コミュニティへの参加など、多方面で活躍。個人ブログ『ひがやすをblog』でエンジニアへの提言も行う

プロフィール

タワーズ・クエスト株式会社 プログラマー 兼 取締役社長
和田卓人氏 [@t_wada]

テスト駆動開発(以下、TDD)の普及役として知られる。学生時代、オブジェクト指向分析/設計に傾倒。その後、ソフトウエアパターンやXP(eXtreme Programing)を実践する人たちと出会い、TDDの誕生を知る。現在は講演活動やハンズオンイベントを開催しながらTDDの普及運動を行う

プロフィール

株式会社ドワンゴ ニコニコ事業本部 ニコニコ静画(電子書籍)システムリーダー
Yoshiori(庄司嘉織)氏 [@yoshiori]

Javaコミュニティ『java-ja』代表として知られるプログラマー。ヘルプデスク業務などをこなした後、25歳から本格的にプログラミングを勉強。その後、ひが氏との出会いから『java-ja』を立ち上げる。2009年からドワンゴに勤め、現在『ニコニコ静画(電子書籍)』の開発リーダー

―― 前回の座談会で、「ある程度の年齢になると、外的環境が変わって仕事の進め方が変わる」というお話が出ました。そこで今回は、「プログラマー35歳限界説」をテーマにお話しいただこうと思います。ところで、皆さんはおいくつなんですか?

Yoshiori オレ、今は36歳ですね。今年で37歳になっちゃいます。

ひが 僕は43歳だね。今年の誕生日で44歳になる。

和田 わたしはまだ34歳です。

Yoshiori お、和田さんだけが”定年前”ですね(笑)。

和田 はい。定説どおりであれば、今年で「限界」を迎えるわけです(笑)。

―― 皆さんは、年齢に関連した悩みってあるんですか?

社内で「開発リーダー」になって以来、仕事の進め方に変化が生じてきたと話すYoshiori氏

社内で「開発リーダー」になって以来、仕事の進め方に変化が生じてきたと話すYoshiori氏

Yoshiori 実は、『ニコニコ静画(電子書籍)』のシステムリーダーになってから、コードを書く時間が前よりずっと短くなっているんですよ。今は15人ほどの部下をまとめながら、開発の全責任を背負っています。だから、自分で手を動かせるのは、1日に1~2時間くらいが精一杯で。

ひが そんな細切れな時間では、まとまったプログラミングはできないよね。自分から「このタスク、引き受けるよ」とは気軽に言えなくなるでしょ。

Yoshiori そうなんですよ。締め切りが決まっているものは、なるべく持たないように注意しています。コードを書くのが好きなオレとしては、ちょっとしたジレンマですね。ただ、すごく悩んでいるかと言われると、実はそうでもないんですけど。
 

和田 というと?

Yoshiori すべての仕様が頭に入っているのはチーム中でオレだけだから、自分の手が増えたというか、皆の手を借りながら自分の作りたいものを作ってる感じなんですよ。昔なら、自分で仕様を考えてそのままコードを書いてましたけど、今は開発全体についていろいろ考え、それを形にしている。基本は変わっていないので、不満はそんなにないんですよね。

―― 「35歳限界説」は、社内でのポジションアップと大きな相関性がありますよね。でも、Yoshioriさんはポジションが変わっても、不満なく働けている。

Yoshiori 管理職なんだけど、管理だけじゃない。ちゃんと開発の舵取りはできているんです。大きな意味でのモノづくりにかかわれているから、楽しいんでしょうね。

「会社をハックする」という発想でモノづくりを続ける

ひが 一般的には、コード書くのが好きな人って、マネジャーになるのを嫌うじゃない? Yoshioriはどうだったの?

Yoshiori あんまり抵抗なかったですよ。オレの場合は、言ってみれば「会社をハックしよう」と思ったんですよ。例えば社内にGitを導入したいと思った時、単純に主張しても効果は薄いでしょ。だから、「こうやって提案したら、あの人はこう答えるだろうな。じゃあ、ここにこうやってアプローチすれば、一番実現しやすいだろう」なんて工夫する。それって楽しいんですよね。

和田 なるほど、会社ハックだ(笑)。

プログラマーが職人的な仕事である以上、「使う道具」を選ぶ権限が持てるのは魅力だと意気投合する2人

プログラマーが職人的な仕事である以上、「使う道具」を選ぶ権限が持てるのは魅力だと意気投合する2人

Yoshiori 上から課題がドーンって降ってきた時に、どの技術を使ってクリアするかを考えるのも楽しい。だから、マネジャーになっても、そんなに不満がないんだと思います。ま、書かなきゃいけないドキュメントが増えたことくらい(笑)。

和田 エンジニアにとって、「使う道具」を自分で決められるのは、確かに大きなモチベーションですよね。

ひが でも、例えば3年くらい現場から離れるとするでしょ。すると、技術がガラッと変わって置いていかれる危険性もあるじゃない? そういう時、マネジャーは怖いよね。

Yoshiori その不安はかなりありますね。だから、絶対にコードを書くことはやめないし、新しい仕組みを作るために新しいモジュールが必要な時は、まず自分で使ってみる。

―― 例えばどんなことをやっているんですか?

Yoshiori この前、Kestrel(Twitter社が作った、Scalaで書かれたオープンソースのメッセージキューサーバ)を導入しようとした時も、まず自分のマシンに入れて検証してから開発環境に入れたんです。その辺も、技術から離れちゃいけないという危機感があるからですね。

ひが SIerとかでマネジャーになって、進ちょく管理と顧客とのやりとりだけ担当するようになっていくのが、ダメになっていく典型的なパターンだと思う。

部下ができた途端に「老害」になってしまう人の特徴とは

和田 Yoshioriはさっき、「手が増えた」と言ってたでしょ。それは、自分自身も開発をしているという実感があるからですよね。進みたい方向を自分で決められるというのが、充実感に直結するのではないかと思います。逆に、望まない道具を使わなきゃいけないとか、Excelでガントチャートを更新するだけの仕事をしていると、無力感を覚えてしまうのかもしれませんね。
 

Yoshiori あー、それはあるかもなぁ。

和田 わたしの同世代にも、マネジャーになる人がポツポツ出始めてるんですよ。中にはいわゆる「管理の仕事」ばっかりになってしまい、ジレンマを抱えている人もいます。
 

ポジションが上がったら「現場の仕事はすべて部下に任せる」というスタイルに、ひが氏は異を唱える

ポジションが上がったら「現場の仕事はすべて部下に任せる」というスタイルに、ひが氏は異を唱える

ひが でもさ、それって本当は自分が悪いんじゃないの? Yoshioriみたいに、「仕様はオレの頭に入ってるから、みんなで一緒に作ろうぜ!」というマネジャーになれば良いわけでしょ。にもかかわらず、ある程度のポジションになると、ほとんどのエンジニアが開発系の仕事を部下に振っちゃうんだよね。

―― 今まで作り手だった人が、簡単にコードを書く仕事を放棄しちゃう理由って何なのでしょう? 会社によっては、マネジャーになると強制的に現場から離されるところもあるようですが。

ひが 僕の私見だと、その方が「楽」だからじゃないかな。確かに、自分が開発も分担してやっちゃうと、そこがボトルネックになってプロジェクトがどうにもならなくなるって現実はあるよね。だから、マネジャーが開発を担当するのは良いことじゃない。マネジャーの役割は、部下に気持ちよく仕事をしてもらう環境を作ること。最低限これはできていないといけない。

でも、それをきちんとやり遂げるのは非常に難しいし、面倒だよね。人に気持ちよく仕事をしてもらうことは、かなりの忍耐と努力が必要。だから、たいていのマネジャーは難しくて面倒なことは避け、部下に仕事を全部振って、楽をする道を選ぶ。

―― そういうものですか……。

ひが マネジャーの評価は、プロジェクトを予算期限通りにきちんと終わらせることで決まるからね。部下のモチベーションを上げることは、評価しにくいんですよ。部下のモチベーションがどれくらい上がったのか、数値化するのも難しいし。しかも、モチベーションが上がったから、それが仕事にどんな良い影響を与えたかを数値化するのはもっと難しい。

Yoshiori うんうん、そうですね。

ひが 結局マネジャーは、評価されにくくて面倒な「部下に気持ちよく仕事をしてもらう」という本来の仕事をやらずに、すべての仕事を部下に振るようになっていくんです。技術も現場感覚も分からない「老害」は、こうして誕生する。

(2/3に続く)

1  |   

>> (2/3)「老害」にならないために知っておきたい2つの心得

>> (3/3)「or」ではなく「and思考」で。限界説をくつがえす、攻めの行動学

<過去のひがやすを×和田卓人対談はコチラ>

第1回【恋愛編】 技術屋の「公平さ」は恋の敵!?

第2回【スキル向上編】 「完ぺきなコード」を求めるな

第3回【ダイエット編】 歩く習慣が、体もコードも軽くする

第4回【シャイ克服編】 『ガラスの仮面』ごっこで恋も仕事も充実!




人気のタグ
業界有名人 スタートアップ 開発 SE 転職 エンジニア Web プログラマー スキルアップ ソーシャル アプリ シリコンバレー 起業 プログラミング キャリア スマートフォン Android SIer 技術者 えふしん クラウド UI btrax スペシャリスト Webサービス アプリ開発 Twitter ギーク Facebook CTO デザイン Apple IoT Brandon K. Hill Google ツイキャス SNS 英語 モイめし 世良耕太 IT 30代 赤松洋介 採用 コーディング 20代 村上福之 勉強会 プロジェクトマネジメント UX Ruby 法林浩之 ITイベント Webエンジニア モノづくり 受託開発 ひがやすを 五十嵐悠紀 LINE ビッグデータ 中島聡 ウエアラブル IT業界 ドワンゴ MAKERS コミュニケーション ロボット ハードウエア SI Webアプリ 女性 ゲーム インフラ iPhone 女性技術者 高須正和 ソーシャルゲーム マイクロソフト トヨタ イノベーション 研究者 ノウハウ tips 息抜き システム プラットフォーム イベント 和田卓人 チームラボ 自動車 メイカームーブメント ソニー エンジン 教育 UI/UX 開発者 iOS オープンソース グローバル Java サイバーエージェント 女子会 メーカー 家入一真 ソフトウェア 増井雄一郎 スーパーギーク コミュニティ IPA ニュース 40代 GitHub 日産 TDD テスト駆動開発 グーグル 音楽 モバイル PHP ソフトウエア TechLION

タグ一覧を見る