導入した記録ではなく導入“しなかった”記録を残す　LADRによるアーキテクチャ意思決定記録のすすめ

LADRのすすめ

鈴木勇氏（以下、鈴木）：それでは私、鈴木が発表したいと思います。『新サービス立ち上げ時の技術選定と、サービス立ち上げに向けたラクスの取り組み（仮）』だったのですが、長いので『LADRのすすめ＆先行技術検証プロジェクトの紹介』といった内容でやりたいと思います。

まずは自己紹介ですが、私は鈴木勇と言います。2013年にラクスに中途入社しました。会社の肩書きはガンプラ部部長です。先行技術検証やアーキテクチャ選定、技術イベントの司会などをやっています。今日は司会はやりません。

上流から下流まで経験済みで、一応プロジェクトマネージャーも含んだフルスタック系の経歴です。先ほど言語の話もありましたが、言語遍歴としてはC/Javaを昔やって、JavaScriptにちょっと倒れて、最近はPython、TypeScriptあたりを触ることが多くなってきました。

あとプライベートですが、自宅にNURO光がやっと開通しました。先月引っ越しましたが、申込みから1ヶ月半、2ヶ月近くかかって開通しました。

引っ越して家のまわりの近くにコンビニもなくてですね。けっこう歩かないと……けっこう歩くっていっても10分も歩かないんですけど。5分以内にはなにもないところだったので、自転車を買いました。10年ぶりくらいなんですけどね。10年前に自転車で事故って以来、乗っていませんでした。最近自転車に乗って楽しんでいます。

あと、知っている人がいるかどうかわからないですがFat Projectという要件定義カードゲームの作者もやっています。新作を来年（2021年）あたりに発表できたらいいなと思っています。

今日話すことですが、アーキテクチャ選定時にやると少し幸せになれることと、新規サービス立ち上げに向けてどんな活動をしているのかについて話したいと思います。

新サービスのアーキテクチャ選定

新サービスのアーキテクチャ選定の事例として、2018年に楽楽労務というサービスの開発プロジェクトが立ち上がりました。立ち上がったというよりは、作ろうと思っているがどういう仕組みでやってったらいいだろう、みたいな話が出てきました。

楽楽労務に関してはこのあと福岡が発表するので、詳しい話はそちらで聞いてもらえればと思いますが、社保手続きなどといった労務管理を効率化するサービスです。

このときの社内の様子がこちらです。東京と大阪に拠点があるんですが、東京の拠点の開発言語は主にJavaでした。フレームワークはSeasar2……ちょっとSeasar2は古いよねっていうところですが。当時新しめのサービスでも、2012年以前に開発に着手したものが最新だったので、ここらへんは歴史があるな、というところで。

あとモノリシックアーキテクチャで、インフラはオンプレミスで作っていました。いろいろな事情があって、こういう構成になっているんですが、こういう構成になっている詳しい理由は、もう長くいる人じゃないとわからないんじゃないかと。たぶんみなさんの職場にも仙人のような人がいて、「これってなんでこうなってんの？」って言ったら、「あの人に聞いてください」みたいな人がいるんじゃないかなと思います。

なんにせよ、新しい技術を導入したりしなかったりすることになると思って、導入しなかった記録を残したいなと思いまして。導入したものってはあとあと現物として残っているので、記録しなくても「なんでこうなっているの？」というのが残りやすいですが、導入しなかったものはあとから見ると「なんで使わなかったんだろう」というのがわからないことが多いかなと思います。

そもそも検討したのか、検討したんだったらなぜ導入しなかったのか、導入しなかった理由もその時点だからなのか、今後も導入しなくていいよねっていう判断をしたのかがわからないな、と。

LADRという手法

そこでLADRという手法があります。Lightweight Architecture Decision Recordsというやつなんですが、これはもともとアメリカの予約管理システムを展開しているSabreという会社のMichael Nygardさんが、ブログでADR、Architecture Decision Recordsとして発表したものです。

