メドピアCTOが明かす、技術的負債を乗り越えるためにやったこと

医師専用のコミュニティサイトを運営するメドピア

福村彰展氏（以下、福村）：始めさせていただきます。今日のタイトルは「チームで向き合う技術的負債との付き合い方」ということで。私からは「ぼくらはこうして乗り越えてきた！」というテーマで、みなさんに有用な情報をお伝えできればと思いますので、よろしくお願いします。

まず、私の自己紹介からですね。

メドピアという会社でCTOをやっていて、2人の子どもがいます。好きな飲み物はビールです。Twitterとかをやってる人は「こいつ毎晩ビールの写真上げてるな」みたいな、そんな感じだと思いますけど。

ちなみにメドピアを知っている人はいますか？

（会場挙手）

あ、けっこう……3分の1ぐらい。ありがとうございます。「MedBeer（メドビア）」というビール飲みながら技術の話をして交流するイベントも不定期でやっているので、機会があればぜひ来てください。

「メドピアってどういう会社？」というところで……あ、まあいいか。本当は「Sansanさん上場おめでとうございます」ってスライドを作ってきたんですけど……。

（会場笑）

福村：貼り間違えちゃって、すみません。「Sansanさん上場おめでとうございます」。ということで、いきます。

メドピアのミッションは「Supporting Doctors, Helping Patients.」。医師を支援して患者を救うということを存在意義にしています。ビジョンが「集合知により医療を再発明する」ということで、こういう経営理念をもとに事業を行っている会社です。

医師専用のコミュニティサイト「MedPeer」を運営していて、これがメインの事業です。

メドピアの特徴は3つあって、この3つをちょっとでも今日覚えていってもらえればなと思います。

1つ目が、社長が現役の医者をやってます。

週に1回、病院で診療をやってるんすね。なので医療現場の手触り感があるし、現場への強い想いがある。そういう会社です。なので、先ほどのような経営理念になっています。

2つ目が、日本のお医者さんの3人に1人が会員になっています。

日本のお医者さんって30万人ぐらいなんですけど、今MedPeerには12万人の会員がいます。医療業界でゲームチェンジが起こせる規模のプラットフォームになったと思います。

3つ目は、エンジニア文化ですね。

僕らはこれをどんどん発信していかないといけないんですけど、2012年から醸成してきています。

技術については、けっこうスピーディに選択していて、「ABテストやって」とかじゃなくて、メリット・デメリットを考えて決めで進めていっちゃうことが多いです。

それから、PHPの独自フレームワークからRailsへ移行しています。開発フローはgithubフローっぽいのでやっています。環境は今風を維持していると思っています。

開発チームとしてはこんな感じで、サービス開発チームと基盤チームのマトリクス構成になっていて、CTO室が横串で各エンジニアチームの生産性を上げるという開発の体制にしています。

今（2019年6月時点）、Railsエンジニアが40名ぐらい、アプリのエンジニアが10名ぐらい、フロントエンドが2名ぐらい、SREは5名、セキュリティ1名、QA1名、増員予定です。あとは2名の技術顧問の方に手伝ってもらっていて、Rubyは前島さん（前島真一氏）という方、フロントエンドは林さん（林優一氏）に手伝ってもらっています。

コードを一緒に書いてもらったり、テックブログを書いてくれたり、社内の勉強会を主導してくれたり、ランチ行ったり、合宿行ったり、色んな手伝い方をしてもらっています。

技術的負債とは何か？

ここから、「技術的負債とメドピアでの取り組み」について、「実際どういうことをやってるの？」というところをシェアしたいと思います。

この「技術的負債ってなんだろう？」というところからちょっと考えました。

Wikipediaを読んでも「技術的負債は、行き当たりばったりなソフトウェアアーキテクチャで、余裕のないソフトウェア開発が引き起こす」、それで「結果的には比喩である」という表現なんですけども、ちょっと考えました。

僕が「技術的負債ってこれかな」と思っているのが、モチベーションを下げるコード、想定外に障害が起きてしまうコード、あとは想定外に工数がかかるコードかなと。

これはなんか「ああ、なるほどな」と思ってくれればうれしいんですけど、個々人の気持ちとかスキルとか、知識とか……何か前提があって、それぞれ人によって感じ方が変わるものかなと思います。

