Findy Engineer Lab

エンジニアの"ちょい先"を考えるメディア

「楽しい・おもしろい」を選び続けた先に今があった GMOペパボ VPofE 兼 技術部長とOSSとの20年間

皆さん、はじめまして。GMOペパボ株式会社の執行役員 VP of Engineeringと技術部長を兼任している柴田@hsbtと申します。私はOSSのプログラマーとして、プログラミング言語Ruby本体と周辺ツールの開発にも携わっています。

今回、「私の選択」と題した寄稿の機会をいただいたので、一定規模の組織のエンジニアリングマネージャーのトップ、OSSのプログラマーの一人として普段考えていることをご紹介したいと思います。本稿が皆さんのキャリアやソフトウェア開発への取り組みへの一助となれば幸いです。

OSSとの出会い ─ コミュニティと仕事との関わり

私がRubyと初めて出会ったのは、ほぼ20年前です。Web日記を書くためのソフトウェアであるtDiaryがきっかけでした。当時、高専生だった私は一人暮らしを始め、インターネット回線を初めて自宅に引き込みました。常時接続のインターネット環境を手に入れた後、私は自分のホームページを作りたいと思い、レンタルサーバーを借りて日記ソフトウェアを選んでいました。

ブログと呼ばれる仕組みが海外から日本に広まる前で、Perlで書かれたhns(ハイパー日記システム)が最も人気がありました。まだ「CGIといえばPerl」という時代でしたが、Rubyで書かれた tDiaryには見た目を簡単に変えることができるテーマ機能が備わっており、それが「なんとなくかっこいい」という理由からtDiaryを使ってみた記憶があります。

tDiaryとの出会いがOSSとの関わりを決めた

tDiaryを使っていくうちに、プラグインによって機能を拡張することができることを知り、すでに存在していたRubyのコードのコピーアンドペーストを繰り返しながら、機能が少しだけ異なる新しいプラグインを作成しました。そして自分が作成したこのプラグインを、tDiaryの本体に付属させてもらえないかと考えました。

当時はGitHubもなく、OSSを修正したらpatchプログラムが解釈できるコードの断片であるパッチをメールに添付して、開発者やメーリングリストに送るという開発をしていました。そこでパッチをtDiaryのメーリングリストに送ってみたところ、見ず知らずの若者が書いたコードに対して、tDiaryの作者から直した方がよい個所をアドバイスしてくれるなど真摯な対応をしてもらい、最終的に本体にも取り込まれました。

このtDiaryというソフトウェアと、作者であるtdtds(ただただし)さんとの出会いが、私とOSSの関わりを決めたと言ってもよいでしょう。このときから私はコードを書き、OSSとして公開されているソフトウェアに、さまざまな手段でコントリビュートを続けています。

今はGMOペパボで働いていますが、社会人として初めて就職した会社から、これまでに転職した会社の全てで、この「OSSに対してコードを書いている」ことを自分の第一の強みとしてアピールし、またキャリアとして時間を使う対象として、自分が触っているOSSを使っている会社を選択し続けています。

なお、私が当時書いたコードは、今でもGitHubのtDiaryで確認できます。

ソフトウェアを届けるために必要なこと

tDiaryのコードをメールに投げ続けるうちに、正式にtDiaryの開発チームの一員となりました。開発チームの中の一人としてOSSに関わるうち、作ってる自分たち以外にソフトウェアを届けるには、コードを書くこと以外に必要なこともたくさんあることが分かってきました。

具体的には、書いたコードをブラウザからワンクリックでダウンロードできる何かしらのアーカイブ形式(Zipなど)にまとめたり、開発者が開発しやすいように構成しているディレクトリのレイアウトを、利用者が利用しやすいように変換したりする必要があります。ほかには、ソフトウェアを配布するサーバーやデモを動かすサーバーといったインフラも必要となります。

