アカツキ IT Service チームがチームでワークするためにやっていること

はじめに

この記事はcorp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2021の24日目の記事です
https://adventar.org/calendars/6178

自己紹介＆チームの紹介

株式会社アカツキのIT Serviceチームでマネージャーをしている徳山（tokuhy）です。
IT ServiceチームではいわゆるコーポレートIT、情シス領域の業務を担当しています。
2017年に専任のひとり情シスとしてチームを立ち上げて以来、今では11人のチームになりました。

チームの業務範囲としてはざっくり

• 全社システム設計と運用
  • Google Workspace、Slack、Zoomなどに始まり他多数
• セキュリティの仕組み構築、運用
• ヘルプデスク
• 備品調達と管理
• 入退社の人員管理

です。

管理している規模でいうと2021/12時点で

• IdPのアカウント数2000程度（システムアカウント含む）
• Mac1300弱、iOS 750弱、Windows180弱、Android600弱
• 台湾拠点含めて子会社3つ

くらいな感じです。
一人、二人でがんばってどうにかなる規模ではないのでチームとして機能的に動く必要があります。

今回はチームでどのようにワークしているかについて簡単にですが紹介したいと思います。

チームのあり方とマネジメント方針

まず自分がチームとして成果を出していくためにマネジメント領域で意識しているポイントについてざっくり書き出してみました。
（当たり前ですがマネージャーは管理することが仕事ではなくチームとしてのアウトプットを最大化していくことが仕事であるというのは大前提です。）

• チームとして持続可能であることが重要である（持続可能性）

  • 業務をブラックボックス化させない。
    ブラックボックスになっていなければ属人化はパフォーマンスを上げるための手段なので問題ない。
  • 特定のスーパーマンに頼らなくてよい状態にする。
  • 人員の入れ替わりが発生していくことを前提とする。
    誰かがいなくなったら業務パフォーマンス落ちるという状態にしない。冗長性をもたせる。
    （もちろん慣れの問題はあるので一時的なパフォーマンス低下はどうしても発生する）

• 長期的な観点でチームとして成長する（長期視点）

  • 課題解決アプローチだけでなく、全体のTo Beを描いた上でのゴールを見据える。

  • 短期成果志向の人は採用しない。

    1〜2年で抜けていきそうな人ではなく、数年レベルで個人と組織の両面で成長を考えられる人でチームを作る。

  • 採用の基準となる軸を明確に持つ。スキル、知見のあるなしは要素のひとつに過ぎない。

  • 時間が経過するほどチームとして業務の質があがる状態にする。後退せずに積み上がっていくことが大事。

• 評価の基準を明確にする（評価基準）

  • 中途入社 or 成長による内部でのステップアップかに関係なく評価の軸は同じ。
    採用したいから長期に渡り待遇を優遇するなどはしない。評価する基準は中も外も同じものを使う。
    釣った魚に餌をあげない状態は悪。
  • 評価を確定する際には説明可能な状態を作る。
    評価者（マネージャー）はその評価内容を他者へ説明可能でなければならない。

• 多様性を尊重する（多様性）

  • 成長意欲の高い人、やるべきことはきちんとやるが自発的な成長意欲は低い人、業務から離れたコミュニケーションが苦手な人、などいろんなタイプの人がいることを理解する。
  • チームで動くには役割分担が肝。適材適所を考える。
  • 業務上必要なもの以外の強制力のあるルールは作らない。

• 柔軟な働き方を可能にする（自立）

  • 遅刻、早退、休暇は理由不要で可能とする（有給休暇取得はそもそも理由不要が当たり前だけど）。

    自分の業務範囲に影響を出さない、影響範囲を他メンバーと調整してコントロールできるなら好きにすればよい。

  • リモートワークも選べる。
    出社するかリモートワークにするかは自身の受け持ち業務の状態で自分で考えればよい。

  • 出社とリモートワークが混在する状況が平常状態であるという前提で業務設計、チームのワーキングアグリーメントの設定を行う。

