情報処理安全確保支援士になりました

今月より晴れて、情報処理安全確保支援士（登録番号028693）を名乗れるようになりました。昨年取った医療情報技師と合わせて、医療情報システムの情報処理安全についてのプロフェッショナルであることをある程度の説得力を持って説明できるようになったと考えています。

とはいえ資格をとったら急に仕事ができるようになるかというとンなわけないので、より複雑な課題解決ができるように継続して学んでいきます。とりあえず今日は、なぜセキュリティなのかと、今後の抱負をここにまとめておこうと考えた次第です。

なぜ今セキュリティなのか

私はいままでCDワークフロー改善であるとか、ログ管理含めた保守性であるとか、エンタープライズアプリケーションの性能改善であるとか、どちらかと言えばシステム実装に寄った非機能要件を多く見てきました。

一応OSSライセンスの管理やビルドスクリプト改善から発展して、OSS脆弱性への対応も経験してはいるのですが、セキュリティについてはそこまで専門でやってこなかったというのが正直なところです。

セキュリティについて学ぶ起点となったのは2021年末、Log4Shellの対応です。GitHubで突如公開されたコミットをもとに修正内容の把握や自社サービスへの影響などを短期間に特定して全社的になんとかする体験をし、セキュリティが「OSSエンジニアとしての経験とベストプラクティスを現場の運用に落とし込むという自身の関心領域とが交差する場」でもあるのだという発見に繋がりました。

そして転職後、医療情報システムの安全管理に関するガイドラインについて学んだり、サイバーセキュリティが医療機関等の管理者に対する義務化されたりして、自然とセキュリティについて学ぶ時間が増えたというのが「なぜセキュリティなのか」への回答というところです。端的に言うと医療業界的にニーズが高いのと、自分のWILLやCANとマッチしたというところですね。

情報処理安全確保の第一歩は相互理解

情報処理安全確保支援士の資格試験では、自分が支援士だと仮定したうえでどう考えて行動すべきかを問う設問が出ます。そしてその場には必ず複数の関係者が出てきます。そもそも情報処理安全確保「支援士」ですから、組織に対して支援を提供してゴールを目指す立ち位置＝実行者ではなくハブであり、経営者や情報システム担当に対する助言者だということなのだと私は理解しました。

同様に医療情報技師も関係者との交流を指す「3C」を重視しています：

他職種との意思疎通を図るためのコミュニケーション（Communication）、他職種と協力して対応するコラボレーション（Collaboration）、部門間や職種間の調整を行うコーディネーション（Coordination）の3つの能力を必要な資質としています

医療機関で働く医療情報技師は自らの管理下にない部門システムや保守用ネットワークを業務の前提とすることも多く、事業者を含む他職種との協業が絶対必要です。だからこそより安全で患者様や職員のためになるシステム運用を実現するために、協調や調整が重要なのだと私は理解しました。

異なる資格が同様に他者とのコミュニケーションを通じての実行にピンを留めているのは面白いですね。それだけ業務遂行に必要な能力だと考えられているわけで、重要性もまた理解できます。

不安に名前をつけるのが情報処理安全確保支援の初手

さてセキュリティに明るくない方とのコミュニケーションにおいて、その出発点は多くの場合「よく知らないけど、これをしたい」「あれってセキュリティに問題あるって本当？」といった漠然とした不安であることが多いと感じます。そしてわかりやすく一網打尽にできそうな、たとえば閉域網のような選択肢が支持されます。情報技術は目に見えないものを扱うので、気持ちは理解できます。

ここで求められる3Cはその不安を具体的に表すことだと思っています。どのようなゴールを望んでいるのか、どんなリスクがあると考えているのか、保守にどれだけの手間をかけられるのかなど、いろんな視点からあるべき姿を探ります。その結果として不安に名前がつき、この不安にはこう対処する、この不安は当面どうしようもないので受け入れる、という議論ができるようになります。

もちろん相手にはよるものの、多くの場合はこうしたコミュニケーションを通じて不安や心配をリスクマネジメントという経営的な営みに近づけること、なんとなくや人から聞いたからではなくて戦略的に決定を下せるようにすること、その決定に大きな穴が無いようにすることが支援士かつ医療情報技師としてできる貢献なのかなぁ、みたいな。

まとめ

