複数プロジェクトを横断するテックリードの戦略とは／ゆめみ

株式会社ゆめみ　取締役　iOS/Andoidテックリード　渡部 陽太氏

受発注関係ではなく、パートナーとして共創関係にありたいと「BnB2C（B and B to C）」というビジネスモデルを掲げているゆめみ。これまで400社以上の開発案件に携わり、現在もモバイル系プロジェクトだけで20～30件が横断的に動いている。

テックリードの渡部氏は、これら複数のモバイルアプリ開発プロジェクトを横断して支援している。その支援における姿勢や考えを次のように語っている。

「すべてのプロジェクトで利用する技術を固定してしまうと、エンジニアが幅広い技術に触れる機会を奪ってしまう。提案の幅の広がりやチャレンジングな気持ち、個人・グループ共の成長を尊重するためにも、技術選定の自由は必要だと考えています」（渡部氏）

技術選定の自由度は保ちつつ、大きな問題を回避するための最低限の指針を定めるために、ゆめみの開発体制では、「標準」という考え方を取り入れている。

例えば、サードパーティのライブラリの選定は任せるが、導入や解決方法は標準化する。CPUアーキテクチャにおいては、Intel Mac（インテルマック）とAppleシリコンマック、どちらでも正しく動く方法を選ぼうといった具合だ。

一方で、標準を文章化すると解釈の差が生じる。サンプルコードで具体例を示してもメンテナンスされず陳腐化する。標準を変更したときの横展開でコストがかかるなど、メンテナンスが難しい。そこでGitHubのTemplate Repository（テンプレートリポジトリ）を活用して、標準技術を管理することにしたという。

まず、GitHubの設定画面で「Template Repository」にチェックを入れると、そのリポジトリがテンプレートリポジトリとなる。テンプレートリポジトリは従来のリポジトリと同じように、開発を進めることができる。

テンプレートリポジトリで保管されている内容は、主に以下となる。

• Script（コード証明書）
• サードパーティのライブラリ管理ツール（各種ツールのインストール、依存関係など）
• CI/CDワークフロー（キャッシュも含む）
• プルリクエストのテンプレート
• lint
• Danger

ゆめみでは、どのプロジェクトでも求められるCI/CDのワークフローはほぼ同じであるため、テンプレート内に入れて置くことでスムーズな管理を行っている。また、グローバル環境を汚染しない環境構築を意識していると、渡部氏は強調する。

「プルリクエストテンプレートも標準を用意しています。レビュー機会の多いテックリードから、こんなPR出してほしいなっていう気持ちを込めて作成しています。モバイルの場合は、画面キャプチャや動作中の動画を貼ってもらえるとレビューイはとても助かるので、シミュレータの画面を録画するコマンドを添えたりしているのもポイントです。」（渡部氏）

また、Dangerは一般的にRuby製を使うことが多いが、ゆめみではSwift製を採用している。一方で、内部ではJavaScript製に依存しているケースなどもあり、その対応でも苦労していると明かした。

こうして作成された標準テンプレートをベースにしながら、プロジェクトごとにリポジトリを派生させて開発を進めていく。 一方で、テンプレートリポジトリが更新された場合に、派生リポジトリは自動的に追従する術がなく、変更に強いとは言い難い。

そこで各プロジェクトの固有値を設定ファイルとして外出しするとともに、YAMLファイルで自動生成するScriptを作成。工夫の結果、テンプレートの変化に派生リポジトリが追従できる仕組みとなっている。

両者はコミット履歴に関連性がないので、マージできない。そこでrsyncを使いコマンド化することで、追従できる工夫も施している。渡部氏は成果を次のように話し、セッションをまとめた。

「実践の中で得られた知見がテンプレートリポジトリに集約されていっています。プロジェクトの効率化と知見共有の両面で役立っています。」（渡部氏）

プロダクト成長と共に変化に強くする方法／カケハシ

株式会社カケハシ　テックリード　横田 直彦氏

カケハシは「日本の医療体験を、しなやかに」とのミッションを掲げ、2016年に設立したヘルステックスタートアップだ。カケハシでは、薬局と患者を結ぶクラウド型電子薬歴サービス「Musubi（ムスビ）」など、医療サービスを開発している。