• 情報の非対称性を（なるべく）作らない（情報共有）

  • 上場企業としてセンシティブな情報を扱う場合もあるのですべてがオープンというわけにはいかない部分もあるが、オープンコミュニケーションを原則とする。

• 目に見える金銭的コストに安易に左右されない（コスト意識）

  • 単純に〇〇を△△にしたらいくら金銭的コストカットになるというスコープの狭い考えはしない。
    それによって別の部分で逆に金銭的コストが増えないか、業務が煩雑になることでミスが増えないか、モチベーションが低下することでチームとして生産性が低下しないかなど複合的な影響も含めて考える。
  • 同様にサービスを比較する上で金銭的コストだけ見ない。
    金銭的コストは評価指標のひとつにすぎない。
  • コストの計算で〇〇分の業務が削減できるから□円の価値があるという考え方に縛られすぎない（大事ではあるけど）。
    浮いた工数を別のアウトプットに転換できてはじめて意味があることは理解しておく。
    （工数浮いてアウトプットが増えないのであれば金銭的にはコストアップだけに終わる。）

• 謙虚（Humility）尊敬（Respect）信頼（Trust）を忘れない（HRT）

  • 自分自身でも意識するし、メンバーとしてもメンバーである資質として認識してもらう。
  • マネージャーは組織において与えられた役割にすぎない。人間関係として上下があるわけではない。

色々意識しながら動いていはいますが、ブラックボックス化の部分はチーム拡大に対してまだまだ渡しきれていない部分もあり、ここは個人的にまだまだ課題が多いなと感じているところです。

実際のチームでの働き方

ここからは実際にどのように業務を遂行しているかについて書き出してみます。
ちなみに実際に業務で利用するコミュニケーションのサービスは

• Google Workspace
• Slack
• Zoom

が中心となっています。

チーム構成

まずはIT Serviceチームの構成の紹介です。
今年の夏、もともと連携して業務することが多かった総務チームと合体してひとつになりました。
現状はITチーム、総務チームという感じで担当領域を大まかに２つにわけています。

ITチームが

• IT領域の企画、設計、改善 4〜5人
• セキュリティ 2人
• ヘルプデスク 1〜2人

総務チームが

• 入退社管理、備品管理 2〜3人

• ヘルプデスク2~3人

といった人数比率で業務をしています（複数領域カバーしているメンバーもいる）。
総務チームからITチームに、ITチームから総務チームにというチーム内での役割転換も行っています。

物理出社かリモートワークか

先述した自立の部分に該当します。2020のコロナ禍以降リモートワークを積極的に取り入れています。
物理的なモノ（PC、備品、社内物理ネットワーク関連業務等）を扱うのでフルリモートではないですが、出社するしないは基本的にはそれぞれのチームにまかせています。

コロナ禍以降、世の中的な流れとして物理出社オンリーに戻ることにはならないと思っており、ハイブリッドな働き方が恒久的なものとなる中でチームでどのように成果を出していくかというのを模索し続けているところです。
今後ジョインするメンバーのことを考えてもリモートワークが可能という環境は前提として持っておかないとチームとしての体制維持は難しいと考えています。

Zoomで朝会

Zoomを用いた朝会を実施していて毎朝全員ひとつのZoomミーティングに集まります。
この中でITチーム、総務チームがそれぞれ時間をずらして朝会を実施しています。
司会は持ち回りで実施しており、ITチームの朝会ではGood & Newも取り入れています。

参考：アカツキメンバーが毎日5分間行う習慣"Good and New"と主な効果３つ | Akatsuki TERRACE
（上記記事にある全体としての仕組みは現在は実施されていないですが、社内の多くのチームの中でそれぞれ実施しています）

それぞれが受け持っているタスクは後述するチケット管理ですべて進捗把握できる状態になっているので、朝会では細かな話というよりかはざっくりトピックを共有して他の人に念入りに共有しておきたいことを口頭で伝えるという感じです。

総務チームでは依頼状況によってオペレーションの優先度が随時変わっていくため、夕会として状況共有の場を別途設けています。

