こんにちは!futaboooです。

弊社も原則在宅ワークになったことで、会社から仕事のパフォーマンスを下げないための在宅勤務手当(上限3万円)が支給されることになりました。

今回はメンバーのみなさんがどんなものを手当で購入し、自宅の仕事環境をアップデートしたのかBefore・Afterで紹介したいと思います。

futabooo Pairsエンゲージ Androidエンジニア

1人目はfutaboooこと私です。

Before

futabooo before
futabooo before

もともと家である程度作業が可能な環境を用意していたので外部ディスプレイや昇降式デスクなどがあります。

After


こんにちは、@futaboooです。

今回は5月のGW直前あたりから約3ヶ月ほどの開発期間を経て8月末にリリースしたPairsエンゲージAndroid版についてリリースまでの話とこれからやりたいことについてご紹介します。

Pairsエンゲージとは

「Pairsエンゲージ」は、累計会員数1000万!利用率NO.1のマッチングサービス、「ペアーズ」がつくった「結婚コンシェルジュアプリ」です!

◆ 結婚コンシェルジュアプリとは?
1年以内に結婚したい人のための、まったく新しい手軽な婚活体験を提供するアプリです。

マッチングサービスの手頃な価格、たくさんの人に出会える、手軽に使えるといった部分と、結婚相談所の真剣な人だけ、プロセスが確立している、サポートがあるといった部分をかけ合わせたサービスがPairsエンゲージです。

Image for post
Image for post

新規Androidアプリ開発時の技術選定について

ひとことで書くと自分が使いたい技術を選びました。

言語

100%Kotlinです。

設計

全体の設計はLayered architecture(like Clean Architecture) + MVVM + Fluxになっています。Android JetpackのData Binding,LiveData,ViewModelを使い、Fluxの単一方向データフローを用いてユーザーのアクション結果をViewModelに反映するような実装をしています。実装するクラスは増えてしまいますが、実装する上で何をどこに書けばいいのかわかりやすくしたいと考えていました。

主要ライブラリー

設計のところでも少し触れていますがAndroid Jetpackをメインで使っています。他に使っている主要なものは下記です。

  • Lifecycles
  • Navigation
  • Room
  • CameraX
  • Dagger2
  • Moshi
  • Kotshi
  • groupie
  • Glide
  • Hyperion

CI/CD

BitriseとFastlaneを使ってテストアプリ配信 やリリース作業を行っています。どちらも社内で知見があり、かつPairsエンゲージチームにはiOS開発メインのメンバーの方が多いためAndroidへのコンバートもしやすいようにFastlaneの導入を決めました。

また社内のテストに関してはFabric BetaとInternal App Sharingを積極的に使いテストを行っています。すみ分けとしてはAndroid App Bundleでの動作を見たいときにInternal App Sharingを使い、それ以外ではFabric Betaを使っています。

開発プロセス

タスク管理にはJiraとGitHub Projects、ドキュメントはConfluenceを使っていました。JiraとGitHub Projectsの並行運用になっていたのはJiraの閲覧権限が無いメンバーが居たためです。

GitHub Projectsの運用を初めてやりましたが、Organizationをまたいで作れたりIssueが作られたときに自動でProjectsへ追加することやIssueをcloseしたときに自動でステージの変更をすることなどもできるのでなかなか使えました。

プロダクト全体の流れとしてはやることと優先順位をPOとチームで決定した後はカンバンでの状況確認を毎日やるという形を取っていました。

これからやりたいこと

Redux化

Pairsエンゲージでは自分と相手の状態によって複数の状態を持つことが多くあります。現状はFluxのStoreの中にApplicationScopeでSingletonとなるようなものを作ることで擬似的にsingle source of truthっぽいことを実現している状況です。また複雑な状態の変化に対してテストを十分に書けている状況でもないので、テストを書きやすいコードベースにするためにもRedux化を検討しています。

kotlin-dsl導入

型の恩恵、AndroidStudioのコード補完の恩恵を受けるようにしたいです。

各種自動化

JiraとGitHub Projectの同期はZapierを導入して自動化しようとしています。他にもAndroidJetpackの最新バージョンを確認するようなSchedule BuildをBitriseでやりたいと思います。

おわりに

怒涛の3ヶ月間でリリースまで来ましたが、サービスとしてはこれからが本番ということでもあります。よい体験をユーザーさんにも開発者にも届けられるように引き続きやっていきたいと思います。


