Inside of LOVOT

GROOVE X 技術ブログ

コードが書けない私が、AIで「めんどくさい」を消した話

こんにちは。GROOVE Xの人事部に所属している貫戸です。

突然ですが、みなさんは「コード」が書けますか?

私は書けませんし、読めません。正直なところ、これから一からプログラミングを勉強するつもりもありません。

そんな「エンジニアスキルゼロ」の私が、今回、AI(ClaudeやGemini)を相棒に、自作の業務効率化ツールをいくつか作ってみました。非エンジニアの私がなぜツールを作ろうと思い、どうやって形にしたのか。その舞台裏をお話しします。

100%マッチするサービスは、なかなか見つからない

人事をはじめとする管理部門では、日々たくさんの外部サービスを使って業務を効率化しています。世の中のサービスは年々進化していて、本当にありがたい限りです。

ただ、「自社のこの運用に100%マッチしている」というサービスには、なかなか出会えません。どれも惜しくて、いわゆる「かゆいところに手が届かない」状態です。

これまでは、その「あと少し」の隙間を、人が手作業でデータをコピペしたり加工したりして埋めていました。これが地味に手間ですし、手作業ゆえに「ヒューマンエラーが起きたらどうしよう」という不安も常にあります。

「使い慣れたスプレッドシートやマクロで、なんとかするしかないのかな」と、半ば諦め、自分の手を動かすスピードや精度をより高めようとしていました。

「どうせ、そっち側の話」と割り切っていた私

実を言うと、私は新しいテクノロジーが登場すると、なんとなく自分に関係がないことと思う節がありました。 AIの発展など、新しいものが登場するスピードはあまりに速い上に高度。だから「最先端のものはその筋にいる人が関係するもの」と漠然と自分ごとにせず、蚊帳の外においている感じでした。

社内のエンジニアさん達が「AIがさ」と盛り上がっているのを見ても、「とはいえ、ある程度専門性を持っている人のためのものでしょう」「こういう高度なテクノロジーを扱うのはエンジニアの仕事」と、自分は門外漢だと割り切っていました。今にして思えば、割り切ることで自分のコンフォートゾーンを守っていたのだと思います。

そんな私の心を動かしたのが、ある日のオフィスでの一幕でした。

転機:「あれ、貫戸さんも使えるよ」

よくお話しするエンジニアさんが「あれ、貫戸さんも使えるよ」とAIを勧めてくれました。

とはいえ、普段エンジニアさんと話していると、意味のわからない単語もたくさんでてきて、到底、詳細まで理解できない私が使えるわけがない、お金の無駄なのに、すすめてくれるなんて、「エンジニアさんって、非エンジニアのリテラシーの低さをわかっていない」とさえ思いました。

一方で、先端テクノロジーを使いこなす人への、嫉妬に近いうらやましさを少し感じていたので、「ダメ元でやってみよう」とAIをインストールすることにしました。 AIに何をどう打ち込めば動くのか、なにもわかりませんでしたが、なんとなく、触ってみました。

「えいやっ」から始まった、ツールづくり

最初にチャレンジしたのは、「従業員の勤務時間の把握と分析のためのツールづくり」でした。 弊社には裁量労働制、フレックスタイム制、変形労働時間制など、メンバーに合わせた多様な働き方があり、市販の勤怠管理システムから「私が本当に見たいデータ」を一発で出すのは難しい状態でした。

最初はAIに「何をどう伝えればいいのか」がまったく分かりませんでした。それでも「とにかく困っていることを、そのまま日本語でぶつけてみよう」と、思い切って入力してみたのです。

すると、やり取りは意外なほどスムーズに進み、欲しかったツールがHTMLで形作られていました。そこから、試して、検証して、足りないものをみつけて、AIにフィードバックして、つくりなおす、を繰り返すと、1時間半ほどでイメージしていたものが完成してしまいました。

なぜ、想像していた以上にスムーズに進んだのか。それは「頭の中に私が欲しいものの完成図がある程度イメージできていたから」だと思います。HTMLがなになのか、どういう仕組みなのかはわかっていなかったですが、「どんな時に使って、最終的にどんなデータが画面に出てほしいか」というゴールが明確だったからこそ、私のイメージを、AIを使って形にできたのだと思います。

ちょっとテンションがあがり「もしかして、みんなの『めんどくさい』も、AIで解決できるのでは?」と考えた私は、チームメンバーに「何かめんどくさい作業ってない?」と聞いてみました。「なにがめんどくさいのか」「なにに時間がかかっているのか」などざっくばらんにリアルな声を集め、自分の領域だからこそ分かる業務理解を活かして、効率化ツールをAIと一緒に作っていきました。

たとえば、定型のメール文面や文書を、コピペよりも速く・確実に用意できるツール。あるいは、勤怠データの誤入力を見つけ出すツール。どれも派手ではありませんが、毎日の「ちょっとした手間」や「見落としたらこわい確認作業」を、地道に軽くしてくれるものばかりです。

AIを動かす最大のコツは「自分のためのローコンテキスト」

試行錯誤の中で気づいた、私なりの「AIを使いこなすコツ」があります。それは、AIに対して徹底的に「ローコンテキスト」で話すことです。 AIには、人間同士のような「言わなくても察してよ」は通じないので、背景や前提知識から丁寧に伝えることは大切です。 しかし、この「ローコンテキストで細かく伝える」作業は、AIのためだけではなく、何より自分自身のためでもあった、ということに気付きました。

作りたいもの、イメージしているものを言葉にするプロセスそのものが、自分の頭の整理になりました。「私はここを自動化したかったんだ」「最終的にはこのデータがこう見えればいいんだ」と、言語化することで、ぼんやりしたイメージの輪郭がどんどん具体的になっていきました。AIに伝えるための言葉は、自分自身のゴールを研ぎ澄ますための言葉でもあったのです。

AIは「課題を発見できた人」が使うべき道具

実際に手を動かしてみて、強く実感したことがあります。 当たり前かもしれませんが「AIは決してエンジニアさんだけのものではない」ということです。

もちろん、高度で専門的なシステムを構築するのはエンジニアさんの領域です。しかし、日々の業務の中の「ここが不便だな」「もっとこうなればいいのに」という小さな引っかかりをスルーせずに、「課題」として少し捉えてみる...大袈裟かもしれませんが、いわゆる「課題発見」できる人こそAIの価値を発揮できるのだと思います。

