Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

Diverseが健全な開発を行える組織を目指すために

Diverseでかいはつ室の室長をしているnogです。

Diverse Advent Calenderの15日目です。

Diverseの開発全体として現在目指している方向性について書かせていただきます。

 

 

 

私は事業としてサービス運営を行っている会社に置いてエンジニアがやるべき開発というのは大きく3つに分かれると考えています。 

1.サービスのための開発(ユーザーに刺さるコンセプトや時代に求められている要素を伸ばすための開発)
2.サービスを事業として成長させていくための開発
3.サービスを持続的に運営していくための開発

3つです。

 

新規のサービス等に置いては12のどちらかへの比重をほぼ100%に置いての開発も非常に有効です。一定のステージに上がるまでそこへの比重を非常に大きくしなければ生き残ることは非常に難しいと思っています。

 

しかし一定期間以上の運用を行っていくサービスはこの3つのバランスを取って開発を行っていくことが非常に重要だと考えています。

 

これまでDiverseでこの3つのバランスを適切にとれていたかというと、正直なところそういう状態ではありませんでした。1もしくは2のどちらかへの比重を非常に高くし、残った2つに対してはほとんど力を割けない。といった状況が長く続いていました。

 

Diverseでは特にYYC,youbride,Poiboyという3つのサービスに力をいれて開発を行っていますが、

このうちYYC, youbrideに関しては累計運用年数が15年を超えるサービスになっています。

長期運用を行っているサービスにおいて3を軽視することの危険性はエンジニアの皆さんなら簡単に想像が出来ると思います。

 

Diverseにいる私の役割はこの1,2,3のバランスを取れる状態を作っていくことだと考えていて、特に3に対する割合を増やしていくことに関しては急務だと考えています。

そこで現在各事業部のエンジニアと協力して各事業部に対して横串で

・ビジネス側のメンバーへの技術的負債を軽減することの重要性の啓蒙や実際の改善作業のサポート

・上手くメンテナンスが出来ていない社内ソフトウェアの切り捨て

・クラウド移行のメリットや移行時にかかるコスト等をまとめ事業の計画に盛り込み、実際に移行作業を進める

・新規に利用する技術の検証や実験

・開発環境の構築

・監視環境の整備

等の少人数の開発チームの中で行いにくいけどやっていかなければいけないことを行なっています。
この結果サービスがより成長出来るような状態を作っていけると信じております。

 

技術的なハードルもなかなか高い仕事ではあるのですが、Diverseではこういった仕事に魅力を感じる!といったエンジニアの方を募集しています!

募集ポジション / 株式会社Diverse

Android Test Night #5にて『Androidテスト全書』の著者の一人としてトークに参加させていただきました

『Androidテスト全書』の一部を書かせていただきました id:kikuchy です。

peaks.cc

こちらの書籍の発売を記念して、DeNAさん主催のAndroid Test Night #5にて、執筆陣のトークが開催されました。
トークにはkikuchyも加わらせていただき、執筆の思い出などについてお話させていただいたり、会場の皆様からお寄せいただいたご質問に答えたりしました。

testnight.connpass.com



なんと当日の模様を、参加してくださった id:nowsprinting さん、 id:Gateau さん、id:wifeofvillon さんがブログにまとめてくださっています。
ありがとうございます!

www.nowsprinting.com

gateau.hatenablog.com

wifeofvillon.hatenablog.com


会場で何があったかは、上記を読んでいただけますとわかりやすいかと思います。

個人的には、「本を手に入れてからテストを書くようになった」というお話、「この場で買った」というお話がとても印象に残っています。
著者冥利に尽きますね…!

原稿管理あたりで思ったこと

当日は言う機会がありませんでしたが、「PEAKSさんの体制すごい」と思っていたのでこの機会に書いてしまおうと思います。


会場でも少し発言しましたが、kikuchyは趣味で小説の同人活動をしていたりします。

