組織の情報格差をなくす!社内向け「CTO通信」の一部を紹介します

株式会社PR TIMES 執行役員CTOの@catatsuyこと金子です。

私が今年の4月に入社してから半年ほど経ちました。入社してから取り組んでいることのひとつとして、月に数回程度、CTO通信という名前で不定期に私が考えていることや、やろうとしていることを社内のNotion上で発信しています。

基本的に私の考えや開発本部の方針に関することを発信しており、今回はそのCTO通信の内容を一部公開します。

完全に社内向けの文章なのでコンテキストが分かりにくかったり、社外の人から見るとポエムにしか見えない内容もありますが、どういったことをやろうとしているのか、生に近い情報を少しだけ共有できればと考えています。引用した内容の中で現在ではアップデートされている情報もあるので、「続報」を追記するかたちで補足していきます。

今回はNotion上のスクリーンショットを貼り、代替テキストにNotion上の本文を指定しています。読みにくい部分もあると思いますが、できる限り生に近い情報を届けるための工夫と思ってもらえたらうれしいです。

目次

なぜCTO通信を始めたのか

その前にまず、なぜCTO通信を始めようと思ったのかについて補足します。

  • 社内の状況を把握していく中で、今の開発本部の状況を発信して他の社内のメンバーにも共有していく必要性を感じた
  • 開発本部のメンバーがCTOの考えていることが見えないせいで仕事のやりにくさを感じているように見えたので、1つの対策としてCTO通信を利用することを考えた
  • 朝会やミーティングの時間はそこまで長くなく、また参加するメンバーも限られているため、特定のミーティングで話した内容が他の社員に共有されず、情報の非対称性が生まれていた
  • 開発本部は現在約20名ほどでチームも複数あり、テキストで誰でも読める状態を作りたかった

そんなCTO通信の中で、社内のメンバーのマインドを変えるために行っている発信をメインに紹介しようと思います。

2021/04/30 CTO通信第1号

## これまでの意思決定をひっくり返している件

既に入社してからこれまでの意思決定をいくつかひっくり返しています。具体的に挙げれば、

- サブドメインで作る方針からディレクトリを切る方針に
- マイクロサービス化のドメイン
- Googleログインの制限など、社内ITのセキュリティ向上策
    - これまで進行していたデバイス認証による認証をストップして、2段階認証を必須にしてもらう方向に

私自身、偉い人からこれまで進んできたことをひっくり返されて、不快な気持ちになったり、やる気を削がれたりした経験があります。こういった意思決定をする度に今までやってきた人達に対して非常に申し訳ないという気持ちになります。しかし今回開発のトップの人間が変わったので、これまでの意思決定基準は踏襲されません。これから私がCTOとしてやっていきたいことはまだたくさんあるので、この時点で私が納得できる意思決定ができなければ、今後適切な意思決定ができなくなると考えています。

これまでの社内の進め方が、私のこれまでの経験からすると良くないと感じるケースは今後も出てくると思います。逆の立場で考えるとつらいことは明白なので非常に心苦しいですが、しばらくはお付き合いを願いたいです。ある程度の方向性が定まれば、こういったことは減らせると考えています。もし方向性が定まらなくて、いつまでも意思決定をひっくり返すようなら責任者として失格なので職を辞すつもりです。それくらいの覚悟で意思決定をしています。## これまでの意思決定をひっくり返している件

既に入社してからこれまでの意思決定をいくつかひっくり返しています。具体的に挙げれば、

- サブドメインで作る方針からディレクトリを切る方針に
- マイクロサービス化のドメイン
- Googleログインの制限など、社内ITのセキュリティ向上策
    - これまで進行していたデバイス認証による認証をストップして、2段階認証を必須にしてもらう方向に

私自身、偉い人からこれまで進んできたことをひっくり返されて、不快な気持ちになったり、やる気を削がれたりした経験があります。こういった意思決定をする度に今までやってきた人達に対して非常に申し訳ないという気持ちになります。しかし今回開発のトップの人間が変わったので、これまでの意思決定基準は踏襲されません。これから私がCTOとしてやっていきたいことはまだたくさんあるので、この時点で私が納得できる意思決定ができなければ、今後適切な意思決定ができなくなると考えています。