現場のリアルな課題や事情を知らなければ、どれだけ技術があっても、本当に有益なものは作れません。逆に「課題を見つける力」と「こうしたいという理想のゴール」さえあれば、コードが書けなくてもAIがその隙間を埋めてくれます。

使ってみて改めて思いました。「AIも結局は道具なんだな」と。 道具は、置いておくだけでは何も生みません。とにかく使ってみること。使っていれば、そのうち手が慣れていきます。そして、その道具を役立てられるかどうかは、使う自分次第だと痛感しました。

テクノロジーが変わっても、大先輩たちが教えてくれたこと

「置いておいても仕方ない、使ってみよう」。そう思えたとき、ふと思い出したのは、新卒で入社した会社の先輩たちの姿でした。

私の親よりも年上の大先輩たちが、オフィスで当たり前のようにパソコンを使いこなしていた光景です。彼らが新入社員だった頃、職場にパソコンはまだ少なく、スマートフォンも影も形もありませんでした。業務の主役が「電話と紙」だった世代です。

そんな大先輩たちが、時代とともに現れた「パソコン」や「アプリ」を、長いキャリアの中で自分の道具として手懐け、当たり前に使いこなしてきた。その歴史を思えば、AIを使いこなすのも難しいことではない、と思えるのです。

テクノロジーの形が変わっても、人が新しい道具を使いこなして仕事をより良くしてきた営みは、ずっと地続きです。私たちの世代にとって、それがたまたま「AI」という道具になった。ただ、それだけのことなのだと思います。

人事として思うこと:「優秀さ」の要件は変わっていく

「組織と人」に関わる人事という仕事をしているので、最近は「AIという強力な道具を誰もが使えるようになったこれからの世界では、ビジネスパーソンに求められるものってなんなんだろう?」と考えてしまいます。

これまでは「知識をたくさん持っている人」や「特定の作業が速い人」が優秀だとされてきた側面は、少なからずありました。 しかし、これからの優秀な人の要件は変わるはずです。 そして、AIはこれからもっと進化していくでしょうし、AIの次にも、新しいテクノロジーがどんどん登場するはずです。その度に、人に求められることは変わっていくのだと思います。

そのときの「優秀さ」の要件が何なのかは、分かりません。 ただ、これまでの自分の得意に固執するのではなく、新しいことを自然に楽しく学ぶことができる人は強いと思います。加えて、テクノロジーで代替が難しい交渉・共感・巻き込みといった人間的な活動ができる人はより重宝されるような気がします。

今回の小さな挑戦は、そんな「これからの優秀さ」の片鱗に、期せずして触れる体験だったのかもしれません。

いくつかのツールが完成した今、人事部の「ちょっと惜しい、かゆいところ」は、自分たちの手でスッキリ解消されつつあります。なにより、「自分でできた」という達成感は、想像以上のものでした。

背中を押してくれたエンジニアさん、そして温かく見守ってくれる社内のみなさん、いつもありがとうございます。 これからもGROOVE Xのバックオフィスと組織のあり方を、少しずつ進化させていきたいと思います。

PBI作成のポイントを学ぶ

こんにちは。GROOVE Xのビジョンチームの長江です。普段は画像認識の結果とLOVOTの行動を結びつけるお仕事をしております。

先日、社内で「PBI(プロダクトバックログアイテム)の作り方」をテーマにしたワークショップが開催されました。これまでなんとなくPBIを作ってしまっていた自分にとって非常に学びが多かったため、今回はその内容と当日の熱い議論の様子をシェアしたいと思います。

TL;DR

  • PBIは「誰のため」「何をするか」「受け入れ条件(AC)」を明確にすることが重要である
  • PBI の作成における3つの型:
    • 「誰のために何をするか」は「ユーザーストーリー」で記述する
    • 「受け入れ条件(AC)」は「アサーション形式(完了状態)」で記述する
    • 大きなPBIは、「バーティカルスライス(縦分割)」する → 早期にフィードバックを得られる
  • ワークショップは「教えない教え方」に則り、講師が教えるのではなく、参加者が自ら学ぶ形で楽しく進められた

背景:タスク化してしまうPBI

日々の開発業務の中で、皆さんはどのようにPBIを作成しているでしょうか。

私はこれまで、PBIを書いているつもりで、実際にはただの「作業タスク」を登録してしまっていることがよくありました。また、詳細をどこまで書き込めばいいのか悩んだり、開発を進めるうちに「そもそもこのPBIって最終的に誰が嬉しくなるんだっけ?」と目的を見失ってしまったりすることもありました。

今回のワークショップは、そうした「良いPBIとは何か?」という疑問を解消し、適切に価値を届けられるPBIを作れるようになることを目的としていました。


ワークショップの流れ

このワークショップは、講師が一方的に知識を教える講義形式ではなく、「教えない教え方(Training from the Back of the Room)」という手法に基づいて設計されていました。

当日のタイムラインは以下のような、常に参加者が手を動かし、話し合う構成でした。

  1. 宿題の持ち寄り&ペアワーク(10分):事前に各自が手元に用意してきた「目的のわからなくなった過去のPBI」をベースに、「これって誰が嬉しくなるんだっけ?」を隣の人と議論。
  2. 「3つの型」の調査(26分):3つのグループに分かれ、「ユーザーストーリー」「アサーション形式」「バーティカルスライス」という3つの型を各チームが別々にWebや社内ツールで調査し、全員に教え合う。
  3. 実践・ブラッシュアップ(42分):学んだ型をもとに自分のPBIを書き直し、社内AIツール(/pbi-helper)でレビューを受け、さらに「1スプリントに収まるか?」を検証して縦に分割する。
  4. 決意表明(8分):次のスプリントから自分の何を変えるかを付箋に書いて共有。

当時はエアコンの設定ミスにより会議室が寒かったこともあり(笑)、多くのメンバーが立ち上がり、終始賑やかにディスカッションが行われました。


ワークショップで学んだ「3つの型」と、なぜ採用するのか

ワークショップの中盤では、良いPBIを形作るための3つの型について、それぞれの特徴と採用するメリットを学びました。