ときたま、二次創作の合同誌(複数人の作家が集まって作る一冊の同人誌)の主宰をしたこともあるのですが、大変なのは(自分の執筆を除けば)原稿の管理と組版でした。

誰から原稿をもらったのか、
どう赤入れをしたのか、
どれが最新版なのか、
どこまで組版用の原稿に反映したのか…
(大抵の場合、原稿はWordドキュメントかtxtをメールかTwitterのDMでいただくことが、組版はAdobe InDesignですることが多いです)

特に組版用の原稿(InDesignファイル)を作り始めてしまった後に原稿の修正が入ると、変更箇所をなんとかして探し出して、変更箇所だけを組版に反映する(文字を全部流し直すと、特殊ルビなどを組んだ箇所が組み直しになるため)ということを手作業でやらねばなりませんでした。

『Androidテスト全書』も著者が複数人ですので、当然原稿管理と組版の問題が発生します。

ところが、やはり技術書の会社は違いました。

原稿はすべてgithubのプライベートリポジトリ管理、
修正依頼はプルリクエスト、
Re:VIEW(内部的にはLaTeX)で簡易組版が可能、
最終的には手作業で組版をされているにしても差分はPRでひと目でわかる…

当然、苦労がないわけではないでしょうが、この簡便さは衝撃的でした。

最近、この一連の本業の作家さんのtweetを見て、こうした便利さがもっと広まるといいなと思いました。
(このツイートに連なるツイートも読んでみてください)


Diverse(ダイバース)はエンジニアの登壇や外部発表を応援しています。興味のある方は、 @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!

『Diverse.tech #1 〜レガシーシステムを語らう夜〜』を開催しました

去る11/22、いい夫婦の日に、マッチングサービス運営の老舗であるDiverse(ダイバース)初のミートアップを開催しました!

その名も、『Diverse.tech #1 〜レガシーシステムを語らう夜〜』

diverse.connpass.com


弊社Diverseでは、YYCyoubrideなど18年間もの歴史を持つサービスを運営し、今なお成長させ続けています。
また同時に新しいサービスの開発にも取り組んでおり、Poiboyなどを開発している会社でもあるのです。

そうした長期に渡ってマッチングサービス開発を継続するノウハウ、新しいマッチングサービスの産みの苦しみを同時に経験している弊社だからこそ、お伝えできるものがあるはず。
それをエンジニアのあなたと共有したい。

という趣旨のもとに、Diverseではミートアップの開催を計画しています。

f:id:kikuchy:20181122194633j:plain
Diverse.tech #1の様子

今回はその第一弾として、レガシーシステムとどう折り合いをつけているのかを、下記4名のエンジニアがお伝えいたしました。


speakerdeck.com

レガシーシステム・技術的負債について分類し、Diverseがどう向き合っているかについて話しました。


とツイートしたように、レガシーシステムや技術的負債を課題として考え解消するためには、どうアプローチしていくか?についての内容になります。


@imaizume は、レガシー返済のため必要な改善活動を継続的に行うための仕組みについて「『「改善Dayを作ろう!」って言ってたけど気づいたらなくなったよね…』を繰り返さないために」というタイトルでお話させていただきました。

bit.ly

継続的改善には改善Dayのような時間の確保以前に、開発体制の見直しなどの仕組みの整備が必要です。
現在のPoiboyはスケジューリングやタスク見積もりといったモダンな開発体制を採用していますが、それらを獲得するまでの変遷や自身が経験した出来事等を整理してご紹介しました。
当日ご来場頂いた方からも共感の声をいただくことができました、皆様の現場でお役立ていただければ幸いです。



speakerdeck.com

仕様も分からなければ、読み応えバツグンのソースコードに出会った時に使えるテクニックとして仕様化テストというテスト手法があるよという話をしました。

今回の登壇では、レガシーソフトウェア改善のためのテクニックに関心をもってもらい、スライド内で紹介した「レガシーソフトウェア改善ガイド」という書籍を手に取ってもらえることをゴールになるように考えていたのですが…