情報処理安全確保支援士になりました。いろんな立場の方との相互理解に努め、ヒアリングを通じて不安に名前をつけ、合理的かつ利便性の高い情報処理安全確保の支援をしていきたいと思います。

そのためには今までやってきたマネジメントやコーチングといった経験が活きるでしょうし、自分のWILLであるベストプラクティスを現場に落とし込むことも役立つはずです。情報セキュリティの知識を常にアップデートしつつ、課題解決に貢献できるエキスパートとして成長していきます。

Gradle用のGitHub Actions勘どころ（2024年夏）

前回に引き続き以下略。

jarファイルのビルドはコンテナの外で行う

ビルドをコンテナの中で行う場合、工夫がなければ毎回はじめからコンテナのビルドが走ります。これはパフォーマンス上好ましくないので、GitHub Actionsのキャッシュ用APIだとかRepository Cacheだとかを使ってビルド性能の改善を図れます：

docs.docker.com

ただGradleプロジェクトの場合はGradle自身が常に同じビルド結果を生成するように動作してくれますので（JVM toolchainとかreproducible buildsとかの話ね）、jarファイルのビルドはコンテナの外でやって Dockerfile では COPY するだけでも良さそうです。この場合は actions/setup-java のキャッシュ機構やRemote Gradle Build Cacheなどを簡単に使えます。

pushとpull_requestで別のワークフローを使う

PR向けのGitHub Actions workflow runが走っているタイミングでPRをマージすると、push時に走るはずのGitHub Actions workflow runが実行されない！という問題があります。ワークフローを分けることで回避できるため push.yml と pull_request.yml とを別に定義してreusable workflowをコールする方法を採ると良さそうです。

# .github/workflows/push.yml
on:
  push:
    branches:
      - main
jobs:
  build:
    uses: ./.github/workflows/reusable-build.yml
    secrets: inherit
  deploy:
    uses: ./.github/workflows/reusable-deploy.yml
    secrets: inherit
    with:
      environment: production

# .github/workflows/reusable-deploy.yml
name: Deploy
run-name: Deploy ${{ github.sha }} to ${{ inputs.environments }}
on:
  workflow_call:
    inputs:
      environment: ...

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    permissions: ...
    steps: ...

プロジェクトを増減させやすいtfactionプロジェクトを書きたい

私はTerraformを使うときにtfactionを利用しています。tfactionはGitHub ActionsとS3やGCSのような永続層だけでTerraformをいい感じに管理できるのでオススメです。

suzuki-shunsuke.github.io

ところでプロジェクトの増減はTerraformの難しいところだと思っていて、OIDCで認証するサービスアカウントの作り方とか権限の設定とか、新規に作成したプロジェクトの初期化や設定がなかなかTerraform単体では完結できなかったりします。手順書を作っておいて全部手動でやるのもいいのですが、できるだけTerraformで記述する方法を考えてみました。

前提となるプロジェクト構成

以下、特に断りのない場合、Google Cloudを前提としています。

プロジェクトは環境（staging, productionなど）ごとに1つ作成します。例外としてArtifact RegistryやCloud DNSを管理する共有プロジェクト（shared）がひとつあります。これはstagingやproductionのサービスアカウントがsharedのArtifact Registryに対して読み書きする権限が必要ということで、権限管理のキモのひとつです。

flowchart TD
  staging --> shared
  production --> shared
  shared

GitHub ActionsからのログインにはOIDCを利用します。これはWIP（Workflow Identity Pool）が早い段階で必要になることを意味しています。ブランチ戦略に従ってWIP Providerのattribute conditionを設定する必要があるので、たとえばproductionにはmainブランチからしかデプロイしない、といったルールは先に決めておきます。

プロジェクトの作成フローを定めておく

プロジェクト作成の大まかなフローは次のようになります。moduleはこれらの複数のステップに跨ることがないように作成しておくと良さそうです：

• プロジェクト作成（scaffold workdir）
• 課金の有効化（手動）
• 各種サービスの有効化（google_project_service）
• terraform plan用サービスアカウント, terraform apply用サービスアカウント, WIPなど作成（モジュール）
• terraform plan用サービスアカウントとterraform apply用サービスアカウントがGCSバケットにアクセスできるようにする（同上）
• terraform plan用サービスアカウントとterraform apply用サービスアカウントの切り替え（workdirのtfaction.yaml更新）

