様々な企業担当者と出会うチャンスをお手伝いする、マイナビ転職主催の転職フェア・イベント情報のご紹介です

マイナビ転職EXPO 講演レポート
会場風景1

開発は楽しいかね?

伊藤 直也

[プロフィール]ニフティ、はてな取締役CTO、グリー統括部長を経て2013年9月よりKaizen Platform Inc. 技術顧問。ブログやソーシャルブックマークなど10年間、ソーシャルメディアの開発と運営に携わる。著書に「入門Chef Solo」(達人出版会)、「サーバ/インフラを支える技術」「Chef実践入門」(技術評論社) など多数。

「楽しい開発」を実現するために、必要なのは“文化”

本日はよろしくお願いいたします。まず、私が技術顧問を務めるKaizenという会社をご紹介します。Kaizenは『PlanBCD』というSaaS形式のABテストのクラウドサービスを提供している会社です。B to Bサービスのため、品質要件はとても厳しいのですが、一般的な業務システムのようにガチガチな開発体制はとっておらず、開発スタイルはとてもカジュアルです。

中心にあるのが『GitHub』。Webでソースコードを共有しながらバージョン管理できるサービスでオープンソースの世界でよく使われてきました。これが最近はWebサービスの会社でもよく使われるようになってきました。『GitHub』を活用した「Pull Requestベース開発」を行っているのですが、私たちはその中でも「コードレビュー」を重視しています。自分の書いたコードにほかのエンジニアがあれこれと言ってくれる機会って、普通はなかなかないはず。間違いの指摘だけでなく、人の書いたコードを見ることで、知識を高められる良さもあります。

開発は前述した「Pull Requestベース」で進め、その後のリリースまでは自動化を取り入れ、早いペースでレビューとパッチを繰り返しています。ほかに開発手法やツールという意味では「Slack」というテキストベースで非同期に会話ができるツールや、家でも仕事ができるリモートワークを取り入れています。そこでのやりとりも、肩の力が抜けたものがほとんど。これほどカジュアルな開発スタイルでも、B to Bのソフトを障害なしで開発できています。

こんな風に開発ができたら「楽しい」と思いませんか?

「他人のコードレビューなんて、インセンティブでもなければ誰もやらないのでは?」とよく聞かれますが、オープンソースの世界では、誰もが楽しいから作っているし、レビューも楽しいからやっているのです。「開発は楽しくなければ」というのは海外では皆が理解していることですし、日本でも同じ考え方の人は増えています。「開発は楽しいか?」と聞かれたら、そういう現場はすでにある、というのが自分の答え。人間、楽しくやるのが一番です。

ただ、開発手法やツールを導入したら開発が楽しくなるというわけではありません。

こういったお話をすると「自分たちもやってみたい」という相談をよくいただきます。GitHubをはじめ、アジャイル開発、スクラム、テスト駆動開発、リモートワーク…… これらのプロセスを導入すれば、自分たちもうまくできるのでは、というわけです。

チーム全員が同じゴールを目指し、チームワークを発揮し、言いたいことを言い合えて、全体を把握でき、結果として全能感を得られる。プロセスはこれらを支えはしますが、導入しただけでそうなるわけでありません。例えば一時期、アジャイル開発がもてはやされましたが、導入して失敗したケースも多くあります。それは、チームワークなどの問題に目を背けているからです。

技術顧問という立場でさまざまな現場に対するアドバイスを求められてきましたが、私が一番にやることは、周囲の“見える化”です。全社で皆が考えていること、気になっていることを机の上に出し、情報や価値観を共有することから始まります。オープンソースの世界と同様、社内でもすべてを見えるようにするためにGitHubなどのツールを使うのです。

「楽しい開発」の入口は、ベタですが“見える化”からです。

これらは、皆が“文化”を意識して初めて可能になります。何でも言いたいことを言える文化、開発はチーム活動であるという文化、全社が見えるようになるのは良いことだという文化。良い開発にはチームがあり、楽しいチームには文化がある。開発は楽しいほうがいいけど、そのためには文化が必要なのです。

大事なのは、「より良いエンジニアになりたい」というモチベーション

会場風景2

司会:ここからは質問形式で伺います。伊藤さんは採用業務にも多くかかわっていらっしゃいますが、一番見るのはどんなところですか?

重視するのは、以前のキャリアより、良い開発とは何かを考えていて、良いエンジニアになりたいという意欲があるかどうか。今までのスキルは、違う現場では通用しないこともあります。新しいことを吸収し、より良いエンジニアになりたいというモチベーションの高い人かどうかを見ますね。

司会:それはどういった部分で確認を? テストはやりますか?

一概には言えないですが、技術の話を楽しそうにするか、どんな本を読んでいるか、志望動機に情熱を感じるか、などが判断材料の例。その場でプログラムを書かせるテストもありますが、中途採用ではあまり意味がないと考えているので、やめました。実際、テストで1行も書けなかった人が入社して、大活躍したというケースもあります。

司会:求職者から見て、楽しく開発している会社を見分ける方法は?

その会社が正しい文化を持っているかが、すごく大事。例えばエンジニアを信頼せず、セキュリティをガチガチにし過ぎているのは、あまりいい会社ではないかもしれません。生産性とリスクは、トレード・オフの関係。セキュリティが強過ぎると仕事もやりにくいですよね。以前いた会社では、社外へのPC持ち出しができない代わりに、エンジニアが信頼されていて、そういう自由が与えられていた。

エンジニアを信頼し、エンジニアにとって働きやすい会社にしたいと考えているかどうか。会社が、何を本当に大切にしているかを見極めるのが大切だと思います。

講演レポートのTOPへ戻る

他の講演を読む