このADRがMartin Fowlerさんなどがいる、ThoughtWorksのTechnology Radarという、技術要素をいろいろ評価して公開してくれているサイトで取り上げられて。そちらで2017年にAdoptに昇格しました。Adoptというのは、どんどん採用していくといいよという評価結果なんですが。そこではこう紹介されています。LADRは重要なアーキテクチャの意思決定をその文脈や結果とともに記録するためのテクニックであり、WikiやWebサイトではなくて、コード管理と一緒に管理していくことを推奨していて、ほとんどのプロジェクトで採用しない理由がないテクニックだよ、と紹介されています。これはやらない理由がないなと。

Lightweightって付いているくらいなので、やること自体は簡単です。ADR（Architecture Decision Records）、アーキテクチャ意思決定記録という日本語訳ですかね、そのフォーマットを決める。アーキテクチャ選定の意思決定を実際にする。何を使う、何を使わないというやつですね。フォーマットにしたがって、記録管理をして、ソース管理に格納しましょうとされています。ね、簡単でしょ。

そう言われても要領がわかんないし、フォーマットを決めるというのがそもそも面倒だよ、というところで、フォーマットがないかなと探したら、やっぱりテンプレートが公開されていました。

ざっと見た感じだと、1個目がオフィシャルっぽいもので、ほかにもいろいろとテンプレートが公開されていました。ただ、英語のものしかないっぽいので、がんばって読んでみましょう。

英語読むのはいいけど、英語だと何を記録すればいいのかニュアンスがわかりにくい。

そこで、ご用意いたしました。moomoo-yaというのは私のアカウントなんですが、moomoo-ya / LADR-templateは完全に日本語版です。何を書くべきなのかも全部テンプレートの中に記載してあります。もちろん、各自カスタムしていただけるとなおいいと思います。使いやすいMITライセンスで公開しています。

こちらのURLで見ていただければと思うのですが、内容はどんな感じのものかというと、右に一応スクショも貼っていますが、こんな感じですね。いつごろ行われた意思決定なのかというのが意外と大事で。なんでこれ使っていないんだろうと思って日付を見たら、「まだなかった時代だ！」とか、けっこうあるあるなんですね。

あと文脈を残すのも大事です。どんな課題があって、どういう検討をして、どういう判断観点で採用になったのか、不採用になったのかというようなことを、ツラツラと書き残す。ステータスは、実際に採用したのか採用しなかったのかを記録していく。自然言語で詳しく書いていくとよいと思います。フォーマットはMarkdownでよいです。

LADRが役に立った事例

で、役に立つの？　っていう話だと思うのですが。2018年のアーキテクチャ選定から1年半ほど経った2020年の1月、今年の頭にグループ企業でアーキテクチャ選定したいのでちょっと相談に乗ってほしいという話がありました。

サービスのソフトウェアリプレイス計画がありますという話を聞いて、実際相談が来た内容が、マイクロサービスにするべきなのかどうか？　とか、コンテナってやっぱり使ったほうがいいの？　っていうような聞き覚えのあるような検討項目が来ていました。

これは実際のリポジトリのファイルリストなんですが、実際に2018年のときに行ったADRの記録を見ると、コンテナやマイクロサービスアーキテクチャを検討しているんですね。

ただ注意点があって、今回のケースだと1年半経過しているので、当時の判断をそのままは使えません。ただ、どんな議論をしたかっていう記録は残っているので、議論のスタート地点を前にずらすことはできます。この手の議論って、だいたいよくわからない状態からスタートするので、時間がかかるんですね。その時間がかかる部分をちょっとでもショートカットできるのが嬉しいなと思います。

あとこれは1年半経っていますが、1年半経っていなくても、半年でそのまま技術トレンド的には使えそうという場合もあるんですが、そういった場合でもプロジェクトが違うとコンテキストが違ってくると思うので、そのまま使うのは難しいと思います。それでも議論はどんどん先に進められるので、ショートカットになります。