ここまではプロジェクトの作成や他のプロジェクトに属するサービスアカウントの作成ができる、強めの権限を持つサービスアカウントを使います。ここからは他のプロジェクトには影響できないサービスアカウントだけで済むはずです。以下のような手順になります：

• firebaseプロジェクトの作成（手動）
• サービスアカウントの作成と権限設定（他プロジェクトにあるArtifact Registryなどを含む）
• リソースの作成
• notification channelの作成（手動）

サービスアカウントの作成とリソースの作成は同じmoduleでやって大丈夫ですが、他プロジェクトにあるリソースのIAM設定を考えると分けておいても良さそうです。Cloud RunがArtifact Registryに接続できなくてterraform applyに失敗した、とかはよくやります。

workdirの作り方

workdirは少なくとも3種類を持つようにします。これはわかりやすさはもちろん、 terraform apply 等を実行するサービスアカウントの権限を単純にするためにも有効です：

• プロジェクトやフォルダを作成・管理するworkdir
  • google_folder
  • google_project
  • google_app_engine_application
  • google_project_service
• 共有プロジェクト内のリソースを管理するworkdir
  • google_artifact_registry_repository
  • google_storage_bucket
  • google_dns_managed_zone
• 各プロジェクト内のリソースを管理するworkdir

プロジェクトやフォルダを作成・管理するworkdirは main.tf 内に直接処理を書きますが、他のworkdirは適宜moduleに処理を委譲するような書き方が良さそうです。共有プロジェクト内のリソースを管理するworkdirでは、接続を許可するプロジェクトのIDを locals.tf に定義して使うようにすると、プロジェクト増減時の手順が簡素化されます。

moduleの作り方

「各プロジェクト内のリソースを管理するworkdir」の処理はmoduleとして実装しておくことで、workdirに似たような処理を書いて回る手間がなくなります。tfaction 1.3.0からローカルモジュールの扱いがより便利になったので、ローカルモジュールを使う上でのハードルも下がってます。

suzuki-shunsuke.github.io

「各プロジェクト内のリソースを管理するworkdir」が使うモジュールは先ほど整理した作成フローをもとに、以下の種類に分けられます：

• 各種サービスの有効化（プロジェクトを作成して課金を有効にした後で行う）
• terraform-plan用サービスアカウント, terraform-apply用サービスアカウント, WIPなど作成（これは他のworkdirでも使える）
• リソースの作成

ひとつのモジュールが複数のステップを担っても問題ありませんが、前提ステップが終わるまで後続ステップを進めないことを確実にできるように、リソース間依存やvariableを使う必要はありそうです。

まとめ

サービス運用中はこういった観点を意識できてなかったりして、いざ環境を増やすぞというときに苦労するということが自分は多かったので、しばらく今回まとめたmoduleやworkdirの書き方を意識してみます。

Javaで覚えておくと便利かもしれないクラス・インタフェース7つ

Twitterでこれ↓が流れてきて、あれーあのクラスは無いんだー、まぁ最低限と言われると違うかもなー。と思うのがあったので便乗。

nowokay.hatenablog.com

java.util.Objects

recordの導入で不要になってきたメソッドも多いが、引数の検証などでまだ出番がある。防御的な書き方を簡単にしてくれるのでおすすめ。

java.util.Scanner

標準入力を受け取ってゴニョゴニョするツールを書くのに便利。競技プログラミング御用達。

java.util.concurrent.Executors

スケジュール実行とか、スレッドを立ち上げてなんかするとか、そういうときに役立つ。

java.util.concurrent.CompletableFuture

JavaにPromiseって無いんですか、と言われたらCompletableFuture があるよ！と返してます。

java.time.Instant

時刻を表すのに便利。でもInstant.now() は使わずに Clock#instant() を使うんじゃよ。

java.time.Clock

Instant.now() や System.currentTimeMillis() などを使いたくなったら、代わりに Clock をコンストラクタインジェクションして使うようにしよう。テストが書きやすくなるので。

java.lang.AutoCloseable

このインタフェースを実装しておくとtry-with-resourcesでお片付けできるようになる。 状態を持つクラスで、かつ依存先を開放するclose() や stop() というメソッドがある場合に便利に使える。