Zoomの常時接続

朝会が終わったあとも基本的に全員Zoomに入ったままの状態になっています。
朝会終了時にミュートにしてビデオもオフの状態にしますが、口頭で相談、質問したいときにさっとはなしかけてつながれるようにこの状態をキープしています。
Slackにもハドル機能が追加されましたが、以前からこの形式なので現在のところハドルは使っていません。

Zoomで会話するときは基本的にビデオもonにすることをチームのルールとしています。
ハイブリッドな働き方をする上でやはりコミュニケーションの課題はあるので、声だけでなく顔を見て会話することは大事だと考えています。
（ハドルはビデオがないのでこの点でも使いづらい）

また、30分程度のミーティングであれば別で部屋を作らずにこの部屋の中でそのまま実施します。
関係者だけビデオをonにして参加しますが、チーム内でオープンに会話することで他の人も自由に聞くことができます。
これによって会話してる中で「そこは〇〇だよ」「こっちのやり方の方がいいんじゃないか」などアイデアがあったときにさっと会議に参加してその場で解決や改善が進むことがよくあります。

オフラインだと会議室で話していて部分的にクローズドになるシーンも多かったですが、働き方としてオンラインを取り入れたことによってクイックに解決や改善につながっていくことがあるなというのは日々実感しています。

タスク管理

業務のタスク管理は

• ITチーム：GitHubのproject機能
• 総務チーム：ServiceNowのVisual Task Board

を利用しています。
どちらもカンバンとしてチケットのステータス管理ができます。
取り組む業務はすべてチケット化し、そのチケットの中に対応の記録を残していきます。

チケットを作成する際には原則以下を記述します（ライセンス発注などのやることが明確な作業タスクは除く）。

• As Is
  • 現状について記述
• Problem
  • As Isによってどういう問題が発生しているかの記述
• To Be
  • あるべき状態はどういう状態か
• How
  • As IsをTo Beに持っていくためにどういう手順、対応が必要か

タスクに着手する前にこれらを整理することを原則とし、目的がぶれない、真に解決したい問題が何かを明確にします。
これを癖付けることでXY問題 的な状況が発生しづらい形を作ります（XY問題にならなくて済んだねなどの会話はチーム内でよく出てきます）。

タスクに関するやりとりや進捗共有は基本的にこのチケット上にすべてコメントとして残しています。
目的としては以下です。

• 調査過程の共有（ナレッジ共有）
• 取り組む方向性の共有
  • コメントはSlackのパブリックチャンネルに流れてくるので誰でもみれる。
  • 着手前に共有することで方針の認識合わせの効果、手戻りを早める効果がある。
    （ここはこっちのやり方がいいんじゃない？など）
• 却下案の記述
  • 別案の〇〇のやり方だと駄目なんだっけ？なんで□□でやらなかったの？という質問をしなくて済む。

これらをチケットにログとして残ることで、今後ジョインするメンバーが将来検索したときに対応時の状況を把握可能となります。
先述の持続可能性の部分のHowのひとつです。

ちなみに将来的にはServiceNowにすべて統合していくことを想定しています。
ServiceNowとSlackの連携機能をWorkatoを使って独自で構築しており、Slackに書いたコメントや添付ファイルをすべて発言者として自動で同期される状態になっています。
Slackでのスレッド上でのやりとりがそのままチケットのログとして整理されて残る仕組みです。
（なぜServiceNowを選んだかについてはまたどこか別の機会に。）

振り返り

定期的にタスクの振り返りを実施しています。
総務チームは毎週、ITチームは隔週でタスクボードのクローズレーンのチケットの最終状況をチームメンバーに共有し、問題なければアーカイブして完全終了となります。

ひとりで完了とするのではなくチームメンバーへ共有して本当に完了で問題ないかという確認をとることで、対応の抜け漏れや対応内容に問題なかったかをすり合わせます。

ヘルプデスク

ヘルプデスクとしての問い合わせ対応は現状Slackから受け付けています。