これまでの社内の進め方が、私のこれまでの経験からすると良くないと感じるケースは今後も出てくると思います。逆の立場で考えるとつらいことは明白なので非常に心苦しいですが、しばらくはお付き合いを願いたいです。ある程度の方向性が定まれば、こういったことは減らせると考えています。もし方向性が定まらなくて、いつまでも意思決定をひっくり返すようなら責任者として失格なので職を辞すつもりです。それくらいの覚悟で意思決定をしています。

私がどういう覚悟で意思決定をしているのか書いた記事です。当時はまだ入社直後であり、私の経験から見ると、明らかに良くない方向に組織が進んでいたことが数多くあり、1つ1つそういったことを見つけては意思決定をしていた時期でした。

メンバー側の気持ちが分かるからこそ、このような発信が必要だと思い、CTO通信での発信を行いました。またこのことは、開発本部内だけでなく、組織全体に伝える必要があると思い、第1号で書きました。

また他のCTO通信第1号の内容の一部の改変版については既に私の個人ブログでも公開済みです。読んでもらえたらうれしいです。

Medium
ソフトウェアエンジニアが執行役員CTOになった理由2021/4に株式会社PR TIMESの執行役員CTOに就任しました。

2021/06/08 CTO通信第3号

## コーポレートチーム発足

開発本部にコーポレートチームを発足させました。