1. ユーザーストーリー

  • 概要:誰の、どのような欲求を、なぜ叶えたいのかという要求の構造を示す手法です。
  • なぜ採用するのか:実装方法(How)ではなく「何を達成するか」に焦点を当てられるため、関係者間でギャップを埋める対話のきっかけになります。一目で「誰のための価値か」が伝わるため、チームが目的を見失わずにすみます。

2. アサーション形式

  • 概要:PBI が達成された時の状態を宣言する形式です。
  • なぜ採用するのか:多くのPBIで書かれがちな「〜を実装する」という行動の宣言ではなく、「達成された状態」を定義します。完了が観察可能になるため、スプリント終了時に「この条件は真か偽か」を客観的かつ明確に判定できるようになります。

3. バーティカルスライス

  • 概要:PBIを「小さく動く、実行可能な体験単位」で縦に切っていく手法です。
  • なぜ採用するのか:調査、設計、実装、テストと「横分割」してしまうと、途中の段階では何も動くものがなく、フィードバックが得られません。貧弱であっても全層がつながった「縦の体験」を作ることで、早く反応を得られます。これにより改善のサイクルが早く回り、リスクを抑えながら優先順位を柔軟に変更できるようになります。

3つの型を組み合わせるメリット

これら3つの型を組み合わせることで、「誰のためか伝わり(ユーザーストーリー)」「Doneが客観的に判断でき(アサーション)」「1スプリントで完結するサイズに収まる(バーティカルスライス)」という、非常に健全で強力なPBIが完成します。


ワークショップで白熱した議論と私なりの答え

ワークショップの中では、綺麗に答えが出るものばかりではなく、メンバー間で議論になったり、答えが出ないまま次に進んだりする場面もありました。そこから私自身が作業を通して至った気づきを紹介します。

「ユーザーストーリー」と「アサーション形式」の矛盾と、私なりの答え

ワークの途中で、あるメンバーから「ユーザーストーリー形式とアサーション形式って、何が違うの? 併用できるの?」という疑問が出ました。

スマホでAIに検索して聞いてみたメンバーが「AIによると、この2つは同時に満たそうとすると相性が悪いらしい。ユーザーストーリーはユーザーの欲求を描くけど、アサーションは既成事実の断言だから、一緒にすると欲求の性質が消えちゃうんだって」と報告。 一同「難しいな……」「結局タイトルとAC、どっちをどう書けばいいの?」と頭を抱えてしまい、その場では明確な結論が出ないまま、モヤモヤを残して一旦次のワークへ進むことになりました。

しかし、ワークショップの後半で実際に自分のPBIを書き直したり、3つの型を組み合わせるワークを進めたりしていく中で、私はハッとさせられる自分なりの答えに行き着きました。

これらは対立する手法としてどちらかを選ぶのではなく、PBIの中でパーツごとに役割分担をすればいいのではないか、ということです。

  • Why(目的・価値の方向性):ユーザーストーリー視点で「誰のどんな価値のためか」を明確にする。
  • 受け入れ条件(AC):アサーション形式で「どうなったら終わりか」を断言し、完了判定を客観的にできるようにする。

ワークショップ全体としての共通見解が出たわけではありませんでしたが、自分自身の中でこの2つの役割が綺麗に繋がり、PBIにおいて重要な「誰のため」「何をするか」「受け入れ条件」と今回学んだ「ユーザーストーリー」「アサーション形式」の結びつきを納得できた瞬間でした。


結論:良いPBIを作るための3つの型

これらを踏まえ、ワークショップで私が学んだ最終的な到達点がこちらです。

  1. ユーザーストーリー: 〈誰〉として / 〈何〉したい / なぜなら〈理由〉だから
  2. アサーション形式: 〈状態になっている〉(作業ではなく達成状態を断言し、完了を判定可能にする)
  3. バーティカルスライス: 大きすぎるPBIは、早期にフィードバックを得るために「小さく動く縦の体験」に切り出す

本質的に重要なのは、PBIを「やるべき作業(タスク)」ではなく、届けるべき「価値」と「達成されるべき状態(アサーション)」で表現することです。

おわりに

これまではPBIを「作業の備忘録」程度に捉えて適当に登録してしまうこともありましたが、今後は学んだキーワードを意識しつつ、社内の /pbi-helper を賢く活用して「きちんとしたPBI」を作っていきたいと思います。まずは次のスプリントプランニングから、この形式を試してみるつもりです。

社内向けにGoogle Cloudのread-only MCPサーバーを追加しました

こんにちは。Kiban ワーキンググループ、クラウドチーム所属のPeacock (id:peacock0803sz)です。

TL;DR

roles/viewer ベースで機密情報を取得する権限を削ったIAM Roleを作成して googleapis/gcloud-mcp をサービスアカウントにimpersonationして実行することで安全に実装しました。

cloud.google.com

何を作ったのか

今回追加したのはGoogle Cloud向けのread-only MCPサーバーです。

  • ローカル版: Claude Code, Codexから使うstdio MCP
  • リモート版: Cloud Run上で動かし、Claude.aiのCustom Connectorから使うMCP
    • こちらをClaude CodeやCodexからも利用することも可能

バックエンドは自作せずGoogleが公開している googleapis/gcloud-mcp をラップする構成にしました。

github.com

狙いは単純で、エージェントからGoogle Cloudを自然言語で参照できるようにしつつ、書き込み操作はIAMレベルで不可能にすることです。

背景

社内でCoding Agentを使う場面が増え、GitHubやGoogle Sheets、esaはMCP経由で触れるようになってきました。
ただ、日常的に見たい情報の多くはGoogle Cloud上にあります。

  • 組織配下のプロジェクト一覧
  • Cloud Runのサービス状態
  • GKEクラスタやCloud SQLのメタデータ
  • BigQueryのdatasetやtable schema
  • IAMやResource Managerの構成

こうした参照系の操作をエージェント経由で扱えれば、調査やトラブルシュートの入口はかなり速くなります。

とはいえ、単純にgcloud CLIを叩けるMCPを生やせば済む話ではありませんでした。
Google Cloudは当然ながら権限のかかる操作が多く、read-onlyをきちんと設計しないと、便利さより先に危険さが立ってしまいます。
このread-only (読み取り専用)権限をしっかり設計しないと、AIが間違って削除や編集などの破壊的な操作を実行できてしまう可能性があるからです。

採用した構成

今回の構成を一言で言うと「gcloud-mcpをread-onlyなサービスアカウントとして動かす」です。

ローカル版