まとめ

java.util パッケージは便利なクラスが多いので眺めておくと良さそう。

docs.oracle.com

組織変革を成功させるために脳科学を理解すると良いという話が面白かった

ハーバード・ビジネス・レビューで紹介されていた「CHANGE 組織はなぜ変われないのか」を読みました。ざっくり言うと、変化の早い時代における脅威と機会に組織として向き合う方法をまとめた本です。理論と実践が程よいバランスで書かれていて、現場のために書かれている本だと感じました。

CHANGE 組織はなぜ変われないのか

紙上の空論とは一線を画した、適用可能な解決としてのデュアル・システム

この本は階層型組織は動きが遅いから機会を活かせないのでやめよう！みたいな極端な主張とは一線を画していて、階層型組織の安定性や脅威への対応能力を一定認めたうえで「機会を活かせないのはなぜか？」を脳科学という切り口から解決を検討し、一般化された回答としてのデュアル・システムを提示しているのが良いです。こういう本が読みたいんですよ私は。

もちろんデュアル・システムを動かすうえでの課題はあります。ひとりが2つ以上の組織に所属する難しさはマトリックス組織や兼務でさんざん知られているところですし、そもそも仕事で自発性なんて発揮したくない・発揮できない人もたくさんいます。そしてこうした問題への解決はケース・バイ・ケースですから、この本にはズバリの回答は載っていません。

ただその組織設計の根っこにある「人間の頭脳は脅威と機会に対してどのように反応するか」という知見はおおむね一般的なものだと考えられますし、M&Aや工場閉鎖などの成功事例もいくつか載っていますので「自分のケースだったらどうできるか」を検討する材料はあります。ので人間を束ねる立場の人はとりあえず読んでみて損はないんじゃないでしょうか。オススメです。

経営や組織運営の難度が上がった、というよりは、ゲームが変わってきている

ところで最近の組織論は人間のポテンシャルを引き出すためのコミュニケーションにピンを留めているものが多い、と感じます。ちょうど恐れのない組織と両利きの経営を読んだあとだったのでそう感じるだけかもしれませんが、どのindicatorに着目しろとかどんな分析や予測をするべきとかじゃなくて「人間というのはこういうナマモノなのだから、それを織り込んで組織を回していこうぜ」という組織活動を検討するときの根本に揺さぶりをかけるものが多いです。

は？そんなの当然っしょ、んなもん10年以上前からそうだよ。という方も多くいらっしゃると思います。実際私の前職も現職も、人間の多様性とポテンシャルに注目した組織作りをしています。古典であるドラッカーですら、目標管理というコミュニケーションに注目していたわけですし。

ただ、そうでない組織も実際まだまだ多いのです。外の人と話をしていると、社内政治がどうのとか、派閥がどうのとか、リモートワークは誠意がなくてけしからんとか、飲み会や運動会に全員参加をとか、そういう人間の多様性を尊重するよりも会社人・社会人という一様化を適用して扱いやすくすることに心を砕いているところがまだ多数派なんじゃないかと感じさせます*1。

そしてそういう組織に限って、いい人が取れないとぶちぶち言ってるんですよね。いや組織づくりを変えればいい人取り放題とは言いませんよ。いつでもどこでも採用は困難です。ただゲームが変わっていることに気づかないまま前時代的な組織づくりや採用をしていても、そりゃ刺さらないよねとしか思わないのも確かです。

良い組織を作ることはお客様によりよい問題解決を届けるだけでなく、自社の採用ひいては事業継続性にも資する行為だと思うので、こういうビジネス書がたくさん出て意思決定層にきちんと届くことはとても重要だろうなぁと思いました。

*1:念の為に書いておくと、飲み会もオフでの繋がりも出社もとても重要だと思っています。だからこそ全員にひとつを求めるのではなく、全員が何らかの形で繋がれるように複数の場を設けることが必要だという主張です。

自分のなかにあったリーダーシップに関する固定概念

自分のなかにあったマネジメントに関する固定概念の続き。リーダーシップに関する固定概念を棚卸しして自覚的になるためにまとめます。

リーダーシップとマネジメントの違い

