【クレド深掘り対談 最終回】「変わらずに変わり続けることを覚悟していく」ために。ユアマイスターが行うふりかえりと改善に向けた取り組みとは

こんにちは！ユアマイスター広報インターンの村上です。

ついに「エンジニアチームクレド深掘り対談」も最終回となりました。

「エンジニアチームクレド深掘り対談」は、毎回エンジニアチームのメンバーを1人お呼びし、プロダクト部長、星さんと私村上の3人で全4回に渡って各回ごとにテーマとなるクレドについての対談を行う連載ですが….今回は特別にメンバー3人＋星さんにお話を伺います！

エンジニアチームクレドとは何か？

対談の前に、ユアマイスターのエンジニアチームクレドとは何かをご紹介していきたいと思います。

エンジニアチームクレドを簡単に説明すると、「ユアマイスターエンジニアが大切にしている価値観」のことです。
(クレド[Credo]とは、チームメンバーが心がける心情や行動指針のことを指します。)

ユアマイスターのエンジニアチームクレドは以下の4つ。

・LISTEN--顧客と仲間からの聞く耳を持つ
・FOCUS--目的から 目を逸らさない
・CHANGE--変化を適応し変化を作り出す
・HACK--構造化+最適化+効率化

これらのクレドは、2020年4月に行われたオンライン開発合宿で設定されました。

オンライン合宿の詳しい内容については、こちらをご覧ください！

今回のクレド「CHANGE」

前回注目したクレドは「FOCUS」。

そして今回注目するクレドは「CHANGE」！

「CHANGE」は、変革を起こしていく改善のためのクレド。改善を行うにはふりかえりを行い、問題点を洗い出すことも大切です。

詳しい説明はこちら↓

> man change

NAME
    change - 変化に適応し変化を作り出す
    
SYNOPSIS
    change [-a|--agile] [-l|--learning]
    
DESCRIPTION
    変化が大きく、不確実なことが多い中でのプロダクト開発。なかなか思うようにいか
    ないこともあります。ユアマイスターエンジニアは、あらゆる活動の中で振り返りを
    行い、改善に向けてネクストアクションを起こします。
    
OPTIONS
    -a, --agile
        「アジャイルソフトウェア開発宣言」を根底に、成果物を短い期間のサイクルで
        リリースします。作りたいものを作るのではなく、必要とされるものを作るため
        に「忘我忠客」を実現します。
    -i, --improve
        初速の速さ、俊敏性を作り出すものは、変化に気づける感覚と素早い意思決定で
        す。計測できるものを増やし、課題の見える化を行い、頻度高く見直しを繰り返
        していくことで、自分たちで最適なチームを作ります。

今回クレドを共に語るのは、プロダクト部長の星さんと2020年にユアマイスターに入社したエンジニア社員の南さん（web）、佐々木さん（web）、井島さん（アプリ）の3名。

ユアマイスターのエンジニアは、エンジニアクレド「CHANGE」についてどんな思いを抱いているのでしょうか。

「CHANGE」につながるユアマイスターのふりかえり

-- 今回は、エンジニアチームクレド「CHANGE」について星さん、南さん、佐々木さん、井島さんにお話を聞きたいと思います。よろしくお願いします！

星さん、南さん、佐々木さん、井島さん（以下敬称略）：よろしくおねがいします！

--まずは最近CHANGEを意識したお仕事の具体例を教えて下さい

佐々木：チーム全体で言うと最近は新しいエンジニアが増えたので、今まで集約されていなかった情報などを積極的にドキュメント化しています。

-- なるほど、ドキュメント化しようという変化が生まれたきっかけはふりかえりによるものだとおもうのですが、ユアマイスターではどのようなふりかえりをしていますか？

井島：毎週金曜日に、新しい社員のオンボーディングについてのふりかえりをしてます。

南：そうですね、最近だと主にはオンボーディングです。

その後はアサイン会議があるので、ふりかえりで出たドキュメントにした方が良いものをタスク化して、タスクの優先順位を決めて特に高かったものをアサインしていく感じです。

佐々木：ふりかえりの際は少人数のほうが意見がまとまりやすいのでブレイクアウトルーム使って2つのグループに分かれます。

