S.A　開発部 部長　2007年中途入社

ご経歴を教えてください

もともと他社やフリーランスでエンジニアをしていて、当社には2007年に中途で入社しました。私の入社と同時に当社に「開発部」ができて、それからずっと部長をしています。最初は開発部の社員が私しかいなくて、自分で開発をしながらアルバイトの方のマネジメントをしていました。そこからどんどん社員数が増えて、現在は18名のメンバーがいます。 12歳からコンピューターを触っていて、さまざまな言語を学んできました。BASICという言語でプログラムを書いて雑誌に投稿していたら、2回ほど掲載されたこともあります。 仕事としては、当社に入るまでに使っていたのがFORTRAN、C、VisualBasic、Java。「エンタープライズアプリケーション」と呼ばれる企業向けのシステムを作っていました。当社に入ってから学んだものがPerl、PHP、JavaScriptです。 当社に入ってから一番長く使っているのはPHPです。言語自体に得意不得意はあまりないのですが、その上の「設計」が得意です。「美しい設計」にするのが好きなんですよ。 「美しい設計」を言葉で説明するのは難しいのですが、「必然性がある設計」ということでしょうか。プログラムを見たときに、なぜその方法で書かれているのかが理解しやすい設計、というか。どうしてこんなふうに書いたんだろう？ という引っかかりを感じないようなプログラムを見ると、「美しい設計だな」と思います。

部下とのコミュニケーションで気をつけていることはありますか？

部下が作ったものを冷静に受け入れることです。私もエンジニアなのでこだわりはありますし、他人の書いたコードに口を出したくなるときもあります。でも、新卒・ベテラン関係なく、まずは受け入れて意見を聞くようにしています。 社長の教えでもあるのですが、「目的に照らして最適な手段を選ぶ」という考えを持っています。目的が達成できるのであれば、それぞれのやりたいようにやってもらうんです。 その理由は、自分の好みを強制して、部下の時間を不要に拘束してしまわないためです。「こうしたい」と口出ししたくなった理由を冷静に考えてみると、「そのほうが私の好みだから」という場合も多いんです。それに、細かい部分ばかり指摘すると部下の良さを殺してしまいます。 それよりは、プログラム全体や今後の開発方針との兼ね合いがきちんと取れているか？ など、本質的な部分に間違いがないかの確認に時間を使いたいと思っています。本質的な部分の間違いは、きちんと伝えて修正してもらうようにしています。

部下の成功をどのように評価していますか？

小さなことでも、良いと思ったことがあればたくさん褒めます。褒め過ぎは良くないという人もいますが、私はそうは思いません。褒められないと、部下も自分の行動が良かったのか悪かったのかがわからないですよね。いいと思ったことは都度口に出して伝え、良い行動を繰り返してもらえるようにと考えています。 最近だと「社内SNSの投稿の仕方が良かったよ」とか、「あの機能は営業部から喜んでもらえたね」、「（テスト仕様書をレビューして）よく書けています」みたいなことです。また、誰かがよい案を出したときに「ナイスアイデア！」と言うのも意識してやっています。

部下が失敗したときの対応はどうしていますか？

「反省は一度だけして、再発防止の対策を考えてほしい」と伝えています。反省を延々してしまうのも良くないし、全くしないのもよくありません。対策をしないのも困ります。 失敗は誰にでもあるので、一度反省したらそれで十分です。そのあとは、対策のほうに時間を使ってほしいと思います。

今の開発部の課題はなんですか？

システムに関することと、組織に関することがあります。 まずシステムについては、システムがだんだん古くなっていて、よく言うところの「レガシーなシステム」になっていることです。「楽待」のメインのシステムは2011年に設計したものですから、10年以上経っていることになります。その間に世の中の技術は進歩しているので、追いつきたいと考えています。とはいえ、システムの更新には莫大な労力がかかります。「通常業務を1カ月止めて更新に集中します」ということはできないので、少しずつ更新を進めています。 組織としては、チーム分けが課題です。今はインフラエンジニアが1人いますが、その他のメンバーはフルスタックエンジニアです。今回はweb、次はアプリ、のように、案件に合わせてさまざまな開発を全員で担当している形です。ですが、社員の人数が増えてきたので、みんなの得意なことややりたいことをうまく活かしながら、もう少し役割に特化したチーム分けをしてみてもいいかなと思っています。