10分という登壇時間の中でスライドをまとめるには、アイスブレイクに費やす時間を多くしすぎてしまったかなと反省しきりの内容になってしまいました;

ということで、改めてレガシーソフトウェアの改善に興味・関心のある方はこちらの書籍を読んでみることをオススメします!

レガシーソフトウェア改善ガイド (Object Oriented Selection)

レガシーソフトウェア改善ガイド (Object Oriented Selection)



speakerdeck.com

レガシーなシステムをどのように効率よく置き換えるかという話をしました。

限られたリソースでレガシーシステムに挑まねばならないことは多々あると思います。
なるべく、手をかけずメンテコストもかからない方法で置き換えていきましょう。


Diverseでは、今後もミートアップの開催を企画しています。
マッチングサービスの老舗で、どんなエンジニアがどう頑張っているのか、どんな挑戦があり、どんな知見を得ることができたのか。
お伝えしていきたいと思います。

ぜひconnpassのグループをフォローして、今後のイベントのお知らせを受け取れるようにしてください。

Diverseではともにレガシーシステムと生きるエンジニアを募集中です!

Matching Dev Meetup#1でクライアントアプリの状態管理と仕様の複雑さについてお話しました

そろそろAdvent Calendarの季節が近づいてきて、勢い勇んで枠だけ取ったものの何を書くのかほとんど決まっていない id:kikuchy です。やばい。


先日、Matching Dev Meetup#1 - iOS / Androidというイベントが開催されました。

マッチングサービスを提供している各社からエンジニアが集まって、マッチングサービスに特有の話題などを共有しよう! という会です。
弊社Diverse(ダイバース)の他にも、Pairsのエウレカさん、タップル誕生のマッチングエージェントさん、withのイグニスさん、CROSS MEのプレイモーションさんなど、たくさんの会社からたくさんの関係者が集まる賑やかな会となりました。

matching-dev-group.connpass.com

マッチングエージェントさんによるブログでも、当日の様子が公開されています。

developers.cyberagent.co.jp



催されたLT会のなかで、私は『男女出し分けと会員状態で画面切り分けが大変な話』というタイトルで、マッチングサービスのクライアントアプリにおける状態管理と仕様の複雑さについてお話しました。



なんの打ち合わせもしていないのに、まるで示し合わせたかのように各社が「マッチングサービスのクライアントアプリは状態管理が鬼門」というLTをしていたのが印象的でした。
それだけ、我々は状態管理に悩まされている訳ですが…

その原因は仕様の複雑さにあります。
マッチングサービスのユーザーは、登録性別やユーザー属性、法的に必須な年齢確認状況など、様々な変数を持っています。
その変数の状態ごとに、運営としてやりたいこと/やらなくてはいけないことが変わってくるのです。
そうなると、「この場合は」「こうする」という仕様が大きくなってゆき、さらにクライアントにつきものの通信処理やそのキャンセルなどが挟まって大変なことになる、という訳です。

エンジニアとしては状態をうまく管理する方法を見つけつつ、サービス運営の中の人としては仕様の単純化と外せない仕様のバランスを上手く取っていくことが、サービス開発の肝となります。

そうしたマッチングサービスの開発の雰囲気が伝われば嬉しい限りです。


懇親会では、CS(カスタマーサービス/カスタマーサティスファクション)も特有の苦労がある話や、「ユーザーに価値を提供するとユーザーが離脱していく」という特性を持った婚活サービスの諸行無常さ(パートナーが見つかると退会する必要があるため)について、各社の関係者さんや、他業界の方と話がはずみました。

またテーマを変えて開催される見込みなので、興味のある方はConnpassのMatching Dev Meetupグループをウォッチしてみてください。

matching-dev-group.connpass.com



状態管理と戦う良い方法の知見をお持ちの方、こうした環境で自分の腕を試したい方は、 @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

弊社エンジニア3人がDroidKaigi 2019に登壇します

id:kikuchy です。

先日DroidKaigi 2019のセッション採択者に通知のメールが送られました。

