技術課題に挑むプログリットMobileチームと、それを支える『チャレンジできる文化』
こんにちは。Mobile Tech LeadのTakahiroです！私がジョインしてから3ヶ月が経ちましたが、短期間でプロダクトと組織の急速なスケールを実感しています。
今回は、その様な環境の中でエンジニアリングがどのように戦略的に取り組み、いかにしてお客様に満足と信頼をお届けしていくのかを書いていきます。
この記事で書かないこと
弊社プロダクト開発は、複数の職能がクロスして一体感を持って推進しています（PdM, Designer, Backend, Mobile, QA）。本記事では、内容をシンプルにするためにMobileエンジニア職能を中心にご紹介していきます。
前提：4プロダクト、7つのモバイルアプリ！
PROGRITでは、効果的に英語を習得するために目的に応じてプロダクトをローンチしています。現在では、以下の4プロダクトを提供しています。
基本的にはiOSとAndroidの両方のモバイルアプリを提供しています。
※ディアトークはiOSのみ提供
※スピフル（口頭英作文）もありますが、現在はWeb版のみ
合計7個のモバイルアプリのエンジニアリングに向き合う必要があります。大枠としては、以下の3つの論点に向き合おうと考えています。
お客様の満足と信頼に俊敏に対応する
開発スループットを高める
全員がリーダーシップを発揮する
それでは、１つ１つ記載していきます。
1. お客様の満足と信頼に俊敏に対応する
プロダクトの利用者数や機能が増え、求められる水準も更に高まっています。
使いやすいUI
目的を達成できる体験
バグなく安心して使える品質
これまでは月1回のサイクルでリリースをしてきましたが、その頻度ではスピード感に物足りなさを感じ始めています。
『今までより更に、密に、お客様の自己実現に寄り添いたい』
そのためにお客様からのフィードバックの機会を増やし、1回のリリースの質を高めるためにリリースサイクルを早めようと考えています。月に1回だった大きな車輪を、月に2回転する小さな車輪にするようなイメージです。
ここでの注意点は、『車輪を小さくし過ぎないこと』です。例えば、毎日UIが変更される様な粒度では逆に使い勝手が悪くなります。より本質的な価値とそれを実現する機能に絞り、磨き上げた上で回転数を上げたいという事です。これが『俊敏な対応』の目的です。
『より的確にお客様の課題を解決する。期待以上の体験の提供に挑戦する』
回転数が上がれば、お客様の課題の芯を捉える確率が高くなっていきます。また、万が一にでも手戻りした場合のお客様へのご迷惑も小さくできますので、より挑戦的な体験の提供が可能になります。そこに甘えるつもりはありませんが、この様にして満足を加速していく事ができます。
ISSUE: 開発バッチサイズを小さくするには？
現状を進化させるためにはToBe像とのギャップを把握する必要があります。弊社ではDevExをつかい定量／定性分析を実施しました。結果、まず解決すべきは『開発バッチサイズが大きい』というISSUEであることが見えてきました。詳細は弊社 Koki の記事をご紹介いたします！
リーン思考でいう『バッチサイズ』というボトルネックを解決するため、まずは有志で以下の取り組みを試験的に行なっています。
要件の振る舞いと操作シナリオを分解し、更に小さくブレークダウンする
直近１〜２週間のゴールを決め、それを達成する最小スコープで開発する
進捗は報告だけじゃなく、動作するプロダクトをチームで見て判断する
いわゆる『Scrum event』『Behavior Driven Development』といった辺りのエッセンスを取り入れた実践をしていきたいと考えています。
2. 開発スループットを高める
『俊敏に対応する』では実現できない『提供する価値の絶対量を増やす』という点についてです。ボトルネックは幾つかありますが、当社において、より良い状態を目指す意味の課題は以下です。
認知負荷低減と可読性の向上
開発絶対量の削減
課題解決の質とスピードアップ
技術課題の可視化
2-1. 認知負荷低減と可読性の向上
これは『明確な技術方針の定義』により既に実行しました。具体的にはArchitecture Decision Record (ADR)をこの3ヶ月で整備し、アーキテクチャのレイヤー毎の責務の定義と、そこに属するクラスの役割を言語化しました。これによりエンジニアが設計で悩んだり議論する時間が削減される効果が得られました。
以下のサイトのフォーマットを参考にさせて頂きましたのでご紹介いたします。
実際のアーキテクチャはどんな感じ？
記事の趣旨から外れてくるので詳細は割愛しますが、弊社は『Clean Architectureを基礎に、MVVMを採用』しています。ただし、MobileアプリにClean Architectureをそのまま適用すると実装が必要以上に複雑になる懸念があったため、以下の様なカスタムをしています。
Entities → Domain層に変更
DBのEntityとの誤解を招くためDomain層として定義。
ValueObject, Aggregate, Repository interfaceを配置する。
Application Business Rules → 利用クラスを限定
UseCase, Repositoryがあれば十分機能するため、それ以外は不要
Interface Adapter → MVVMに代替え
責務が細かく実装が大変。
『MVVM』にてやりたい事が実現できる。
結果としては『Domain層』『Application層』『UI層』『Infrastructure層』と4つのレイヤーにシンプルに着地しました。この様に抽象層としては方針が決まり、幾つかのプロダクトでは実際にソースコードに反映しました。今後は、プロダクト全体に適応していくフェーズとなります。
以下に、簡単にアーキテクチャのイメージをご紹介します。
2-2. 開発絶対量の削減
こちらも『プロダクト間のコード重複除去』として既に着手を始めています。以前、私が投稿させて頂いた記事や、弊社インターンのKaiが投稿した記事など、バックエンドも含めて全体のモジュール構造を分析し、無駄が大きい箇所から共通化を実施していきます。
余談ですが、本取り組みはADRにてアーキテクチャ方針が定義され、プロダクト同士で構造が共通化されたことにより、推進が可能になりました。
2-3. 課題解決の質とスピードアップ
こちらは『ペアワーク、モブワーク』としてエンジニア同士の集合知が機能する様に仕組んでいます。状況に合わせて様々な形でトライアルをしている最中です。
ADRの記載や、モジュール構造の分析は対面同期で行う
毎朝所定の時間にGatherに集い、プルリクのコードレビューを口頭で実施
頻度は各自で相談しつつ、ペアプログラミングを実施
直感としては『複数人での作業は、工数がもったい無いのでは？』と感じるかもしれません。しかし、実際はペアやモブで仕事をすることで『その場で不明点や課題を解決できる』『集合知により個人では発想できなかったアイデアが出る』『ナレッジの交換や継承により効果的に成長できる』など大きなメリットが生まれています！
2-4. 技術課題の可視化
プロダクト開発のエコシステムは複雑なので、どこかを変えると予期しない箇所に影響が出ます。つまりは自分たちの行動により、ボトルネックが日々移動しているという事です。
これを各位がバラバラに追いかけると部分最適に陥るかもしれないので、戦略的に取り組むため『Mobile Appの技術課題Backlog』を作成し、隔週MTGにてチームでリファインメント（見直し）をする様にしました。
新しい課題が出てきたら共有する
担当している課題の状況を説明する
課題の優先順位に変更がある場合はディスカッションする
例えば、前述の『ADRの作成』もバックログアイテムの1つとして存在していますし、その結果から『レイヤー構成をリファクタリングする』といった派生タスクが生まれたりしています。具体的なイメージが湧きやすいように一部をご紹介します。
また、『忙しくて対応できませんでした、、、』を避けるため、課題をなるべく小さく分解し、そして1つだけ担当する様にしました。少しずつでも良いので、着実に前に進んでいる事を実感するためです。また、大きく対応している間に状況が変化してしまう事も回避する事ができます。
これは『車輪を小さくする』にも通ずるところがありますね。
3. 全員がリーダーシップを発揮する
過去職にて学んだのですが『リーダーシップ＝曖昧で未確定な事を推し進める事』と解釈しています。何をするにしても、そこに正解はないしベネフィットやアウトカムを仮説思考で行動しないと『So what？』になってしまう。
『決められたタスクをやる』→『曖昧なコトに挑戦する！』
この様に全員が『受け身』から『攻め』に転じる事で、組織全体の課題解決力が高まっていきます。曖昧なコトは大小、山ほどありますので、全員が何かしらの不確実性に挑んでいる状態を作り出せたら良いなと考えています。
その状態は技術課題Backlogを分担する事でも作り出せていますが『MobileチームのToBe像に向かい、各位が目標設定をする』というアプローチもできるのではないかと考えました。
そういう訳で『チームをToBe像とは？』というテーマでMobileチームで座談会を実施しました。
Mobileチーム座談会の内容
目的
エンジニアが持てる力を全力で発揮できるToBe像を見出す
どんどん楽しく成長できるモチベーションやエンゲージメントを探る
やりかた
あえて自由な発想でブレーンストーミングをする
そうすることで、各位の個性が発揮され集合知が機能する
備考
事業成果やKPIは、プロダクトチームのスキームで追っているのでスコープ外とする
少しふわふわした内容ですが、あえて各位のWillを引き出す作戦でした。では、その結果がどうなったのかをご紹介します。
ブレーンストーミングの要約（GPT 4o）
技術に貪欲であり続ける: メンバー全員が技術的な好奇心を持ち、新しいことに挑戦し続けるチームを目指す。
オープンでレジリエントなチーム文化: 互いに意見を遠慮なく交換し、失敗を教訓として成長することを奨励する。
自律的な働き方の推進: 各メンバーが自分の時間をコントロールし、自律的に働ける環境を整備する。
小さなトライアルで素早く結果を出す: 迅速に試行し、早期に結果を評価して教訓を得るサイクルを確立する。
感想になってしまいますが、結構、いいビジョンが見えてくる内容だと思っています！具体は詰めていく必要がありますが、参加者からは『チームメンバー同士の相互理解、アラインメントの効果があるので、これからも定期的に開催したい！』という嬉しいフィードバックも頂けました。
おわりに：チャレンジを支える企業文化
長くなってしまいましたが、プログリットのMobileチームは上記に向かって進んでいきます。挑戦的な内容も多いですが、私は実現できると確信しています。弊社の特徴的なカルチャーとして『FIVE GRIT』があり、チームの皆様はとても成長意欲が高く、経験のない事でも『まずはやってみよう！』と行動できる人たちばかりです。
余談ですが、私は入社前にこのVALUEを見て『自分にできるだろうか』と正直不安を覚えました。入社してすぐにそれは杞憂だと分かり、非常に暖かく受け入れて頂けて感謝しています。また、メンバー同士も和気あいあいとしていて、常にリラックスしながら仕事に取り組む事ができています。（先日は、出社日のランチ中の雑談が面白過ぎて涙が出るほど笑ってしまいました）
これから先、難しい課題に全員で取り組む中で様々な教訓が生まれると考えています。随時、テックブログとして情報発信して参りますので、課題解決に悩む方々のご参考になれば幸いです。
プログリットの成長を加速させる仲間を募集しています！
プログリットでは、プロダクト開発のメンバーを募集しています！
私たちと一緒に『世界で自由に活躍できる人を増やす』ための新しいチャレンジをしてみませんか？ぜひカジュアル面談でお話しましょう！
この記事が気に入ったらサポートをしてみませんか？