今回登壇した横田氏はバックエンドエンジニアを経て、Musubi InsightというBIツールの立ち上げに携わり、現在はテックリードを務めている。横田氏はカケハシにおけるテックリードの役割、仕事のやりがいを次のように語った。

「アーキテクチャの決定など、チームで扱う技術選定の責任を持つと同時に、メンバーの技術サポート、開発ロードマップの作成においてはPdMのサポートを行います。実際に薬局を訪れ、利用者の生の声を聞くことが、大きなやりがいになっています」（横田氏）

カケハシでは、リーン開発やスクラム開発を取り入れており、開発チーム内にドメインエキスパートとして薬剤師が加わっている。

開発体制はスクラムであり、変化に強いシステムにするために、カケハシではテックリードとPdMがコミュニケーションしながら、課題解決とプロダクト改善を目指していることも大きな特徴と言えるだろう。

PdMとのコミュニケーションの際に、特に着目しているのが以下の点である。

• 耐性をつける
• 暫定・恒久対応2つのフレームワークで考える
• 本質的な課題を特定する

横田氏がテックリードを務めるBIツール「Musubi Insight」は、Musubiで得たデータを活用し、薬局経営で重要な指標を可視化するツールである。

BIツールのデータはAPI Gatewayとlambdaで取得、夜間のバッチ処理で集計した上で別のDBに移動させている。アーキテクチャは以下の図となる。

横田氏は、薬局で働く人たちがどのような行動改善を行ったら業務が効率化し、業績がアップするのかに着目し、開発を進めていった。

「薬歴当日記載完了率」はまさに代表例で、薬剤師の薬歴記載が、数字で明確に表示されている。さらに横田氏は3つの事例から、課題の本質と暫定・恒久対応の事例を紹介した。

【事例①】業界ルール変更

新型コロナウイルス拡大の影響から、国は新型コロナウイルスに関する診療報酬を臨時的に追加した。そのため、同報酬に関する指標をシステムに加える必要があった。

暫定的な対応としては、集計スクリプトの算定コードにコロナ報酬の内容を追加。しかし薬剤師でもあるPdMに確認すると、今回は「臨時」ではあったが、算定ルールは2年に一度の頻度で更新されることがわかった。

そこで2年に一度の変更頻度に対応できるシステムに設計するという恒久対応に至った。具体的には算定コードの一覧をCSVで管理し、データデプロイで変更できる仕様とした。

【事例②】データ不具合

バッチ集計でバグが発生したので調べてみると、数値と文字が混在していることがわかった。暫定対応としては、バッチ集計前に数値型に変換・統一することとした。

一般的には、データ関連の問題はデータソース側で対応した方がよいが、別チーム管轄だったため恒久対応は断念した。

「データソースを担当するチームに相談すると、対応には時間が必要とのことでした。そこで暫定対応を続けると並行して、恒久対応に向けて集計ミスの情報を、ソース側にも共有するようにしました」（横田氏）

【事例③】レイテンシ問題

バックエンドでの集計時間が、以前の10秒から30秒と約3倍になるレイテンシが発生している問題は、ユーザー数ならびにデータ量増加が理由であった。

暫定対応としては、SQLのパフォーマンスチューニングを行った。すると一時的に改善するが、しばらくすると再びデータ量の増加で、同様の課題が生じる。今後も同様のケースが継続することも明白だった。

そこで、Athenaなどのクエリエンジンを採用し、UIを改善する2つの恒久改善案が浮かぶ。だが、前者は工数的に余裕がなく、改善するか不確実であったため、後者案を採用した。

「ここでも考えたのは本質的な課題です。レイテンシの発生により、ユーザーの操作も同様に止まってしまう。操作を止めることのない集計リクエストができるようなUI設計に変更しました」（横田氏）

3つの事例を踏まえ、横田氏は改めて本質的な課題に対し、暫定・恒久どちらで対応するべきかをまとめた。

例えば、解決案が出ても工数などの観点からすぐに実施できないケースは、PdMと情報共有することで、着手のバランスを取ることが重要だ。