結果、弊社Diverse(ダイバース)からは、三人のエンジニアが登壇する事となりました! 🎉㊗



以下、登壇する三人の発表内容と意気込みです。
DroidKaigi 2019のセッション選びの参考にしてください。



id:samukei は「PWAでここまで出来る」というタイトルで発表します。

PWAはWebアプリの開発者がスマートフォンアプリケーションも開発できるという可能性を秘めた技術です。

PWAを知らない方には知ってもらうきっかけに、PWAを知っている人にもこんなことまでできるアプリケーションを作れるんだ!
と感じてもらえるようなセッションにしたいと思っています!



id:kmnmn は「実践Lottie」というタイトルで発表させていただきます。
私が担当しているプロダクト Poiboy にて実際にLottieを使って得たメリットやデメリット、デザイナーさんとのやりとりなども含めて共有できたらと思います。



id:kikuchy は『All About Test of Flutter』というタイトルで、
Flutterアプリ開発で必要になるであろう自動テストの始め方をお話します。

にわかによく名前を聞くようになったFlutter。
業務でも使用される例もちらほらと聞こえるようになり、普及してきた様子が伺えます。

しかし、テストは書かれているでしょうか?
また、Flutterアプリケーションに対するテストの知見は一般化されているでしょうか?

私のセッションの内容だけで自動テストを書き始められるようになっていただくのを目標にお話をしたいと思います。



また、DiverseではDroidKaigi 2019へのスポンサー参加を計画しています。

↓ちなみに前回のDroidKaigi 2018では同人誌を頒布して、すぐに当日頒布分がなくなってしまうほどの人気をいただきました!


今回もスポンサー参加の暁にはスポンサーブースで面白いことをできるように画策しておりますので、ぜひ記憶にとどめておいていただければと思います。

DroiKaigi登壇者がたくさん所属する環境で開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

書籍『Androidテスト全書』を弊社社員が執筆しました

『Androidテスト全書』のJUnit 5の章(7章)を執筆しました id:kikuchy です。
クラウドファンディング出資者への発送が一段落し、『Androidテスト全書』の一般販売がはじまりました。

peaks.cc


白山さん外山さんと平田さんがすでに概要やそれぞれのエピソードを語ってくださっております。

ここではkikuchyの視点から、本の概要、kikuchyの担当章の解説と裏話をお伝えします。お付き合いください。


本書の概要

  • 第1章 テスト入門
  • 第2章 ユニットテスト実践入門
  • 第3章 ユニットテスト応用編
  • 第4章 UIテスト (概要編)
  • 第5章 UIテスト (Espresso編)
  • 第6章 UIテスト(Appium編)
  • 第7章 JUnit 5
  • 第8章 CI/CD

この1冊で、現在のAndroid開発環境に自動テストを取り入れるためのノウハウすべてが揃います。
なぜなら、テストに必要な概念の説明から、ツールの基本的/応用的な使い方、最新動向、テストを育てて役立てる仕組みまで解説されているからです。

「自動テストいれたいよな〜〜」と考えながらもどうしたら良いのか詳細なイメージが付いていなかった、
ユニットテストはできたけれどUIテストに挑戦してみたい、
そんなあなたに特におすすめの一冊に仕上がっています。


7章 JUnit 5について

kikuchyは7章を担当しました。

Javaを使ったプロジェクトの自動テストには、すでにJUnit系最新のJUnit 5が使用されるようになっています。
が、Androidの界隈では未だにJUnit 4が主流です。

本章ではその理由と、AndroidプロジェクトでJUnit 5を使用できるようにするandroid-junit5 Gradle Pluginを紹介しています。
さらに、JUnit 5で導入された新機能、そして中でも使用頻度が高いであろうパラメタライズドテストについて、ライブラリの使用方法を(Andoridで動かす際の注意事項を含めて)詳しく解説しています。

特にandroid-junit5については日本語で詳細に解説した初めての文章になっていると自負しています。



裏話

ことの成行

