株式会社PR TIMES 執行役員CTOの@catatsuyこと金子です。
今年の4月に私が執行役員CTOに就任してから8ヶ月が過ぎ、2021年が終わろうとしています。
私が入社してから様々な変化が起こりました。今回は社内で起こった変化について振り返っていきたいと思います。本当に色々あるので雑多な記事になりそうですが、ご容赦ください。
3つの成果指標の進捗
このブログの最初の記事は私が書いたものです。以下の3つの成果指標を掲げていました。
- システム全体のセキュリティ向上
- マイクロサービス化を進めてモノリスの責務を減らす
- モノリスのレガシー改善
これらについてどうなったのか、赤裸々に書いていきます。
システム全体のセキュリティ向上
セキュリティ向上について大きかったのは発表前情報の不正アクセスがあったことです。セキュリティ向上を進めようとした矢先の出来事でした。
本件は実装に漏れがあった状態で放置してしまっていました。お客様に多大な迷惑をかける前に防ぐことができず、申し訳ございませんでした。
今回の事象が発覚してすぐに総点検・改修プロジェクトが開始され、調査と改修を行っていきました。
こういったことが起こった時にすぐに調査できるようにBigQueryの導入を進めていたり、リファクタリングデーの設定により古いソースコードにも目を触れる機会を作っていこうとしていたのですが、いずれも間に合わず、かなり悔しい思いをしました。
しかしそんな中でも各メンバーが頑張り、1つずつ問題を解消していき、何とか終わらせることができました。こんな大変な状況でも対応をし続けてくれた人には本当に感謝の気持ちでいっぱいです。
セキュリティ対策で唯一間に合ったと言えるのはKENROの導入でした。
KENROは新卒＋希望者の人に受けてもらいましたが、KENROで得た知識を今回のプロジェクトで活用できたという声も上がりました。今後も新卒入社の社員中心にKENROの研修を受けてもらう予定になっています。
この総点検・改修プロジェクトが進行している裏で、パスワードセキュリティ向上も進めていました。
これまでのPR TIMESでは6-12文字の英数字のみしかパスワードに設定することができませんでした。この制限を緩和することで安全なパスワードを設定できるようになりました。もしこちらの記事を見ているユーザーの方で、まだパスワードの文字数が短い方がいれば是非パスワードを変更して欲しいです。よろしくお願いします。
またパスワードがコピーアンドペーストができなかったので、こちらもできるようにしてパスワード管理アプリで複雑なパスワードを管理しているユーザーに配慮するように変更しています。
他にも様々な改修を色々入れています。また先程触れたデータ解析用途のBigQuery導入はされており、月1でリファクタリングデー開催も現在行っております。今後のPR TIMESの開発本部に期待してもらえたらうれしいです。
セキュリティ向上のためにはまだやらなければいけないことがたくさんあります。ただし現状はPHPのバージョンアップに力を入れる必要があり、リソースが足りていないため、少しずつになってしまいます。そんな状況ではありますが、これからも確実に改修を行っていきます。
マイクロサービス化を進めてモノリスの責務を減らす
マイクロサービス化は私の入社前に進んでいたプロジェクトでした。こちらについて調査を行っていったところ、以下のことが分かりました。
- 既存システムとの同時稼働について考えられていないため、既存システム移行には利用できない
- マイクロサービスを増やすと、現行のPR TIMESのソースコードも増やす必要があり、モノリスが減らせない
これらのことから以下の方針を定めました。
- 既存のシステムの移行プロジェクトはすべて停止し、今後も行う予定はない
- PR TIMESとは独立したサービスについては現行のマイクロサービス基盤を活用し、モダンなシステム上で開発することで開発速度を上げていく
- 各マイクロサービスは利用するURLのpathを決めて、CloudFrontから直接マイクロサービスにリクエストを送る
- 現行のPR TIMES側のソースコードを変更する必要がなく、レガシーは増えない
- Cookieのpath属性を利用することで各サービスが付与するCookieが増えることを防ぐ
この方針に基づいて、WebクリッピングのPR TIMES組み込みプロジェクトなど複数のプロジェクトが進行中です。新規サービスの開発速度を上げていくことで会社を前に進めていきます。
モノリスのレガシー改善
レガシー改善ではPHPバージョンアッププロジェクトが始動し、ソースコード改善を進めています。
E2Eテストの作成のためのアクセスログ精査から始まり、デッドコード削除やソースコードの書き換えなど様々なことを一気に行っています。
PHPバージョンアッププロジェクトを始め、企業ページのフロントエンドリプレイスプロジェクトや、新機能追加を試験機能として先行リリースできる仕組みを導入したことでデプロイ回数が激増（週に1度あるかどうか→月〜木は毎日複数回デプロイがある）し、開発速度が改善してきています。この傾向はFindy Teamsでも見ることができました。
企業ページのフロントエンドリプレイスにより、これまでjQueryで作られていたレガシーなソースコードからReactを利用したモダンなソースコードに一気に書き換わりました。これによりこれまで開発に時間がかかっていたり、そもそも不可能と考えられていた新機能追加も現実的となりました。今の開発チームは新機能追加に向けてがんばっているところです。
デプロイ回数の激増によりステージング環境が1つしかないことが開発やQAの大きなボトルネックになっていました。そこでApacheのVirtualDocumentRootを活用した構成に変更しました。レガシー改善を行う場合、根本的な構成変更を行おうとすると大変になりすぎます。最低限の変更で効果を出すことが重要です。デプロイ改善により開発時の確認やQAの効率が上がり、複数のプロジェクトが同時に進行し、それぞれが様々なデプロイを行うことが可能になりました。
また全員でソースコードを改善していくために月1でリファクタリングデーを開催しています。現在はデッドコード削除が中心ですが、開発本部全体でソースコードを改善していく組織になりました。このリファクタリングデーもデプロイ改善により可能になった変更です。今後もソースコードの改善を進め、モノリス側でも開発速度を上げていけるようにしていきます。
また来年からオンプレミスのインフラをAWSに移行するプロジェクトを始動します。レガシー化したミドルウェアのリプレイスも同時に行っていく予定です。
社員の挑戦と成長を促す組織へ
私が入社する前のPR TIMES開発本部は半分以上が業務委託であり、業務委託のメンバー中心の開発組織でした。しかし新卒向けハッカソンやベトナムから入社してくれた新卒社員が10名以上在籍しており、モチベーションもポテンシャルも高いメンバーが多くいました。そこでそんな正社員が挑戦できる組織を目指しました。そういう組織に近づいていることはこの開発者ブログを読んでもらえれば伝わる部分もあると思いますし、来年は更に加速させて実感してもらえるところまで行きたいと思っています。
正社員中心ではありますが、業務委託を受け入れないわけでは全くありません。私が入社する前から今に至るまでがんばってくれている業務委託のメンバーは何人もおりますし、私が入社してから新しく入ってもらった業務委託のメンバーもいます。
これについて私は「正社員が挑戦するに辺り、正社員や会社に対して良い影響を与えられる、高い技術力を有した業務委託の人達の力を積極的に借りていきたい」と考えています。そのため正社員や会社に対して良い影響を与えられる人であれば雇用形態に関係なく採用していくつもりです。実際にPHPバージョンアッププロジェクトやコーポレートチームを引っ張っているのは私が入社した後に入社してもらった業務委託のメンバーです。
正直なことを書くと、この方針については一部の業務委託のメンバーから強く反発され、実際に退職していく人は何人もいました。これまで活躍してくれていた業務委託のメンバーには突然の方針変更で非常に迷惑をかけてしまい、申し訳なかったです。しかしPR TIMESを技術の力で今以上に成長させる組織にしていきたいのでこのような意思決定を行いました。
今後も高い技術力を持った業務委託の人達に助けてもらいながら、正社員が挑戦できる組織にしていくことを更に進めていきます。この開発者ブログの発信を通して、社内でどのような挑戦が行われているのか感じてもらえたらうれしいです。
ドキュメント文化
社内にドキュメントを残していく文化が根付いてきました。ドキュメント化することにより、チーム内の情報共有のコストも下がりますし、何より違うチームの人にも伝わるようになるので様々な効果があります。ドキュメント化は組織を強くすると考えています。今回は具体的に今年起こった変化について紹介していきます。
ツール整理・明確化
これまでは情報共有ツールが乱立しており、どこにドキュメントがあるのかよく分からない状況でした。そこでツールの整理を行い、基本的に以下のツールで情報共有を行うことにしました。
- Google Drive
- Notion
それ以外のツールについては順次情報を移行していくことにしています。ドキュメントを保存する場所が明確になることで、ドキュメントを溜めていく文化も生まれました。まずは使用するツールを整理して明確化することが重要です。
しかしこれ以外のサービスを絶対に利用禁止にするということはありません。新しいツールを試しに使ってみること自体は推奨しています。事前に以下の項目を申請してもらいます。
- 目的・用途
- 導入・検証手順
- 検証終了予定日
申請があった場合は簡単なセキュリティチェックだけを行ってテスト利用を許可しています。テスト利用は基本許可しますが、実際に導入するかどうかは厳しく判断したいと考えています。そこで担当者は検証期間中に業務効率改善の実績を作り、それにより業務効率が改善されたと見なされた場合のみ導入するルールにしています。
現在はこのルールによりJiraが新規導入され、業務効率改善に繋がっています。他にもいくつかのツールが本導入は断念したものの、テスト利用を行いました。今後も新しいツールをテスト利用することを推奨していきます。
開発者ブログ
そもそもこの開発者ブログも私が入社してから始まったものです。
見てもらえれば分かる通り、現在まで様々なメンバーが色々な記事を書いてくれていて、弊社の開発本部がどのような挑戦を行っているのかが分かるメディアに育ってきたように思います。
方針としてCTOである私1人が目立つのではなく、各メンバー1人1人にちゃんとスポットライトが当たるようにしていきたかったので、色んなメンバーに書いてもらうことを意識していました。この方針はこれからも変わりません。まだ記事を書いていない人もいるので来年は書いてもらいたいと思っています。
CTO通信
社内の情報格差を減らすためにCTO通信を始めました。内容も一部ですが以下の記事で公開しています。
今のところ不定期更新ですが、月に1,2度程度更新しています。今後も無理せず更新していきたいと思っています。
Design Doc
新規プロジェクトで大きな仕様変更を行う場合はその方向性が技術的に問題ないのか、サービスが向かうべき方向なのか、などチーム内で合意を取る必要があります。また技術的に誤った方向性で実装し始めてしまうと、成果がすべて無駄になる可能性もあります。方向性について早い段階で合意を取る必要があります。また途中からプロジェクトに参加したメンバーや他のプロジェクトのメンバーにも確認して欲しいことがあるのでドキュメントとしてまとまっている必要があります。
そこで導入したのがDesign Docです。このテンプレートを参考にGoogle Docsのテンプレートを登録してあり、適宜項目なども調整しながら用意しています。
Design DocはGoogle DriveのShared drives内に保存するフォルダを用意しているので、その中を見れば様々なDesign Docを確認することができます。
ちなみにすべての仕様変更に対してDesign Docを必ず書くということではありません。それについては以下の記事を参考にしました。
Design Docs at Google （日本語訳 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 – BppLOG）
原文の”When not to write a design doc”、日本語訳の「デザインドキュメントを書いてはいけない時」から引用します。
デザインドキュメントの作成はオーバーヘッドです。デザインドキュメントを書くかどうかの判断は、設計、文書化、上級職によるレビューなどに関する組織的な合意形成のメリットが、デザインドキュメントの作成に伴う労力を上回るかどうかというトレードオフに帰着します。この決定の中心にあるのは、設計問題の解決策が曖昧であるかどうか、つまり問題の複雑さが原因なのか、解決策の複雑さが原因なのか、あるいはその両方なのかということです。そうでない場合は、ドキュメントを作成するプロセスを経る価値はほとんどありません。
デザインドキュメントが不要かもしれないという判断ポイントとしては、デザインドキュメントが実際には実装マニュアルになっていないかどうかです。トレードオフや代替案、意思決定の説明を行わずに、ドキュメントが基本的に「これが実装方法です」というだけの文書であれば (あるいは、解決策にトレードオフがなかったことを意味するほど明白であれば)、プログラムをすぐに書く方がいいでしょう。
毎回Design Docを書いていてはいつまで経ってもサービスは改善されません。実際にプログラムを書く時間をしっかり確保する必要があります。合意形成が必要な大きな変更や、議論の余地がある変更の場合はDesign Docを書いてレビューを行っています。それ以外の場合は基本的には不要のルールにしています。その場合についてJiraなどに変更内容などを他のメンバーにも分かるようにしてもらっています。
障害報告書
これまでもサービスダウンなどがあった場合は対外向けに障害報告書を公開していました。しかし社内で振り返りや共有に使える開発部門の障害報告書のルールがありませんでした。
また情報共有フローも定まっているものがありませんでした。そこで各チャンネルの役割を整理し、以下のようなルールを作成しました。折角なので社内向けのNotionをそのまま公開します（代替テキストも指定しています）。
対応チャンネルが明確化されることで迷わなくなり、情報共有もスムーズになりました。障害報告書も一次対応完了後に作成することが社内で当たり前となりましたし、他の社員が書いた障害報告書を読んだ社員が同様の問題が発生する他のシステムを見つけるなど、情報共有をしたからこそ事前に問題を防げたり、実際に障害対応を行っていない社員にとっても知見の1つにできています。
障害報告書もDesign Doc同様、Google DriveのShared driveの障害報告書フォルダに保存しているため、他の社員が気軽に障害報告書を確認することができます。2021/5から始まった取り組みですが、2021/12/27時点で既に41個の障害報告書がありました。障害報告書は資産と考えています。ちゃんと溜めて今後の振り返りに使用できるようにしていきます。
障害報告書のためにGoogle Docsのテンプレートを用意していますが、こちらはSRE本の付録D ポストモーテムの例を参考に作成しました。また先程紹介したNotion上のルール作成にも参考にした本なのでおすすめします。
メンバーの成長を促す仕組み
新卒1,2年目のメンバーが主力の開発組織のため、様々なことを行ってきました。その一部を紹介します。
社内ISUCON
新卒研修も兼ねて、開発本部内で社内ISUCONとしてTIMES-ISUCONを開催しました。
当日は盛り上がりましたし、触ったことがない技術に触れる機会になったので良い機会になったようです。
使用した問題は過去に私が社内ISUCON用に作った問題のバージョンアップなどを行い利用したものです。
これにより他の用途でも使用できるようになったため、学生インターン用の課題としても利用しました。
学生インターン用にも利用できるようにするためにDocker Composeの整備やREADMEの調整を行っています。より使いやすくなったと思います。
AMIなどで手軽に試せるようになっているため、皆さんも是非試しに解いてみてください。感想があれば教えてもらえたらうれしいです。
エンジニア勉強会
社内で様々な挑戦が行われるようになり、様々な知見が各メンバーに生まれてきたので社内でエンジニア勉強会を月1で行いました。
またカヤックさんとの合同勉強会も行いました。機会があれば他社の方との繋がりを増やしたいと思っています。
これまでは月1で行ってきましたが、発表者がすぐに埋まるようになったので来年から隔週にすることにしました。もっと増えたら週1にまで増やしたいと考えています。
社内YouTube
開発本部はほとんどリモート勤務のため、気軽に質問したりする環境を意識的に作る必要があると考えています。数ヶ月前からGoogle Meetの録画機能が使えるようにプラン変更を行ったので、気楽に会議を録画できるようになりました。そこでまず事前にテーマを決めておいて、希望参加者をSlack上で募り、Google Meet上で説明をしたり質問に回答していきます。その動画を録画しておいて無編集でNotion上に貼って配信しています。
テーマは今のところ以下のようになっており、雑談も含まれるなど多岐に渡っています。このような動画を無編集で流すことで手間をかけずに希望者が情報をキャッチアップできるようにしています。
もちろん重要な情報共有はすべてテキストで行っていますが、説明などはテキストにするのは大変だったりもするので、社内YouTubeで行っています。社内YouTubeは動画を配信することが目的ではなく、その場の参加者からの質問に回答していくことが目的で、その動画を後で見れるようにするのはあくまでもおまけだと考えています。しかし後から動画を見てくれている人は何人もいるため、今後も行っていくつもりです。
ペアプロ
希望者に対しては私自らメンバーと一緒にペアプロも行っています。希望がいればいつでもやるつもりです。
また障害対応時は積極的にGoogle Meetで繋ぎながら一緒に対応を行っています。障害対応は孤独になりやすく、また慣れてないと迷いやミスも起こります。そこで早い段階で一緒に議論しながら進めることで迅速な障害復旧を目指しています。障害対応の時こそ技術力が上げられる機会だったりもするので、積極的に関わって欲しいなと個人的には思っていたりします。
レビュー
先程紹介したDesign Docはもちろん、GitHub上の各PRのレビューも希望があれば行っています。Findy Teamsの2021年12月13日(月)〜2021年12月19日(日)のウィークリーレポートでは私がぶっちぎりのレビュー数1位だったようです。
週にもよりますが、それなりに上位に来ることが多いみたいです。それくらい気軽にメンバーからレビュー依頼されますし、これからも希望があればやっていくつもりです。
技術アドバイス
技術力の高い人から技術的なアドバイスを受けられる機会を作っていきたいため、業務委託でアドバイスや週1日程度の稼働をお願いしている方もいます。
Reactの本格導入が始まっているので、1000chさんから週数時間程度、アドバイスを受けたり、都度Slack上で質問をしたりしています。
またインフラもAWSの本格的な利用やterraformの導入も進んでいるため、mizzyさんに週1程度稼働してもらい、Ansibleの整備やterraformのレビューなどをやってもらっています。
こういった方達からの支援を受けながら、更に強い開発組織を作っていきたいと思っています。
コーポレートチーム発足で社内ITも攻める部署に
2021/6に開発本部コーポレートチームが発足しました。
社内ITのセキュリティ向上・業務効率改善を行う部署としてスタートしました。その後に新オフィスへの移転も決定し、現在では新オフィスのIT環境整備も重要なタスクになっています。今年やったことは以下の記事に大体書いてあるので是非参考にしてください。
元々業務委託のメンバー1人のみが所属していましたが、現在では別チームだった社内ITチームも開発本部コーポレートチームに統合され、2人が所属するチームになっています。
全社員にとって身近な社内ITが攻める部署になることで、会社全体が挑戦できる組織になれればと考えています。
来年以降目指すこと
来年以降はこれまでやってきたことを続けるのはもちろんですが、更に進めることとして現在オンプレミスにあるインフラを廃止し、AWSに移行していこうとしています。これにより機動的なインフラ追加を行えるようになりますし、新機能追加もAWSなどの便利なクラウドサービスを活用することでサービスの提供速度を上げられると考えています。また利用するミドルウェア類もマネージドサービスに寄せることで運用を省力化し、セキュリティも向上させたいと考えています。
また新機能リリースも当然予定しています。現在進行中のプロジェクトがいくつもあるので、来年は色々な新機能が出てくるはずです。
また今年の11月にプロダクト本部と開発本部が統合されました。これからサービスを前に進めるために開発とプロダクトの連携を更に強めて、開発組織として強い組織を目指していきます。
最後に
私がCTOに着任してから、これまで本当に色々なことがありましたが、現在は私も予想していなかったほどチーム内の雰囲気が良くなり、様々な挑戦を行える組織になってきています。
今年は準備や整理する時間が多かったのですが、来年には今年進んでいたプロジェクトがリリースされていく予定です。PR TIMESが変わったと実感してもらえるように引き続きがんばって行きたいと思います。
しかしやらなければならないことが非常に多く、ほとんど手が回っていない状況です。一緒に挑戦してもらえる仲間を求めています。興味のある方はまずはカジュアル面談で色々お話しできればと思います。よろしくお願いします。