自分の中ではこれはかなり明確です。私はVisionary Leadership and Strategic Managementという言葉を多用していますが、マネジメントが戦略的に地盤を作ってリーダーシップがその上でreactiveに問題解決に動くイメージ。例えば文化を醸成してガードレールを用意するSREはマネジメント的だと言えます。

他の観点から言うと、私が言うマネジメントはドラッカーが提唱するものを指していて、ほぼほぼ経営のことです。顧客の創造に必要なことは全部やる。しかし「やる」というのは直接手を下すことではなく、権限委譲や組織文化づくり、つまり「自分より強い人に気持ちよく働いてもらう」ことを指しています。だからこそのビジネスモデル、だからこその目標設定です。なお自分のマーケティング側の解像度がイノベーション側のそれよりも粗いのが、個人的には課題だと思っていますがここでは割愛。

そしてリーダーシップは現職で田中聡先生が勉強会を開いてくださった、チームワーキング本の定義がわかりやすいです。私の解釈ではリーダーシップとは知的労働者みんなが持つべき「働き方」「新常識」であり、それが目標を握り続けるなどのチームの行動原理を通じて働く上での共通言語として機能します。

チームワーキング　ケースとデータで学ぶ「最強チーム」のつくり方

だからこそ知的労働者が勤める企業においては、少なくともMVVのうちValueはリーダーシップを内包するものになるでしょう。現職の行動指針はまさにそんな感じですし、前職の「問題解決の核になる」もまさにリーダシップのレゾンデートルを表しています。

で、なんでこの「リーダーシップとマネジメントの違い」を一番最初に持ってきたかと言うと、同僚とまずここをすり合わせないと会話が成立しないからなんですね。例えばこちらは同僚が書いたnoteなんですが、このnoteで語られるリーダーは戦略的に組織機能を設計する役割を担っていて、私の定義ではマネジメントに踏み込んでいます。リーダーシップという概念的な話ではなくチームリーダーという具体的な役割について議論しているのだと私は理解しましたが、この理解を敷かずに「それリーダーじゃなくない？」と突っ込むのは違うわけです。ので「リーダーシップとマネジメントの違い」を自分の中できちんと持っておいて、相手の提示した概念とのマッピングを構築しながら議論することが必要です。

リーダーシップとは必ずしも情熱を持っていたりヒエラルキーの頂点に立っていたりするとは限らない

リーダーシップとは熱い情熱を持って部下を引っ張ることではありません。もちろん理想や目標を掲げるのは立派なリーダーシップですし、引っ張ることはリーダーシップの形のひとつではあります。ここで言いたいのは「リーダーが全員そうである必要はない」ということです。むしろ熱い想いを語り続けるあまりに周囲の声や自発性を拾えないようであれば、リーダー失格とすら言えます。情熱型であることはリーダーシップの発現の形のひとつでしかなく、必要条件でも十分条件でもないわけです。

ではヒエラルキーの頂点に立つことはリーダーシップかというと、これも違います。肩書がリーダー業務を楽にしてくれる部分はもちろんあるのですが、リーダーシップとはむしろ顧客や課題に直接接する人間こそが発揮するべきものであり、頂点に立つ人にはそれを邪魔しないことが求められます。よってどちらかといえばマネジメント側の存在だと言えるでしょう。

周囲に影響をめっちゃ及ぼしている方がリーダー適性がないという自己評価を持っている場合、だいたいこのあたりのかみ合わせがズレていたりします。ので、いやいやめっちゃエナジャイズしてますやん、巻き込み力高いじゃん、と思った場合は「リーダーっていろんなやり方があるんですよ〜」みたいな話ができます。

リーダーの言うことは常に同じだが、目標やアプローチはコロコロ変わる

リーダーの言動は常に一致しなければなりません。リーダーが顧客が第一だと言うならば、それは常にそうである必要があります。昨日までは顧客が第一だったけど、今日からは株主を優先します！という人はリーダーではありません。いかに顧客が重要で、そのために我々がどうしたいかを手を変え品を変えて力説する人こそが良いリーダーです。

一方で、良いリーダーが取るアプローチはコロコロ変わります。それは理想（TO-BE）が変わらずとも現実（AS-IS）が変化するためであり、仮説検証を通じた学習が頻繁に行われているためでもあります。先月と今月では見ている指標が変わるでしょうし、昨日と今日では最優先のEpicが変化しているでしょう。だからこそチームは目標を握り続ける必要があります。