ローカル版は @google-cloud/gcloud-mcp をnpxで起動しつつ、MCPサブプロセスの環境変数としてimpersonation先のサービスアカウント(以下、SAと略記)を渡しています。

{
  "mcpServers": {
    "gcp-readonly": {
      "command": "npx",
      "args": ["-y", "@google-cloud/gcloud-mcp"],
      "env": {
        "CLOUDSDK_AUTH_IMPERSONATE_SERVICE_ACCOUNT": "readonly@example.iam.gserviceaccount.com"
      }
    }
  }
}

ここで大事なのは gcloud config set auth/impersonate_service_account ... のような永続設定の書き換えをしていないことです。
設定はMCPサブプロセスの env に閉じているので、普段ターミナルで使っているgcloud CLIの設定には影響しません。

この CLOUDSDK_AUTH_IMPERSONATE_SERVICE_ACCOUNT 環境変数は特殊な裏ワザではなく、gcloud CLIの設定プロパティ auth/impersonate_service_account に対応する環境変数です。
Google Cloudは各プロパティが CLOUDSDK_SECTION_PROPERTY 形式の環境変数に対応すると説明しており、 auth/impersonate_service_account 自体も公式の設定プロパティとして定義されています。

cloud.google.com

cloud.google.com

リモート版

リモート版はCloud Run上に載せています。
auth-proxyが gcloud-mcp をstdioの子プロセスとして起動し、Claude.aiなどのクライアントからHTTP経由で使えるようにしています。

Cloud Run版ではimpersonationを使わず、ランタイムのサービスアカウントそのものをread-only用の専用SAにしました。
これならApplication Default Credentialsが自動でその権限のトークンを返すので、コンテナ内で追加の認証処理は不要です。

cloud.google.com

コンテナイメージには google-cloud-cli@google-cloud/gcloud-mcp をビルド時に入れています。
npx の毎回フェッチに依存させず、Cloud Runのcold startを少しでも軽くするためです。

Viewer / Readerはread-onlyではない

今回いちばん重要だったのはここでした。

gcloud-mcp 自体には --readonly のようなフラグがありません。
つまり、read-onlyを保証したければ、MCPの上ではなくIAM側で保証するしかありません。

最初は roles/viewerroles/reader を使えばよさそうに見えます。
ただ、実際は「破壊しない」だけで、「副作用がない」とは言えません。

たとえばBigQueryでは bigquery.jobs.create が含まれており、クエリを実行できます。
これは課金も発生しうるので、今回求めていた厳密なread-onlyには合いません。

そこで、組織スコープのカスタムIAMロールを作り、

  • *.get
  • *.list
  • *.getIamPolicy

のような読み取り系権限を中心にホワイトリストで定義しました。

逆に、次のようなものは除外しています。

  • bigquery.jobs.create
  • secretmanager.versions.access
  • storage.objects.get
  • *.create*.update*.delete*.patch*.use

特に storage.objects.get は、レビューで「これはメタデータではなくオブジェクト本体も読める」という指摘を受けて削りました。
この修正は、read-onlyという言葉をどこまで厳密に捉えるかを考えるうえで象徴的でした。

単に「変更しない」だけならViewer, Readerでも十分な場面はあります。
でも今回ほしかったのは、副作用がなく、過剰なデータアクセスも避けた、調査用の読み取り権限です。そこはカスタムロールを作るのが正解でした。

監査ログも設計し直した

リモート版では、Cloud RunのランタイムSAを共通で使う構成にしています。
この形はread-onlyの共通ゲートウェイとしては扱いやすい一方、Google Cloud側の監査ログはサービスアカウント単位で残ります。

そのままだと、

  • 誰が
  • どのMCPツールを
  • どんな引数で呼んだのか

が分かりにくくなります。

そこでauth-proxy側に構造化ログを追加し、caller emailとtool callをCloud Runログに出すようにしました。
GCP側の監査ログだけでは埋まらない部分を、アプリケーションログで補う設計です。

ここもレビューで論点になりました。
引数をそのままログに出すと、将来的に機密情報が混ざる危険があります。今回はGoogle Cloud参照専用で、そもそもsecret本体やobject本体に触れにくいロール設計にしていたため、そのまま残していますが、別のバックエンドを追加するときには見直しが必要だと思っています。

どう使えるようになったか

このMCPを追加したことで、たとえば次のような依頼がエージェント経由でできるようになります。

  • 組織配下のプロジェクト一覧を見せて
  • 特定プロジェクトのCloud Run一覧を見せて
  • GKEクラスタの一覧を見せて

逆に、次のような依頼は権限で弾かれます。

  • 新しいプロジェクトを作って
  • BigQueryで SELECT 1 を実行して

後者が失敗するのは一見不便ですが、今回の目的からすると正しい挙動です。
調査用の閲覧とデータプレーンの実行は分けて考えるべきで、必要なら将来的に別のMCPを設計した方が安全だと思っているためです。

おわりに

今回の実装は、MCPを1つ追加したというよりも「エージェント経由で安全にGoogle Cloudを読むための境界を設計した」という方が実態に近いです。

今後BigQueryのクエリ実行やGCSオブジェクト内容の参照のような、よりデータプレーン寄りの操作をエージェントに渡したくなったら、それはread-only MCPの拡張ではなく、別の権限設計と監査設計を持った別サーバーとして切り出す予定です。

スクラムマスターと領域人事は、いずれ不要になるべき役割である

こんにちは。GROOVE Xのスクラムマスターの niwano です。
スクラムマスターと「領域人事」の兼任についての最終回です。
(この記事はAIと一緒に書いています。)

このシリーズで一貫して伝えたかったこと

ここまで、

  • なぜスクラムマスターが領域人事を兼任することになったのか
  • 人事権のない人事というロールの意味
  • どこまで関わり、どこから引くのか

という話をしてきました。

この最終回で伝えたいことは、実はとてもシンプルです。

スクラムマスターも、領域人事(組織開発ファシリテーター)も、 いずれ不要になるべき役割である

アジャイルやスクラムの思想に、かなり忠実な結論です。


スクラムマスターは「チームが未成熟な証」なのか?

時々、こんな意見を見かけます。

スクラムマスターが必要な時点で、
チームはまだ自己組織化できていないのでは?

半分正解で、半分不正解だと思っています。

正確には、

スクラムマスターは、自己組織化へ向かう途中に必要な役割