発起人の白山さんからお誘いいただきまして執筆に参加させていただきました。

以前にAndroid Test Night #1にて『JUnit5とAndroidのテスト』という発表をしたときの資料をご覧になって、ご連絡くださったようでした。

どんなきっかけでお声掛けいただくか、わからないものですね。
なるべく外部発表などで露出の機会を増やしておくのが、エンジニアの成長戦略の一つとして有効なのだなと再確認した瞬間でもありました。

嬉しかったこと

執筆途中、JUnit 5の新機能の一つ @Tag アノテーションによるテストケースの実行制御が、android-junit5で期待したとおりに使用できないバグを見つけました。
issueを立てて報告したところ、リポジトリオーナーのmannodermausさんがすぐに修正(といってもほぼ新機能追加)をしてくださいました。

以前、Android Test Night #4では「報告した」というお話だけしたのですが、なんと直していただけた、という後日談です。

世界が良くなることに本以外の場所でも貢献できたというのが、個人的に嬉しいエピソードの一つでした。

ありがたいこと

PEAKSのみなさまには誤字脱字修正などで大変お世話になりました。
私は誤字脱字が多く、特に英語のスペリングを間違うことが多いので、あの原稿の中から探し出してくださって本当に感謝しています。

ひつじさん(日高さん)には編集の際に特にお世話になりました。
技術書向きな書き方になおしていただくのを始め、話の順序の入れ替えや、コラムレベルをどうするかなどご相談に乗っていただきました。ありがとうございます。

共著者の白山さん、外山さん、平田さん、堀江さんには相互レビューを始め、途中で励ましていただいたり、様々な部分でお世話になりました。ありがとうございます!



なお、この本の7章は弊社の業務の一部として執筆されました。
平たく言いますと、業務時間を使って執筆をしております。

こうしたことが許可される会社に興味がある方は、@kikuchyならびに弊社Diverse(ダイバース)社員へDMやメンションなどでお声掛けください!

『マッチングサービスの裏側Night』を開催しました

id:kikuchy です。気の利いた時候の挨拶が思いつきませんでした。

去る9/28に、記念すべき初めてのDiverse主催の勉強会を開催しました!
その名も『マッチングサービス開発の裏側Night』!! 🎉 🙌🎊㊗

diverse.connpass.com


マッチングサービス業界のみなさま、他の会社が何を考えてプロダクト作ったり運営したりしているか知りたくないですか?

マッチングサービス業界外のみなさま、こうしたサービス運営の裏側ってどうなっているのか知りたくないですか?

そんな要望をマッチングさせ、マッチングサービス開発の裏側を知ることができる勉強会を開催することとなりました。


始めは25人定員として募集を開始したものの、予想以上の参加者の伸び率だったために、急遽増枠を行いました。
最終的に(直前のキャンセルを除けば)枠はいっぱいになり、実にたくさんの方に起こしいただくことができました。

参加してくださった皆様、ありがとうございます!!


以前からお声掛けさせていただいていたマッチングエージェントさんからも、エンジニアさんお二人にご登壇いただくことができました。

内容は以下のように非常に多岐にわたっています。

  • サービスレベル目標
  • 残されたレガシーシステムの扱い
  • 組織拡充
  • iOSアプリ開発
  • キャリア観
  • Firebase
  • ストアレビュー
  • 業界用語

たくさんの方に楽しんでいただけた一方で、テーマを絞って話を聞きたいというお声も頂戴しました。



id:SAMUKEI は「老舗マッチングサービスとの付き合い方」というレガシー環境との付き合い方についてお話しました。

speakerdeck.com

運営実績の長いサービスの抱えている様々な課題をどのように解決していくか?といった観点の話となります。
その中でも解決に向かいつつある「オーパーツ化したツール」にフォーカスしたやっていき💪を話しました。
他の課題も解決した際にはまた話したいと思います。


@imaizume は「チュートリアル実装の『そこどうしてる?』 Poiboyではこうしてる!」というタイトルで、Poiboy iOSのチュートリアル実装に関するお話をさせていただきました。

