※この記事は過去反響が多かった記事を転載しております。一部掲載当時とは状況が異なる箇所がございますのでその点ご了承ください。原文はこちらのサイトに掲載しております。

こんにちは、Helpfeelエンジニアの teramotodaiki です。

実はこれまで正社員として働いたことが一度もなく、チームでプロダクトを開発した経験もほとんどなかった僕ですが、Helpfeelでは入社してすぐに自分で考えたアイデアを実装し、新機能としてリリースする経験を積むことが出来ました。*1 そこで今回は、Helpfeelエンジニアの開発スタイルについて紹介したいと思います。

僕が考えるHelpfeelの開発スタイルを、３つのポイントにまとめてみました。

• 積極的にドッグフーディングする
• デモを重視する
• 実装者の意見を尊重する

それでは、詳しくみていきます。

ドッグフーディングという言葉をご存知ですか？

Eating your own dog food （自社のドッグフードを食べる）という言い回しがあります。これは開発者が自社製品を日常的に使うことを意味します。Helpfeelが開発しているプロダクトは全てドッグフーディングを行っています。

GyazoやScrapboxの改善は、日々のドッグフーディングの賜物と言えます。HelpfeelはB2BのSaaSなので、自分で日常的に使う場面がイメージできませんでした。そこで僕がHelpfeel社外で開発しているHackforPlayという教育系のウェブサービスにHelpfeelを導入し、それまでNotionで提供していたFAQを置き換えることにしました。サービスを比較することにより、記事の書きやすさや検索性能の違いがよくわかりました。

こんな機能が欲しい！

ドッグフーディングによって分かったのは製品の違いだけではなく、足りない機能も見えてきました。Helpfeelのほとんどの機能はお客様からの要望から生まれますが、稀に「エンジニアが欲しいと思った機能」を追加することもあります。例えば、音声ファイル再生機能です。mp3ファイルを記事に添付したとき、ブラウザ上で音声を聞けるようにする機能です。HackforPlayで使える効果音の素材を聞けるページを作りたいと思ったのがキッカケでした。

試しに作ってから説得する

ウェブサービスの開発は、変化するニーズへの素早い対応が求められる一方で、機能の取捨選択も重要と言われています。機能が増えればバグが生まれやすくなりますし、サービスとしての一貫性を保つのが難しくなっていくからです。そこで重要になるのが、機能としてリリースするだけの価値があるだろうか？という、価値の検証です。Helpfeelチームでは最終的な判断はPO（プロダクトオーナー）である daiizさんが下しますが、POを説得するのは思いついた人（＝実装者）の責務です。

具体的には、次のような行動が推奨されています。

• とりあえず Scrapbox にページを立てて、解決したい課題やアイデアを書き出してみる
• とりあえず実装してみる
• とりあえずデモを見せる

実装者の意見を尊重する

Helpfeelではデモが何より重視されています。実物を見た方がわかりやすいからというのもありますが、もう一つ理由があります。それは、作ってみるのが一番理解が深まるからです。

デモをするためには、伝わるレベルのUIを考えたり、データを作ったり、実装方法を考えたりする必要があります。その過程で、例えばメンテナンスが大変だったり、パフォーマンスが良くなかったり、提供方法も考える必要があったりといった、重要な気づきが得られるのです。そのためHelpfeelでは、UIなども含めて実装者の意見が尊重されます。実装した本人が一番そのテーマについて深く考えているはずで、かつモチベーションもあるはずだからです。「UIはUIデザイナーの仕事」のような役職ありきの考え方ではなく、一番深く考えている人が全てを考えるというのが、Helpfeelのやり方です。この思想によって、プロダクトに対する当事者意識が育まれているのではないかと思います。

リリースされなくてもかまわない

これはエンジニア以外の方には伝わりづらい話かも知れませんが、僕がHelpfeelに入って目から鱗だった話があるので紹介します。以下はHelpfeel社内のScrapboxページ「アプリケーションの設計力」からの引用です。

PullRequestは、マージされなくてもかまわない
・PullReqの概要に「機能だけ見て欲しい。コードのレビューは不要です」と書く
・「◯◯を実験中」などの書き方でもよい
・その結果得られるコメントは、おそらく、便利！とか、こうしたらもっとよくなるのでは？などといった機能や利便性についてのフィードバックになるはず
・また、そもそもあまりアプローチがよくないからやめましょうという話にもなる
・この機能を使うのは、1年に一度もないから、やめましょう
・特定の環境・ユーザーしか使うことがないからやめましょう
・そもそも気がつかれないからやめましょう
・ユーザーを混乱させるからやめましょう
・利便性とコードの複雑さのトレードオフになることもある
・検索アルゴリズムがめちゃくちゃ複雑になるわりにあまりメリットが多くないのでやめましょう、等
・こういうフィードバックと議論を重ねることで、選択眼やアプローチが磨かれていくことになる

PullReqというのはエンジニアの仕事の単位で、マージというのは、世に出る（リリースされる）ことを意味します。せっかくコードを書いてもリリースしなければユーザーにとってはないのと同じですから、これまで僕はリリースされない仕事をすることに意味があるとは思っていませんでした。しかし、今ある解決策が最良ではない場合、「やらない」というのもまた重要な選択肢なのです。

また、「作ってみたけどやらない」という選択肢が許されているということは、試しに作ってみるハードルを下げることにもつながります。SaaSは関わる人が多く、機能の設計にはとても気を遣うことが多いです。そんな状況でもHelpfeelのリリースサイクルが落ちていないのは、長年培われてきたHelpfeelのプロダクト開発思想のお陰かも知れません。

いかがでしたでしょうか。Helpfeelチームでは、エンジニアを積極採用中です！ご興味のある方はぜひ採用情報をチェックしてください。

*1：2015年にプログラミングの楽しさを伝えるゲーム「HackforPlay」の開発を機に学生起業し、これまで4人以上のチームで開発をしたことがありませんでした。詳細なプロフィールはこちらです。