Amebaの中堅・ベテランエンジニアが語る、サーバーサイドエンジニアのリアルな現場

17年も経ってますからね〜（笑）。AmebaってPCブログから立ち上がったんですよ。その後、スマートフォンプラットフォームがサービスのハブになって、その下に色々なサービスが出来ました。事業の変遷を経て、今はブログメインになってますね。

事業の成長スピードにシステムの整理が追いついていないのが現状ですね。事業的にはブログ中心に力を入れて売り上げを上げていこうとなっているのに、システム的に保守しなきゃいけない範囲はブログ以外にもたくさんあるんです。事業的にリソースを割くべきところと、システム的にリソースを割かなきゃいけないところがずれてるんです。

技術の多様さですね。事業の成長に合わせてチームの統廃合を繰り返して、今はAmebaのサーバーサイドチームは一つになりました。でも、チームの統廃合の過程で各チームの技術選定がバラバラだったんです。各チームリーダーが、「最近この技術きてるから使おう！」って言えば、その技術が採用されてたんですよ。

統一的な技術選定が出来ていなかったので、過去のシステムを保守するためのキャッチアップの工数が大きいんですよ。一つ隣のチームのシステムを見ると、言語も違うしクラウドかオンプレミスかも違うみたいなことがありますね。

そうですね。

分かってませんでした（笑）。というのも、私が配属された時はチーム体制が今とは異なっていて、Amebaではなくブログのサーバーサイドチームという括りだったんです。

はい。たしかにキャッチアップしていくと、ドキュメントが最新じゃなかったり、フレームワークが遅れているなと思うことはありますね。

難しい問題ですね。システムの刷新などで一時的に、「統一的にやっていくぞ！」という動きは作れてると思います。だけど、長期的に見て継続メンテナンスできるようなドキュメントの整備とかは、各々の目線を合わせられてるかというと、そうではないですね。

課題を感じるのが、ドキュメントを読むときであって、書くときでは無いというずれも結構ありますよね。ちゃんとした知見を得たらそれに満足しちゃって、ドキュメントには還元しないまま放置されちゃうっていうのは、どの組織でもよくあることですからね。オンボーディングとかで新しく入ってくる人たちが、「このドキュメント古くない？」となるのは申し訳ないですね。

動機付けをしてあげられていないんですよね。最近このツイートを見たんですけど。

ハッとしましたね（笑）。たしかに新機能のリリースのタイミング、技術構成の変更のタイミングで、その都度ドキュメントの更新してるかなーと自問自答しました。

たしかにそうですね。インシデント対応とかが当てはまるかもしれないですね。Amebaでは保守しなきゃいけないシステムの数が多いのに加えて、そのシステムを見れる人が少ないんですよね。だからインシデント対応も特定の人に偏っちゃうんですよね。

そうなんです。一旦は週替わりの担当が対応にあたって、インシデントの対応から終了までに責任を持つようにしました。障害復旧時間を可視化しつつ、みんなで協力して対応しましょうという取り組みですね。

大きいものとしては、老朽化した大規模システムのAWS移行・刷新プロジェクトを行っています。また、開発プロセスの指標を可視化して、長期的・根本的な生産性改善を目指した10xプロジェクトも進行中ですね。

まだまだ課題はたくさんあるけど、それらを綺麗にしていくことに快感を覚える人がいいですね。あまりメンテナンスされてなくて、仕様を理解するのが難しいシステムとかいっぱいあるけど、それをポジティブに捉えられる人は、ずっと楽しく仕事できると思います。

目の前にある壁に向かって一緒に頑張ってくれる人ですかね。特に新卒の方とかAmebaの広大なシステムを見ると、腰が引けちゃう人っていっぱいいると思うんです。それでも壁を乗り越えることにやりがいを見出せる人は働きやすいと思います。