あと、技術的負債を放置するとどうなるかといったら、「やっぱこうかな？」と僕は思っています。

生産性はやっぱり落ちますよね。それで障害が起きやすくなるし、障害が起きると経営陣との信頼関係、上長との信頼関係もそうですけど、それが崩れてきます。崩れてくると、モチベーションが下がって辞めたくなるよねと。

というところで「カイゼンだ」と。

こんな感じでメドピアは改善しています。

モチベーションを下げるコード

今日のテーマは技術的負債ですけど、「モチベーションを下げるコードってどういうもの？」というところでは3つあると思っています。

仕様がよくわからない、バージョンが最新じゃない・古い。あとはトレンドじゃない。こういうのってモチベーションを下げますよね。

あと「障害が予想外に起きてしまうコードってどんなコードだろう」ということも考えたんですけど、テストがない、可読性が悪い、設計思想の理解が薄い。

この3つかなと。

また、「想定より余計に工数がかかるコード」というのは、これも一部同じなんですけど可読性が悪いもの、Fatになっているもの、あとはDRYじゃないまたはDRYすぎるもの。

こういうものが、実際に改修しようと思ったときに、けっこう工数かかっちゃうんじゃないかなと。

というところで、技術的負債への対策としては今お伝えした3つを解決すれば、ある程度は抑え込めるんじゃないかなと考えています。つまり、モチベーションを上げる環境作り、障害が起きにくいコードと環境作り、あと開発がぐんぐん進むコードが生まれる環境作り。こうした環境作りに取り組んでいます。

モチベーションを上げる環境作り

3つそれぞれ、メドピアでの取り組みをご紹介します。まず、1つ目の「モチベーションを上げる環境作り」。まず弊社が行ったのは、僕も入社する前に作られた独自フレームワークを、RailsというRubyのフレームワークに置き換えるという決定です。

なるべく最新のものを使いたいというのはチーム間でも醸成していて、今はもうけっこういろんなリポジトリが作られているんですけど、Rails6は今も2つのプロジェクトで走っています。ちなみにRails開発をしている人ってどれくらいいますか？

（会場挙手）

あ、わかりました。あとモチベーションを上げるためには、テストを書く。後世に安心を与えるためにも、テストを書いていこうということを徹底しています。

見積もりのときに、「テストを書く分を想定して見積もるように」ということをけっこう言っています。これはエンジニアじゃない人たちに対しても「これは必要だ」と言わないといけないんですけど、こういうふう当たり前にすることでモチベーションを上げる。

書き方に関しては、RSpecっていうRubyのテストのコードがあるんですけど、これの書き方とかは、メドピアの開発ブログを読んでもらえたらもう少し詳しいことが書いてあります。

あとは、ちょっとRailsに寄っているんですけど、定期的なバージョンアップ。これは言語によらないことだと思うんですけど、定期的なバージョンアップをやっていく仕組みを作るとすごく効果があると思ってます。

メドピアでは月に2回、自動でプルリクが作られる仕組みを採用しています。GitHubを使われている会社さんも多いと思うんですけど、ちょうどDependabotが無料になったりしたので、さっそくうちの一部のサービスで使われています。Railsの場合は、自動で対象のgemごとに全部プルリクが作られてしまう点で、ちょっと使いづらいとかあるんですけど、そういうものなどを使ったらいいんじゃないかなぁと思います。

（スライド内の）キャプチャのやつは、「circleci-bundle-update-pr」というもので、メドピアではそれを使っています。

障害が起きにくいコードと環境作り

2つ目の「障害が起きにくいコードと環境作り」という点については、これはちょっと大事なことなので2回書きましたけど、テストを書く。これは大事で、テストを書く文化がないところはテストを書くようにしていくといいんじゃないかなと。

CIを入れるのがつらいというときは、「テストする」になるんでしょうけど、それはちょっとモチベーション下がってきますよね。

あとは障害が起きにくいコードということで、メドピアではみんなで勉強するという文化を作っています。

