2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
まず、そもそもの大前提からです。不要なものは消そうって話です。
アプリケーションに1個、複雑な部分がある。その複雑さがそのままのうちは、まだなんとかなるかもしれない。でも、例えば機能の拡張、あるいはそれのスケーリング、あとは開発環境を用意しましょうというときに、その複雑さをさらになんとかしようと思うと、もっともっと複雑になっていく。
その複雑さの理由にはいろいろあると思うんですけど、少しでも、1ミリでもシンプルで複雑じゃないほうがいい。
できる方法としては、まず、いらないファイルやクラスやライブラリは消そう。もしかすると、あってもなくてもいいかという理由で残ってるのかもしれませんが、僕は経験上、そういうものは絶対にないほうがいいと思います。まずはそれを消そう、ということが最初にできる取り組みかなと。
たまに、消すなんてもったいないって気持ちも出てきます。でも、おおよそGitを使ってると思うので、GitHubでいつでも取り戻せます。そうでない方ももしかしたらいるかもしれないですが、そのときいらないようであれば、どんどん消したほうがいいと思います。
シンプルにしていく1つ目「隠蔽しない」。これも最近あった話なんですが、CircleCIって、並列実行の仕組みがありますよね。parallelismだったかな? インスタンスを分けて実行できるという。(それで)PHPUnitを並列実行したいなと思った。
テストファイルを分割するコマンドはCircleCIで用意されている。ただこれ、分割されたファイルのリストを出してくれるんですけど、phpunitのコマンドにはそのまま渡せない。phpunit.xmlとか、設定ファイルでこのテストを実行してくださいって指定する必要がある。
つまり並列実行に必要なこととして、まずcircleciのコマンドでテストファイルを得る。そこからそれ用の、例えばXMLを生成して、そのXMLをphpunitコマンドのconfigurationというオプションで渡してやって実行する、みたいな手順が必要になってくる。
これをやろうとしたとき、最初、一連のやらなきゃいけないことを一発でやってくれるスクリプトでも書こうかなと思ったんです。すごく簡単ですよね。
でもよくよく考えると、けっこう大変なことが出てくる。phpunitにはいろんなオプションがあります。カバレッジを出すかどうかとか。状況によって違ったりします。
あと、circleciのコマンドを含めてしまうと、ローカルで検証しにくい。CircleCIをローカルで動かすライブラリも提供されているんですが、完全に再現できるわけではないみたいなので、あまり良い方法ではないと思います。
またRich Hickeyのプレゼンテーションの引用ですが「抽象化とは隠蔽することではありません。ただ隠すだけでは、なんの役にも立ちません」とはっきり言っています。
じゃあどうしようかと思って、僕らは、PHPUnit用の、XMLを作るだけのスクリプトを書きました。
ほかの部分はそれぞれでちゃんと書いて、使い方としてCircleCIのテストのファイルを分割します。それを使ってXMLを作り、そのXMLを使ってPHPUnitを実行します。これはCircleCIに書いてあるものです。
何がいいかというと、(実際の)書く量は増えているんですけど、例えばリポジトリに全部のテストを実行するphpunit.xmlがあって、それをもとに生成するので、ほかの項目の環境変数とか、あとグローバル変数をどうするかなどを変更しても、差分が発生しないんです。
circleciのコマンドやphpunitのコマンドには、自由にオプションを渡せる。かつ、一番いいところは、ローカルでちゃんと検証ができる。このへんはQiitaに書いたので、詳しいことは見てみてください。これがまず1つ目です。
2つ目「まとめない」。
先ほど紹介した「北欧、暮らしの道具店」というECサイト、これはいくつかのアプリケーションから成り立っています。表側に2つと、裏側に管理用の画面のアプリケーションがあって、それらが組み合わさって動いているサービスです。
これらには共通する処理があるので、lumen-modulesという、共通の処理をまとめるライブラリを作っていました。この名前、スライドには歴史的経緯によるって書いたんですけど(笑)、正確にいえば、僕が入社する前からあったものなので由来はわからないです。なんとなくわかる気もしますけど。
これを1つ、独立したリポジトリに分けて、Composerでそれぞれのアプリケーションがそれに依存するというかたちで運用していました。確かに共通する処理がまとめられていれば、その部分に関する変更はlumen-modulesを変更するだけでよくなるので、楽というか、合理的な面もありました。
しかし、きれいに分割できてたらよかったんですが、共通化する部分だけを抽象化してきちんと分けられていたわけではなかった。
本当に共通する部分はあったとしても、共通していないところもlumen-modulesに入れなければいけない。クラスの依存関係とか、lumen-modules内でテストを実行しようとするときに必要になる部分が含まれている、という状態になっていたんですね。
こういうものを運用していくと、結局、(1つのアプリケーションで)ぜんぜん共通してないところだけど、このリポジトリを触らないといけない部分を変更する必要があるときに、各アプリケーションが依存しているせいで、最新版に保つために各アプリケーションでcomposer updateを実行するという手間があったり。
関係ないはずのアプリケーションのほうでなぜかテストが落ちることもあって、まあまあ開発の足を引っ張っている状況がありました。
『マイクロサービスアーキテクチャ』の本に「サービス間の結合が多すぎることによる害は、コードの重複が引き起こす問題よりもはるかに悪くなります」と書いてあって、あ、これのことや! ってすごく思いました。
結局どうしたかというと、分割することにしました。
さっきのlumen-modulesというモジュールに入っていたコードを、多少のコードの重複があったとしても、各アプリケーション内に含めるようにしました。
構成上どうしても共通にしておく必要があったmigrationsとseedsのところだけ残して。まあこれ自体もどうかなってところはあるんですけど、さっきよりはだいぶシンプルになりました。
かつ、さっきありました変更があるアプリケーションではうまくいくけど、ほかのアプリケーションではうまくいかないということを防ぐために、CircleCIでかなりがんばっているのですが、こいつに依存しているすべてのアプリケーションのコードを引っ張ってきて、それらのテストを実行して初めてマスターにマージできるみたいな仕組みにしました。
これが2つ目です。
シンプルにしていこうという話の3つ目、「作りすぎない」。さっき紹介したように、僕らのアプリケーションは複数に分かれています。
厳密にはマイクロサービスではないですが。
何が問題かって、開発環境の構築がすっごく面倒くさい。会社に入ったとき、途方に暮れるくらいびっくりしました。そんな状況でhokuoukurashi-dev-envというものを作って、最初は自分用だったんですけど、今は開発のチームみんなで使うようにしています。
これは、すべてのアプリケーションの開発環境を一度に立ち上げられるというもので、ただのdocker-compose.ymlとか、必要なDockerfileとかが入ってるだけです。とくにスクリプトとかを書いているわけではありません。僕はそれでいいと思ってたんです。
そしたら同僚が「一緒に立ち上げられるのは便利だから、各アプリケーションのセットアップや、アセットのビルドとか、ほかの大変なやつも一発でできるように作ろう」って言ってきたんです。でも僕は、それにすごく抵抗があった。
例えば、Aというアプリケーションのセットアップ手順が変わったら、そのスクリプトも追従するのか? アセットのビルドにも、ホットモジュールリプレイスメントとか、いろんなパターンがありますよね。それもオプションで渡すの? というようなことを考えると、なんだかなと思った。
そのへんをどうやって伝えようかと思ったときに、コレコレがなにかを複雑にすることを「〇〇をコンプレクトする」という言葉で説明するといいんじゃないかなと。(Rich Hickeyの)プレゼンテーションにあったんですけど。「それコンプレクトするんじゃないの?」って、便利ですよね。
今日の話を踏まえると「それ、創味のつゆになってるんじゃないですか?」って言い方が使えるかな。
(会場笑)
結局、どうしたか。スクリプトを書くのだけはどうしても嫌だったので、スクリプトよりはメンテが容易なREADMEを書きました。
容易というか、動作確認とかはそれぞれのアプリケーションの手順を書くだけだし、その手順自体はそれぞれのアプリケーションで確かめられるというイメージです。
READMEをとにかく書く。いいところとしては、いろんな手順が隠蔽されない。さっきの「隠蔽しない」ですね。そして、これだけダーって書いたら、そんなに複雑なセットアップ手順がそもそも問題だということに気づくわけです。じゃあそこを直していこうという気持ちにもなれる、と思います。
まとめです。
SimpleとEasyは違う。ちゃんと区別して考える。Easyを選ばなければいけないときはあるけれど、それはトレードオフであって、なにかを犠牲にしている。
そこをちゃんと認識したうえで、できればSimpleを選択したい。自動的にシンプルになるわけではないです。選びとっていきたい。できるところから、SimpleにしていけるところはSimpleにしていこう、というふうにやっていきたいと思っています。
僕らが作っている「北欧、暮らしの道具店」というサイトも、ECだと思っていたらいきなり短編ドラマを作り始めたり、どんどん変わっていくわけですね。
これに対して、僕らはどう対応していくか。
もちろん(新しいコンテンツは)楽しい話なので歓迎ではあるんですけど、システムを作る人間として、それに対応していかなければいけない。Simpleにしていくのも、なかなか終わらない道です。結局、Laravel MixはWebpackへ移行しようかなと考えています。
知ってる人、いますかね? 昔、日産MOCOというCMで「あなたはあなたが選んだものでできている」というコピーがありました。
言い替えるのであれば「あなたが作ったものは、あなたが選んだものでできている」。こういうふうにするかしないかはあなたの選択ですよ、ということを肝に銘じて、仕事していきたいと思います。
以上です。ご清聴ありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには