2022.07.22
部長って一体どんな人?【開発部編】
「自分の上司になるのはどんな人だろう?」
「怖い人だと嫌だな…」
「自分と合わなかったらどうしよう」
そんな不安に駆られたことはないでしょうか。自分がこれから働く会社でどんな人が上司になるのか、就活をしていれば誰でも気になるものです。
せっかく志望した会社で内定を貰えても、入社後に「上司と合わないから辞める」なんてことになったら勿体ないですよね。どのような人物が自分の上司になるのか、事前に知っていればミスマッチを防ぐことができます。
そこで今回は、開発部の部長にインタビューをしてみました。開発部に配属された場合、この人が上長となります。
部長がどのような人物なのか、部長の考え方や価値観が自分と合っているか、などを少しでも知っていただけたらと思います。
※他部署の部長インタビューはこちら→ 営業部編 / マーケティング部編
◇
S.A 開発部 部長 2007年中途入社
プログラミング歴40年!? 生粋のエンジニア
― ご経歴を教えてください
もともと他社やフリーランスでエンジニアをしていて、当社には2007年に中途で入社しました。私の入社と同時に当社に「開発部」ができて、それからずっと部長をしています。最初は開発部の社員が私しかいなくて、自分で開発をしながらアルバイトの方のマネジメントをしていました。そこからどんどん社員数が増えて、現在は18名のメンバーがいます。
― これまでどんなプログラミング言語を扱ってきましたか?
12歳からコンピューターを触っていて、さまざまな言語を学んできました。BASICという言語でプログラムを書いて雑誌に投稿していたら、2回ほど掲載されたこともあります。
仕事としては、当社に入るまでに使っていたのがFORTRAN、C、VisualBasic、Java。「エンタープライズアプリケーション」と呼ばれる企業向けのシステムを作っていました。当社に入ってから学んだものがPerl、PHP、JavaScriptです。
― 得意な言語はありますか?
当社に入ってから一番長く使っているのはPHPです。言語自体に得意不得意はあまりないのですが、その上の「設計」が得意です。「美しい設計」にするのが好きなんですよ。
「美しい設計」を言葉で説明するのは難しいのですが、「必然性がある設計」ということでしょうか。プログラムを見たときに、なぜその方法で書かれているのかが理解しやすい設計、というか。どうしてこんなふうに書いたんだろう? という引っかかりを感じないようなプログラムを見ると、「美しい設計だな」と思います。
失敗経験からたどり着いた「迷い」のないマネジメント
― 当社に入社する前まで、マネジメントの経験はありましたか?
なかったです。ずっとエンジニアをやってはいたのですが、当時は何度か転職をしていたため、部下を持つまでいかなかったんです。それに、当社に入社する直前は6年くらいフリーランスでした。だからどこに行っても1人で、「部下を率いてチームでなにかする」ということに関しては全くの未経験でした。
― 未経験で部長になり、苦労したことはなんですか?
チームをまとめることや、他人を評価することです。部長になったからには、いいと思ったこと・ダメだと思ったことを言葉にしてメンバーに伝えなければなりません。
たとえば、業務時間中に業務とは関係ないおしゃべりを長く続けるなど勤務態度が悪かったり、会社のルールを守らなかったりする社員がいたら叱ったこともありました。また、基本的には叱る前に注意をして改善を促します。最近だと、新入社員に対して「結論から話して」と注意をしました。簡単そうに思われがちですが、気になったことを言語化して伝えるのは意外と最初の頃は難しいものです。
― 大変だったエピソードで記憶に残っているものはありますか?
チームをうまくまとめられず、半年間も開発に取り組んだのになにも完成しなかったことです。アジャイル開発を初めて導入してみたときだったのですが、全くうまくいきませんでしたね。私にチームの意見をまとめる力がなくて、メンバーが好き放題開発をするような形になってしまいました。
― どのように解決されたのですか?
なにもできないまま半年が経ち、まずいと思って体制をすべてリセットしました。開発のゴールを明確に決め、役割分担を徹底したらうまく進み始めたのを覚えています。
この時の経験から、今でもチームマネジメントでは役割を明確にすることを大切にしています。たとえば、何かを2人に任せるときはどちらかをリーダーにします。どちらかに決定権を持たせたほうが、仕事が早く進むんです。これ以外にも、役割を明確にして「迷い」がない状態になるようマネジメントをしています。
まずは「他者を冷静に受け入れる」
― 部下とのコミュニケーションで気をつけていることはありますか?
部下が作ったものを冷静に受け入れることです。私もエンジニアなのでこだわりはありますし、他人の書いたコードに口を出したくなるときもあります。でも、新卒・ベテラン関係なく、まずは受け入れて意見を聞くようにしています。
社長の教えでもあるのですが、「目的に照らして最適な手段を選ぶ」という考えを持っています。目的が達成できるのであれば、それぞれのやりたいようにやってもらうんです。
― それはなぜですか?
自分の好みを強制して、部下の時間を不要に拘束してしまわないためです。「こうしたい」と口出ししたくなった理由を冷静に考えてみると、「そのほうが私の好みだから」という場合も多いんです。それに、細かい部分ばかり指摘すると部下の良さを殺してしまいます。
それよりは、プログラム全体や今後の開発方針との兼ね合いがきちんと取れているか? など、本質的な部分に間違いがないかの確認に時間を使いたいと思っています。本質的な部分の間違いは、きちんと伝えて修正してもらうようにしています。
― 部下の成功をどのように評価していますか?
小さなことでも、良いと思ったことがあればたくさん褒めます。褒め過ぎは良くないという人もいますが、私はそうは思いません。褒められないと、部下も自分の行動が良かったのか悪かったのかがわからないですよね。いいと思ったことは都度口に出して伝え、良い行動を繰り返してもらえるようにと考えています。
最近だと「社内SNSの投稿の仕方が良かったよ」とか、「あの機能は営業部から喜んでもらえたね」、「(テスト仕様書をレビューして)よく書けています」みたいなことです。また、誰かがよい案を出したときに「ナイスアイデア!」と言うのも意識してやっています。
― 部下が失敗したときの対応はどうしていますか?
「反省は一度だけして、再発防止の対策を考えてほしい」と伝えています。反省を延々してしまうのも良くないし、全くしないのもよくありません。対策をしないのも困ります。
失敗は誰にでもあるので、一度反省したらそれで十分です。そのあとは、対策のほうに時間を使ってほしいと思います。
― 部下の技術力向上のために、どんな指導をしていますか?
「自分の書いたプログラムに責任を持とう」ということを言っています。自分の書いたコードは自分できちんと理解して、しっかり動くようにしてほしい、ということです。さらに言えば、自分の書いたコードが全体にどんな影響をおよぼすのか考えてほしいと思っています。
たとえば、「本やネットに載っていたコードを写して入れたら、上手く動かなくなった」というケースがよくあります。もちろん、コピーするのが悪いというわけではないです。でも、プログラムの前後の流れを無視して一部分だけコードを貼り付けたのなら、うまく動かなくて当たり前ですよね。
自分のコードを理解して、プログラム全体の中できちんと動くように考えていると、技術力が上がってくると思っています。
「いいもの」を突き詰める開発部
― 開発部ではどんなことをしていますか?
不動産投資ポータルサイト「楽待」の開発をしています。今は、先日リリースした有料会員サービス「楽待プレミアム」の追加開発がメインです。最近では、「土地の値段の自動計算機能がついた地図アプリ」のようなサービスを作りました。
開発フローは、ウォーターフォール型とアジャイル型のミックスだと思います。基本的にはアジャイル型ですが、開発内容によって使い分けています。大規模な開発の場合は、ウォーターフォール型のほうがうまく進みやすかったりしますしね。
― 「楽待」はすでにできあがっているサービスだと思うのですが、まだ開発することがあるのですか?
これが、たくさんあるんです! 「楽待」はたしかにできあがっていますが、もっと便利で、もっと大家さんの役に立てるサービスになれると思っています。たとえば、「楽待」は昔はweb版しかないサービスでした。しかし、スマホアプリ版もあったほうが便利だろうと考え、最近はアプリ版の開発に力を入れています。
サービスを便利にするためにはどんな新機能が必要だろう? 既存の機能にAIを組み合わせたらもっと使いやすいかも? など、より使いやすいサービスを作るために日々開発に励んでいます。
― 開発部の仕事で楽しいと感じたことはなんですか?
最近だと6月にあった「楽待プレミアム」のリリースは楽しかったです。「楽待プレミアム」とは有料会員サービスのことです。このサービスはメンバー全員がかりで半年ほどかけて作ったものだったので、久しぶりにイベント感があって楽しかったです。開発部は基本いつもなにかを作っているとはいえ、今回ほど大きい開発は数年に一度ですから。
― 「楽待プレミアム」のリリースで大変だったことはありますか?
決済システムを作ることです。当社には一切ノウハウがなく、どんな技術があるのか調べるところから始める必要がありました。最終的にはStripeやRevenueCatといった技術を新しく採用し、web、Apple、Googleなど、さまざまなルートから決済できるシステムを作り上げました。
― 新しい技術を導入するときはどのような流れで行いますか?
まず「こんな機能を作りたい」という目的があり、そこに新しい技術が必要なのであれば導入するという決まりです。
社員から「この技術を使いたい」と提案を受けることももちろんあります。その場合、まずは技術を導入するメリットがあるのかどうか検討します。メリットがありそうなら導入するといったような流れです。
たとえば、「AIを使って何か面白いことはできないか?」という考え方はしません。「サービスを改善するのにAIを使えないか?」という考え方はします。あくまで、やりたいことが先にあるのです。「この技術を使ってみたい」というだけで導入を決めないのは、当社の特徴でもあると思います。
― 「この技術を使ってみたい」というだけで導入しないのはどうしてでしょうか
導入コストに見合うメリットがあるか考えるためです。新しい技術を導入するには、メンバー全員が技術について学ぶなどそれなりにコストがかかります。この技術を使ってみたい、から始めてもよいのですが、実際に使うかは費用対効果で考えます。
― 導入するとなった新しい技術はどのようにして学ぶのですか?
先に勉強したメンバーから他のメンバーに教えてもらっています。作りたい機能が決まったら、それが実現できそうな技術を調べてもらいます。次に、数ある技術の中から良さそうなものを選び、導入を決めたら、本やネットでさらに詳しく学んでもらいます。その後、他のメンバーにも知識を共有してもらうという流れです。
― 今の開発部の課題はなんですか?
システムに関することと、組織に関することがあります。
まずシステムについては、システムがだんだん古くなっていて、よく言うところの「レガシーなシステム」になっていることです。「楽待」のメインのシステムは2011年に設計したものですから、10年以上経っていることになります。その間に世の中の技術は進歩しているので、追いつきたいと考えています。とはいえ、システムの更新には莫大な労力がかかります。「通常業務を1カ月止めて更新に集中します」ということはできないので、少しずつ更新を進めています。
組織としては、チーム分けが課題です。今はインフラエンジニアが1人いますが、その他のメンバーはフルスタックエンジニアです。今回はweb、次はアプリ、のように、案件に合わせてさまざまな開発を全員で担当している形です。ですが、社員の人数が増えてきたので、みんなの得意なことややりたいことをうまく活かしながら、もう少し役割に特化したチーム分けをしてみてもいいかなと思っています。
― 開発部として会社にどのように貢献したいですか?
売れる商品を作りたいです。あとは、ユーザーに喜んでもらいたいですね。社内で「投資家さんや不動産会社さんから嬉しい声が届きました!」という共有があると、私達も嬉しくなります。
こんな人に来てほしい!
― 開発部のメンバーには何を求めていますか?
「いいものにする」ということを真剣に考える姿勢を求めています。受託開発ではなく、自社サービスを作れるという恵まれた環境にいるのですから。
たとえば、営業部からシステムに関する要望が届いたとします。これを、何も考えずに実装するのでは足りないんです。さまざまな人の意見を聞いて、営業部も、お客さんも、我々開発部も「いい」と思える仕組みをよく考えて作るところまでやってほしいと思っています。
― 開発部には、どんな方に来てほしいですか?
真面目な人に来てほしいと思っています。「カリスマプログラマー」のようなキラキラ感はいらないので(笑)、「何か作りたい」という真剣な思いのある人、どうやったら良くなるかを自分で考えられる人に当社の環境は合うのではないかなと思っています。自社サービスを作りたい方や、フルスタックエンジニアになりたい方におすすめです。
新卒に関しては、文理は問いません。方程式などに興味を持てるのはたしかに理系の方が多いかもしれませんが、「サイトをどう変えたら使いやすくなるか?」ということを考える力は文系の方も負けていないと思います。「文系で経験がないから」とエンジニアの道を諦める方がいると聞きますが、その必要はないと伝えたいです!
◇
開発部の部長がどのような人物か、少しでも伝わったでしょうか?
「部長と直接会ってみたい」
「もっと色々な話を聞いてみたい」
そう思われた方はぜひ、ファーストロジックの説明会や選考に参加してみてください。社員一同、お待ちしております!