輪読会はおすすめです。同じ書籍を持ち寄って、みんなで読むっていうやつですね。社内の知見者、リーダークラスの人とかに参加してもらって、ただ単に本を読むんじゃなくて、本を読んで「どういう経験をしてきたか」というのを語ってもらうのが重要で、そうすると盛り上がるみたいな……（輪読会を）やられてみるとすごくいいと思います。

こんなものを僕らは読んでいます。

あとは、「レビューする」ですね。

「レビューしてるよ」というのはあると思うんですけど、うちの場合は、プルリクのテンプレート化をしています。プルリクを作ったら、このプルリクエストは何なのかとか、僕らJiraを使っているのでチケットのURLとか。あと重点的に見てほしいところ、不安なところ。どんなテストをしたか。あとは、ローカル環境で動かしたくなったときの手順。こういうことをプルリクに書いてレビュー依頼をするという感じでやっています。

あと「可読性をよくする」というのは、CIで怒ってもらうのがいいのかなと。

コーディング規約にチェック入れて、RubocopとかPHPとか、PHPだったらCodeSnifferとか。JavaとかPythonとかいっぱいあると思うんですけど、そういうのを入れてCIに怒ってもらうと。

開発がぐんぐん進むコードが生まれる環境作り

最後3つ目の「開発がぐんぐん進むコードが生まれる環境作り」については、Railsの話と弊社の話ですけど、レールに乗るということが大事かなと。

そのなかでも輪読会がおすすめで、Ruby関連の書籍とか、メドピアで使っているgemのREADMEとかをみんなで読んで、「あ、こういうふうに使うんだ」とか、チーム間の情報共有をしています。

あと最近始めた……最近でもないか。整地部というのをやっています。

ちょっとスライドの画像は薄くてわかりにくいんですけど、esaに荒地というページが作られていて、荒地ページを作ってリファクタリングしたいところを潰していきます。隔週で1.5時間ぐらい確保して、修正が大きい部分は技術力が高い人をアサインして、一緒にモブプロをするという取り組みをしています。

そうすると「リファクタして気持ちがいい」とか、みんなモチベーションが上がっていくので。これもメドピアの開発ブログにもっと詳しい内容が載っているので、ちょっと知りたい方はこっちを見ていただけたらなと思います。

あとは、けっこう前から、みんなでプルリクを振り返る「プルリク振り返り会」というものをやっています。

言われたら「ああ、なるほど」と感じてくれる方もいると思うんですけど、プルリクってコードの変更の知見じゃないですか。それをみんなでシェアすることでいい感じになります。

最近だとRails6が出たばっかりなんですけど、ハマった知見でプルリクを通して、「こういうふうにハマりました」みたいなことをメンバーに共有することで、みんなが同じ地雷を踏まないようにするというのをやったりしています。これはけっこういいので、やっていただけたらなと思います。

あとは、すぐには取り入れられないかもしれないんですけど、「JavaScriptStudy」とかをやっています。

これは、僕らはRailsのエンジニアがけっこう多いので、ES6とかVue.jsとかTypeScriptなど、主戦場じゃないところの知見を増やしてほしいというところで、ハンズオンでやっています。

あと「インフラStudy」とかですね。

Webエンジニアだと、権限がないとサーバの設定とかよくわからないところがあると思うんですけど、シンプルなRailsのアプリ作成をしてもらって、VPC作ったりとかセキュリティグループとかそういう設計を実際にやってもらって、血肉にしてもらう。そういうことをやっています。

あとは「SecurityStudy」っていう勉強用のリポジトリも作っています。

RailsGoatという攻撃用のリポジトリがOSSで公開されているんですけど、OWASP Top10の10個の脆弱性を突くような、そういうリポジトリです。メドピアが注意してほしいような脆弱性をもう少し多く仕込んだやつを実際に作って、最初はCapybara RSpecが全部failなんですけど、脆弱性を潰していくとsuccessになる。そういうのもあります。

こういうものを使って勉強をしてもらって、変なコードを作らないようにする。こういう取り組みをやっています。

技術的負債を返すためにすぐに取り組むべきこと