LADRのPros / Cons、メリットデメリットというところですが、メリットとしては選定理由が記録に残る。通常1年後にはみんな忘れているんですよね。覚えている人もいるかもしれないですが、僕は忘れています。あと相談されたときに楽です。「あそこに記録してあるよ」ってパスを送るだけで一瞬で仕事が終わるので。

新規メンバーの疑問解消にも役立ちます。「これなんで使っていないんだろう？」って思ったときに「ここに書いてあるから見てみてね」で済むので楽です。あと軽量だから更新が続く。マークダウンでさらっと書くだけなので、そんなに難しい取り組みではない。

さらに経緯を知ったうえで判断できる。その後、アーキテクチャに関する検討が追加で行われたときに、過去に判断して使わない理由になった事情が変わっていれば、採用も考えますし、同じ事情が維持されているのであれば、うっかり採用しなくて済むのが利点だと思います。

デメリットの部分でいくと、記録するのはやはりちょっと手間。とはいえ実際に記録した感じでは許容できる範囲の手間かなという感じでした。

あとLADRって発音しにくいですね。噛みます。もともとのMichael NygardさんのブログでADRって紹介されていたんですけど、内容はLADRとして紹介しているTechnology Radarのほうと変わっていないので。LADRのLって何が違うんだろうと思いましたが差はないようです。普通にADRでいいのかなと思います。デメリットは実質0でした。

新サービスの立ち上げに向けた日々の取り組み

ちょっと話は変わりまして、新サービス立ち上げ時に向けて日々どんな取り組みをしているのかというところですが、そもそも新サービスの立ち上げって忙しいですよね。

エンジニアで新サービスの立ち上げって言われたら、流行りのフレームワークを採用して、話題の言語も使いたいし、最新のツールも使いたいし、イケている設計手法や開発プロセスも使いたいしって思うんですが。だいたい「いつからマネタイズできますか？」って言われるっていう、この現実。

新サービス立ち上げ時はやっぱり忙しくて、リリースするまではコストにしかならないので、いち早く最低限の機能でリリースしたいというのは、たぶん正義なんですね。そうなると、ノウハウのある技術でってなりがちで、技術面よりも業務要件まとめるほうが難しいし、優先すべき部分。まあわかるんですが、エンジニアとしてはつらいなというところだと思います。

ということがあるので「開発の未来に先手を打つプロジェクト」というプロジェクトが発足しました。2017年2月ごろからプロジェクトが動いていて、どんなことやるのかというと、今後使う見込みの技術を先行検証するプロジェクトです。

サービスを横断的に選抜した4人でスタートして、途中から1名追加して検証を行っていっていて。半期ごとに1テーマやって、毎週5時間なので、参加メンバーの業務時間のだいたい12パーセントちょっとくらいを使って検証を進めていました。サービスへの導入を想定した検証をしています。

うちの会社独自のいろいろなしがらみも考慮しながら、既存のサービスも考慮しながら検証していくことをやっていました。

横断的に選抜したメンバーというのは理由があって、うちは複数サービスやっているので、個別にやるとコストパフォーマンスが悪くなります。横断的にチームを作って、検証した結果の成果を同じように横断的に展開していく、というやり方でやっています。

発足の経緯としては、もちろん現場のエンジニアは漠然とした不安感で「技術の更新やらないとねー」っていうのはあったのですが、なかなか思っているだけで動き出すことってないと思うんです。

そのタイミングで経営層から「やりましょう」というオーダーがあったんですね。ありがたいことに弊社はちゃんと利益も上がっていっているので、こういったことをやる余裕もあるんだな、と思いました。

かみせんプロジェクトから技術推進プロジェクトに

3年経って順調に拡大しておりまして、名前はかみせんプロジェクトから技術推進プロジェクトという名前に変わりました。プロジェクトを推進する担当部署が設立されまして、僕もそこに所属しています。

