依頼仕事業務をボードゲームなど他の視点で紐解いてみる

【Unit1 ブログリレー5日目】こんにちは。先日阪口さんのブログで違和感について良いことが書かれていました。せっかくなのでそちらの記事にのっかった形で「趣味を通じて仕事を考える」というテーマでやっていきたいと思います。 www.m3tech.blog

自分の趣味であるボードゲームの話や漫画の話を比喩的に使いながら依頼仕事業務を紐解いていこうと思います。皆さんの琴線に触れることが出来れば幸いです。

本編に入る前に、ボードゲームの話題として２０２５年の大きなトピックを紹介します。日本人ゲームデザイナー林尚志さんの「ボムバスターズ（ボムスカッド）*1」が世界最高峰の賞であるドイツ年間ゲーム大賞（Spiel des Jahres）を受賞*2しました。本当におめでとうございます。

依頼仕事を分解してみる

まずは自分の仕事の話から。 私が所属しているチームの仕事の１つに「非エンジニアからの依頼を受け、トラブル対応や調査、データなどを作成」があります。これは非エンジニアと多くの接点を持つエンジニアとも言えます。そしてその場合の仕事は以下の流れになります。

• 依頼受付フェイズ*3
• 調査やデータ作成フェイズ
• 報告フェイズ

依頼からスタートする仕事で調査やデータ出力を行う場合、攻守で考えると守の仕事となります。函谷関の戦いの王翦将軍の役割*4です。仕事の依頼が降ってくる形式ですが、テトリスのように受動的に大量*5に降ってきます。そして量が多いので、その内容を振るメンバーや至急の割り込みを調整するために工数を割いています。

依頼受付フェイズ：依頼の配分とカジュアルな悲鳴

多くの依頼に対応しながら、メンバーの作業量などを鑑みて割り振りする作業をしていました（現在は他のメンバーがやってくれているのでありがたい）。この、作業量を見て割り振りを行うという職人芸みたいな作業は蕞城戦の介億を思い出します*6。ちなみに私のチームでは、作業量と割り振りについてのアプローチとして「ヤバそうになるちょっと前にカジュアルな悲鳴を上げて」とし、そういった会話をしやすい、話しやすいチームになるよう心がけています。

依頼受付フェイズ：トラブル対応の難しさをアイスで考える

依頼の中にはトラブル調査が含まれています。しかも結構な量です。トラブルといっても幾つかのものに分類されます。

1. システム的エラー
2. 仕様通りなのに仕様と運用が合っていない
3. 仕様も運用も合っていて依頼者の認識が間違い

問題は、依頼時点では上記のどれなのか不明な事です。そして依頼者から見ると全てトラブルでエラーです。中には調査依頼からスタートしてトラブルを発見したり、依頼内容から想像もつかないようなパターンもあります。２０２０年の逸話ですが、ゼネラルモーターズ社のエンジニアに「バニラアイスのときだけ車が動かない、他のアイスは問題ない」というオカルトのような苦情が上がったことがあります。後日調査を進めて「バニラアイスだけよく売れるから提供が早く」「車に帰って来る時間が他のアイスより短く」「そのためベーパーロック現象*7を起こしていた」という事がわかりました。依頼からは想像しにくい形でトラブルが発覚することもあります。トラブル対応は依頼者目線で深堀りしてみると、思わぬパターンが埋まっている場合があります。

依頼受付フェイズ：依頼者の情報は大体省略されている

依頼を日本語で受け付けているのですが（日本企業なので）、ここで登場するのが日本語の難しさです。とにかく明るい安村氏のネタ「安心してください、はいてますよ」をイギリスで披露*8したとき、英語でネタをやったのですが「I’m wearing」と言った後、審査員や観客が「pants!」と叫んでいました。日本語母語話者からしたら分かり難いのですが、「I’m wearing」で文章が終わること自体が座りが悪く、逆に補完によってコミュニケーションが生まれた例です。日本語ではアレコレを説明しなくても勝手に補完してそれっぽく成立してしまいます。 依頼においても似たようなことが発生し「依頼者の頭の中には補完されているので省かれた情報」に重要情報が含まれていたりします。こういった情報を引き出すだけで、初動のパワーを持っていかれます。対処法としては、依頼フォームでの質問事項を常にブラッシュアップしていき、依頼時に情報が抜けることなく、勘違いすることのないアプローチを取っています。

依頼受付フェイズ：依頼者と依頼対応者の視座の違いをOSI参照モデルで考えてみる

