
2025.02.19
アルペンの“店舗の現場”までデータドリブンを浸透させる試み 生成AI×kintone活用の3つのポイント
Rust完全に理解した(嘘)_LT2(全1記事)
リンクをコピー
記事をブックマーク
刈部拓未氏:私からは「業務でRustをしれっと使う方法」について話します。私が最初にRustを触ったきっかけは、プログラミングを始めた頃にいろいろなパラダイムの言語を触ってみたいと思ったことです。スライドにある『7つの言語 7つの世界』という本を読んでいました。
この本の中にRustはありませんでしたが、言語への関心が高まっていた時に見た言語設計などの公式のドキュメントには、ちょうど仕事で触っていたSwiftが、Rustに影響を受けていると書いてあり、それでたまたま知って、興味を持つようになりました。
そのあとは、公式のドキュメントやオライリーのカニの本や、表紙に自転車が書いてあるRustの参考書などを読みながらRustで書いて勉強しました。さらに、C++で書いていた競技プログラミングをRustで書いたり、スライドの右下にある『Go言語でつくるインタプリタ』をRustに移植したりして勉強しました。
徐々に書く量が増えて、Rustを業務で使ってみたいなと思うようになり、前職までにいくつか業務でRustを取り入れてみたことが、今回の本題です。
今回は3つの話をします。1つ目は、謎のCSVコンバータを作った話です。他部署から渡される謎のCSVを自部署が使う謎のCSVに変換するためのツールをRustで書いてみました。
これは設計もなく、変換処理がベタッと書いてあるだけのCLIのツールで、公式ドキュメントを行ったり来たりしながら、なんとかコンパイルを通して動くものを作るためにひたすら書いていきました。今思うと、ひたすらコンパイルエラーを検索して、コピペするコードでした。
よかったことは、わからないことを自分で調べながらやるので、これをきっかけに外部crateの使い方やドキュメントの読み方に慣れたことです。
Rustとは関係ありませんが、この謎のCSVは恒常的に変換する必要はなく、単発だったので、特に運用に乗せることを考えずに書いて、そのまま捨てられるものだったというのも、よかったことの1つだと思います。
また、初めてきちんとしたものを作るきっかけになったので、「よくわからないけれど、とりあえずunwrap()で見なかったことにしよう」と割り切れたのはよかったと思います。
2つ目は、未完のViewerです。社内で高速な画像Viewerを作ろうという話が持ち上がった時に、検証のため作ったものです。これはWebGLをWasm(WebAssembly)経由で呼び出すため、Rustを採用して書いてみました。結局は検証で終わってしまって、本格的にプロダクトに組み込んでチームで開発しようという結論には至りませんでした。
社内の技術検証でRustを使う話をした時に、それほど反対されなかったので、このような技術検証だと、あまり反対されないのだと学びました。
結局、これは本格的な開発には至りませんでした。しかし、周りの誰もRustが書けないチームだったため、仮に本格的にプロダクトを開発するとなれば、それなりに学習コストも発生するのであまりよくない進め方だったと思っています。
3つ目は、マイクロサービスの依存関係を可視化するツールを作りました。このツールは、Terraformで書かれたAmazon SNSと、Amazon SQSの依存関係をパースして可視化するツールです。最終的なアウトプットとしては、スライドの右にあるようなグラフ構造として画像を出力します。
よかったことは、可視化されたことで依存関係が複雑化しているマイクロサービスを発見しやすくなり、社内で共有しやすくなったことです。ほかにも、2つ目のViewer開発の反省を活かして、あまりRustを書かない人に運用を強いらないように、CIには組み込まず、気になる人が気なる時に叩いて確認できる程度にした点はよかったと思います。
このツールを社内のLTで発表したのですが、SREチームの人から「HCLはJSON互換だから、JSONをパースしたほうが速いんじゃないか」と言われました。何も知らなかったのでかなり驚愕したことを覚えています。
マイクロサービスとして本当に必要だったのは、なぜ依存しているのか、また、どういう時に依存するのかという「依存している意味」だったので、これも結局あまり使われないという結末を迎えました。
結論です。社内のニッチなツールや技術検証であれば、どんな会社にもRustで作れるものがけっこうあると思います。同じ作業を繰り返しているようなトイルの撲滅にもいいですし、書き捨てられるようなものや技術検証であれば、特にハードルは低いと体感的に思いました。
ただ、プロダクトとしてRustを使う場合は、スライドに書いてあるようにかなりの責任と覚悟が必要だと思っています。これはRustに限りませんが、中途半端にツールを導入して退職すると、残される人はかなり運用がつらくなってしまうので、ある程度自分が責任を負える範囲で作るのがいいと思います。そういう意味では、Rustを仕事で使ううえでのハードルはRustそのものよりも人にあるのではないでしょうか。
学習において非常によかったことは、業務の時間にRustを書けたことです。Rustでの良い書き方を求めずに、unwrap()、unwrap()、unwrap()である程度動くものを作って、社内でフィードバックをもらいました。家に帰ってから本や公式のドキュメントを読んで、翌日また修正するというサイクルが作れたのは、非常によかったです。写経に飽きた人にはすごくおすすめです。
ということで、「自分の手の届く範囲で業務でRustをしれっと使う方法」の発表は以上です。
関連タグ:
2025.03.07
部下へのフィードバックで最初に伝える一言 何度も指摘せずに済むマネジメントの秘訣
2025.03.04
チームが協力しないのはマネジメントの問題 “協働意識”を高めるマネージャーの特徴とは?
2025.03.05
「一人前のエンジニア」になるために必要なこと 未経験からフルスタックエンジニアへの道筋
2025.01.28
適応障害→ニート→起業して1年で年収1,000万円を達成できたわけ “統計のお姉さん”サトマイ氏が語る、予想外の成功をつかめたポイント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.03
大企業で成功したマネージャーが中小企業で苦戦する理由 “指示待ち”部下を主体的に動かす方法
2025.03.05
「はい、わかりました」と返事をした部下が“かたちだけ動く”理由 主体性を引き出すマネジメントの鍵
2025.03.06
細かく指示出し、何度も確認…部下に悪影響をもたらすマネジメント 過干渉にならない「適度な管理」と任せるコツ
2015.11.24
人は食事をしないとどうなるか 餓死に至る3つのステップ
2025.03.12
新規事業を継続するかどうかを見極める2パターンの判断軸 会社の規模別「撤退基準」の設け方