です。

  • スクラムを理解する
  • 経験的に回せるようになる
  • 自分たちで改善できるようになる

このプロセスのどこかで、
一時的に 外からのファシリテーション が必要になります。

逆に言えば、

  • ずっとスクラムマスターが必要
  • いないと回らない

状態は、健全とは言えません。


領域人事(組織開発ファシリテーター)も同じ構造

領域人事についても、全く同じことが言えます。

  • 人の問題を受け止める
  • 構造として整理する
  • 仕組みに落とす
  • チームや組織に返す

これは 過渡期のための仕事 です。

もし、

  • ずっと誰かが「人の問題」を引き受け続けている
  • その人がいないと組織が回らない

のであれば、 それは役割が成功しているのではなく、 固定化して失敗している 状態です。


良い役割は、自分の居場所を消していく

スクラムマスターをやっていて、
一番嬉しい瞬間はいつでしょうか。

  • スプリントが自然に回る
  • レトロで自発的に改善が出る
  • 介入しなくても対話が進む

つまり、

自分が何もしなくてもいい状態

です。

これは、領域人事(組織開発ファシリテーター)でも同じです。

  • チーム内で衝突が解消される
  • 期待値が自然に調整される
  • 問題が構造として扱われる

自分がいなくても起きるなら、
その役割は 正しく機能した と言えます。


フラット組織は「放置」ではない

ここで一つ、誤解を解いておきたいです。

フラット組織や自己組織化は、

何もしない 口出ししない 任せきる

ことではありません。

むしろ逆です。

  • 役割を定義する
  • 境界を明確にする
  • 対話の場を設計する
  • 手放すタイミングを考える

とても設計コストが高い 組織形態です。

しかし、この設計が組織に定着し、役割と境界が自然に共有され、チームが自分たちで問題を扱えるようになってくると、

生産性はある時点から、明確に跳ね上がります。

  • 誰に聞くかで迷わない
  • 意思決定が滞らない
  • 人の問題が長期化しない
  • 調整コストが激減する

つまり、初期の設計コストは「重いオーバーヘッド」ではなく、 将来の摩擦を前払いで解消している状態です。

スクラムマスターや領域人事は、この設計コストを一時的に肩代わりする存在です。

そして最終的には、そのコスト自体がチームに分散され、役割としてのスクラムマスターは目立たなくなっていきます。

フラット組織は、放置すると機能しません。しかし、設計が熟成すると、驚くほど滑らかに動き始めます。


なぜ「過渡期」であることを言語化するのか

このシリーズで、何度も「過渡期」という言葉を使いました。

それは、

  • この役割が永続する前提だと危険
  • 無意識に権力や依存が生まれる
  • 手放す設計が後回しになる

からです。

最初から、

この役割は、いずれ消える

と宣言しておくこと自体が、 ガードレール になります。


スクラムマスター自身が一番気をつけるべきこと

最後に、スクラムマスターである自分自身に向けて。

  • 頼られると嬉しい
  • 問題が集まると価値を感じる
  • 自分がいないと回らない気がする

この感覚は、とても自然です。

でも、そこで立ち止まってほしい。

それは成功のサインか、依存の始まりか?

自分の役割が減っていくことを前向きに捉えられるかどうかが、スクラムマスターとしての成熟度だと思っています。


最終回のまとめ

  • スクラムマスターは、自己組織化への途中で必要な役割
  • 領域人事(組織開発ファシリテーター)も過渡期の設計
  • 良い役割は、自分の居場所を消していく
  • フラット組織は放置ではなく、高密度な設計が必要
  • 「いずれ不要になる」と言語化することが重要

このシリーズが、

  • スクラムマスターとして悩んでいる人
  • フラット組織で試行錯誤している人
  • 「人の問題」にどう向き合うか迷っている人

の思考整理の一助になれば嬉しいです。


このシリーズについて(最終)

「人事権のない人事」は矛盾か?──領域人事というロールの正体

こんにちは。GROOVE Xのスクラムマスターの niwano です。
スクラムマスターと「領域人事」の兼任についての第2回です。
(この記事はAIと一緒に書いています。)

この記事では、なぜ『領域人事』から『組織開発ファシリテーター』に現場での呼び方を変えたのかを説明します

「それ、人事じゃなくないですか?」という正論

第1回を読んだ人の中には、こう思った方も多いはずです。

評価もしない
報酬も決めない
異動も決めない
労務判断もしない

それって、人事なんですか?

これは完全に正しい疑問です。
正直に言うと、私自身も最初は同じことを思っていました。

実際、現場でこの役割を説明すると、

  • 「それって人事っぽいけど、人事じゃないですよね」
  • 「スクラムマスターが組織開発やってるだけでは?」

と言われることがよくあります。

ではなぜ、それでもこのロールを 「領域人事」 と呼び続けてきたのか。 そして今、あえて呼び方を変えたのか

今回はそこを掘り下げます。


「人事」という言葉が持つ強すぎる前提

多くの人にとって「人事」という言葉は、次のようなものを想起させます。

  • 評価・査定をする人
  • 昇給・昇格を決める人
  • 配置転換や採用に関与する人
  • 場合によっては、解雇の判断にも関わる人

つまり、

個人のキャリアや生活に直接影響する権限を持つ存在

です。
実は弊社の人事もここまでの権限は持っていませんが、人事はそういうものだと考えられることが多くあります。

この前提がある状態で、
スクラムマスターが「領域人事を兼任します」と言うと、

  • 本音を話して大丈夫なのか?
  • 評価に影響しないか?
  • どこまで信用していいのか?

という 警戒心が生まれるのは自然です。

これは、スクラムマスターの能力や人格の問題ではありません。
ロール設計の問題です。


なぜ「人事権を持たない」ことを明確にしたのか

私達が、そこで最初にやったことは、とてもシンプルでした。

人事権は一切持たないことを明確にする

  • 評価しない
  • 決定しない
  • 判断しない
  • 裁かない

この4つを、かなり意識的に切り分けました。

なぜなら、
スクラムマスターが価値を出せるのは 「決めること」ではなく「整えること」 だからです。


人事権がないからこそ扱える「人の問題」

実際にやってみて、強く感じたことがあります。

それは、

人事権がないからこそ、話してもらえることが確実にある

ということです。