ここはリーダーシップの理解がズレると言うか、働き方についての理想像がズレがちなところかなと思っていて、マネージャが働き方の理想像を継続的に発信していく必要がありそうです。

リーダーシップは良いマネジメントに依存している

アプローチや目標がコロコロ変わる必要があるということは、それが可能な勤務体系や評価制度が必要です。例えばプロダクトバックログの順番を変えると混乱をきたすようなコミュニケーションが行われてはいけませんし、半年前に設定した目標の達成度合いで評価されるようでは良いリーダシップは発揮できないということですね。ここはマネージャがリーダーのために心を砕いて戦略的に整備するべきところです。

これは組織内に閉じた話ではありません。目標やその優先度を変えるということは、顧客に提供する価値の内容や順番が変化することを意味します。ですから顧客の理解を得るためのコミュニケーションをすることや、過多なコミットメントを避けることもまたマネジメントには必要です。情報システムで言うならば顧客にビジョンへの共感を持っていただき、具体的な価値を提供し、継続的にブランドを作ることで、UIや機能の変化をポジティブに受け止めていただけるだけの関係性を構築するということです。これはマーケティングであり明確にマネジメントの領域です。

ですからマネージャはリーダシップを理解し、良きリーダーに寄り添えるようにしなければなりません。マネージャの払う工数の大多数はここに突っ込まれるべきなのではと思うことも多いです。

まとめ

マネジメントが「全部自分でやれ」ならリーダシップは「皆を巻き込め」です。ひとりでできない問題解決をするためにビジョンを掲げて人を巻きこむことを指します。 リーダーシップは今日の知的労働者が持つべき新常識であり、その点で採用の時点で考慮するべきものです。MVVや行動指針に組み込むのが一番わかりやすいでしょう。 またリーダーシップとマネジメントは両立します。問題の核となる能力と問題解決に向けた戦略を考えることは、問題解決の両輪であって排他的なものではありません。

という3点が噛み合わないと話がどこまでも発散するので、リーダーやリーダシップについて話すときはその言葉の意味するところや議論の目的を見極めるところから入る必要がありそうです。

自分のなかにあったマネジメントに関する固定概念

中途採用メインの会社に転職して、違うバックグラウンドのひととたくさん話すようになって、自分の中の固定概念というか思い込みや信念みたいなものがよく見えるので、それを言語化しておきたい。

— 新米医療情報技師 (@Kengo_TODA) 2024年1月27日

固定概念、自分の行動を爆速にしていくうえでは非常に有効なバフなんですが、ナチュラルに「あれ？僕またなんかやっちゃいました？」を生産する機会にもなるのできちんと棚卸しして自覚的になっておきたいため、まとめました。

「ちゃんとやる」コストを自分で払う

ソフトウェアエンジニアリング業あるあるだと信じているのですが、この仕事はベスト・プラクティスが積み上がっていて目指すべき働き方が明確なだけに、「ちゃんとやる」ことがとても難しいという問題があります。たとえばRedmineのようなものでチケットを積み上げてガントチャートを消化していくようなプロジェクトであれば、チケットの管理だけでも以下のようなことを「ちゃんとやる」ことが理想です：

1. チケットは最長でも3日でデフォルトブランチにマージできる大きさを保つ
2. 新しく発生したタスクはチケットに落とし込み、DONEの定義についてチームで合意を取る
3. チケットにはチケットを解決するうえで判明した事実やブロッカーを書く
4. 朝会までに変更をpushし、着手していたチケットを更新し、経過を共有できるようにしておく
5. チケットやチャットで判明した事実のうち、ストックするべきと思われた事実はWikiやドキュメンテーションコメントにする
6. チケットは他のチケットやPull Request、デプロイとの紐づけを行い、あとから関係性を追跡できるようにしておく

さて、これをチーム全員ができているプロジェクトはどのくらいあるのでしょうか。無いでしょというのが自分の意見です。これは新卒採用がメインで「走りながら教える」必要があった自分の経験から来ている考え方ではありますが、ベテランが集うプロジェクトでも大差ないだろうと感じています。

