前提：所属組織と使用ツール
所属組織
-
- ピアノを中心とした音楽教育団体
- こちらの本部事務局の正職員（いわゆるサラリーマン）
- 従業員全体で 70 名程度の規模感
- エンジニア職は 5 ～ 6 名ほど
-
株式会社 東音企画 外部 CTO
- ピアノを中心とした音楽教育関連の事業を行う
- こちらは個人事業主として請け負っている
- 従業員全体で 15 名程度の規模感
- エンジニア職は 3 ～ 4 名ほど
担当職域
- マネジメント / 調整
- チーム
- 経営層
- ビジネスサイド
- 研修 / 教育
- チーム
- 社内全体
- 採用
- 新卒
- 中途
- インターン
- 副業
- 派遣
- 技術選定 / 開拓
- 設計 / 開発 / 保守
- 社内情報システム全般
- FileMaker / Google Workspace / Microsoft 365
- WEB
- Ruby on Rails / Vue / PHP
- ネイティブアプリ
- Flutter
- インフラ / ネットワーク
- GCP / AWS / 物理ルータ等オンプレ環境
- 社内情報システム全般
CTOとしてリモートワークを始めたきっかけ
実はコロナではなく、育休がきっかけでした。育休明けの2020年3月の1ヶ月は、部分的に出社していたのですが、見ている会社が二つある場合、物理的にどこに自分がいるかによって、意識に偏りが生じてしまいがちです。事実、その一ヶ月の間は、そうなってしまっていました。
ただコロナの影響もあり、2020年4月からリモート推奨という体制に移りました。その際、両社を等距離感覚で見るには、リモートの方が適していると実感でき、以後も継続するようにしました。
2社同時に見ているならではのこと
最初に言ってしまうと、そこまで大きいことはありません。
……と、そのように言えてしまうことが、リモートで対応していることの強みなのかなと感じています。リモートでなければ、両社を等距離感覚で見ることが極めて難しくなるという実感があるので、より多くの工夫を必要になると思います。
とはいえ、全く別の第3社目を追加で見る必要が出てきたとしても、ツール等の差異がよほど大きくなければそこまで苦労は起こらないかなと思っています。
つまるところ、リモートが可能かどうかと、ツール等の環境をどこまで共通化できるか、というのが大きいですね。
リモートワークで採り入れているツール等の環境
オフィススイート
主には Google Workspace ( 旧 GSuite ) です。
オフィス系のドキュメントやシートは主に Google ドキュメント／スプレッドシート／スライドを用いるようにしているので、リモートで困ることはありません。
チャット
Slack をメインに使っています。なるべく非開発者系の社員にも Slack 利用を推進していて、少しずつ浸透させてきているので、現在、全体の 6 割くらいはユーザになっています。
趣味系の Channel や RSS フィードを流す Channel などもあり。
タスク管理
一時期は Trello を用いていましたが、今はもっぱら GitHub の issues だけに絞るようにしました。
GitHub issues も非開発者系の社員になるべく使ってもらうようにしていまして、タスク依頼をメールや口頭などではなく issues で直接起こすようにし、「依頼した／していない」というような水掛け論が起こらないようにしています。
ミーティング／雑談
社内全体でスタンダードなミーティングツールは Zoom ですが、チーム内では現在は Spatial Chat を使っていることが多いです。2020 年中はいわゆる仮想オフィス的な常時接続しているサービスを色々と渡り歩いていたのですが、利用人数の上限が 2021 年にあらためて緩和されてから Spatial Chat を常用しています。
そんな Spatial Chat には、なるべく常時いるようにしていて、気軽に同期的コミュニケーションも受けられるようにしています。
開発環境
かなり多岐にわたって色々とやっているところなので、あまり統一的なものはありません。コードベースのものは Git 運用をしているのは当然のことながら、Bitbucket から GitHub への全面移行はおこなっています。
エディタは VSC ( Visual Studio Code ) 使いが多いですが、Flutter 開発においては Android Studio / Xcode がメインとなります。BYOD も含めて OS 選択から任意です。
CI/CD は Cloud Build と GitHub Actions がプロジェクトごとに使われていますが、まだ CI/CD 導入が進められていないところもあるので、順次手を入れています。
リモートワークの一日の流れ
前置きとして、よくある一日の流れを記しておきます。
10:00 - 13:00
- コードレビューを中心に、メールや issue への返信などが割合多め。
- 週初の週例ミーティングはこの時間帯におこないます。
14:00 - 18:00
- 社内外問わず、同期的コミュニケーション／ミーティングが多く入る時間帯。
- この時間帯であっても、コードレビューの依頼が来たら優先的に対応はします。
18:00 - 21:00
- やっと腰を落ちつけて自分の作業ができる時間帯。
- 本記事もこの時間帯に手を動かしています。
- この時間帯に社外勉強会的なものが入ることも、しばしばあります。
チーム構築で気をつけていること
週初ミーティング
週の初めの日、午前中に Spatial Chat でミーティングをおこないます。事前にドキュメントに各自伝えたいことを書いてきておいて、そこにあらかじめコメント等をつけておいた上で、口頭で話しておかないとならないことを中心におこなうようにしています。
最初のうちは、アジェンダとなるドキュメントなし、とか、ミーティング開始して初めてドキュメントを見る、とかいう形態もとっていたのですが、時間が無駄にかさむので、この形式で落ち着きました。
3ヶ月（ クォータ毎 ）に1度の振り返りミーティング
おおよそ2時間くらいかけて、1対1でおこないます。
スプレッドシートにヒアリング用のシートのテンプレートを用意しておいて、直近3ヶ月で「学んだこと」「チャレンジしたこと」「うまくいかなかったこと」「影響を受けたこと」という4つの観点について、聞き出しながら、ヒアリングする側がその場で文字に起こしていきます。
さらにそれを承け、次の3ヶ月にどうしていきたいか、ということも、上記4つの観点で同じようにヒアリングして文字に起こします。「自分であらかじめ書いてくる」のではなく、その場で対話の中から引き出す、ということが重要かと思ってやっています。
チームメンバー間の相互の期待を可視化
自分自身がやろうとしていることと、他者から期待されていることとの間にギャップが生じていると、そこには不和が生まれます。また、チームメンバー一人ひとりが、他メンバーに対して何を期待しているのか、というのは、あえて言語化しないと、なかなか伝わらないものです。
なので、半年に一度というペースで、メンバー同士期待していることを可視化するようにしました。スプレッドシートに用意したマトリクス票を使います。
これは「入力しておいてくださいね」ではなくて、ミーティングを設けて、「いっせーのせ」でお互いに開示し合い、感想を言い合うということでおこなってみています。まだ始めてみて間もないのですが、やはりギャップが生じているということが可視化できたので、うまく回っていきそうです。
週末に雑談的なお話会
社内全体で毎週末の 17:00 に終礼ミーティングが 10 分ほど Zoom 上でおこなわれます。お疲れ様でした、という感じでわりと有効に働いています。その前の時間帯に、CTOの私に何でも質問してくださいどうぞ、という時間を設けるようにしてみています。
アカデミックな話題から最近の時事ネタから、SFチックな将来予測まで、何でもアリな時間です。ともすれば、遠い距離として感じられがちな 9割リモートなCTOという存在を、なるべく身近に思ってもらえたらということで試みています。
CEO との週一ミーティング
経営全体に占める IT のポジションの重要性については今さら語る必要もないので割愛しますが、週一で CEO とはガッツリとミーティングしています。
チーム全体の振り返りや重要な報告／相談事項についてはもちろんながら、CEO に対しての技術動向のレクチャーなどもおこなっています。経営判断のための材料提供という側面が強いです。
コミュニケーションで気をつけていること
同期的コミュニケーション
リモートだからこそ、同期的コミュニケーションを意識的に取るようにしています。
チャット上での迅速な反応と気軽なつぶやき
人によって特に向き／不向きが大きいところとは思いますが、私はマルチタスクが向いている方なので、Slack で何かあったら迅速に反応するようにしています。「喋ったのに無視された」というような嫌な体験をされないよう、とにかく絵文字でも何でもつけるようにしています。カスタム絵文字は結構多めに登録しています。
また、「あ、そんなレベルのことでもつぶやいていいんだ」というような、些細なことも積極的につぶやくようにしています。作業中、何か詰まったらわりとすぐにキャプチャ画像を貼りながら「あれー、動かん」というくらいのアウトプットをするのですが、これによって「あ、この人もこんなところで詰まるんだなー。自分だけじゃないんだなー」と、心理的安全性を高められればと思ってやっています。（それが成功しているのかどうかは定かではない……）
優先度で気をつけていること
コードレビューをつとめて最優先におこなう
「一日の流れ」の項でも書いた通り、コードレビュー依頼が来ている時というのは自分がボトルネックになっている瞬間なので、それを滞りなく流すことを最優先としています。
すぐにレビューができないような長大なものが来ることもあります。そもそもそういうプルリクエストは出さないようにというフィードバックを返すことは大切ですが、来てしまったものは内容面で NG なものでない限りは一通り目を通します。
それでも時間がなくてレビューができないときは、「すぐにレビューできない」という旨をコメントつけるだけしておくようにしています。とにかく「反応がない」というのがストレス要因となるので、「認識したぞ」というアクションを取ることが重要です。
タスク管理で気をつけていること
定期的な issue の棚卸し
週初のミーティングでもおこないますが、特に月に一度、月末には、挙がっている全ての issue を再確認して、
- 優先度を上げるべきか
- 進捗が見えないけれど今どうなっているのか
- これはもう終わったので Close してよいはず
- そもそもこれはやるべきではない
- 別の人に割り振り直すべきか
- 自分で巻き取るか
などの判断をするようにしています。
issue の棚卸しをしないと、無限に issue が積もっていくのですが、チームメンバーの各自に棚卸しを依頼しても進まないことが実体験としてあるので、CTO なりリーダー格の人なりがおこなってしまうことをオススメしたいです。
issue の風通しが悪い（ひと月あたりの Close の数が少ない／新規 issue が少ない）場合には、何かしらチームメンバーの中で問題が起きているということなので、新規 issue の数は Integromat + スプレッドシート → Google データポータルで定量的に計測しつつ、Close についてはこの棚卸しで内容面含めチェックするようにします。
担当者と担当者との狭間に落ちたボール拾い
おそらく多くのマネジメント担当者から同意を得られると思うのですが、担当者と担当者との狭間に落ちたボール拾い、つまり、「誰からも認識されていないタスク」「認識されているけれど、誰もが自分がやると思っていないタスク」が発生したことを察知することが、強く求められる職務です。
というか、これさえできれば、他のことなんてたかが知れている（暴論）
とまあ、それくらい大事なことですが、例に漏れずとても強く意識しています。
最初に issue を作って ToDo を立てた時にはヌケモレがないように完璧にできていたとしても、進行していくにあたって状況が変わり、新たなタスクが発生することはしばしばです。その際、タスクが発生したということを誰よりも敏感に察知しておかなくてはならず、また、そのタスクを誰がやるか、という割り振りまでしなくてはなりません。必要に応じて、自分で拾いきる覚悟も必要です。
いかにして自分でやらないようにするか
前項の最後には自分でやらないといけない時もある、と書いていますが、それでも、自分で手を動かしているというのはマネジメントの敗北だという認識でいます。
つまり、負けっぱなしなのが現状なのですが……
自分で手を動かさなくてはならない範囲を狭めて、他担当者に割り振る。あるいはリソース不足であれば外注等の検討も視野に入れていくことになります。
なお、新しめの技術については積極的に自分で手を動かし、感触を確かめてみるということは推奨されると考えています。技術選定における判断のための感覚を養うことは重要です。そのための時間を作るべく、自分がやらなくてもよいことは、自分でやらない、ということが求められてくるわけですね。
積極的に2社目のCTOを副業で狙ってみることもアリ
ここまで書いてきて、やはりよくあるマネジメント手法の紹介になってしまったような感がありますが、1社だろうが2社だろうが、CTO として求められることに大きな違いがあるはずもなく、基本に忠実にやっていくことが重要です。……という、これもまたよくある決まり文句のまとめになってしまいました。
2社同時にやっていて良かったなと思えることを書いておくと、「この新しい技術はこちらで試してみる方が適切だから、こちらで試した後に、うまくいったら別の方でも導入してみよう」ということが容易にできる点です。成功例の水平展開はもちろん、逆に、失敗した場合の知見も持っていけるので、1社だけしか見ていないよりは、自分自身に溜まる経験値の量は 1.2 ～ 1.4 倍くらいの掛け率を得られているかなと思います。
というわけで、既に1社の CTO なりリーダーポジションなりで、わりとうまく回せているかなと思える方は、積極的に2社目のCTOを副業で狙ってみることもアリなのではないでしょうか。CTO はとかく日本全体で不足しているので、知見を具体的な各社の事業にあてはめていくことで、日本の地力を向上させることに一役買うことができるはずです。
逆に、CTO 未経験だけれど副業でやってみたい、という方もチャレンジしてみる価値はあると思います（募集口があれば）誰でも最初は未経験です。