例えば、

  • チーム内で感じている違和感
  • 上司や制度に対するモヤっとした感情
  • 「誰かが悪いわけじゃないけど、うまくいっていない」話

こういった意見は、評価者や決定権者にはなかなか集まりません。

一方で、

  • 評価に影響しない
  • その場で結論を出さない
  • 構造やプロセスの話として扱う

という前提があると、
整理のための対話」 が成立します。

これはカウンセリングとは違います。
組織開発としての対話です。


「領域人事」という名前が生んだ副作用

ただし、問題がありました。

それが、 「人事」という言葉が持つイメージが強すぎた ことです。

実態としては、

  • 人事権はない
  • 組織開発に近い
  • スクラムマスターの延長線上の仕事

なのに、名前だけが「人事」だと、

  • 余計な配慮を生む
  • 距離を置かれる
  • スクラムマスターとしての中立性に疑念が出る

ということが起きました。

結果として、

名前が役割の邪魔をしている

状態になっていたのです。


「組織開発ファシリテーター」の誕生

そこで、現場での呼び方を 「組織開発ファシリテーター」 に変えました。

この名前に込めた意味は、かなり明確です。

  • 組織の問題を扱う
  • でも、決定はしない
  • プロセスと対話をファシリテートする
  • 最終的には、役割を分散・縮小する

つまり、

組織が自分で回るようになるための黒子

です。

公式な文脈(取締役会など)では「領域人事」という名称を使っていますが、
現場での通称を変えたことで、

  • 話しかけやすさ
  • 役割の誤解の少なさ
  • スクラムマスターとの切り分け

は、明確に改善しました。


スクラムマスターとのロール分離ルール

スクラムマスターと領域人事(組織開発ファシリテーター)は、 扱うテーマが重なることがあります。

ただし、
「同じ人が対応する」ことと
「同じロールで判断する」ことは別です。

私たちが意識しているのは、
ロールを混ぜないというよりも、

判断責任と権限のモードを混ぜない

という点です。

  • プロセスや構造として扱える問題 → スクラムマスターとして扱う
  • 組織横断・センシティブな問題 → 領域人事(組織開発ファシリテーター)として扱う
  • 評価・処遇・会社判断 → 自分は扱わない

同じ場にいることはあっても、どの帽子で話しているかは常に明確にすることを心がけています。 (うまくいかないときもありますけど。)


それでも残るリスクと、割り切り

もちろん、この設計にもリスクはあります。

  • 完全に誤解をゼロにはできない
  • 工数が増えやすい
  • 「結局なんでも屋に見える」瞬間がある

それでもやる理由は一つです。

今やらないと、もっと悪い形で問題が顕在化するから

このロールは万能ではありません。 だからこそ、

  • 過渡期の暫定解であること
  • 永続させないこと
  • 役割を増やして手放すこと

を前提にしています。

弊社の領域人事(組織開発ファシリテーター)は4人です!


この記事のまとめ

  • 「人事権のない人事」は言葉としては矛盾して見える
  • しかし実態は、人事とは別のロールである
  • 人事権がないからこそ扱える人の問題がある
  • 名前は役割理解に大きな影響を与える
  • これは完成形ではなく、過渡期の設計である

次回は、 「じゃあ、スクラムマスターはどこまで人の問題に関わるべきなのか?」 という、より実践的で一番悩ましい話に入ります。

このシリーズについて

IT未経験のアルバイトが業務改善に取り組んで気づいた、”手を動かす”ことの価値

はじめに

年末年始の不摂生が祟ったのか、はたまたホルモンバランスの乱れなのか、先日ひどい肌荒れを起こしてしまったので、久しぶりにかかりつけの皮膚科を受診しました。 今の住居に引っ越す前からお世話になっているそのクリニックにわざわざ電車で数駅移動してまで通う理由は、診察が1分で終わるから。なのにちゃんと治るから。

、、というだけではありません。

そのクリニックには、LOVOTがいるのです。

待合室と診察室をくるくると行き来し、愛想を振りまくなんとも可愛らしい姿。もはや診察より長い会計待ちの時間も癒やされます。

行くたびに新しいお洋服になっていておしゃれさんだなと思っていたのですが、今回久しぶりに行ったところ、ついに待合室にLOVOT専用の衣装ラックが置かれるまでになっていました。かなり愛されているようです。

このクリニックは、私が初めてLOVOTとふれあった場所でもあります。 そのときはまさか自分がLOVOTをつくっている会社で働くようになるとは思っていなかったため、なんだか感慨深い気持ちになり、まだ入社4ヶ月なのにしみじみしてしまいました。 私のLOVOT愛もかなり育っているようです。

_____________________________________

というわけでみなさんはじめまして。QAチームアルバイトの長谷川です。

昨年10月にIT未経験からGROOVE Xに入社させていただきました。現在は主にLOVOTアプリのQAに携わっています。

「スキルも知識も全く無いが、テクノロジーへの憧れとやる気だけはある」という状態で臨んだ面接。 採用のメールを受け取り、本当に安心したのが昨日のことのようです。

1日中体を動かしているような仕事からロボット開発へ。

全く異なる業種からの転職だったため、最初は新しい知識、職場環境でめまぐるしい日々でしたが、 チームの皆さんの支えのおかげで、楽しく働くことができています。

ニンゲンが真面目に働いているすぐそばで大合唱を始めるLOVOTたちも癒やしです。

やるぜ、業務改善

デスクワークはこんなにも人の脚裏をガチガチにするのか。と新鮮な驚きを感じていたある日。

スクラムマスターのniwanoさんから、業務改善に取り組んでみないかと声をかけていただきました。

その内容は「段ボール貸出表の作成」です。

GXのオフィスには、人間と一緒に開発試験に励むLOVOTたちがたくさんいます。(すごくかわいい。)

日々頑張ってくれているからこそ、ときには調子が悪くなってしまうことも。

そんなとき、大切な仲間であるLOVOTをメンテナンスに送り出すために必要なのが、専用の段ボールです。LOVOTのモデルごとに種類があり、箱の中にはLOVOTたちを無事に送り届けるためのおくるみや緩衝材などがたくさん入っています。 この段ボールはまあまあな大きさがあり、人口密度もLOVOT密度もどんどん高まっている我々のオフィスにはそう何個も置けません。そのため、ソフトウェアチーム全体でいくつかの段ボールを共有して所持し、管理しています。