ではやっていない人を吊るし上げればいいのか、やれない人に根気よく教えるべきかというと、そうではありません。中途半端なコードの共有に抵抗のある方、状況や考えをテキストにダンプすることが苦手な方、コードを書くときは集中しており終わったら疲れ果てているのでチケットを更新する時間が捻出できない方、他のことに挑戦していてチケット管理の優先度が低い方など、「ちゃんとやれない」背景には様々な事情・個性があります。特に気質や価値観、健康に根ざしている場合は「やれ」と言うこと自体がリスクなわけです。

少し抽象化した表現をすると、自分は企業文化・行動規範以外に「チーム全員に画一的な素質・行動を求める」のは失敗パターンだと思っています。そりゃ面倒をみる側からすればチーム全員がちゃんとチケットを管理してくれれば大助かりです。実際に教えればできるようになるケースも多数あるでしょう。しかししばらく声をかけてみてダメだったり、ヒアリングや観察の結果「いまは難しそうだな」と思ったら、諦めも肝心です。あまりにも致命的で協力関係が築けない場合は除くとして、基本的には自分が「ちゃんとやれる」範囲で手助けするほうが良いでしょう：

1. 新規に作成されたチケットの粒度を確認し、大きすぎると思ったら分割を提案する
2. チケットのDONEの定義が明確ではない場合、チームで話し合いの機会を持つ
3. 考えをテキストに落とせていない場合、朝会でヒアリングしてその場でチケットに書いていく
4. 変更をpushできていない場合、朝会の前後で座席に行って画面を見せてもらう
5. wikiやドキュメンテーションコメントを更新できていない、自分で変更を提案する
6. 紐付けられていないチケットがあれば、自分で紐付けるか、自動化を用意するか、デプロイやレトロスペクティブのタイミングで一緒に紐付ける機会を持つ

こんな考えだからマネジメントに超人性を求めてしまうのだとはわかっていますが、チームワークを円滑に回して組織としてのアウトカムをコミットするのがマネージャである以上、必要なことだとも思います。

実際、こうやって「ちゃんとやる」フォローに回ることで一番メリットを享受できるのは、マネージャである自分自身なんですよね。組織がアウトプットを作れていてアウトカムの実現に近づいているかという、そのプロセスの透明性を見たいですよね。ので「ちゃんと見せろ」と他力本願するよりは、「ちゃんと見に行く」ほうがControllableだし育成の方向性も見えてくるし建設的なはず。

なおマイクロマネジメントとの線引きは自分の中では明確で、「ちゃんと設計できてないから自分で設計する」「ちゃんとテスト書くのが大変だから書いてあげる」「ちゃんと機能追加するのが難しそうだから代わりにやってあげる」あたりはマイクロマネジメント寄りかなと思います。

この判断基準については、最近同僚が「相手のプロフェッショナルに踏み込む」という表現をしていていいなと思いました。相手がプロフェッショナルとしてやるべきところ、やりたいと思っているところには触れない。スクラム回すからには透明性を上げるのもプロフェッショナルの範囲だろうと言う考え方はできるかもしれませんが、そこは先程の「チーム全員に画一的な素質・行動を求める」のは避けるを適用します。

まぁこれ、たぶん真のcross-functional teamをマネジメントしてるとあんまり問題にならないんでは無いかなと思います。そもそもチームメイトと自分のプロフェッショナルがぜんぜん違うんで、代わりにやってあげるという選択肢がそもそも取れない。ので自分がcross-functional teamの経験が浅いことの裏返しなのかなとは思う。

最後まで自分で追いかける

先の例（チケット管理）だと、マネージャじゃなくてスクラムマスターがやればいいのでは？という疑問があるかと思います。もちろんスクラムマスターに委譲するなど、仕組みや委譲で解決できればその方が良いことも多々あります。

それでもそのスクラムマスターがちゃんとやっているか？は自分で見る必要があります。チームメイトの1on1を通じて、スクラムマスターに目指してほしいチームづくりができているか、できていないなら何を変えるべきかを考えていくわけです。またこの姿勢は相手と一緒にDONEの定義を考え、適切な問題空間を設定することに繋がります。チームメイトにとって難しすぎる問題設定を避けるとともに、あとあとで「期待とぜんぜん違うアウトプットが出てくる」リスクに対する対策にもなるため、チームマネジメントにおける重要な姿勢だと言えます。