OSSは作者以外に使ってもらうことで、自分では気がつかなかったアイデアを取り組むことができます。そのためには、使いたいと思う人へソフトウェアを届けなければなりません。そのために必要なことは全部、コードを書くだけではなく、開発チームの一員として自分で手を動かして用意するようになりました。そのような活動を続けているうちに、ソフトウェアを書いて届けるまでの一連の流れについて、全体像をイメージできるまでになっていました。

Rubyの開発で必要なことを全てやる

tDiaryを触っているうちに、プログラミング言語Rubyそのものにも興味が湧いてきました。しかし、私はRubyインタプリタに使われているC言語について深い知識があるわけでもなく、Rubyインタプリタを修正してパッチを投げることは簡単にはできません。

そんな一歩を踏み出せないなかで参加したAsakusa.rb(プログラマーが集まってコードの話をする地域ミートアップ)で、Rubyの開発メンバーであるnahi(中村浩士)さんから「Rubyの半分はRubyのコードなんだから、いくらでもできるでしょ」と言われ、それで「プログラミング言語のような広く使われているソフトウェアにコードを送ることは難しい」という壁を自分自身で作っていたことに気付いたのです。

そのときから、自分が分かる範囲でパッチを投げたり、開発中のバージョンでRailsアプリケーションを動かしてみて、期待通りに動かない個所のエラーログをRubyの開発メーリングリストに投稿したりしてきました。当時は、Rubyの開発で使われるCIも今ほど用意されておらず、自前のサーバーでJenkinsを動かして、開発中のRubyでRailsのテストを実行する仕組みを作り、どのコミットからテストが失敗するようになったかを発見しやすくするなどもしました。

そのような活動を続けるうち、Ruby本体の開発メンバーであるmame(遠藤侑介)さんにRubyの開発メンバー(コミッター)に推薦してもらい、改めてRubyを開発する一員となりました。実は開発メンバーになってからも、続けている作業は変わっていません。自分が開発できるRubyで書かれたライブラリをメンテナンスし、世界中の人々にRubyを届けるために必要なインフラや仕組みを毎日構築し続けています。

こうして自分がしてきたことを振り返ってみると、ソフトウェアを届けるために必要なことを全てやり続け、届ける範囲をより広くし続けてきたことこそが、私のOSS活動だと言えるように思います。

プロダクトの成長に必要なことは全てやる

ここでOSSの話からいったん離れて、GMOペパボの一員としてプロダクトを開発することについてお話ししたいと思います。

企業に所属してソフトウェアを開発することがOSSと異なるのは、ただ開発したソフトウェアを使ってもらうだけでなく、その結果として企業理念が達成されたり、それによって利潤を上げ続けることが多くの場合に求められることだと思います。

一方で、OSS同様に、より多くの人に使ってもらってフィードバックを得るということは、ソフトウェアである以上は変わらない、本質的な領域であるとも言えます。そういう意味では、ソフトウェアを開発する上で、OSSだから/仕事で書くからという分け方には大きな違いがないことも分かります。

ソフトウェアを届けることにフォーカスする

私はGMOペパボのエンジニアとして、入社してからずっと技術基盤チームに所属し、プロダクトのコードを直接書くことより、ソフトウェアを届けるために必要なことを中心に活動してきました。そこではミドルウェアを選定し、それをサーバー上で動かすために必要なコードを書きました。

また、ソフトウェア開発でGitやGitHubが広く使われはじめた時期でもあったので、GMOペパボの社内で利用促進のために活動したり、OSSでやったことと同じようにCIを準備したり、CIの結果から得られたプロダクトの不具合を直してきました。

このような活動を続けるうちに、ソフトウェアを届けるには、コードを書いてインフラを用意するだけでは足りないと感じはじめました。より多くの人に使ってもらうには、多くの人の考えを知り、多くの人がフィードバック──ここでは意見や金銭など──を開発者に送ることができる手段を提供する必要があると考えるようになりました。そのため利用者のユースケースを最後まで考え、コードとして実現し、利用者にソフトウェアを届けて、早くフィードバックを得ることが必要です。