今日の資料をつくりながら「なんかいろいろやってるな」と思ったんですけど、とっつきやすい、明日からできるような取り組みをピックアップするなら、まずは「整地部」、さっきのリファクタリングの話ですね。整地部は、時間が確保できれば、けっこうやりやすいかなと思います。あとは「輪読会」ですね。本があれば、電子書籍でもいいですし、RailsだとRailsガイドとかああいうものでもいいんですけど、みんなで読むとエンジニア間の技術力の向上になって、技術的負債を減らしていけるかなと。

あとは「プルリク振り返り会」と「プルリクテンプレート」。プルリクテンプレートは気楽にやれるんで、やったらいいかなって思います。

それから、「レビュー」。レビューやってなかったらレビューやってください。レビュー文化を醸成するのはなかなかあれかもしれないですけど。ただ、技術的負債を防げるのはけっこうレビューが大きいかなというところで、レビューやってなかったらやってください。

あと、「コーディング規約自動チェック」ですね。CIに怒ってもらいましょうと。この辺はとっつきやすいかなと思います。

それから「少しハードルがあるかもしれない取り組み」を挙げると、まずは「エンジニア文化を醸成」すること。そうすると例えば新しい技術を導入するときにスムーズにいくとか、けっこう便利というか、いいです。

あと、「技術的負債の解消チームを作る」といいと思います。これもけっこうハードルが高いですね。メドピアは2016年ぐらいからRails化をしているんですけど、2年ぐらいは解消チームを作らないで、並行でやってきたんですね。リバースプロキシを立てて、イベントリごとにPHP側とRails側の両方やってきたんですけど、2年でだいたい2割か3割ぐらいの移行しかできなくて、そのかわりトラフィックはやったUI/UXを意識して改善していくので、トラフィックはそっちのほうが上がってきます。

でも、PHPをRailsに移行するという観点から見るとぜんぜんスピードがあがってこなかったので、もう移行するチームを作っちゃいました。それを去年の10月ぐらいからスタートして、長いですけど今年末までロードマップを引いている感じです。

あとは「技術顧問の力を借りる」のがすごくいいかなと思うんですけど、これもちょっとハードルが上がりますかね。どう開発をしたらいいかというときに、けっこう迷うことがあると思うんですけど、そういうときに判断できる人がいない場合は、そういう技術顧問とか、外の人の知見を借りるのが問題解決の近道になるかなと。

それから、「技術研鑽系のイベントの定期開催」ですね。これはけっこうがんばってやらないとダメなんですけど、そうすることでエンジニアのベースの技術がどんどん上がっていくので、やっていったらいいかなと思います。

最後は「技術研鑽のサポート」ですね。会社がサポートして、会社がどんどんエンジニアの技術力を上げていく。僕らは開発合宿を2013年から年に2、3回行っていて、ちょうど来週も行くんですけど、そういう取り組みをやっています。

やれることからやっていく姿勢

まとめに入りますけど、2016年までの開発チームって僕らこのぐらいだったんですね。

メドピアと新規事業開発チーム。2016年以前は（サービスが）「MedPeer」しかなかったので。それが2017年になって、「first call」と「DietPlus」というコンシューマ向けのサービスを展開し始めて、またチームが増えました。

さらに去年2018年には「スギサポ」というスギ薬局との共同事業を開発するチームが増えて。

今年は新たに薬剤師のプラットフォーム「ヤクメド」を作って、また増えて。

お医者さんのコミュニティサイトの運営がメインですって言ったんですけど、今はけっこうこのぐらいのペースでサービスが拡大しています。

人が増えてくると、技術的負債を望んで作る人はいなくても、やっぱりできてしまうんですね。できてしまうんですけど、それはもう仕方がないと。

あと、技術的負債について最初に僕なりの定義をしましたが、技術的負債って見る人が変わると技術的負債に早変わりしちゃうっていう側面があると思うんですよね。だからすごい困りものだと思っています。

なので、今日はやりやすいところとやりにくいところを分けましたけど、やれるところからやっていって、どんどん抑え込んでいく。抑え込んでいても違う人が入ってきたら、違う人が見たら技術的負債って言われちゃうかもしれないんですけど、そういう対策をやっていくという姿勢が大事かなと思っています。

はい。ということで、うちのエンジニアのチームは一部ですがこんな感じです。仲間を募集しています。

ご清聴ありがとうございました。

（会場拍手）