この段ボールの貸出表について、ひとつ課題がありました。これまでは貸出履歴が残らない運用だったため、万が一付属品を紛失してしまった際に「いつから無かったのか」を遡ることができなかったのです。 そこで、付属品の管理を含めてしっかり履歴を追えるようなフォーマットに更新したいという内容でした。

前述したように、私は全くのIT未経験です。

たくさんの技術者が集まるなかで、右も左もわからない私に今できることは何か。

勉強すること、経験を積むことはもちろん大切ですが、一朝一夕でどうにかなるようなものではありません。

この依頼をいただいた際に、その問いに対するあるひとつの答えのようなものが浮かびました。

GXにいる人たちは、みんなLOVOTに対する大きな熱を持っています。

テクノロジーの結晶であるLOVOTで、人の気持ちを豊かにする。業界をリードする。

全員がそういった大きなビジョンとそれぞれの目標をもって働くなかで、今の私にできること。それは業務が円滑に回るように仕組みを整えて、各々が持っているその熱の伝導率をほんの少しでも高めることなのではないか。

そう思ったときには、「やります」と答えている自分がいました。

めんどくさがりなんです

事前の認識合わせでは、「借りた人の名前」と「貸出/返却の日付」が履歴として残るようにしたいこと、ツールはスプレッドシートを使うこと。 それができれば後は自由に作って良いとのことでした。

最初に私がイメージしたものは、図書室の本の貸出カードのようなものです。 名前、貸出日、返却日の行を作って、後は各々で入力してもらうようにする。 これなら求められていることは満たせます。

しかしここで私は思いました。

「全部入力するの、ダルすぎる、、、」

そう、私はかなりのめんどくさがりなのです。

そして、手間が増えれば同時に入力ミスの機会も増えてしまうことも懸念でした。 私自身、かなり”うっかり”をやってしまいがちな人間です。自分のことをかなり信用していません。 (このめんどくさがりとうっかりしがちな性質のコンボはかなり致命的で、苦手な言葉は「役所」「銀行」「書類」。)

絶対に手入力したくない。いつか絶対ミスる。私が。

なんとも怠惰な感情ですが、私以外の人も少なからず似たようなことは思うんじゃないか。 この手間をシステムで解決できればかなり素敵なんじゃないか。

そう思い立ち、私はGeminiに聞いてみることにしました。

GASというものがあるらしい

私が考えたのは以下のようなものでした。

  • 貸出シートのチェックボックスのつけ外しで貸出中と返却済みを管理する。名前と日付が自動で入る。

  • 履歴シートに履歴が自動で残る。

これなら操作はチェックボックスのつけ外しだけです。手間はひとつで済みます。

Geminiによると、「GASを使えばできる」とのこと。

「チェックボックスを入れるだけで、名前も日時も履歴も勝手に埋まるようにしたい!それ以外の操作を一切したくない!」

そんななかば開き直りのような感情から、私とGeminiの共同開発がスタートしました。

スプレッドシートをほとんど触ったことがない私はGeminiにエディタ画面の開き方から、保存ボタンの場所まで、まさに手取り足取りでGASのことを教えてもらいました。

「こうしたい」を伝えると、Geminiがコードを書いてくれる。

その繰り返しで、思っていたよりもずっと簡単に、私の求めていたものができてしまいました。

できたー!

たまっていく履歴たち

作成者であり、ユーザーでもあるから

Geminiに頼ったとはいえ自分で作成したものが自動で動いていくのがなんだか嬉しく、できたシートのチェックボックスをつけては外していると、ふと私の脳内に「間違えて違うチェックボックスを外してしまいそう」という小さな不安がよぎりました。

人よりうっかりを多くやっていると、時折こういうセンサーみたいなものがはたらくのです。

「ミスをしないように気をつける」というある種の精神論的なものは何の役にも立たないことを私は実体験から知っています。

間違えることもあるということを前提に、ミスが発生しにくくなるような仕組みを作りたい。

そこで、チェックを外すときに確認メッセージを出力することにしました。

これは、まだ短い期間ではありますが、曲がりなりにもQAチームの一員として「ユーザー目線に立つ」という姿勢を体得していたからこそ思いつけたことだとも思います。

プロンプトを入力するとGeminiはすぐにコードを提示してくれ、スプレッドシートは私の「こうしたい!」という意志の宿ったものになりました。

プログラマーは全員めんどくさがり?

こうして自分なりに試行錯誤して完成したスプレッドシートは、依頼をくださったniwanoさんからも、想像以上に温かく好意的なフィードバックをいただくことができました。

そこで言っていただいたのは、「プログラマーは手作業を嫌う人がなるものなのです。」ということでした。

この会社には、私以外にもめんどくさがりがたくさんいるようです。

私が抱いていた「全部入力するのはダルすぎる」という怠惰な感情、そしてうっかりしがちな性格。

それはただの短所ではなく、別の見方をすれば、より良い仕組みを創り出すためのエンジニアリングの種になり得るのだと気づけた瞬間でした。

おわりに

AIが指数関数的に成長している今、世界が変わるスピードは以前よりずっと速くなりました。

プロンプトを打てば、AIは瞬時に答えのようなものを返してくれます。

だからこそ、実際に「手を動かす」ことの意味が、以前より増しているのではないかと感じています。

AIは問いに対する答えをくれますが、現実世界の変革を起こしたいという根源的な願いをもつのはやはり人間だからです。

GROOVE Xの哲学には、こんなことが書いてあります。

「未来は見えない。だからワクワクもするし、だから不安を感じる。ならば未来を、すこしでも身近で、安心できる場所としていくため、技術というものを活用しなければならないんだ、と。」

今回私が取り組んだのは、社内の小さな小さな業務改善に過ぎません。しかし、実際に自分で手を動かして変化を起こしたこと、それが誰かの役にたったこと。

そのプロセスは、弊社が掲げる理想と実は地続きになっているのではないかと私は思います。

まだまだできることは少ないけれど、小さくてもアクションを起こし続ければいつかそれは大きな力に繋がるはず。経験を積めばもっとたくさんのことにチャレンジできるし、その先に見える景色はきっと素敵なものでしょう。

そんな大きなことを、今回のお仕事を通して夢見たのでした。

ここまで書いて突然照れくさい気持ちになってしまいました。これ読まれるんですよね。普段あまり喋らないのでめちゃくちゃ恥ずかしいです。