依頼を受けるエンジニアにおいて、視座の違いは想定より大きな問題です。エンジニアと非エンジニア、どちらが上とか下とか存在しませんが、エンジニアはシステムのスペシャリストという位置付けで仕事をこなしています。その際、エンジニアもシステムの全て（ソース全部）を熟知していれば最高ですが、複数システムを扱っていると流石に不可能です。稀にとんでもない記憶力で１０万３０００冊*9を覚えてるようなすごい人も居ますが、相当な突出例なので横に置きます。エンジニアも仕様書やソース、データベースを実際に見ないとわからないことも多々ありますが、非エンジニアからすると「全部ひっくるめてブラックボックス」なので「この辺は知っているだろう」という先入観で情報が抜けていたりします。

分類として、

• 調査したらわかる（余計に時間が掛かる）
• 調査してもわからない（取っ掛かりがない）

があります。ただこれは依頼者が怠けているというより「視座の違い」を念頭に、エンジニアみんな大好きOSI参照モデル*10で考えてみます。依頼者はアプリケーション層で考えて依頼し、アプリケーション層の回答を欲していますが、エンジニアからすると原因が大体他の層です（しかも最初のうちはどの層かすら不明）。そのため、とにかく小さい情報でも良いので取っ掛かりが欲しいわけですが、そのあたりの細かいことはアプリケーション層から見ると噛み合って無かったりします。結局時間を掛けて「そもそも依頼者と会話の階層が噛み合っているか」を考えつつ、引き出さなければなりません。

依頼受付フェイズ：目的を引き出そう

トラブルは解決することが目的なのでわかりやすいですが、データ作成やレポート作成は、まず目的を引き出す必要があります。目的がわかると代替え案も考えられますし、データ作成なら仮説が間違えていることも依頼時に気づくことが出来ます。そして大体の依頼には目的が書かれていません。「クライアント対応のため」みたいな目的になってない情報が書かれることもしばしばです。たまに内海課長*11のように手段のために目的を選ばないような依頼もあります。目的の情報が曖昧だと判断がつきません。そしてどんな時にも大切なことは、依頼者も同じ「何らかの目的を達成する仲間」であることです。これを忘れないようにしたいと思っています。ちなみに目的は後段の報告時に重要になるので聞き出しておきましょう。

調査やデータ作成フェイズ

ここでも色々ネタはありますが、今回は割愛します。

報告フェイズ：ボードゲームで考える説明の仕方について

さて。トラブルやらデータ調査やら諸々調査したら今度は報告です。ここでも前述の「視座の違い」を考える必要があります。なにせ「ｘｘシステムの△△がトラブルにより云々」とか詳細を書かれても「結局どういうこと？」となったりするわけです。 ここでボードゲームという趣味を軸に、この問題を紐解いていこうと思います。 まず、ボードゲームって何？みたいな話を簡単にすると「コンピュータゲームが流行る以前からあった卓上で遊ぶゲーム全般*12」を指すので、実は将棋とかオセロも範疇に入ったりしますが、ここではドイツで連綿と作られてきたボードゲーム文化という括りで説明します。カタンとかカルカソンヌとかウノとかやったことある人は多いと思いますが、大体その辺です。この趣味の珍しいところは「新しいゲームをやるたびに知らないプレイヤーが居たら毎回説明が必要」という点です。なんせ新しいゲームが大量に出るので、ルールを読んで他のプレイヤーに説明するという作業が必要だったりします。これをインストと言います。将棋のようにプレイヤー全員がルールを知ってたり、コンピューターゲームのように「やりながら覚える」という手法がどうしても取りにくいため（最近はプレイしながらシステムを覚えるゲームもあったりします）、それがインストの難易度となり、説明する人が大変だったりするわけです。最近ではボードゲームカフェなど店員が教えてくれる場所もあり、いい時代になったものだと思っています。 要点としては「ボードゲームのインストって説明力が付くよね」という話です。ゲームにしろ依頼の報告にしろ、人に何かを説明しようとした場合の難しさが共通していると考えていたりします。

報告フェイズ：ボードゲームのルールブックで考える報告の仕方について

ボードゲームのルールブックは、まず冒頭に何を遊ぶのか概要があり、重要度によって情報が分けられています。次にプレイでやることを列挙し、全体像が頭に入りやすくなっています。しかしボードゲームのルールブックが格段に読みやすくなったのはここ十年ほどの話だったりするので、ちょうど良い例としてルールブックを参考にし、報告について考えてみました。