その実践としてGMOペパボでは、開発手法としてスクラムを採用し、講師を呼んで講演会を開催したり、私と同日に入社した現CTOの栗林@kentaroとともに、スクラムの考え方を浸透させることを目的としたワークショップを全事業部で実施したりしました。ほかにも、当時新たなプロダクト開発の考え方として提唱されたリーン開発など、より多くの人に使ってもらえるプロダクトを開発するために必要なことは全て試し、GMOペパボという組織で広げる活動を続けてきました。

こういった経験から、ソフトウェアを届けるには、ソフトウェアを書くだけではなく、多くの人を動かし、同じ方向に向かっていくことの必要性を重視するようになったように思います。

技術だけではなくビジネスについての理解と実践

このような活動を続けるなかで、ハンドメイドマーケット「minne」をさらに成長させるプロジェクトが始まりました。私は、このプロジェクトに技術面のリーダーとして関わることになり、技術面だけではなく技術と接するビジネスやデザインの全てについて、課題が発生したら検討し、経営メンバーへ意見を述べることを求められました。

例えば、テレビCMを開始するにあたってシステム面で必要となることだけではなく、スケジュールを把握し、ビジネス上の期待される数字も把握し、それを実現するために必要な組織上のアクションについて述べることが多くなりました。このように技術面では人とコストの制約を柔軟にコントロールすることと、その権限が与えられていたため、技術的にできることは全てやり切ったと思います。

その結果として私が感じたことは、技術面のボトルネックを解消すると、施策の立案やビジネスの設計などにボトルネックが移動するということです。開発チームがコードを書き、プロダクトを届けられる状態にできたとしても、それが実現することについてアイデアが出てこない状態になったり、期待する結果まで届かないということが起こりはじめました。

つまり「ソフトウェアを届ける」だけではなく、ソフトウェアを届けた結果を高めるには、技術面だけではなくプロダクトに関わる全ての事象のボトルネックを取り除き続けることが必要だと気が付きました。

生産性をマネジメントする

「minne」のプロジェクトがひと段落したのち、CTOの栗林から「トップマネジメントの一員として取り組むのはどうか?」という提案をされました。私は二つ返事で「やります!」と回答しましたが、マネージャーになることより、プロダクトを成長させるために「必要なことは全てやる」という気持ちが先行していただろうと思います。

このような経緯で執行役員に任命され、ビジネスプロセス革新室という部署を立ち上げて室長となり、配下に情報システム部門を統括することになりました。

楽しさにはビジネス価値がある

新たに自分の組織を持ち、ユーザーに選んでもらえるプロダクトを作るために必要なものは何かと改めて考えたときに、技術力や企画力はもちろんですが、関わる人々のモチベーションがそれ以上により重要であると部門の中で位置付けました。優れた技術や企画とともにそれを突き動かすモチベーションがなければ、プロダクトとして世の中に生み出されるまでに到ることは難しいでしょう。

そして、モチベーションは「楽しい」「おもしろい」という気持ちと密接に関係していると考えます。自分たちが作ろうとしているプロダクトがつまらないと感じるものであったり、自分にとって楽しさを感じない、そんな状況でプロダクトを作り続けても、優れたものはできないでしょう。

この「楽しい」「おもしろい」という感情は「難しい」「厳しい」という状況と両立することもポイントです。プロダクト開発においてスケジュールが厳しく、求められる品質水準も高い、そんな難しい状況下でも、楽しい・おもしろいという感情の前なら乗り越えられるものです。逆に、簡単な仕事でやってて「つまらない」「楽しくない」という状況こそ、GMOペパボという組織からなくしていきたいと考えています。

このように「楽しい」「おもしろい」という感情には何より変えがたい価値があります。前職の永和システムマネジメントで同僚だったkakutani(角谷信太郎)さんが「楽しさにはビジネス価値があります」というMartin Folwerの言葉を紹介していますが、私もこの言葉に大きく影響を受けています。