speakerdeck.com

チュートリアルの実装における画面定義の分割や、コーチマークの実装で悩んだことのある方もいらっしゃるのではないでしょうか。
今回の発表では、Poiboyでのチュートリアル実装における見解を、コード例と共に述べさせていただきました。
またチュートリアルのデバッグで、現在Poiboyが行っている取り組みについてもご紹介させていただきました。
Poiboyに限らず、各サービスにはそれぞれ最適なチュートリアルがあると思いますので、皆様のアプリにおける実装でもご参考になれば幸いです。




@bomneko_attack は「旅のおわりとはじまり」と題してDiverseに所属し、YYCの開発に携わっている経緯についてお話しました。
所属することになったきっかけはスマホアプリ開発未経験でも開発したくて異動を受け入れてくれるところを探した結果であってマッチング業界に対する興味ではなかったですが、それでも元気にやってます、という内容です。(スライドは一身上の都合により非公開にさせていただきます、)

10年以上運営しているサービスであるため歴史の積み重ねから来る技術的負債がたくさんあり、それを返済しないとサービスの健全な成長を阻害してしまうのでこれから解決していきたいというやっていき💪宣言をしました。マッチング業界にダイレクトな興味がなくてもたくさんのユーザ様にご利用いただいてるサービスに携わってみたい、技術的なチャレンジがしたいなど別の観点の興味から入ってみるのも良いのではないでしょうか!



@giiiita は 「アプリ向けにPopupを爆速実装」というテーマでFirebaseの機能の中の一つ"In-App Messaging"についてお話しました。
スライドに関しましては実演が含まれている内容だったため非公開にさせていただきます。

PoiチームではFireStoreやCloudFunctionsなどすでにいくつかのFirebase機能を使用しているのですが、個人的に注目していた機能についてどういった機能で何が出来るのかについて説明させていただきました。

デザイン面のカスタマイズに条件が付くのを懸念していたのですが、
最近の更新で柔軟にデザインがカスタマイズ出来るようになったのでよりアプリに組み込めるようになってきたのではと思っております。

今後もFirebaseの機能で何か共有出来るものがあれば発表したいと思います!


id:kmnmn は「アプリのレビューが0.1アップした話」をさせていただきました。マッチングアプリのセンシティブなアプリレビューにおいて、エンジニアがした施策とサポートの方に対応いただいた施策に関する話です。
スライドに関しましては口頭ベースで伝えるような簡素なものなので非公開にさせていただきました。
アプリのサービスを行うに伴いどのようにレビューを上げていくかは、様々な企業や個人の方も悩まれているのではないかと思います。
レビュー施策で新しい発見や失敗をした際にはまた共有できたらなと思います。


id:kikuchy は業界用語についてお話しました。

docs.google.com

技術に関係のないテーマではありますが、チームメンバーとコミュニケーションをとって開発を行う上で用語は重要です。
今回はいくつかの用語について、独断と偏見を交えながら解説を行いました。
ご笑納いただけましたら幸いです。

またいつか機会があれば、紹介しきれなかった用語も解説したいと思います。
(特に聞きたいものがあれば@kikuchyに言ってください!)


さて、記念すべき第1回を終えたマッチングサービス開発の裏側Nightですが、早速Diverseの手を離れ、マッチングサービスのエンジニアコミュニティに引き継がれました。

待望の第2回は、11月の中旬〜末に、サイバーエージェントさんで開催されます!
テーマは「クライアントアプリ開発」です。

実はクライアントアプリをテーマにした、マッチングサービスエンジニアによる勉強会のアイデアは弊社以外のところからもあがっており、それを受けて合流することと相成りました。

きっと次回は今回以上の濃ゆい話が聞けるのではないか…という予感があります。
お楽しみに!


これからも、Diverseでは業界の魅力や知見を広めるための活動をしてゆきます。
少しでも興味が湧いた、という方は公式アカウントをフォローしてください!