[前回のCTO通信](https://www.notion.so/2021-05-10-CTO-2-cc9280506bd4412aae031d9ca19cc632)で「社内ITを改善したい」という話を書いていましたが、実際に社内ITを改善するために開発本部内にコーポレートチームを新設しました。

以前にも似たような試みはあったそうですが、うまくいかなかったと聞いています。しかしこれは私の入社で状況は変わったと思っています。CTO直下のコーポレートチームでコーポレート分野に再チャレンジします。

開発本部内ではなく、CTO室を作ってその下に紐付けるということも考えましたが、組織図自体を大きく書き換えようとすると影響範囲も大きいのと、現状所属人数は0なのでまずは開発本部内にコーポレートチームを作って、まずは始めることを重視しました。今後人数が増えたら開発本部の外に出すかもしれませんが、現状は何も考えていません。

しばらくは採用面のインパクト(CTO直下という言い方を使いたい)や、言い出しっぺの法則からコーポレートチームのマネージャーは私CTOが兼任する予定です。今のところ所属メンバーは0ですが、採用ができたら色々変えていく予定です。もう少し待ってもらえたら助かります。

入社してちょうど2か月ほど経過した時期のCTO通信です。様々な課題を把握していく中で、社内のセキュリティ向上や業務効率改善が必要だと感じていました。また、それを進めていくためには、直接的なレポートラインがCTOの私になっている組織でなければ太刀打ちできないと感じ、開発本部内にコーポレートチームを新設しました。

現在ではその後、信頼できる外部の業務委託の方の力を強く借りながら、コーポレートチーム主導で力強く社内IT改善が進んでいます。当時「今すぐやりたい」と言っていた改善(Googleアカウントのセキュリティ向上、1Passwordの導入、メールの添付ファイルポリシー策定など)は既に完了しており、現在も更なる改善に向かっているところです。

2021/06/30 CTO通信第4号

## 開発本部のスタンス

私が考えている開発本部のスタンスについて明文化しておいた方が良いなと思ったので明文化します。

これは私個人のスタンスですが**「方針を示して、崖に突き落としてみて、困っていたら助ける」**というスタンスです。

方針はできる限り示します。この方針にはある程度詳細な技術情報が含まれていることもあれば、本当に方向性しか含まれてないこともあると思います。その状況でみんなに挑戦してもらいます。

私は開発本部の全メンバーに挑戦することを求めます。もちろん困っていたら助けるので、困っていたら助けを求めてください、私は適切に助けを求めることも実力の内だと考えています。最初のうちは迷ったら助けを求めて大丈夫なので、助けを求めてみてください。

そういう方針なので特に挑戦する気のない人にとって、私と一緒に働くことは本当につらいことなのだと思います。それでも私はみんなが挑戦できる場を用意し続けます。そして一緒に挑戦させてください。

そしてこれからPR TIMESの開発本部は**正社員が技術的な挑戦をドンドンできる組織へと変えていきます**。正社員だけだと解決が難しい技術課題などの解決には効率よく業務委託を配置していき、正社員も刺激を受けやすい環境を作っていきます。

そうすることで開発本部が社内の他の部署から信頼される部署になると考えています。そのために開発本部のメンバーには技術的な挑戦を求めていきます。それに頑張って付いてきてください。そうすることで驚くほど実力が付き、みんなから信頼される業界内でも有数のソフトウェアエンジニアになれるはずです。そういったソフトウェアエンジニアがPR TIMESに当たり前のように所属している、そんな組織を目指していきます。

入社してある程度のことが見えてきた頃です。これまでの開発本部の方針と、自分自身が考える方針との差が大きかったので、私のスタンスについて明文化しました。

人によってはいきなり技術的な挑戦をすると言われても混乱するでしょう。どういう考えで行っているのか明文化する必要性を感じてこの発信になりました。

この少し後くらいから「自分にも挑戦的なタスクをやらせて欲しい!」といった声が開発本部内で徐々に増えていったことは、私としても嬉しいことでした。そのような声が増えることで、また次の人に伝播していくような雰囲気に変わっていったのは、何か変えようと思い行動してくれたメンバーのみんなのおかげです。大変感謝しています。

2021/07/06 CTO通信第5号

## PHPバージョンアッププロジェクト開始

[CTO通信第3号](https://www.notion.so/2021-06-08-CTO-3-2ae5ee537fef448e994bb4dbaee6c2f0)で紹介したuzullaさんが7月に無事入社してくれました。早速PHPバージョンアッププロジェクトが開始しています。

とはいってもいきなりバージョンが上がることはなく、最初はテストの導入やデッドコードの削除などから行います。具体的な成果が出てくるのは少し先の話ですが、確実に成果を上げていくので楽しみにしていて欲しいです。

とはいってもこれまでPHPのバージョンアップができないと考えられていた当社では、具体的に他社がどうやってPHPのバージョンアップをしてきたのか、当社がどうやって戦っていくのかなどよく分かってない人がほとんどだと思います。そこで社内勉強会として他社事例を紹介しつつ、当社でどう戦っていくか座談会をすることにしました。

[PHPバージョンアップ kickoff (2021/07/15 15:00〜)](https://breaktimes.connpass.com/event/218221/)

こういった勉強会を通して、**当社のレガシーは他社に比べて突出してひどいわけではない**ということが伝えられればとも思っています。

こちらの勉強会は社内向けですが、社外に公開しても(PHPのバージョン以外は😅)問題ないので社外の人も参加可能にしました。勉強会の動画自体は公開予定はありませんが、できればこの座談会の内容は開発者ブログのコンテンツとしても公開できないか検討しています。

この勉強会一つで社内のエンジニアの知識も増えて、社外へのアピールにもなるのでかなりコストパフォーマンスがいいのではないかと思っています。社内のリソースも限られているので、こういったイベントは頻繁には開催できないかもしれませんが、タイミングを見て積極的にやっていきたいと考えています。何かアイディアがあれば提案してくれたら嬉しいです。

7月に開催したPHPバージョンアップ kickoff – connpassを開催するにあたり、なぜこのような勉強会をおこなうのかを事前に社内共有したときの文章です。

実際にこの勉強会は、社内外の人に参加してもらい、PHPのバージョンアップは現在進行形で進んでいます。

開催後に実際に座談会の内容の書き起こしを公開しました。

2021/08/25 CTO通信第7号

## 変化は善

変化しない組織は必ず腐ると思っています。もちろん変えてはいけないことを何でも変えていいというわけではありません。関わっている人への相談や過去の意図はくみ取る必要はあります。しかしなんで継続しているのかよく分からない風習などは思い切って変えてみましょう。もし問題があれば戻せばいいです。

他のメンバーからの反発を心配する気持ちも分かります。そういう場合はCTOである私に相談して欲しいです。そういった恨みを実行するメンバーが買うべきではありません。それによる恨みはCTOである私に向けてもらってかまいません。最終的にCTOである私の意思決定として動いてもらうことで実行するメンバーが動きやすいようにしていきます。

具体的に言えば、今のPR TIMESのリリース手順はGit-flowと呼ばれるフローにおおむね沿って行われています。Git-flow自体は他社でも利用されることがある一般的なフローですが、基本的にリリース頻度が低いシステムでの利用が多いフローで、ほぼ毎日何かしらリリースしているWebサービスでの利用にはあまり利用されません。

それにもかかわらずPR TIMESには向かないはずのリリース手順は何年も守られてきました。これはなぜでしょうか?

私の印象ですが、リリース手順は会社のポリシーなどが反映されやすく、業務委託の人から見ると変えてはいけないものに見えてしまうからだと思います。私も業務委託として知り合いの会社の仕事を受けたことが何回かありますが、そういう形態で関わった会社のリリース手順を変更しようと考えたことはありません。様々なやり方を根底から変えてしまうので、恐くて触れないと考えるからです。

PR TIMESの開発本部はこれまで業務委託中心の組織でした。ほとんどのメンバーが恐くて触れないと考えていれば、正社員の他のメンバーにも変えてはいけないものに見えてしまうのは当然だと思います。

しかしそれは違います。変化は善です。変えて良いのです。なんで続いているか分からない習慣こそ思い切って変えてみましょう。そういったことを積み重ねていくことで業務効率は上がっていきます。

迷ったら相談してください。適切な方法を一緒に模索したいです。

私が入社する前は変化を恐れる雰囲気が、少なからずあったと感じています。しかし実際に様々な変化を目にする中で、上述した通り、少しずつメンバーのマインドにも変化があらわれていると感じていました。そのような時期に、私自身が変化を作っていくだけでなく、開発本部内の多くの人が変化を起こす側になってほしいと思い、書いた内容です。

たとえば具体的には、このCTO通信を出す直前にGit-flowによるデプロイ手順は廃止され、デプロイに必要な手順を減らしました。まだデプロイ手順やデプロイスクリプトに対する改善は現在進行中です。そのうちの1つは先日公開されています。

他の改善も行っている最中です。開発者ブログでもこういったデプロイ改善を事例として少しずつ公開していきたいと考えています。

2021/09/22 CTO通信第8号

## 評価の心得

完全に時機を逸しましたが、評価について簡単に書いておきます。

自己評価を書くときは**自分が如何に強いエンジニアか主張する**ことを意識して書いてください。あなたの強さを主張してくれる人は自分自身しかいません。あなたが主張しなければあなたの強みは誰にも伝わりません。

言わなくても分かってくれるだろうと思うかもしれませんが、自分が思うより他人にはなかなか真意は伝わらないものです。思っている以上に伝わっていないと考えて欲しいです。

また評価は直属の上長以外の人も関わります。細かいコンテキストも把握していない人が読んでも如何に自分自身が技術的に難しいことをやったのか、如何に会社やサービスに貢献したのか伝わるように書いてください。

こういったアピール力があると対外的にもプレゼンスは上がり、自身の市場価値も上がります。それは会社にとっても自分自身のキャリアにとっても非常にいい影響を与えますし、そうなれば自ずと給料は上がります。もし給料が上がらなくても簡単に転職できるはずです。

私は**PR TIMESの開発本部を市場価値の高いエンジニアが多数所属している組織にしていきたい**と思っています。そのための支援もやっていきます。なので皆さんからの質問だったり、相談はいつでも受け付けています。よろしくお願いします。

上半期の評価時期にあたり、評価の心得を共有しました。エンジニア以外の職種でも同様のことが言えるかもしれませんが、技術力の評価は特に自分自身が主張することが大事だと考えています。それは単にアピール上手になってほしいのではなく、相手に伝わるように伝えることが大切だと考えているからです。

私はこの開発者ブログなどを通して、PR TIMESのエンジニアの市場価値を上げていくつもりです。

最後に

CTO通信を始めた当初は本当に読んでくれるかも分からなかったですが、現在では開発本部だけでなく、他部署のメンバーも読んでくれる人が多くいます。

少しでも情報格差をなくし、できる限り広く正確にCTOである私の考え方ややっていること、今後の方針を現場のメンバーに届けたいという気持ちで始めたので、これからも不定期ではありますが続けていこうと思っています。他にも公開していないコンテンツがいくつもあるので、よりリアルな話が聞きたい方はカジュアル面談Meetyでお話しましょう(面談では、聞かれた事は何でも話しています)。お待ちしています!

この記事を書いた人

金子 達哉のアバター 金子 達哉 執行役員CTO

株式会社PR TIMES 執行役員CTOをやっています。がんばります。

目次
閉じる