20年以上運営してるメディアと周辺サービスの再設計・再構築してるから話を聞いてほしい

こんにちは！株式会社オールアバウト開発部 All Aboutリアーキテクティングプロジェクト PM（言い出しっぺ）兼エンジニアの @C058です。

2022年のアドベントカレンダーも最終日となりました。これまでのオールアバウトのカレンダーはこちら：

All About Group（株式会社オールアバウト）のカレンダー | Advent Calendar 2022 - Qiita

最終日の記事は、自称：オールアバウトで一番アツい開発をしている「All About リアーキテクティングプロジェクト」についての立ち上げと、先が見えない問題にどう立ち向かっているかを表面的に紹介したいと思います。

技術選定の話や、ガチガチのエンジニアリング話は近々どこかで公開します！（乞うご期待）

※同じ悩みを持っているPMもしくはエンジニアの方、ぜひカジュアル面談と称して情報交換しましょう！

All About リアーキテクティングプロジェクトとは

文字通り、All About (https://allabout.co.jp )の再設計（リアーキテクチャ）を行うプロジェクトです。

allabout.co.jp

All Aboutは「人々が「知らなくて損する」をなくす」ために運営しているメディアです。マネーから恋愛まで幅広いテーマで専門家の方と一緒にコンテンツ発信を行っております。

株式会社オールアバウトの主力事業であり、弊社が立ち上がったときからずっと運営を続け、 2022年12月時点ではサービス開始から21年目となりました。（今年度入社した新卒さんと同い年かと思うとなんとも言えない気持ちが止まりません。）

さて、察しの良い方ならもうお気づきでしょう。長く続くサービスでレガシー＆技術的負債がまったくないとは言えません。

これまでオールアバウトのエンジニアは時間をかけて技術的負債を返済し続けていました。記事入稿システムの刷新やオンプレミスからクラウド移行など様々な対応をする間、All About自体もPHPのバージョンアップ、DBのバージョンアップなど保守運用改善をしてきたのです。が…~~もう、限界です。~~

残すところは「All About」そのものです。

文章量の都合上、ここでは書ききれない検討を重ねた結果、約11年ぶりに本格的な技術刷新（言語からアーキテクチャもすべて見直し）をしようと決断に至りました。

All Aboutのリアーキテクティングプロジェクトのテーマは以下の通りです。

「All About」を「長く続く（ける）サービス」として「作り直す」

現在のプロジェクトステータス：技術選定が完了しました。

※詳細は後日の記事で

次のAll About は主言語をPHPからTypeScriptに変更します。

All About本体はnext.jsを採用し、BackendにNestJS +GraphQLの組み合わせで開発することに決めました。

※詳細気になる方、ぜひカジュアル面談しましょう！連絡先：株式会社オールアバウト (All About, Inc.) | Webアプリケーションエンジニア（Allaboutリビルド） | IT/Web業界の求人・中途採用情報に強い転職サイトGreen(グリーン)

ぜひ、「気になる！」or 応募で「カジュアル面談希望」と一言いただけると嬉しいです！

聞いて（読んで）欲しい話。

アドベントカレンダーに寄稿するにあたって、本プロジェクトを立ち上げから今日まで、PMとして頭を抱えたり、ひねってきた小話を紹介しようと考えていました。私自身、大規模システム刷新のような規模のPMということもあり、ありがたいことに（？）書けるネタが多かったので、今回はタイトルとあらすじをエモい感じで紹介します。

この記事になにか反応があれば詳細を今後別の記事で執筆がんばります。。。

episode1：気づいたら地雷原を歩むような開発、すべての仕様を把握した人・ドキュメントは存在しない…だ、と…？

All Aboutに出戻りしたある日、知らない機能が増えていた。増え続けた仕様をみんなは部分的にしか知らない。必要以上のようなテスト工数、それでも出てしまう考慮漏れ…。この現状を打破するにはどうしたら良いのか？ここにプロジェクトチームが立ち上がったのだ。

episode2: これはあいつが言い出した仕事、エンジニアが勝手にやってるんだ…にしないためには？どうしたら良いのだろう。

このまま事業を続けて改善するより、立ち止まりシステムの見直しを。プロジェクトメンバーは最初は2名？！とりあえず、プロジェクトを立ち上げるぞ。仲間を探し、事業チーム、仲間に現状を伝えていくにはどうしたらいいか？冒険が始まる。

episode3: 俺たちは雰囲気で技術選定をしている…？！課題を特定することからはじめてみた。

無事、新メンバーも迎えることができた。え、あ…みんな、リアーキテクチャ・技術選定はほぼ始めて！？好みだけで新しい技術は選べない気がする。よし、どんな軸で技術を選ぶべきかから始めよう。まずは事業部長に話を聞きにいこうか。

episode4: ◯年後、あの技術選定は失敗だった！にしないためにはどうしたら？

若かりし日に「この採用技術、まじで謎なんだけど。しかもなんであんな設計なの？」とぼやいていたことを思い出した。あ、これ、いつか私達も言われかねない、後続の開発者たちに同じ思いをさせたくはない...! 自分たちの~~言い訳~~ 意思決定を残すぞ！そうしてチームはADR: architecture decision recordに手を出した。今は正解か確信がなくても正解にしていくことも大事にしよう。

episode5: この選択、デメリットが気になってきた…不安な状況でチームメンバーとどう乗り越えよう？

「この選定では…実装は厳しいかもしれません…」ある朝、メンバーから告げられた。メンバーは浮かない顔をしている。一体、何があったのか…話を聞いてみよう。いまの発言、PMとエンジニア…どっちの自分が考えて話しているんだっけ？立場を明確にして判断をしていかないとプロジェクトが意図しないところで止まってしまう！！

episode6: ところで人が足りないんだけど…？採用もPMの仕事でした。

色々あった問題を乗り越えて、開発スコープ、技術選定も進んでいる。けど、これはどう考えても人が足りない、PMが手を動かすのはアンチパターンですよね？！今後の事業拡大も見えるのに、来る人を待つことはやめよう。一緒に働きたい人は自分で探す時代です。人事と一緒に作戦会議だっ！

episode7: PM兼エンジニアもコードを書きたい！でも時間を捻出することって出来るんだっけ？

技術検証、選定もおわり本格的なフェーズに入ってきた。開発スケジュールもおおよそ立って、あとは進捗を把握しながらアップデートしていくだけ。ちょっとぐらいならコードを書け…ない？！なんてこった。どうやって時間をつくり、そして気持ち・立場の折り合いをつけることはできるだろうか。※episode6と矛盾していますが書きたいんです。