Image for post
Image for post

こんにちはエウレカのカイゼンマスター@futaboooです。先日会社の組織戦略の理解を深めるOSTを実施したので、その時の様子をご紹介します。

OSTとは


こんにちは、エウレカで開発プロセスのカイゼンとかやってる@futaboooです。今回はRSGT2019に参加してきた感想をお伝えします。

RSGTとは?

Regional Scrum Gathering® Tokyoは、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。

今年の基調講演ではHunter者のクリスさんの公演もありました。

モブプログラミングの動画を見たことある人も多いのではないでしょうか。

印象に残ったセッション

参加する中で印象に残ったセッションをリアルタイムで聞きながら書いたTweetと共にいくつか紹介します。

1.ちゃんとやってるのになんかうまくいかないスクラムからの脱出

bufferingsさんの発表。スライド2ページ目にありますが、自然とそうなっているというのを強調されていたし、発表内容もそう感じる内容でうんうんとうなづきながら聞いていました。スクラムのプラクティスを自分の言葉で言い換えて表現されてるところが本当にすばらしいなー、真似したいなーと感じました。


Image for post
Image for post

この記事はeureka Advent Calendar 2018 24日目の記事です。

メリークリスマス!!エウレカの自称カイゼンマスター@futaboooです。今日は12/24のクリスマスイブですね。みなさんはいかがお過ごしでしょうか。私は家で1人ケンタッキーのクリスマス向けセットを注文するかどうかずっと悩んでいます。

さて、今回の記事では普段業務のルーチンワークとして行っている事業部のリアルカンバンの状況を写真に撮ってSlackに投稿するという作業を自動化した話をします。

なぜリアルカンバンの状況を写真に撮ってSlackに投稿する作業が必要だったのか

エウレカでは今年の4月からPairs日本版の着手中なプロダクトバックログアイテムの管理にリアルカンバンを使うようになっています。リアルカンバンについてはこれまでの記事も参考にしてください。

リアルカンバンを使った管理に変えた後、自 …


認定スクラムマスター(CSM)になりました

こんにちは!自称エウレカのカイゼンマスター@futaboooです。今回は認定スクラムマスター研修について紹介するとともに、研修を通して私が感じたことなどを紹介したいと思います。

認定スクラムマスターについて

認定スクラムマスター(CSM: Certified ScrumMaster)とは2日間の研修を受けて筆記試験に合格すると取得できる資格です。

認定スクラムマスター研修

2日間の研修で、座学やワークショップを行います。座学ではスクラムとは何か?スクラムはどうして生まれたのか?どのようにして進化してきたのか?など源流や歴史について学びます。またワークショップではプロダクトバックログづくりや実際にスプリントを回してみるワークがあります。中でも私が一番面白かったのは円になって名前のあいうえお順にボールを渡していくワークで、自分たちでどうしたらもっと早くできるか?を考えて実行することが楽しくてしょうがなかったです。

私が受けたのはJames Coplienさんのものでした。他の講師の方の研修を受けたわけではないので比較はできませんが、とても情熱的で刺激的な体験ができました。いくつかアジャイルやスクラムについて質問をさせてもらいましたが、どうしてその質問をしたのか?というWhyを何度も聞かれました。

筆記テストについてはアジャイルマニフェストやスクラムガイドを理解していれば問題なく突破できる難易度だと感じました。

認定スクラムマスター研修を受けた感想

参加することに意味がある

スクラムやアジャイルについて知識を得るだけであれば本やWebの情報で十分だと思います。それでもこの研修を受ける価値としては、スクラムやアジャイルに興味がある、すでに自社のチームでスクラムをやってるなどで、なにかしら共通の問題意識や課題感を抱えた人が集まって2日間の研修を一緒に受けることにあると思いました。座学に対する質問の量や、ワークショップでの熱量などその場でにいることで感じられるものがたくさんありました。中でも休み時間にチームの人としていたお互いの状況などの雑談が一番学びが多かったようにも感じます。

問題は現場で起きている

参加者からの質問ではスクラムのプラクティスについて、こういう時はどうするか?という内容が多かったように感じます。例えば私からは「1つのプロダクトで複数のスクラムチームを作ることをどう思うか?コミュニケーションが増えるだけで無駄ではないか?」という感じのことを聞きました。講師の方はスクラムをスケールさせるパターンについて教えてくれましたが、どのパターンも共通して言っていることで「スクラムをスケールさせるな」と必ず最初に釘をさしたうえで、それでもやるならどうするかというようになっていると教えてくれました。