1. 概要を最初の１〜３行で纏めよう
   大量に文字が並ぶと、些末情報を理解するため読むことに注力し、要点を見逃します。報告時に一番言いたいことだけを纏めましょう。

2. フレーバーで考える情報の重み付け
   ボードゲームの世界でもフレーバーという「そのゲームのプレイにはあんまり関係ないが世界観を知る情報」というものが存在します。これはルールブックに書かれていますが、フォントやブロックを変え「これはフレーバーだな」とすぐに分かるようになっています。大体イタリックだったりします。 情報には「メイン情報（みんなに必要）」と「フレーバー情報（一部に必要）」があります。報告時にこれらを明確に区別することで可読性を上げていきましょう。

3. 選択肢がある場合はわかりやすく列挙する
   文中に「〇〇の場合は１１が必要で、△△の場合は２２が必要で・・・」と書かれても脳が理解しません。読み手に選択肢が存在する（アクションがある）場合、それを明確にするため列挙型にしていきましょう。これも可読性が大幅に上がります。

4. ストーリーで報告しよう
   トラブルは解決が目的ですが、データ出力系は出して終わりということは意外に少ないのです。依頼されたデータが、依頼者の想定する目的と相違している「目的と地味に合ってない」場合は結構存在します。なのでそのデータを「どういったストーリーで、どう使うか」とセットで考えます。ボードゲームのインストで言うところの「このゲームは何の視点で何をプレイするのか」の部分です。コレなしでインストして「マストフォローでｘｘ点取ったら勝ち」みたいな説明をすると、何の目的で何をやるゲームなのかさっぱりわからず、説明が頭に入ってこなかったりします。まあたまにワレスのビザンチウム*13みたいに「何の視点のゲームなんだろう？」みたいなゲームがあったりしますが、あれは結構稀なケースだと思います。 ここで依頼受付時の「目的は何か」が重要になってきます。最初に目的を聞いておかなければ、終わらないPDCAサイクルみたいな依頼になりやすくなります。

報告したい相手のレイヤーに合わせ読みやすい報告をする。どんな作業でも存在しそうな内容をボードゲームのルールブックという切り口で考えてみました。

まとめ

依頼を受ける、対応する、報告をする、というよくある業務だけでも、普段の趣味や他の要素と比較して考えることは面白いなあ、と思ったことを書き殴りました。たまに他視点を入れると違った読み解き方、対応の仕方、そしてより良い報告方法にたどり着くことがあります。仕事をするだけではなく、様々な趣味を持ち、その趣味を周りの人に広めつつ仕事にも活かしていきましょう。

We are hiring!!

エムスリーではギークなエンジニアを募集しており、社内で定期的にボードゲームをプレイする会があったりします。趣味を楽しみ、そしてそれらの知見や思考が仕事にフィードバック出来れば最高です（趣味なのでフィードバックできなくても楽しめれば最高です）。ちょっとでも面白そうだなと思いましたら、下記のリンクからカジュアル面談のご応募をお待ちしております。 jobs.m3.com

*1:日本初発売がボムスカッド。カクテルゲームズ出版がボムバスターズ。

*2:日本人初受賞。ドイツで販売していることが条件の1つなのでそもそも難しい。

*3:ボードゲームでよくある表現の１つ。

*4:原泰久「キングダム」で合従軍との防衛戦において、蒙武を攻、王翦を守とした役割分担。

*5:自分のチームでは月２００件ほど依頼が発生し、これを数人でさばいています。

*6:原泰久「キングダム」で対合従軍最終戦において、比較的余力のある介億が苦戦度合いを見ながら他戦線に追加援軍。各戦線を均一化することで全体を崩壊させない行動。

*7:ガソリンに気泡が発生してブレーキを効かなくしたりエンジンを止めたりする現象。

*8:2023年にオーディション番組「ブリテンズ・ゴット・タレント」披露した話。

*9:鎌池和馬「とある魔術の禁書目録」のインデックスさん。

*10:通信プロトコルなどを７階層で考える仕組み。ITパスポートなどの取得で最初に大体勉強する。

*11:ヘッドギア原作「機動警察パトレイバー」に登場する、非常にかっこいい悪役キャラ。

*12:最近では一部コンピュータを使ったり、卓上ですらないパターンもあるので定義がとても難しい。

*13:マーチン・ワレス「ビザンチウム」。2005年出版。3時間くらい掛かる重量級ゲーム。