これはスクラムマスター以外のプロフェッショナルについても同様で、新しいデザインや機能が顧客の課題を解決したのか、新しく導入した品質管理手法はどう作用したのか、作成したドキュメントやツールが現場で使われているのか、実装の最適化でランニングコストやレイテンシは改善されたのか……などをプロフェッショナルと一緒に最後まで追いかけることが必要です。昔の上司が「信頼はするけど信用はしない」と言っていましたが、プロフェッショナルを信頼することとそのアウトプットを確かめもしないことは別なのです。

もちろん他のチームやお客様に対しても同様の姿勢が必要です。依頼したタスクが終わったのか、その効果が出ているのか、やるべきことを忘れていないか……などを追跡することで、組織的な課題がチームの間にこぼれ落ちたり、顧客が必要としていないことにコストを掛けたりといった問題を早期に発見できます。

ここは意外と多くのマネージャが「そこまで私の仕事なの？」と言いがちなところで、まぁ実際マネージャのマネージャや経営がしっかりしてたらマネージャがそこまでやらなくていいよねとか、給料に入ってるんだっけこれという思いも無いわけではないのですが、結論、やったほうがいいですね。チケットのDONEの定義をクリアしたらオッケーなのはチームメイトにとっての話で、マネージャの仕事である「チームとしてアウトカムをデリバリーする（横文字多いな）」はチケットの積み上げからは見えないラストワンマイルがあったりするので、ほぼ例外なくデリバリー先を見に行くことが必要です。そしてこれをやるためにも日頃からのチーム内外との関係性構築が大切で、このためにもマネージャはWorking Loud Outしておくと良いと思います。

developers.freee.co.jp

が、すべてのマネージャがこの考えを持っているかというとそうではないので、あくまでも自分の固定概念だということに自覚的になっておきたいと思いました。

なお、これはマネジメントもそうだけど、リーダーシップを発揮するうえでも必要な姿勢かもしれません。リーダーシップについても近々考えをまとめておきたいです。→まとめました。

マネージャは暇してるべき

自分でやれ、最後までやれと来て、最後がこれか？とは自分でも思います。思いますが、チームの前に立ちはだかる障害を即座に解決してチームをトップスピードに保つためにはやはり必要です。経験的には毎日勤務時間の4割に空きがあって、いつでも1on1や対応工数を積めるくらいの暇さがあったほうがいいです。どんなに定期1on1や朝会などの仕組みを整えてもイレギュラーは発生するので、即対応できる時間はいつでもつかえるようにしておくべきです。

べきですが、ここは自分の考えに柔軟性がなかったなと反省するところで。大企業ならチームの役割も比較的明確なのでこれで回るのですが、そもそも市場を探している段階だったり1人で3つも4つも役割を兼任しないといけない場合だったりすると、そんな暇を抱えてるわけにはいかないのも事実でした。本来マネージャに兼務はご法度なんですが（むしろ兼務自体が滅べばいいとすら思っている）、マネージャをやるということは集まる情報が増えるということなので、その人が複数の役割を持つことは展開としてまぁナシじゃないなという。

この場合、即応するのはマネージャではなくチームメイト同士が有機的に行うことになるはずで、お互いに即助けに入れるくらいチームメイトの仕事と状況を理解していないといけません。cross-functional teamであれば一時的に自分の専門外のことに着手することもあるでしょう。そういう空気や関係性を醸成することのほうが、マネジメントにとっては優先度の高い営みなのかもしれません。

まとめ

自分のなかにあったマネジメントに関する固定概念を一言でいうと「全部自分でやれ」なんですよね。もちろん組織としてのアウトカムをコミットするのがマネージャである以上、マネージャが口にする主語は常にweなんですが、weという存在を円滑に動かす機能の最後の砦がマネジメントなのは疑いないので、文化情勢や仕組みでの解決では漏れてしまうところは常にマネージャが拾い続ける必要があると思っています。

何でもかんでも自分でやる姿勢、一歩踏み外すとマイクロマネジメントや部下の成果をぶんどる系上司になりがちなのはあると思います。自分でやるのか、コーチングするのか、根気よく教えるのか、それとも諦めて別の手段を取るのかという判断基準は「相手のプロフェッショナルに踏み込む」を基本にしつつも相手に依って調整が必要なため、今後も手探りになりそうです。