もっとおもしろくできる」。これはGMOペパボの企業理念です。そこで私も「もっと(仕事を)おもしろくできる」と考えて、あらゆる施策を検討し、実行に移しています。

†本稿公開時点では、Martin Folwerのblikiとして原文日本語訳をそれぞれ参照のこと。

楽しく仕事をするための裏方に徹する

それでは、楽しく仕事をするには何が必要でしょうか? ここまで書いてきたことから分かるように、何か一つを実行すれば楽しくなるということはありません。新たな学びもない毎日行う作業があれば、コードを書いて自動化を行う。自分たちの組織のコアコンピタンスたり得ないものは、SaaSに置き換える。組織の中で「これ面倒……」というつまらない仕事を見つけたら、おもしろくしていく。そういう活動を地道に続ける必要があります。

私は現在、VP of Engineeringかつ技術部長として、日々何かしらを選択し、決めています。その際に判断の軸としているのが「楽しく・おもしろくなるのはどちらの選択肢か」ということです。エンジニアの各種制度、規定に定められる公式の組織から非公式の組織までの編成、プロダクトを作る上での技術要素や戦略など、自分の関心とする対象の範囲は、コードからそれを届ける周辺のシステム、関わるチームの境界面、チーム全体に関わる人々、会社という組織に所属する人全てというように、エンジニアとしてプロダクトに関わってきた頃から、想像もできないくらい大きくなりました。

しかし私の中では、必要とされるスキルがコードから人にシフトしたこと以外は、大きく変わっていないという印象があります。ソフトウェア、プロダクトを自分以外の人に届ける、そのために自分ができることは全てやる。一貫してこの考えで動いてきて、今の私があります。

「選択」するために必要なこと

私は、コードや人をシステムとして捉えて、それらを効果的かつ効率的に作動させることに、楽しさとおもしろさを感じるようです。その楽しさを享受するため、日々マネジメントを行う上で必要なことを学び、自分にはない視点の人々とディスカッションして学びを得ています。体感ではありますが、今この瞬間が人生で最も勉強している、とも感じます。

何かを選択し、判断する。これはマネージャーだけの仕事ではありません。プロダクト開発に関わる全ての人が、毎日何かしら選択しています。このコードにはもっとテストを書くべきか書くべきではないか、ある施策の結果をスプレッドシートにまとめておくべきか、Slackで伝えるだけにすべきか。それら全てが選択です。その選択一つ一つの積み重ねによって、優れたプロダクトは生まれます。

選択するには、選ぶためのデータとロジックが必要です。私の場合、データについては、SaaSを自分で触ってみる、他の人にも触ってもらって感想を聞く、OSSを動かしてみる、実際に小さいアプリケーションを書いてみるなど、自分で触るということを積み重ねています。そしてロジックは、先ほど紹介したように「使う人が楽しい、おもしろいと感じる方を選ぶ」です。このように、毎日のあらゆる選択において、自分にとってのデータをロジックを作り上げる、これが自分にとって後悔のない「選択」を行うために必要なことだと思います。

そして、毎日の生活の中における選択だけではなく、人生の未来を選択することもあるでしょう。私にとって、人生の岐路となるような選択は、tDiaryとの出会い、Rubyの開発者への推薦、トップマネジメントへの転身などが挙げられますが、これらはいずれもキャリアをこのように作ろうと思い動いてきた結果として遭遇し、選択したものではありません。自分が楽しい、おもしろいと思うことを選択し続け、ある瞬間に選択肢が目の前に登場したときに、自分のロジックに従って選択した結果であったと思います。

毎日選択し続けるなかで、自分の判断軸を養い続け、今後の人生を左右するような選択肢が目の前に現れたときは、自分の価値に合うものを迷わず選択する。そしてその結果を自分の責任として受け入れる。これが私にとっての「選択」に対する考え方です。

OSSと共にエンジニアとして成長する
最近の仕事風景

関連記事

編集:はてな編集部