
2025.03.07
メール対応担当の8割以上が「カスハラ被害」に クレームのハード化・長期化を防ぐ4つの対策
大規模フロントエンドの技術的負債と向き合う。(全1記事)
リンクをコピー
記事をブックマーク
外松俊尚氏:はい。それでは「大規模フロントエンドの技術的負債と向き合う」というタイトルで、サイボウズ株式会社の外松が発表いたします。よろしくお願いします。
(会場拍手)
私は今、新卒3年目になるエンジニアです。今はkintoneというプロダクトの開発をしています。最近だとフロントエンドエキスパートチームという横断的な組織と兼務しています。今日は技術的負債というテーマについてお話します。みなさんも何かしら技術的負債と向き合ってきたり、何か苦労した経験があるんじゃないかなと思います。
今日話すことは、現場の目線で、いま抱えている問題であったり、これまでこの問題とどう向き合ってきたかであったり、技術的負債と向き合うことのメリットについて話をしようかと思っています。
なので特定の技術とかライブラリに限った話とかはしません。今、技術的負債に苦しんでいる人がこれから前向きに取り組むきっかけになったらいいなぁと思っています。
さっそく、私が開発しているkintoneというプロダクトの話を中心にします。
kintoneはWebのアプリケーションなんですけど、2011年にリリースをしているということもあって、プロダクトのライフサイクルとしてはすごい長いんですよね。これからも機能をどんどん実装していくということで、継続的な開発が必要になっています。ドラッグアンドドロップといった複雑な処理もできるので、今JavaScriptで約45万行と大規模なアプリケーションとなっています。つまりkintoneは大規模フロントエンドを抱えています。
このフロントエンドというトピックに関して言うと、やっぱり変化が激しいのが特徴としてあると思っています。例えば、毎年JavaScriptの新しい仕様が出ていたり、ブラウザがどんどん進化していたり、あとはnpmのエコシステムにより新しい技術やライブラリ、ツールが日々生まれています。
世間はどんどん進化しているんですよね。ですけど「kintoneはどうだろう?」と考えると、2011年の開発スタート時のフロントエンドとは状況が違っています。なので昔活躍していた技術は、今は負債として残っているのが現状です。
kintoneが抱えている問題をもうちょっと深堀りして考えると、例えば特定のライブラリやコンパイラに強く依存していて、今のnpmのエコシステムの恩恵を受けづらい状況があったり、使っているツールやライブラリが古いとか、あとはすべてを新しいコンポーネントに書き換えられるような規模ではないなど、いろいろな問題を抱えています。
現状として、技術的負債を多く抱えているというのが、これでわかります。私がこれまでにどのようにこの問題と向き合ってきたかをお話します。
この技術的負債と向き合うきっかけが、趣味でフロントエンドの開発とかをしているんですけど、その開発の体験と業務での開発の体験が「なんか違うなぁ」という違和感がきっかけでした。ふだんの開発でも自分がやっている良い体験がしたかったので、そしたら今ある問題を改善しないといけないなと考えて、この問題に向き合うきっかけになりました。
改善しようと思って、まずはチームで考えないと向き合えないので、チームのみんなで開発系の改善をテーマにワークショップを開催してみました。グループに分かれて「ここがつらい」とかいう改善をブレストして、それを3つの優先順位でグルーピングしてみんなでまとめました。
でもこの回はぜんぜん上手くいかなくて、アイディアがすごい多く出るわけでもないし、議論がすごい活発にできたわけでもありませんでした。
この場でみんなと話してわかったことがいくつかあって、当たり前だけどみんなが自分と同じように「これがいいよね」「今やっぱりこれが大事」とか、そういう同じ感覚を持っているわけではないことがわかりました。
説明するときに「これがデファクトだから」という説明はやっぱりダメで、みんななんとなく良いというのはわかるんですけど、そこからの実行になかなか繋がりませんでした。あとは、ツールとかライブラリを先行して考えるとみんなに伝わらないので、でもみんなふだんの開発のつらみとかなら共感して聞いてくれるんだなと感じました。
これがきっかけで、自分以外の人からの見え方を考えるようになってきました。例えば、新しい技術やツールなどで言うと、みんな良さはなんとなくわかるんですけど、本当にここで導入すべきかはわからないと感じていて、そもそもその良いものを体験していないからイメージするのが難しいみたいな状況があると思いました。
なので、ここで「チームのみんなで新しいものを学べるフロントエンド勉強会をやるといいかも」と考えて開催してみました。今はみんなで毎週木曜日にやっています。すごくよかったのが、ふだんの開発だけでは学べないことを学べるので、新しいツールの良さなどをみんなが体験できてイメージできて、そこから「これを導入したい」みたいな感じで実行につながるということができました。
あともう1つ良い点があって、同じチームの人だけでやっているので、より具体的な話ができます。「kintoneだと、ここはこうだよね」「これkintoneで導入したいよね」みたいな具体的な話がどんどんできるようになってきました。
知識を得るという部分について話をしたんですけど、「ところで最初に話した技術的負債はどうなったんだろう」と考えるとやっぱりぜんぜん進んでいなくて、自分が空いている時間とかに探求してみたけどそれではぜんぜん進まなかったです。
やっぱり継続的に改善するためには時間を掛けてちゃんと向き合わないといけないので、社内にある組織横断的な専門チームとしてフロントエンドエキスパートチームがあるので、そこと兼務することにしました。
兼務を始めてみてすごい良かったことは、フロントエンドが得意なメンバーと今の問題について考えることが頻繁になったり、横断的な組織なので他のプロダクトとも関わるようになって、他のチームで導入しているツールとか、チームに持ち帰れそうな知見が増えました。
これがきっかけで技術的負債の解消が進んできました。今は超巨大な問題から小さい細々した問題までそれぞれ向き合っています。例えば強く依存しているライブラリやツールを減らす作業だったり、DXが向上するようなツールの導入だったり、あとはkintoneの中で「ここは良い設計、ここは悪い設計」ということをみんなで考える会を開くようになりました。
あとはモブプログラミングというものをすごい活用していて、技術的負債だとどこから手を着けたらいいかわからないとか、何をしたらいいかもわからないみたいな「なんかつらい」みたいな。
そういう不確実性が多い問題は週に2日30分とか区切って定期的にスケジューリングしています。次のスケジュールまでにメンバーが解決してくれたりするので、すごく良いです。やることが明確なら一気に進めてプルリクを作るみたいなことをしています。
最近「ちゃんと向き合えてるな」と感じてたんですけど、普通に失敗もあって、最近Prettierの導入をしてみたんですけど、技術的負債の特定の問題とPrettierの相性が悪くて導入ができませんでした。ここで感じたのは、技術的負債を解消しないと世界の進化に追従できなくなって、恩恵を受けれなくなるというのをすごい認識しました。
「やっぱり技術的負債と向き合わないと」と思ったきっかけでした。
「技術的負債と向き合うとどういうメリットがあるだろう」というのを、最近自分の中で考えるようになりました。けっこういいなぁと思っているのが、最初からツールを導入するというのと、大規模なプロジェクトに途中から導入するのは難易度がぜんぜん違くて、その技術についてちゃんと理解をしていないとやっぱりできないので、自分としてはすごいスキルアップにつながる場だなと思っています。
あとは個人開発で当たり前に使っているものを「なんでこれが良いんだろう」と考えるきっかけになっています。例えば、当たり前のようにReactやTypeScript、新しいツールなどを使っているけど「それを入れることによってどういう問題がどう改善するだろう? どれくらい改善するだろう?」と、すごく考えるようになっています。
確かにこれは自分は深く意識できていなかったところかなと思っています。
最後に、すごい優秀なエンジニアじゃない新卒3年目のエンジニアが一歩一歩技術的負債と向き合って進めています。勉強会とかモブプロとかを活用してチームで向き合えば怖くないかなと思っています。すごい自分の成長にもつながります。それでは、ぜひチームと自分のために技術的負債と向き合いましょう!
ありがとうございました。
(会場拍手)
関連タグ:
2025.03.07
部下へのフィードバックで最初に伝える一言 何度も指摘せずに済むマネジメントの秘訣
2025.03.05
「一人前のエンジニア」になるために必要なこと 未経験からフルスタックエンジニアへの道筋
2025.03.12
SNSで炎上している研究者は「研究者として正しい」 人文学のプロ・阿部幸大氏が説く“強い意見を出せない時代”に対する考え方
2025.03.04
チームが協力しないのはマネジメントの問題 “協働意識”を高めるマネージャーの特徴とは?
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2021.09.30
「なぜセーラー服で出社してはいけないの?」 さくらインターネット・江草陽太氏の自由な発想の源
2025.03.12
新規事業を継続するかどうかを見極める2パターンの判断軸 会社の規模別「撤退基準」の設け方
2025.03.11
自分よりできる人を採用し、ゴリ押しで権限委譲 東大発スタートアップに学ぶ、組織を伸ばすマネジメント
2025.03.03
大企業で成功したマネージャーが中小企業で苦戦する理由 “指示待ち”部下を主体的に動かす方法
2015.11.24
人は食事をしないとどうなるか 餓死に至る3つのステップ