• ITに関する問い合わせ：ServiceNowへ連携
• 総務に関する問い合わせ：Trelloへ連携

という構成です。
どちらもSlackでのやりとりがそのままの発言者としてServiceNow/Trelloにも転記されるようになっています。
それぞれのシステム上でコメントしたものもそのまま該当のスレッドに投稿されるので、オペレーターはどちらからでも対応可能になっています。

ServiceNowの場合、自動的にナレッジとして蓄積されていくため、過去対応事例の参考情報として活用できるようになります。
ナレッジベースも整備することでここの自動応答や対応オペレーションの工数削減につながっていきます。

これらの利便性があるためにTrelloの仕組みもServiceNowにすべて統合していく想定で準備中です。

スキルマッピング

IT、総務ともにチームとして対応する内容が明確化されている業務は項目としてリストアップされ整理されています。
誰がどの項目をどのレベルで対応できるかというのをスコアリングしており、評価や成長目標の指標のひとつとしています。
ここは個人の主観ではなく過去の業務の実例とともにチームメンバーとの認識をすり合わせながら相互に確認します。

これを作成している目的は以下です。

• 業務として何があるかが明確になっていることで担当範囲として何をできるようになればよいかわかる
• 新メンバーがタスクキャッチアップするための指標になる
• 業務が項目で分けられていることで、OJTの時に誰が教えるかを役割分担して対応できる

これらもチームとしての持続可能性に基づくHowのひとつです。

研修

ITチームでは新しい人が入った場合一通り業務とフローを把握していただくことを目的として、基本的にはオペレーション業務についても研修を実施しています。
先述のスキルマッピングの項目があるため、どの項目を誰が教えるのかを役割分担して実際の作業を一緒に実施します。
この研修も録画されたものが項目ごとにあるため、実際の作業前に動画で予習してから研修となります。

教える人を固定化させない、分散化する、自己学習が可能、ブラックボックス化させないというチームの持続可能性のためのHowのひとつです。

役割の分散

朝会、振り返り会などは持ち回りで司会を交代しています。
マネージャーが必ずしも仕切らなくて良いものはチームとして動いていけるように役割を分散する形をとっています。

勉強会

ITチームでは隔週開催で持ち回りで勉強会を実施しています。

• 利用しているサービスについてそれを構築したメンバーが設計や仕組みを共有
• 汎用的な技術に関する説明
• LT的な軽めの話（業務に直接関係ない話でも可）

などです。
担当する場合の資料作成はもちろん業務時間内で対応可です。

過去の内容はすべて動画で記録してGoogleドライブに入っているので新しく入社した方はピックアップして社内の仕組みを自己学習できるようになっています。
（勉強会なのでオリエン的な内容ではなく、あくまでも情報キャッチアップとして利用しています）

リモートワークでZoomが当たり前になったので手軽に録画できるようになったのはよかったと考えています。

ワーキングアグリーメント

これまでに書いてきたもの（タスク管理と進め方、朝会やZoomの利用のルールなど）はチームのワーキングアグリーメントとして明文化して設定しています。

新メンバージョイン時の共有

新しいメンバーがジョインしたときは、自分がマネージャーとして以下を直接口頭説明しています。

• これらの内容（ワーキングアグリーメント）の説明
• 会社全体の組織構造の説明
• 福利厚生

伝える内容がぶれないように、この内容も明文化されています。
また実際にどういうコミュニケーションを行っているかをクローズドにしないように、サブリーダーも同席して実施しています（自分に何かあった場合は代行できる状態）。

最後に

以上チームとして継続して成長していく上で実際にアカツキのIT Serviceチームで行っている仕組みの紹介でした。
他にもチームとしてワークする上での業務フローやルールはあるのですが、ざっくり主だったものを羅列してみました。

業務の仕組み、チームでの働き方の仕組みはどんどんアップデートしていっているため多分1年後にはまた違った状態になっていると思いますが、参考になる部分があったのであれば幸いです。

より具体的な個別の内容については、また別の機会にアウトプットできればと思います。