2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
複数プロダクトで利用する共通ライブラリの戦略と運用経験(全1記事)
リンクをコピー
記事をブックマーク
井上真吾氏:みなさんおはようございます。さっそくですが「複数プロダクトで利用する共通ライブラリの戦略と運用経験」という題でトークさせていただきます。よろしくお願いします。
まず自己紹介になります。井上真吾と申します。株式会社CureAppというところでチーフエンジニアをやらさせていただいています。言語としてはTypeScriptやNode.js、要はJavaScript系がとても大好きです。サーバもフロントもWebもアプリもという感じです。言語処理系を読んだり、ASTなどをいじったりするのが大好きです。
株式会社CureAppについて紹介をさせてください。株式会社CureAppですが「アプリで治療する未来を創造する」ということで、「治療アプリ」と呼ばれるソフトウェア医療機器を作っている会社になります。
具体的にどういうプロダクトなのかみたいな、詳しい説明をしに来たわけではないので「実際にCureAppが成し遂げること」としては、医療費の問題が今後続々と増えてくると思います。
その医療費の削減だったり、医療格差を埋めることなど、日本の医療の世界はいろいろな制約とかがあったりするんですけど、その規制緩和に合わせて、日本発のイノベーションを生むことを目指しています。
主に生活習慣病を題材に、ニコチン依存症や非アルコール性脂肪肝炎、高血圧などを扱っています。ヘルスケアの事業も別途やっているんですけど、そのへんの詳しい話はもしよかったら懇親会やAsk the speakerコーナーで聞いてもらえればと思います。
最近では治験というものがアルバイトなどであると思うんですけど、弊社のアプリで治験をやっていまして、その結果が出たので、記者会見をしたり、22億円ぐらいの増資を受けたり、評価や注目をいただいている企業だと思っています。
会社紹介はそれぐらいにして、技術スタックとしてはJavaScriptやTypeScriptで書いています。ちょっと小さくて見にくいかもしれないですが、SPAをクラウドフロントに配布してAPIサーバはAPIGatewayとLambdaを使って、仕組みを作っている感じになります。
主に使用している技術としては、すべてJavaScriptやTypeScriptで書いています。アプリも作っているので、アプリに関してもJavaScriptで作っています。
本題ですが、このディレクトリ名たちを見て、みなさんはピンと来るかと思います。たぶん、みなさんのプロダクトに1個ぐらいこんなフォルダがあるんじゃないかと思います。うちのアプリもあります。紹介できる限りは4個なんですけど、他にもいろんなプロダクトを作っています。
次のプロダクトに移って書いているときに「あれ? これ前も書いたな」みたいなことがけっこうあって、シンプルなユーティリティ関数、例えばゼロフィル、数字の手前に0を入れる処理とか、そういったシンプルなものあたりから始まったんですけど、他にも共通になり得るものはたくさんあるかなと思っています。
例えば画面や、認証・認可まわりなど、ビルドやデプロイの設定だったり、プロジェクトの大枠の技術スタックは似ているので、例えば「ボイラープレートを作ったらいいんじゃないか」とか、他にもいろいろとありました。
前にも作ったし、もう1回同じものを作ってまたエンバグして、プロダクトがリリースされるまでの期間がかかります。バグを直して確認して、もう1回バグを直して、「各プロダクトで同じことをやっているな」と、とても思いました。
なので、あらかじめ1回踏んだバグはライブラリにして、他のプロダクトではバグがないライブラリを使ってプロダクトを開発すれば、時間の節約にもなるし、ライブラリを集約していくことで、プロダクト開発のコアに割かないといけない時間が生まれると思って、ライブラリ化の作成を始めました。
昨日数えてみたんですが、Node.jsなのでnpmというツールを使ってライブラリを公開します。OSSになっているものもあるんですけど、社内だけで使えるパッケージがほとんどです。そのライブラリのリリースペースを数えてみたんですが、この1年で仕事で473回、自分の趣味のOSSで196回のリリースをしていました。
これだけリリースをしてきたからこそ得た失敗や成功もあったかなと思っているので、今日はそういうお話をさせていただければと思います。
そのライブラリを作り始めるときに、「こういう要件のアプリです」と決まって、「じゃあ作るぞ!」ってなるんですけど、そのプロダクトを作り始める前に先に「こういう要件なんだから、こういうライブラリが必要なはずだ」みたいなことを考えながら、いきなり作り始めて「実際にプロダクトを作り始めて、そのライブラリを入れてみよう」となると「ちょっと要件とマッチしていない」みたいなことが発生したりします。スライドのような感じでライブラリ先行で作ると失敗しやすいかなと思います。
こんな感じで起きた失敗と、どういう学びを得たかをつらつらと並べていこうかなと思います。
こうした反省を活かして、今度はプロダクトの中で使いながらなるべくライブラリになるように汎用的にプロダクト固有の知識がなるべく混じらないようにと切り分けながら作っていって「プロダクトが完成した。よしライブラリを出してみよう!」となったときに、なるべく気を付けながら書いていっても、そのプロダクトの都合がどうしても混じってきてしまって、ドッグフーディングをしすぎないように早めに分離をするといいかなと思います。
ボイラープレートはなるべく作らないほうがよかったかなと思います。その各プロダクトでベストプラクティスになっているコードを公開しておいて、それを参考にすることだったり、必要であればライブラリ化をする。プロジェクト全体の雛形は作らないほうがいいかなと思いました。
アップデートをすると「こういう機能の変更やこのバグが直ったよ」みたいなことを共有するコストが掛かって、そこにライブラリを作っている人はみんなそうしているんですけど、それを使っている側の人はぜんぜんキャッチアップできない。
それでその情報格差がどんどん生まれていったので、リリースの通知は全部自動化して「このバージョンでこれがリリースされました」みたいなリリースノートをちゃんと書いたりして、なるべくあとからでも見返せるし、リアルタイムでも気が付ける工夫をしていました。
1つのプロダクトの都合で機能の追加や使用の変更をして、他のプロダクトにとって都合の悪いものになってしまったこともありました。これに関してはReactやNode.js、VimなどのOSSにのっているんですけど、rfcsみたいなリポジトリがあります。
ここで仕様を議論するという「Request for Comments」という略で「rfcs」なんですけど、ここまで大げさなことはやらずとも、こういう大きい変更を加えたいという意表を立てて、そこでその各プロダクトのエンジニアで議論しながら「どうなるのがみんなにとって都合がいいか」と練ったりしていました。
たぶん自作でライブラリを作るときに一番の強敵はドキュメントだと思っています。ここを蔑ろにしてやってしまうと、作っていた人や当時使っていた人だけが知っていて新しい人がぜんぜんついていけないってなっちゃうので「ドキュメントとかを書くことも含めてライブラリを作ることなんですよ」というのをとても学びました。
キャッチアップすることに関しては、モブプロを定期的に開催していました。
単にハウツーではなくて「なんでこのライブラリがあるのか?」みたいな思想も共有して、みんなとコードを書いていって、そのライブラリの中身や思想を知ってもらったり、こうやって登壇をしてみなさんからフィードバックをもらいながらやっていました。
あともう1個。やっぱりそれでも日々プロダクトの開発をしていると時間って取れないので、合宿をやってプロジェクトの開発じゃなくて「ライブラリだけをやる合宿」とか「ドキュメントを書く合宿」みたいなのをやっていました。
そろそろお時間ということでまとめに入っていきます。こんなことをやってみた結果、プロダクトが違うから、同じ技術で同じスタックなのに縦割り感があったところが薄らいでいきました。
最後になるんですが、こういうライブラリの戦略として作ってちゃんとコストに対してペイするかというところは事業の優先順位にもよるので、そこも考えながら、やり方としてはOSSをリスペクトしながら運用していくと良いライブラリやエンジニア組織になっていけるんじゃないかと思っております。
「We are hiring」ということで、ご清聴ありがとうございました。
(会場拍手)
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05