さらに横田氏は、PdMとのコミュニケーションによって、暫定・恒久両方の解決策を考えるフレームワークは有効であること、判断が複雑で難しい場合は、ペイオフマトリクスなどを作成することも重要だと語る。

さらに横田氏は、以下のように補足してセッションをまとめた。

「ビジネス要件を優先させるため、技術負債を後回しにしてしまう傾向があります。実際、恒久対応案はバックログとして残り続けているケースが少なくありません。そのためスプリントやチームの半期目標の中に、恒久対応を組み込むことが有効です。また、バックログに調査タスクとして記載しておくのもよいでしょう」（横田氏）

既存Webサービスのアプリ版を1週間でリリースした舞台裏／Ubie

Ubie株式会社　ソフトウェアエンジニア　小谷 優空氏

カケハシと同じくヘルスケアテックスタートアップのUbieでは、エンドユーザー向けの症状検索エンジン「ユビー」などを展開する。

病気ではないかと不安な利用者は、家にいながら「喉が痛い」「熱がある」といった不調を、画面上の質問に応える形で進んでいくだけで、推測される病名や受診すべき診療科、近くで対応してくれる医療機関を案内する。

2020年5月に正式版が公開されて以降、利用者は増え続け、現在では月に利用するアクティブユーザー数は700万人以上にもなる。

フロントエンドはTypeScriptとNext.js、バックエンドはKotlinとSpring Boot、GraphQLやCapacitorなどの技術を採用している。

Ubieにはテックリードのポジションはないが、近しい役割を担う小谷氏は、リリース当時の開発背景を、「既存の技術はすべてWebに偏っており、ネイティブアプリをフルスクラッチで開発するコストは大きすぎた。」と振り返る。

モバイルアプリを開発してどれだけKPIに寄与するのか。「ビジネス的にも不確実であったことから、まずはできるだけコストをかけずにリリースしたかった」と、小谷氏。そこで採用したのがクロスプラットフォームアプリのフレームワーク、Capacitorだ。

Capacitorを使えば、Web開発技術でモバイルアプリを開発することができ、既存の実装を活用することができる。一方、ネイティブ実装のような滑らかな体験は提供できない。ただし、ユビーのサービス性質を考えると、リッチアニメーションのようなUIは必要ない。

加えて、最近モビリティ界隈でも注目されるOTA（over-the-air）アップデートによって、Web版と同じように高頻度でのデプロイも可能。

これらを踏まえて、Flutterなど他の選択肢と比較検討した結果、Capacitorを採用することとした。

開発に際してはブラウザ版・アプリ版とも、共通のコードベースで実装することとした。システムアーキテクチャならびにデータや処理の流れも紹介した。

「ブラウザ・アプリ版ともにNext.jsにアクセスします。コードベースは同じですが、ビルドを分けて異なるインスタンスで配信する流れとしました。それぞれが同じくGraphQLのBFFサーバーを見て、マイクロサービスにつながる構成です」（小谷氏）

同じコードベースでビルドを分けるとは、環境変数でブラウザ版とアプリ版の挙動を分岐、ビルド時に定数置換、デッドコード削除を行うことである。このような構成とすることで、モバイルアプリ向けの実装や依存ライブラリがブラウザ版のバンドルに入らないため、サイズが膨らまずSEOを毀損しないことがメリットだと、小谷氏は説明した。

CapacitorではWebViewからリモートサーバーへのアクセスが非推奨とされている点が、この構成の懸念だった。調査すると、Capacitorメンテナのコメントなどから、非推奨の理由はオフライン対応できないことと、ストアの審査に通らない可能性があることだとわかった。ユビーではオフライン対応の必要性が当面なく、ストア規約でリモート配信が許可されていることを確認できたため、この懸念を解消することができた。
小谷氏は実際にCapacitorを導入して良かった点、気になっている点、今後改善したい点を紹介した。特に改善点については、次のように語っている。

「当初はレンダリングの重さに起因するユーザー体験毀損が気になっていました。しかし実装してみると、ページの履歴管理においてブラウザとの差分が大きく、アプリに求められる体験のために独自実装が必要という課題が見えてきました」（小谷氏）