とはいえ機能や改善をたくさんリリースして売上を上げていきたいじゃないか!みたいなことを言ったら、「ユーザーは一度にそんなにたくさんの機能や改善を受け取れるのか?」と返されました。この視点は今まで私にはありませんでした。ハッとしました。

ひとつめの感想と矛盾してますが問題は現場で起きているのです。原理原則に乗っ取る事が大事であることは理解しつつも、現場のことを考えてどのように適用していくかが大事だと感じます。

カイゼンを超えたカイカクをやっていく

スクラムではスプリントの終わりに振り返り会をすることでプロセスの見直しを行います。振り返りの積み重ねによってチームはより無駄の少ないプロセスを学習していくことができます。この活動はいうなれば連続的成長です、日々の積み重ねで昨日の自分たちより少し強くなる。

しかし連続的な成長だけでは頭打ちになる、伸び悩む場面が来ることもあります。その時に必要なのがカイカクです。例えば組織が職能別のチームの場合にもっと売上やサービスへの意識を持ってほしいといった場合、情報の公開や共有で解決を図ることはカイゼンですが、そもそも職能別のチームをやめて職能横断型チームにするなどがカイカクにあたります。

スクラムマスターとしてはカイゼンはもちろんですが、カイカクが必要なタイミングでしっかり組織をサポートできることが望ましいと感じました。

プロダクト開発においてはチームだけあればいい

過激な言い方ですが、職能横断型チームさえあればプロダクト開発には十分ではないか?感じました。「スクラムはスケールさせるな」というところともつながってきますが、1つのプロダクト・サービスに複数のチームが関わることでチーム間の調整が発生します。調整は無駄です。調整を効率的にやる方法を考える前にどうしたら調整が必要なくなるか考えるほうがプロダクト開発においては筋が良いように感じます。雑に言うと会社すら邪魔なんじゃないかと思います。

現実から目をそむけずに戦う準備

研修の冒頭で「赤いピルと青いピルのどちらがほしいか?」とたずねられました。映画マトリックスでモーフィアスがネオに問いかけるシーンからの引用です。僕は赤いピルを選択しました。これまでの仮想世界での居心地がいい生活を捨て、現実から目をそむけずに戦う覚悟を決めました。このブログを読んでるあなたは赤いピルと青いピルのどちらがほしいですか?戦う覚悟はありますか?

さいごに

2日間の研修を経てたくさんのインプットがあり、多くのことを考えました。チームについて、プロダクト開発について、組織について、報酬について、etc…。ここで紹介した感想もごく一部のものです、また自分の見えてる範囲での感想となるので実際にはもっと多くの見方があると思います。ぜひぜひフィードバックをいただきたいです。記事へのコメントでもTwitterへでもなんでも大丈夫です!

そういえば私と同じ11/18,19にJames Coplienさんの研修を受けた方向けのSlackチームを作成しました。引き続き色々な議論や共有などできれば嬉しいです! https://csm-coplien.slack.com/


こんにちは。今日は普段自分が関わっていないチームの振り返り会を観察していた時に、Tryを出す時にこんなことを意識しておくとTryからの学びを増やすことができそうだなと感じた点について3つ紹介したいと思います。みなさんの振り返りの気づきになれば幸いです。

①どんな課題を解決するTryなのかチームの認識が一致していること

いきなり、「当たり前だろ!」とツッコミを受けそうな内容ですが、大事なことだと感じたので書いています。

それまでペアプロをやってWIP数2でやっていたチームのTryにWIP3にしようというものが上がっていました(WIPとはWork In Progressの略で同時進行するタスクの数を表しています)。チームの人数的にWIP3になるとペアプロが成立しない場合が出てきます。外から見ていた自分にはペアプロをやっている時に享受できていたナレッジシェアのメリットが無くなると思うけど、それでもこのTryを実行することについてチームの認識が合ってるのかな??と感じました。

振り返り会の後にチームに質問してみたところ、チームメンバーの認識は統一されていたので素晴らしいチームだ!とホッとしました。

どんな課題を解決するTryなのか?そのTryが生み出すデメリットはなんなのか?の認識をあわせておかないと、次回の振り返り会で予測できたデメリットを言って終わりになってしまうこともあると思います。