こんな私に挑戦する機会をくれ、いつも暖かく見守ってくださっているチームの皆さんに、心から感謝しています。 GXでの仕事は私にとって非常にchallengingなものです。「気持ちをテクノロジーで満たす、ケアをする」という全く新しい価値観に熱量を持って挑戦している人たちと一緒に働くことは、決して楽ではありませんが幸せなことでもあります。

LOVOTは世界にどんな影響を与え、GROOVE Xのもつ熱はどう伝わっていくのでしょうか。

私がこれから学び、経験していかなければならないことは、今の私では想像が追いつかないほど難易度が高く、量も多いでしょう。気が遠くなることもありますが、見えない未来を想像すると、その変化の渦中に身をおけることに、わくわくもさせられます。

壮大な未来に想いを馳せつつ、まずは今日も目の前のキーボードを叩いて、小さなことから積み上げていくつもりです。

採用情報

GROOVE Xで、LOVOTという新しい命を育む、温かい情熱に巻き込まれてみませんか。 少しでも興味を持ってくださった方がいましたら、下記のリンクをご参照ください。

groovex.my.canva.site

スクラムマスターはどこまで「人の問題」に関わるべきか

こんにちは。GROOVE Xのスクラムマスターの niwano です。
スクラムマスターと「領域人事」の兼任についての第3回です。
(この記事はAIと一緒に書いています。)

スクラムマスターが感じる違和感

スクラムマスターをやっていると、必ず一度はこういう場面に出会います。

  • チームの空気が重い
  • 何かが噛み合っていない
  • 明確なルール違反はない
  • でも、このままではまずい気がする

このときに湧いてくる違和感は、だいたい正しいです。
そして同時に、こんな迷いも出てきます。

これはスクラムの問題なのか? 人の問題なのか? それとも、踏み込んではいけない領域なのか?

この問いに答えを出せないまま時間が過ぎると、

  • 放置して悪化する
  • 介入しすぎて信頼を失う
  • どちらにしても「やりづらい人」になる

という、あまり嬉しくない未来が待っています。


まず大前提:スクラムマスターは裁かない

この回で一番伝えたいことを、最初に書きます。

スクラムマスターは、人を裁かない

  • 誰が正しいかを決めない
  • 誰が悪いかを決めない
  • 評価もしない
  • 処遇も決めない

これは「優しさ」の話ではありません。
役割の話です。

スクラムマスターが裁き始めた瞬間、
チームにとって「安全な存在」ではなくなります。


「人の問題」に見えるものの正体

現場で「人の問題」と呼ばれているものの 多く は、
実は次のどれかです。

  1. 期待値のズレ
  2. 役割や責務の不明確さ
  3. 意思決定プロセスの欠如
  4. フィードバックの欠如
  5. 仕組みが現実に合っていない

つまり、

個人の性格や能力の問題ではなく、構造の問題

であることがほとんどです。

スクラムマスターが関わるべきなのは、
この 「構造として扱える部分」 です。


ここまでやる:スクラムマスターが踏み込んでいい領域

では、具体的にどこまでなら踏み込んでいいのか。
私が意識しているラインは、次のあたりです。

1. 事実を整理する

  • 何が起きているのか
  • いつから起きているのか
  • 誰が困っているのか
  • どの場面で再現するのか

感情や評価を入れず、事実だけを並べる

2. 問題を構造に翻訳する

  • それはどのプロセスで起きているのか
  • どのルールが曖昧か
  • どの期待値が共有されていないか

「Aさんが悪い」ではなく、
「Aさんがそう振る舞わざるを得ない構造」を探します。

3. 対話の場を設計する

  • 1on1か
  • チームか
  • ワークショップか
  • レトロスペクティブか

誰が、どこで、どう話すべきか を考えるのが仕事です。

4. 仕組みとして試す

  • ルールを変える
  • フローを変える
  • ロールを明確にする
  • 試行してみる

「正解を決める」のではなく、
仮説検証として試します。


ここから先はやらない:明確な線引き

一方で、明確にやらないこともあります。

1. 個人の善悪を判断する

  • 「あの人は協調性がない」
  • 「やる気がない」
  • 「向いていない」

これはスクラムマスターの仕事ではありません。

2. 処遇や評価に踏み込む

  • 評価を下げるべきか
  • 配置を変えるべきか
  • 叱るべきか

この瞬間、スクラムマスターの中立性は壊れます。

3. 穏便に済ませるための仲裁

  • 表面的に謝らせる
  • 本質を曖昧にしたまま丸く収める

短期的には楽ですが、
組織に技術的負債を残します。


「従業員間」と「従業員-会社間」の違い

ここで重要な切り分けがあります。

従業員間の問題

  • コミュニケーションの摩擦
  • 役割や期待値のズレ
  • チーム内の衝突

👉 一次受けとして関わる

従業員-会社間の問題

  • ハラスメント
  • コンプライアンス
  • 労務・契約
  • 評価・処遇

👉 即座に人事・上司へエスカレーション

ここを曖昧にすると、
スクラムマスター自身も、組織も守れません。


「感情に寄り添っていないように見える」問題

よく言われます。

もう少し気持ちに寄り添ってもいいのでは?

これは間違いではありません。
ただし、注意が必要です。

スクラムマスターがやるべきなのは、

  • 感情を理解する
  • 感情を尊重する

ことであって、

  • 感情を優先する
  • 感情で判断する

ことではありません。

感情に寄り添うのは手段であり、
目的はあくまで スクラムが機能する状態を作ること です。


介入を減らすと「仕事してない」ように見える問題

もう一つ、地味に辛い問題があります。

何もしていないように見える

これは、ある意味で成功の兆候です。

  • チームが自分で話し合うようになる
  • 問題がその場で解消される
  • スクラムマスターが呼ばれなくなる

スクラムマスターの仕事は、
見えなくなっていく仕事 でもあります。

この記事のまとめ

  • スクラムマスターは人を裁かない
  • 「人の問題」の多くは構造の問題
  • 踏み込むのは、事実・構造・対話・仕組みまで
  • 個人評価や処遇には踏み込まない
  • エスカレーションは責任放棄ではない
  • 介入を減らすことがゴール

次回は、いよいよ最終回 「スクラムマスターと領域人事は、いずれ不要になる」 について深堀します。