今回の取り組みをテックリードという観点から振り返ると、メジャーとは言えないCapacitorが候補に挙がったのは、広く浅いインデックス的な知識があったからと言える。

一方で、自社のビジネスインパクトが大きい部分は深掘りしておくと応用が効きやすい。今回のケースで言えば、ビルドプロセスについて専門性を持っていたために、SEOに関する懸念を解消してCapacitorを選択することができたと語り、次のようにまとめた。

「目の前のUXを妥協したくない、最高のアーキテクチャにしたい。開発者はどうしてもこのあたりに目線が向きがちです。しかしテックリードに求められるのは、会社のミッションを最短距離で達成するために、中長期で連続的な成長を描くことだと思います」（小谷氏）

【Q＆A】視聴者からの質問に答えるQ＆Aセッション

続いては、視聴者からの質問に答えるQ＆Aセッションとなった。その一部を紹介する。

Q．テンプレートから派生反映での手作業の有無。また、wikiなどのコピーはどうか

渡部：基本的には自動でファイルを吐き出す設計ですが、あまりにも乖離した内容の場合は一部、手作業で反映することもあります。また、Wikiはコピーされません。

Q．テンプレートはゆめみ全体で採用されているのか

渡部：iOSで活用はしていますが、それ以外の開発はFlutterのテンプレートを作っている最中です。また、Androidではテンプレートはありませんが、GitHubのCI/CDのワークフローを非公開で共有できます。

Q．恒久対応の管理方法について聞きたい

横田：バックログで管理していますが、残りがちです。そこで半年に一度はチケットの棚卸しをして、優先順位付けをしています。

渡部：ゆめみもバックログを使っています。また、スプリントの何％かは技術負債に当てる、メンバーのやる気で恒久対応を行う“情熱投資”という制度も整備しています。

小谷：Ubieもツールは同じですが、解消しないとどの程度の損害が何％の確率で起きるのか。金銭的なインパクトを定量的に明示した上で、優先順位付けをしています。Ubieでは全メンバーがビジネス視点で業務に取り組んでいるため、該当領域に一番詳しい人が担当しています。特に專門のメンバーがいるわけではなく、このような取り組みは、負債全般でも共通しています。

Q．医療業界はやりがいも大きい分、苦労も多いのではないか

横田：家の近くの薬局で導入されているのを知ると、素直に嬉しいです。コロナ禍の際はコロナ加算の状況が目で分かることも、やりがいのひとつでした。最終的に患者の幸せに貢献できるビジネスであることも、大きなやりがいとなっています。

小谷：ステークホルダーが多いため、対応も大変だと感じています。ただ視点を変えると、患者、病院、自治体など、いろいろな属性の方々に価値を提供できることが、喜びややりがいとなっています。

Q．capacitorの採用は、社内でどう納得させたのか

小谷：提案する際にはデモ版を用意し、実際にアプリを見せながら行うことで、いかに簡単に作成できるかを理解してもらうよう努めました。

また、ビジネスインパクトが出なかった際に撤退しやすいことも伝えました。反対意見はほとんど出ませんでしたが、プラグインのバージョンメンテナンスにリソースを割いており、事前にもう少し準備しておけばよかったなと感じています。

Q．テックリードとして大切なことは何か

横田：引き出しの多さが大事だと考えています。普段から継続的に勉強することはもちろん、チームメンバーの得意分野を把握するなど、自分一人の力だけでなく、集合知で最適解を突き詰めることも大切です。

渡部：プロジェクトにコミットメントしているメンバー、採用や広報などの領域にコミットメントしているメンバーなど、いろいろなメンバーが集まっています。そうした全メンバーのサポート、支援をするマインドが重要だと考えています。

小谷：広く浅い知識と専門性、両方の知見の掛け算が重要です。また、メンバーに腹落ちしてもらうロジックも大切ですが、技術選定にはどうしても”決め”の要素があります。「お前が言うなら」と思ってもらえる信頼感や情熱といった、エモーショナルな面も大事だと思います。

株式会社カケハシ
https://www.kakehashi.life/

株式会社カケハシの採用情報
https://recruit.kakehashi.life/

KAKEHASHI Tech Blog
https://kakehashi-dev.hatenablog.com/