参加メンバーは10名を超えて、この10名はやはり各チームから横断的に選抜されています。テーマももともと半期で1テーマずつ進めていたんですが、今年からは年間7テーマ、半期で4テーマが並行して進んでいるような状態です（半期4テーマ＋通年1テーマで合計5テーマが並行して進んでいる）。

成果については弊社のテックブログで公開していて、過去の記事からタイトルをピックアップすると、『マイクロサービスアーキテクチャにおけるサービス分割の難しさ』や『失敗しない機械学習プロジェクトの進め方入門』といった記事がブログで公開されています。右側にQRコードも付けているのでよろしければ見てみてください。

発表は以上です。内容としてはアーキテクチャ選定時は記録を残そう。LADRはいいぞ。わりとすぐに活用できます。新サービス立ち上げに向けて備えをしよう。見えてからでは間に合わないことが多いぞ、というような内容でした。ありがとうございました。

質疑応答

司会者：ありがとうございます。新規サービスを立ち上げる前から立ち上げたあとまでの、LADR……たしかに言いにくいですね（笑）。LADR。

鈴木：ADRでいいかなと思います。Lightweight感がどこにあるのかよくわからなかったです。もともと、ADRもLightweightな内容だったので。

司会者：コメントで「ラダーやレイダーでいいんじゃないですか？」という方がいましたね。公式にはとくに読み方決まっていないんですか？

鈴木：公式には決まっていなくて、YouTubeでこれに関する発表をしている人のを聞いても、略称を呼んでいる人が見つからなくて。ラダーっていないかなと思って探したんですけど。Lightweight Architecture Decision Recordsって言っていましたね（笑）。

司会者：きっちり言うんですね（笑）。

鈴木：あんまりまだメジャーになっていないのかもしれないですね。手法自体が。

司会者：「プロジェクトで採用しなかったアーキテクチャはどこにも残らない。それを残すことが大事」について「わかる！」とコメントをいただいています。

鈴木：そうなんですよね。みんな忘れますからね。なんで使わなかったの？　なんでだっけ？　ってなりますよね。

司会者：ほかの人だけではなく自分自身ですら、思い出すのに時間かかったりはしますよね。プログラムでも半年経ったら別の人が作ったものって言われるので。

鈴木：そうですね。

司会者：アーキテクチャ以外でも、いろいろ使える考え方、ハウツーだなと思いましたね。

鈴木：そうですね。アーキテクチャに限らない話な気はします。意思決定全般に使えそう。

司会者：あと私が気になったのは、ステータスがAcceptedと他にあったじゃないですか。RejectedとかOn holdingとか。あのへんって、どういったタイミングで見直しをかけるのかなというのは、ちょっと気になりました。

鈴木：基本的にADRのタイトルにある内容の議論が終わったら、その時点で凍結します。それに対して、例えば翌年にちょっとここの部分考え直してみようとなったときには、新たなADRを起票して、「このADRが以前の議論」みたいな感じで、参照先を記載して、新たな議論の内容を記録します。

司会者：議論が終わったら凍結するということですね。議論した、Acceptedにならない、それなら凍結する。

鈴木：そうですね。Rejectedになったら、一旦そこで凍結してっていう感じですね。1つのファイルを何度も更新するような運用はしないほうがいいとは書いてありました。

司会者：古いものをそのままではなく、新しくしていくということですね。

鈴木：そうですね。

司会者：わかりました。ほかにも「Technology RadarそのものもLADRっぽいやり方なのかな？」っていうコメントが来ています。

鈴木：あー、かもしれないですね。言われてみればそれっぽい感じ。Lightweightじゃないですけどね、Technology Radarは。あれはけっこう、コッテリと記録残していっているので。

司会者：でも重要視しているポイントは同じような感じですよね。

鈴木：そうですね。

司会者：では鈴木さん、発表ありがとうございました。

鈴木：ありがとうございました。