こんにちは、エンジニアリングマネージャーの 
id:onk です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの 
id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:onkが担当する第12回のゲストは、株式会社Flatt Securityでセキュリティエンジニアとして活躍する
id:akiymさんこと、秋山卓巳さんです。
2017年にはてなに新卒で開発エンジニアとして入社し、受託系のWeb開発などを中心にご活躍いただきました。
2021年にはてなを卒業後、2021年9月、株式会社Flatt Securityに入社し、セキュリティエンジニアとして、主にWebアプリケーション診断やFirebase診断などのセキュリティ診断を担当しています。内製開発のセキュリティ診断プラットフォーム「ORCAs」などの社内ツールの開発も行っているid:akiymさんの現在のご活躍、はてなを離れてみての印象など、いろいろお話を伺いました。
秋山卓巳さん（
2017年～2021年 はてな在籍
X：https://x.com/akiym
Blog：https://blog.akiym.com/
- 独自スタイルのセキュリティ診断を行う「Flatt Security」でセキュリティエンジニアとして活躍
- 「YAPC::Hakodate」で語ったセキュリティエンジニアの歩き方
- 開発者向けに、再現手順を伝える報告書を書く
- はてなに入社する前は何をしていた？
- はてなでは、Perlを書きまくる
- はてなのテックリードとして、GraphQLへの移行を進めた頃の思い出
- はてなで印象的だったこと
- 今のはてなに思うことは？
独自スタイルのセキュリティ診断を行う「Flatt Security」でセキュリティエンジニアとして活躍
id:onk（以下「」）今回のゲストは、株式会社Flatt Securityのセキュリティエンジニア、id:akiymさんです。よろしくお願いします。まずは、id:akiymさんの現在の仕事内容から聞かせてください。
id:akiym（以下「」）今はセキュリティ診断を専門とするFlatt Securityという企業の、プロフェッショナルサービス事業部という部署に所属し、セキュリティエンジニアとして働いています。
Webアプリケーション開発をしているとあまりなじみがないので、まずセキュリティエンジニアとはどのような職種なのか、説明してもらっていいですか？
セキュリティエンジニアといっても結構幅広いのですが、自分の担当している事業部では、いわゆる脆弱性診断と呼ばれるようなアプリケーションやパブリッククラウドなどのレイヤーのリスクを報告するセキュリティ診断を実施しています。そのセキュリティ診断をセキュリティエンジニアとして担当しています。
akiymさんはそれだけじゃなく、簡単な脆弱性診断ではない、難しい脆弱性診断を担当していると、以前に伺ったような気がします。
そうですね。とはいえ、完全に簡単な業務しか担当しない人と難しい脆弱性診断を担当する人という分け方ではなく、「基本的に全体をみんなができたらいいだろう」といった考え方をしています。
例えば、スマホだけの担当みたいな分業制ではなく、みんなが全体を見られたらいいなというところをやっているのがメインなんですね。なので、セキュリティ診断に関係するものがやってきたら、とりあえず何でもやるといった感じですね。
どういう診断依頼が来ることが多いんですか？
いろいろあるんですけど、一般的なのはWebアプリケーションですね。例えば、RESTのAPIであったりとか、たまにGraphQLみたいなものもあったりします。それ以外だと、Firebaseで使われているセキュリティルール部分を見るといったこともありますね。
その中で、クラウドの構成をチェックしたり、Webアプリに動的スキャンをかけたりするようなアプリケーションも作っていますよね。
それは僕とは違う感じの部署なんですけど、「Shisho Cloud」というサービスがありますね。
「Shisho Cloud」を開発している 
id:pizzacat83さんも 2022 年のはてなインターンにいらしてましたよね。何か関わりはあるんですか？
基本的には分けているんですけど、診断という単位では同じお客様から受注するといったケースもあります。「例えば、Shisho Cloudで、こういった部分もできますよ」というように一緒に提案することもあるので、一緒に進んでいくっていう形では似ていますね。
ただ僕が開発を担当してはいなくて、サービスとして一緒に提案・提供しているスタイルです。
なるほど。セキュリティテストの案件って、何人くらいで行うんですか？
案件の規模にもよりますが、本当に小さいものだったら、一人で数週間くらいというのもあります。多いものは分担が大変なので2～3人とか、大規模案件だと4人とか、そのくらいの規模ですね。
4人でテストしなきゃいけないセキュリティ診断のイメージがつかないです。
分担する場合は、エンドポイント単位での診断みたいなものが多いので、機能ごとにエンドポイント単位で振り分けて、どんどん消化していくイメージですね。例えば、「ユーザーが触る機能だったら、〇〇が担当」「投稿系の機能だったら、〇〇が担当」という感じです。
インタビュー（以下、Flatt Security 採用ページに掲載された akiymさんのインタビュー記事）でも毎回同じ仕事はないですって書かれていましたけど、本当にそんなに毎回バラバラな感じになるんですか？
そうですね。使われている技術にもよりますが、会社によって扱うサービスの機能もコードも異なるので、全然違いますね。
もともとセキュリティにずっと興味があって、CTF（Capture The Flag・サイバーセキュリティのスキルを競うイベント）とかもされていたんですよね。はてなというWebアプリケーションを開発する会社に入って、それからセキュリティエンジニアになったというキャリアの変遷をしていますけど、セキュリティエンジニアになってみてどうですか？一番聞いてみたかったところです。
新卒で就職するときに、セキュリティエンジニアを選ぶ道もあったとは思っています。ただ脆弱性診断って、スキャンを回して、ツールを使って、とりあえずやるみたいな形を想像して、それを続けていくと飽きが来るんじゃないかなって気もしたんです。
いわゆるブラックボックスなエンドポイント単位しか与えられてない状態で、パラメーターをいろいろいじって試しまくることをやっていても、そんなに面白くないんじゃないかなと。そういった意味で、最初は開発エンジニアの方が面白そうだなと思って選びました。
でも、いろいろ進めていく上で、開発者的な目線から見ていると、診断にはいろいろなスタイルがあることに気づいてきたんです。例えば、ソースコードを読んで診断を進めるみたいなことができたらすごく面白そうだなと思いました。
Flatt Securityでは、そういう診断をやっていることや、開発者的な視点や経験を活かせると思い、セキュリティエンジニアになりました。
実際やってみていかがですか？
めちゃくちゃ面白いですね。開発エンジニアの経験がすごく活きている気がします。やっぱり新卒でセキュリティエンジニアスタートよりも、ソフトウェアエンジニアスタートの経験値がすごく活かせています。
「こういう修正をしたらいい」というケースも、ソフトウェアエンジニアなら経験値からわかることも、完全にセキュリティエンジニアスタートだとだったら、経験上わからない場合ってあると思うので。そうした経験を活かせるのは、すごく楽しいなと思いますね。
技術としては、セキュリティエンジニアとWebアプリケーションエンジニアで、そんなに差はない気はするんですけど、どんな差があるんですか？
どういう実装をしたらダメなのかみたいなところを判断していくところですね。なので、いわゆるエンジニアのコードレビューを、以前より少し広くやっています。
コードレビューは局所的というか、一つのプロジェクトに対して見ていく部分がありますが、セキュリティエンジニアが脆弱性診断をやる場合は、全体的に見るみたいな部分もあるんですね。経験的にこういったところが怪しいから、部分的に深掘りして、見つけていく。
どれだけリスクとして深刻になる部分を探していくか、というところで少し違いはあるという気がします。
「YAPC::Hakodate」で語ったセキュリティエンジニアの歩き方
YAPC::Hakodateでのトークも、セキュリティの入り口に関する話でしたね。そこで何か考えたこととかあれば聞かせてください。
様々な診断をしていく仕事ですけど、いろいろ考慮すべきところは広くあるなと考えています。実際に診断でどういったところを見ているのかを分析してみると、例えば、フレームワークによって見るべきところが違うなど、思っていたより広い部分もあるんですね。
そういったところを散りばめられていくと、かなり面白いんじゃないかと思い、資料を作りました。ちょっとマイナーなネタを仕込んだり、実はこういったところも見ないといけないといったネタを紹介しました。そういったところを、知ってもらえたら嬉しいと思いながら発表しました。
たしかに、これらの一つでも見逃すと脆弱性になるというのはしんどいなと、見ていて思いましたね。多層防御が重要って言いますけど、ミスると裏まで通ってしまうのも辛いですよね。
こうした知識は仕事で見つけたものがベースだったり、一般的な情報や書籍などから得ているんですか？
そうですね。一般的な情報がベースではあるんですけど、普通に仕事でフレームワークなどを調べていく上で、発見するっていう部分もあるので、一般的なものが大きいですね。
すごいな。本当に数年間でいろんなフレームワークを読めるようになっているんですね。
もともとRubyとかRailsなどは、全く触ってなかったんですけど、最近仕事で使うようになって、結構いいなという気持ちになってきています。
見ていくフレームワークの割合は、世の中で使われている割合と同じだったりするんですよね。何か面白かった出来事とかありますか？
お客様の話になってしまうので、言えないことが多いと思いますが、見つけた脆弱性について、フレームワーク側で対応すべきだと報告したりするケースもあるのでしょうか。
YAPCで発表したAWSのSDKのGoバージョンで、パストラバーサルができてしまったケ－ス。あれは、報告はしたんですけど、もともとこういう仕様なのでV2を使ってくれって、返ってきたので。世の中には、そういったこともありますね。
開発者向けに、再現手順を伝える報告書を書く
Flatt Securityさんでの仕事で、akiymさんがほかにもおもしろさを感じていることなどあれば聞きたいです。
開発者向けの報告書を書くことですかね。結局、セキュリティ診断をして結果を伝えても、一方的になりがちみたいなところもあると感じています。
では、「どうやって修正したらいいんですか？」という質問に対しても、例えば、「XSSの対策であれば、エスケープしてください」みたいな一般的な修正方法しか伝えられていないんですね。
じゃあ、大量にエスケープしてない箇所があったら、「抜け漏れをしないために全部エスケープするんですか？」といったことになってしまうので、現実的に考えてどんな対策がいいのか、アプリケーションに合わせていろいろ報告書に書いています。
あと面白いのは、再現手順です。一般的な報告書では、「こういった脆弱性があったら、こういうふうに攻撃されますよね」という状況に対して、「このボタンをクリックして」「ここに入力して」「プロキシーツールを使ってリクエストを書き換えて」というように書かれることが多いんですね。
それをFlatt Securityでは、DevToolsを開いて、このコンソールにJavaScriptをコピーペーストしてもらうと、全部一気に手順が動くといったことをやっています。開発者的にも、再現がしやすいみたいなところを、重点的に考えてやっている傾向がありますね。
面白い。そういう形で返ってくるんですね。それ、以前からやっていたんですか？
以前からちょこちょこやってはいたんですけど、僕が入社してから、「本格的にこういったふうにJavaScriptを書くといいですよ」といった感じで、社内に展開して進めていった結果、ほぼ全てのレポートで再現するようになりましたね。
脆弱性診断周りの技術の進歩というのを、あんまり聞いたことがなかったから本当に興味深いです。
他には、脆弱性診断を効率化する内製のプラットフォームを作っていて、それもおもしろいですね。業務時間内で時間が余ったときに改善したりもしています。どういうプラットフォームなのかというと、脆弱性診断のどこを誰が担当して、どういった観点で見たかを記録するものです。それをやっていかないと、漏れる可能性があるからです。
そういったところをWebアプリケーション化して、完全に管理してくれると、みんなが手軽に使えるし、かなり効率的に回せます。例えば、Slackと連携したり、診断員が複数いるパターンに対応できたりなど、いろいろな機能を作っています。
Webアプリケーションの開発だとRedmineを使ったり、Asanaを使ったりしますが、そういう内製ツールがあるんですか。
AsanaやJiraなどもあると思うんですけど、やりたいことに合わないというか。報告書も形式化されたもので、最終的にPDFとして書き出したいものもありますし、レビューをしたいものもあるんですよね。
そういったものを管理するには、自分たちで作らないといい形のものはできないんじゃないかと考えて、わざわざ工数をかけて作っています。その分の効率はすごく感じていて、逆に、それがないともう診断が回せないくらいの依存をしています。
これは入社前からあったんですか？
入社前からありました。最近では人数が増えてきたので、アサインする案件の担当者が誰なのかを手動で管理していたのですが、それが回らなくなってきたんです。そこで、この機能を作りました。いわゆるこのチャートで、誰がアサインされているかを管理・可視化できるようになりました。
めちゃめちゃ面白い。自分たちの業務で内製化する判断って、なかなかできないなと思うのですが、Jiraのカスタマイズじゃなくて、内製で実現するのはすごいですね。時間があるとそこにコミットしているってことなんですね。
そうですね。完全に全部自分で作っています。
セキュリティテストのドメインの話など、意外な話がいろいろ興味深いですね。
とはいえ、内部で持っている診断項目に対して、テストできたかといったところをチェック入れていくかんじで、一応見られるようになっていますね。
はてなに入社する前は何をしていた？
はてなに入る前の話を聞きたいです。akiymさんがはてなに入ったときに、「Hokkaido.pmの高校生が来た！」って、社内で騒がれていたんです。コミュニティに出たり、そもそもコードを書き始めたのって、いつぐらいからなんですか？
HTMLを書き出したのは、小学生ぐらいの時からですね。それからinfoseek iswebでCGIを動かしていたのが最初です。その頃って、Perlがすごく活発で発信していた人もいろいろいましたね。Perlが絶対面白いなと思って、Perlから始まったかんじです。
そして、Hokkaido.pmに参加しに行ったと。この時にはもうPerlにかなり詳しい状態でコミュニティに来たんで、教える必要なかった。そんな話を見た気がします。
でも、最初の頃はそんなにめちゃくちゃコードを書いていたわけではないので、ミーハーな感じで触っていました。配布されているCGIをコピペして、ちょっと変えるくらいしかできなかった気がします。
そもそもコミュニティというものがあることを知ったのって、どういうきっかけなんですか？
多分、SNSやブログなどで見かけたのが、最初だとは思うんですよね。僕がHokkaido.pmに行っていた当時は、Hokkaido.pmだけではなくて、地方のPMやShibuya.pmとかも活発だった時代だったので。
インターネットでHokkaido.pmという、めっちゃくちゃ近くでやっているのもあることを知って、ちょっと行ってみようって感じで行った気がしますね。
CTFも、高校の時には参加していますよね。中学くらいからやっていたんですか？
高校生の時はちゃんとはやってなかったですね。本格的にやり始めたのは、大学生くらいになってからです。そもそも、高校生の時は、そういったものがあること自体、全然知らなかったです。
SECCONに行って知ったんでしたっけ？
もともとは、シマンテックさんがやっているサイバーセキュリティ・チャレンジというイベントに参加したのが最初のきっかけです。脆弱性のあるWindowsアプリケーションを渡されて、どういったところがダメなのかを見つけてレポートを書くイベントがあったんです。
それに応募したら入賞して、東京に呼ばれたんですよね。当時は、高校3年生だったと思うんですけど、懇親会で「CTFというものがあるよ」と聞いて、そういう世界もあるんだと知りました。セキュリティでやる競技もあることを知ったのが、きっかけでしたね。
でも、CTFやり始めてからはプレイヤーとしてもそうですけど、作問側でもしっかりがっつりやっていますよね。はてなの朝会で聞いた記憶があります。
最近は全然時間が取れてないのですが、大学生ぐらいの時は結構やっていましたね。そこで現取締役CTOの米内に出会った経緯で、今Flatt Securityにいます。
はてなでは、Perlを書きまくる
では、はてなでの仕事の話に入っていきましょう。はてなでまず配属されたのがマンガチームで、ここでずっとPerlを書いていたんですよね。その後、ゲームチームに異動して、ノベルチーム、サービスプラットフォームチームといった変遷だったと思います。
インターンの頃も含めると、最初にブログチームにもいましたね。インターンの時にやったのは、引用機能の実装などです。今も引用したところに引用アイコンが出る機能があるんですけど、あれはインターンの時に作ったやつですね。
マンガチームに入った直後からは、Test2を導入したり、YAPCで登壇したりしていますよね。
そうですね。当時、普通に業務でコードを書くと、テストを書くという比重が大きいなという課題があって、テストを書くときは、効率的に書きたいというか、いろいろなモジュールを組み合わせてテストを便利にしていたところもあったんですけど、完全に整理されている状態ではなかったんです。
そうした中で、Test2のことを知って試してみたら、意外と使い勝手がすごく良かったんです。マンガチームで導入したら、めっちゃいいじゃんっていうことで、上手く導入できました。YAPCでも発表できて、すごく良かったですね。
社内のテストを全部、Test2に書き換えてまわるのは大変だったけど、導入できてよかったなと思っています。そして、もう一つ書き換えて回ったのは、Smart::ArgsからSmart::Args::TypeTiny。
個人で書いていた時はSmart::Argsは使ってなかったんですよね。はてなに入って、めちゃくちゃSmart::Argsが使われていることもあって、使ってみたらその使い勝手にハマりまくりました。
ただSmart::Args単体だと、ある程度寛容に書けるというか、引数をたくさん書いても怒られないといったところがあって、たまにテストで使われている部分に不要なコードがあったりもしたんですね。そこで、Smart::Args::TypeTinyを書いたという経緯がありました。
マンガチームに導入するときは、だいたいドロップ・インレプレイスメントになっているんだけど、数百ファイル書き換えなきゃいけないっていうのを、えいってやっていて、進め方も面白かったなと思っていましたよ。
インターフェース的には同じなので、文字列の置き換えでできました。あとは普通に引数を無駄に渡しているところなどは、テストを動かすと教えてくれるので、そういったところをちまちま直していったみたいな感じですね。
この頃の働き方って、何か大きな変更を入れるぞって思い立ったら、ついカッとなってやったみたいなのが多かった気がするんですけど。
そうですね。でも、あまり大きい変更を入れるぞっていう気持ちでもなくて。とりあえず、絶対使い勝手は良くなるから、空いた時間に進めたことを積み重ねていったような記憶はありますね。
そうだったんだ。利用者的には大きな変更だと思っていました。他にグッと使い勝手が良くなったものだと、APISchema::YAMLは開発体験がガラッと変わりました。APISchemaのスキーマ定義を YAML で書くように変えた社内ライブラリですね。
もともとは独自のPerlで書かれたDSLから生成できるんですけど、ちょっと手で書くには量が多かったんです。APIの規模的にも、パラメーターなども含めて、もうちょっと楽に書けるのではないかなと、いろいろ考えていたところ、自分で作った方が早いと思い、作ったというかんじです。
この辺は、世の中のエコシステムが、OpenAPIのスキーマをそのまま食わせれば動くものが一般的だったと思うけど、そうじゃなくて、PerlのDSLになっていた。そこからまた別のYAMLにしたことで、スマホクライアント用の実装も作りやすくなった、みたいな感じですよね。
当時はOpenAPIからPerlのクライアントや、スマホのクライアント用のコードを吐き出すところも使い勝手が悪くて。スマホの実装をした方とも話していたんですけど、それなら自分で書いた方が絶対使い勝手はいいという話になって、自分で実装することにしました。
なるほど。本体側を触るより、自分で一から書き直す方が多いのは、なんかPerlの文化ですね。
たしかに、そんな気はします。今それをやろうとしたら、一旦考えてみようという感じです(笑)。メンテナンスとかを考えると、どうなんだっていう感じで、止めるかもしれないんですけど。当時はやっぱり速度が命だったので、良かった部分ではあったという気はします。
といった感じでどんどん使い勝手を良くしていましたが、Flatt Securityさんとはてなの働き方の違いみたいなのって、何かあったりします？
そんなに違いはない感じはしますね。コードの書き方というか、リファクタリングするのがすごい好きなんですよね。ちょっとでも一貫性があった方がコードは書きやすいとは思うので、そういった意味でも、一貫性がない部分を見つけたら、直したいみたいなところがあって。マンガチームにいた時も、そういったのがあったんだと思います。
ちょっとプルリクを投げるか、みたいなところはあるんですけど、今でもその気持ちは変わってなくて。ちょっと暇になったらリファクタリングするみたいなことを、繰り返していますね。
はてなのテックリードとして、GraphQLへの移行を進めた頃の思い出
「魔法のiらんど」の移行チームに異動した頃は、テックリードとして「GraphQLで行くぞ」ってどんどん決めて、移行していましたけど、この頃の思い出はあります？
大きめのサービスで使われるGraphQLスキーマを設計したことが、それまで経験してきた中で初めての規模でした。そういった意味で、GraphQLの設計でどういった機能を作るのか、真剣に考えることができました。そこは良かったなと思います。
id:yigarashiさんが途中で入ってきてくれて、スキーマを最初から全部、設計して考えて、2人で作っていたんですけど、そのスキーマのおかげで分担しやすくなりました。あの経験はすごい良かったですね。
マンガの頃はもうスキーマはあったからもう自然と先に分担できていたけど、「魔法のiらんど」はまずスキーマを考えなきゃいけなかったのか。
その頃って、画面ごとに合わせたREST APIみたいなのを作っていくのを、マンガチームではやっていたんですよね。そういった意味では、一人だったらイチからAPIを作っていけばいい感じに、テンプレートも一緒に作ってやると進められるって気はするんですけど、複数人になると、どこかで止まってしまう。このAPIを実装しないと、これができないみたいなかんじですね。
そういった意味では、「こういうスキーマがあれば、こういう分担ができる」ということに気づけたみたいなところはありましたね。
スキーマ駆動で開発するメリットを実感できたのは良い体験ですね。
はてなで印象的だったこと
はてなでは社内のチームをいろいろ見てきたし、Flatt Securityさんに行ってからもいくつか見てると思うんですけど、この辺が特徴だったというのはありますか？
今って、チームで開発を進めていくという感じではなくて、案件を時には一人でコツコツ進めていくみたいな感じなんですよね。なので、はてなでやっていたチーム開発とは、全く別の感じになっている気がしますね。
チーム作りとか、どう変わるんですか？
そもそもチーム作りすらもない感じで、本当に一人で進めるっていうところもあるんですよね。なんでかというと、診断の案件って、1週間とか2週間とか、そういう単位でやっていくので、固定化されてないんです。
もちろん、案件以外で交流するっていうのはあるんですけど、仕事で一緒になるっていうのはそんなにないんですよね。
今のはてなに思うことは？
最後に定番の質問になるんですけど、今のはてなを見ていて、思うことを聞きたいです。
新サービスが出るのは、元はてなとしては、すごく嬉しい気持ちにはなるんですけど、既存のサービス、例えばプラットフォーム側で多要素認証とかパスキー対応みたいなところも地道に進めているみたいなところも見ています。
もともとサービスプラットフォームチームにいたので、既存サービスに手を入れている様子が見れて、個人的にはすごく嬉しいですね。
あのあたりは、新しくGoでマイクロサービスとして切り出して作ったんですよね。その過程で、PerlとGoをうまく相互にやり取りしなきゃいけなくなって。もともとPerlの頃はTheSchwartzっていう、akiymさんがメンテナンスしているものですね。
このTheSchwartzというジョブキューでは引数をシリアライズするときにPerlのStorableでバイナリにシリアライズするんですよね。これをGoからパースして、PerlでシリアライズしたものをGoでデシリアライズするということをやって移行しました。
すごいですね。
単純に、多要素認証を今入れるのでは、ちょっと遅すぎるので、もう一個進めてパスキーまで行きました。マイクロサービスとして切り出すときに、時流に乗っている機能を入れ込めたのはとても良かったですね。
悪い部分はそんなに思いつかないんですが、いい部分でいうと、前回の
id:itchynyさんの記事にもあった社内グループウェアが活発だってことですね。テキスト文化はすごいいい文化だったなと思っています。
なるほど。akiymさんの「チラシの裏宣言」話題になっていましたね。
はてなエンジニアのいる社内のグループウェアでいろいろ投稿していくと、みんながツッコミを入れるみたいな、そういうエンジニア的なSlackのチャンネルが、普通に世の中の会社にあるんじゃないかなと思っていたら、意外となくて。そういう部分が外により出てくると、個人的には嬉しいなと思って始めました。
発信はすればするほどいいし、はてなはたぶんエンジニアっぽいことは全部、エンジニアのところに流したらいいじゃん、みたいな、そんなノリで始めていますよね。
はてなはそうですよね、もっと文化の違いでいうと、Slackのスレッドを使う人が結構多くて。限られた人数の中で共有できるみたいなところは、メリットとしてあると思うんですけど。そこがリスクでもあるとは思うんですよね。大きく発信しすぎなければ、そんな変なことにはならない。とにかく外に全部出してくれという気持ちで、そういう感じでやっていますね。
はてなへの期待で言うと、やっぱりPerlを使い続けていく会社ではあると思うので、既存サービスとかもそうですし。もちろん、Perlから移行するっていう部分もあると思うんですけど、Perl軸の発信という意味でも活発になってほしいです。
例えば、使っているモジュールのメンテナンスをちまちま進めるみたいなところから発信とかしてもらえると、すごく嬉しいです。
YAPC::Hakodateでも、Perl 5.40まで上げていく、モダンな書き方にどんどん書き換えていますという発表しました。10何年かけて書いてきたPerlプロダクトを1年やそこらですべて置き換えるのは無理なので、上手く付き合っていきます。この過程も公開していくので、期待していてください。
今日はありがとうございました。
id:akiymさんこと秋山さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2025年1月頃更新予定、担当はid:onishiです。
id:onk
2018年4月 中途入社(3社目)。アプリケーションエンジニアとしてマンガビューワ「GigaViewer」や、Web小説サイト「カクヨム」「魔法のiらんど」の開発を担当。2019年4月よりチーフエンジニアとして技術組織全体のマネジメントにも携わる。
Twitter: @onk
GitHub: onk
blog: id:onk のはてなブログ