②チームの誰もがそのTryを推進することに合意できていること

声が大きい人が言ったTryが採用されてしまうという場面もあると思います。しかしチームで合意したTryにしておかないと結局実行されずに終わってしまうことになりかねません。

そんなときには掲げたTryに対して5フィンガーをしてみると良いと思います。5が自分が積極的にそのTryを推進してもいい1がこのTryになったら自分は声を荒げるぞ!みたいな感じです。

③Tryの手段として越境することも視野に入れておくこと

チームで振り返り会をしていると自分たちだけでなんとかする方法を考えてしまいがちです。しかしチームの外に専門家がいるかもしれないですし、すでに知見を持った誰かに聞くだけでうまくできるようになる可能性もあります。

チームに限らず事業や会社は規模が大きくなるだけで味方に違いはありません。助けてくれー!力を貸してくれー!と言ってみてもいいんじゃないでしょうか。

おわりに

いかがでしたでしょうか?簡単にですが振り返り会のTryからの学びを増やすために意識しておくと良さそうなことを紹介しました。今後もなにか気づいたことがあれば書いていきたいと思います!

最後に宣伝になりますが、年明けのRSGT2019で登壇することが決まりました。開発プロセスに興味あるかたはぜひご参加ください。


Image for post
Image for post

技術書典とは?

新しい技術に出会えるお祭りです。
技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。
技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、技術に関わる人のための場として『技術書典』を開催します。

技術書典5にサークル名「エウレ・テクノロギア」として参加します。場所はう-01です。


現在Pairs Japan Androidチームで行っているモブプログラミングについて、先日弊社で開催したイベントで発表しました。

概要

発表内容を簡単にまとめると下記のようになります。

  • モブプログラミングとは
  • なぜモブプログラミングという開発スタイルを選択したのか
  • Pairs Japan Androidチームでのモブプログラミングについて

特に、3つ目にお話したPairs Japan Androidチームでのモブプログラミングについての部分では、実際に2ヶ月ほどチームでモブプログラミングをやってきた中で徐々にできていったチームの開発スタイルについてやモブプログラミングをやる前とやった後の生産性の比較などについて触れています。

少しでも興味をもっていただけたら、ぜひモブプログラミングをやってみてほしいと思っています!

また発表時の動画が後日crash.academyさんで公開される予定でもありますので、資料だけではわからない部分も見ていただけると思います。


Image for post
Image for post

こんにちは!エウレカでAndroid開発やらちょっとしたプロセス改善やらをやっている@futabooo(ふたぶー)です。

以前弊社の梶原がPairs事業部全体での「カンバン」を作った話を紹介してくれました。今日はその「カンバン」を作成から2週間で作り直した話をしようと思います。カイゼンです。

Pairs事業部全体での「カンバン」をつくるにいたった経緯や考えについての詳細は記事をご覧ください。(先にこちらを読んでいただいたほうがこの記事の内容もスムーズに読んでいただけるように思います!)

プロセス改善委員会

4月からの組織変更のタイミングで事業部横断のプロセスを見直すプロセス改善委員会が各チームの中から1人以上参加する形で作られました。「カンバン」をVol.1から2週間で作り直すにいたったのも、このプロセス改善委員会によるものです。

プロセス改善委員会は週1で開発プロセス全体の改善について話し合いをしています。各チームの視点からもっとうまくやれそうなことやうまくやれずに困っていることを共有し、次のアクションを一緒に考え実行するということをやっています。

「カンバン」Vol.1での課題感

「カンバン」Vol.1では各ステージ(縦の分割、検証・開発・QA・効果測定など)内での優先順位がつけられており、ひとつのストーリーに関係する付箋が横一列に並ぶとは限りませんでした。

各チームごとでみた時はステージ内での優先順位がわかっていればそれでよかったのですが、俯瞰して見てみると優先順位が高いストーリーがちゃんと進んでいるのか?に対してすぐに答えることが出来ない状態だと感じていました。

各チーム内ではJIRAやTrelloによるタスク管理を行っていたので、事業部全体「カンバン」ではもっとマクロに状況を把握できるような作りに変えたいと考えました。

「カンバン」Vol.2を作る

「カンバン」Vol.2の草案を考えたホワイトボードです。

futabooo

Software Engineer at 10X,Inc.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store