その時期によって話し合うべきことが頻繁に変わってきているのですが、状況に沿ったテーマでディスカッションしています。週次のふりかえりではこれまでに、クレドに沿ったふりかえりや、Fun Done Learnなども行ってきています。

また金曜日以外のふりかえりでは、全体ではなく毎日4人でデイリーのものをやっています。

毎日朝と夕方に15分ずつzoomをつなげて、朝は「今日はここまで終わらせる」という目標宣言、夕方は「達成できたか、できなかった場合はどうやったらできたか」というふりかえりを行います。

夕方はそれに加えて「FEEDBACK is Gift」という独自の取り組みもやっていて、個々人のリリースや行動に対して「こうしたほうがよかった」とか「これ良かった」などという話し合いを行っています。

自分が悪かったことに対するふりかえりを行うと、それをもとにどんどん改善を行うことができるので良い取り組みだと思います。

井島：アプリでも月1くらいでふりかえり会をやっています。
リリースの結果というより開発のボトルネックやそれをどう改善していったらいいかを話し合っていて、ふりかえりを行った結果問題点が洗い出され、改善をすることができました。

課題と時間の見える化のための取り組み

-- ふりかえり以外に、課題の見える化のためにやっていることはありますか？

井島：アプリでは利用率を月1くらいで見ています。
アプリ内での使われ方を見る機能も今開発している最中ですね。

佐々木：プロダクトに対してでは無いのですが、チームとしての課題の見える化はmiro(オンラインホワイトボードツール)でやっています。

「ペアプロしにくい」「オンラインだと伝えにくい」「ディレクターとの要件定義が甘い」など、何か自分が課題に感じていることに気づいたときに付箋に書いて貼るようにしています。

それを気づいたメンバーが「こうしたほうがいい」とアドバイスをくれるので、それを改善に繋げます。

南：そうですね。あとは毎週アサイン会議の前に、その週で自分のもっているタスクでかかった時間の数字を出して「MTGが多い」「プロダクト開発が多い」などの時間の見える化をやっています。

【毎週金曜日に書く次の週の余力フォーマット例】

【5営業日想定】

プロダクト開発 (20~25h)
- 案件名 20h

プロフィット開発(10~12.5h)
- チケット名 10h

Hack or Learn開発 (6~7.5h)
- チケット名 4h
- お問い合わせ・障害対応 3h(max 3h)

MTG等(4~5h)
- 朝会 1.4h
- プロダクト部関連MTG 2h
- 社員MTG 1h

余力
- 

その他(0h)

--------------------
合計 40~50h

半年前くらいに「持ち越しが多かった=タスクの量が多すぎる」などの課題感を感じ、「持っている余力って実際どれくらいだろう」と考えたことがきっかけです。

余力時間とタスクの優先順位を照らし合わせ、トレードしてからアサインをするように心がけることで、大幅な時間の想定のズレを無くし、確実に1週間でリリースできるチケットが増えました。

ユアマイスターに入社してからの3つの「CHANGE」

-- みなさん2020年にユアマイスターにご入社されたと思うのですが、ユアマイスターに入ってからのあなたの「CHANGE」は何ですか？

井島：技術的に大きなことは開発言語とフレームワークが変わったところですね。

チームとしても前職ではアプリチームが4,5人だったのですが、今は1人（外部委託を入れて2人）なのは大きなCHANGEだと思います。

また、前職でサービスのふりかえりは1ヶ月に1回やっていたのですが、個人の行動を振り返ることはあまりやっていなかったですね。その点ユアマイスターでは個人の行動を振り返る機会が多く、自分自身に対して改善できるところが見つけやすいです。

南：僕は変わったところで言うと大きく3つあります。

まず1つ目は、自分が行っている開発を最小で出すにはどうすればいいかを考えるようになったことです。

これまでは量が多かったとしても1つタスクを1つのチケットですべて実装し、リリースしていたのですが、最近は1つのチケットですべてリリースしてしまうと確認が多くなってしまうため、ふりかえりをした結果細かく出すようにしています。分割してチェックの負担減らすことで、リリースのスピードが上がりました。

2つ目は、ディレクターやチケットに関わりのある人により声をかけるようになったこと。

自分の理解とチケットの起案者が考えていることに差異があることはよくあると思います。なのでなるべくそのようなズレがなくなるようにいろんな人に声をかけるようになりましたね。

実際やってみて、早めに声をかけると実際に開発したいものがどんな感じなのかがわかり、新しいアイデアが出てくることもあります。いろいろな人が同じ改修の要件を見ていくことで、チケットを見た時に新しいアイデアなどが出て相乗効果が得られることもあるのはいいですね。

デザインなどでも、実装しているときは周りが見えなくなってしまうことがあるので、リリース前に他の人と一緒に見ると多くのことに気づくことができます。

また、前職で働いていた受託の会社は納期優先でした。

そのため、テストコードを書くとその時の実装の工数が膨れてしまうということがあり、テストケースシートを作成してカバーしていました。

テストコードがあると問題があったときにすぐ気づけたり、別の人が後で同じ箇所のテストコードを書く時にどんなふうに書けばいいのかがわかりやすかったり…ユアマイスターの社内輪読会で「テスト駆動開発」を呼んだこともあり今後のプロダクトの成長を考えるとテストは大事だなということを思い、今はテストを書くようになりました。

あたりまえに「疑う」ことに対する衝撃

佐々木：今までは「システムをどうバグらせないか」「いかに早くリリースできるか」だけを考えていたのですが、ユアマイスターに入ってからは「GMS（流通額）にいかに貢献しているか」「使っている人がハッピーになれるか」「それは今リリースすべきなのか」ということを深く考えるようになり、より広い視点でプロダクトを見ることができるようになりました。

今まで上司やディレクターの言うことなどは全部正しいと思っていて、「この人が要件を考えたのだからこの要件には何かしら理由がある」と思い何も疑わずに実装をしていたのですが、ユアマイスターでは「本当に必要か？なぜそれがいいのか？その先に何が見えるのか？」を考えて、わからない場合はしっかり聞くようにしています。

ユアマイスターではこの姿勢があたりまえで、先輩社員の姿を見てこのあたりまえを学んだので、これまでの「出てきたものが合っている」という前提を崩され、いい意味で衝撃的な「CHANGE」でした。

「CHANGE」で最も大切なことは変わること自体ではない

-- 最後に「CHANGE」に関してプロダクト部長の星さんの想いはありますか？

星：「CHANGE」に関しては変わることが目的ではなくて、「変わった結果何が得られるか」ということを忘れないことが大事だと思っています。

前回の「FOCUS」にも近いですが、変わることが目的ではなく、変わることで得たい目的に近づけるように自分を戒めていますね。新しい技術や取り組みに関しては前向きにチャレンジしていきたいと思っていますが、それだけが価値ではないからです。

1度作ったものをメンテナンスして、10割のゴールがあったときに1~2割の状態ででリリースしてユーザーにフィードバックしてもらいますが、残りの8割を作り切ることが部分リリース、段階リリースするときに最も大事なことで、1割2割のところで満足して終わってはいけません。

目的を大事にし、勇気を持って変わり続けることが大事です。

4周年で取締役が言っていた「変わらずに変わり続けることを覚悟していく(keep changing)」という言葉が好きなのですが、まさにそうでスタートアップだからこそ変わり続けることを忘れてはいけないと思います。

-- 星さん、エンジニア社員の皆さんありがとうございました！

おわりに

ユアマイスターのエンジニアチームはふりかえりを通して前向きに様々な取り組みにチャレンジし、より良いものに変化していく生き物のようなチームでしたね。その変化を支えるものがエンジニアチームクレドの1つ「CHANGE」でした。

最後になりますが、これを読んでいる方が全4回に渡りお送りした対談でユアマイスターのエンジニアが大切にしている4つの指針の深堀りを通して、エンジニアチームの雰囲気やマインドを少しでも感じ取ることができれば嬉しいです！

これからもユアマイスターエンジニアチームはこの4つのクレドを大切にし、ハッピートライアングルの実現のためのプロダクト開発を進めていきます。