この記事は traP Advent Calendar 2023 23日目の記事(遅刻)です。

こんにちは。19Bの@kegraです。traP内で「ハイテクドアプロジェクト」というプロジェクトのリーダーをやっています。

サークル棟にあるtraPの部室ドアになぜかディスプレイが設置されているのはうちのプロジェクトの仕業です。

現在は進捗部屋^[1]の表示などをしており、今後も機能を拡充していく予定となっています。

ところで...

このtraPというサークルは、正式名称に「デジタル創作」とある通り、基本的にはソフトウェアやイラストレーションなど物理的なモノを伴わない制作が主です。その中にあってこの「ハイテクドアプロジェクト」はかなりイレギュラーな部分が多く、部内でそれなりに調整を迫られることになりました。しかし協力してくれた各所およびプロジェクトメンバーのおかげで、今は部室のドアで電光掲示板が動作しています。協力してくれている部員のみなさん、本当にありがとうございます。

本題

さて、ここからが本題です。

組織内で(風土的に、あるいは通例的に)今まで行われていなかったことを行うのには当然何かしらの障壁が付き物です。 しかし僕が考えるに、そうした障壁はしばしば過剰に高く見られます。そしてそれを適切に見定めて乗り越えることができる人は、もっと言えばそれを選択肢として持つことができる人は、そうでない人よりやれることの範囲において圧倒的なアドバンテージを持てると思うのです。

僕はこのプロジェクトでそういうことを感じたのでそれを記事として共有したいと思います。

人間の運営する組織には何かしらの柔軟性があります。そうでなければ、日々ちょっとずつ違う活動に耐えられないからです。もちろんそうした柔軟性には限度があり、過度に使いすぎれば人々は疲弊してしまいますが、適切な程度で少しずつ活用していけば何かしらが変わり、今までより面白いことが実現していけるはずです。

組織で今まで行われていなかったことを行う方法

自分のやりたいことが所属組織の仕組みと合わない場合、とれる選択肢はいくつかあります。

• 単に個人的にやる
• 別の組織でやる
• 頑張って組織のトップ(あるいは幹部)になり、強引に進める

しかしどれにも短所があります。例えば個人で勝手にやろうとした場合、労力には限界があります。また権限や管轄の問題が出てくれば、これはどんなに個人が労力を発揮してもどうにもできません。

そしてこれらとは別の選択肢として、

• 組織の人間と交渉してやっていく

というものがあることに自分は気が付きました。

この記事ではこれについて主に説明したいと思います。

気を付けるべきこと

まず、自分のプロジェクトの話をしましょう。

ハイテクドアプロジェクトを実施するにあたっては、

• 部室ドアへの設置の許可取り
• 部室ネットワーク環境の整備
• 既存の部内インフラ^[2]への要望出し

などを行うことになりました。

traPは部員が個人で勝手に何かすることが多いサークルですが、上に挙げたようなものはサークルとして管理しているものの話になるので、色々とやり取りを行うことになりました。

その中で思ったことをいくつか。

部署の領分と裁量を理解する

大抵の組織は、組織として何かを管理しています。何かというのは物理的なモノだったり、金銭だったり、プロジェクトだったり、何かの権利だったり、色々です。そうした組織として管理している何かに干渉する場合、まずは一旦窓口的なところ^[3]に投げるのが筋です。なのですが、何がどのように管理されているかを把握しているとより話をスムーズに進められる可能性があります。

ある程度の規模の組織においては、何かしらの部署、役職、担当があります。そしてその部署にはその部署が管轄管理する領分があり、そしてその領分のもとでの裁量があります。

例えばtraPには部内のインフラのほとんどを引き受けるSysAd班があり^[4]、また部全体の意思決定をする役員会やその下の各役職などがあります。

既存の仕組みに干渉したい場合、それがどこの部署の領分なのか、そしてそこでどの程度の裁量権を持っているのか、その雰囲気を把握していると話がスムーズに運びます。逆にそれを把握していなければ見当違いの部署や役職の人に要望などを出してしまい、相手を困らせてしまいますし、お互い時間を取られてしまいます。単に実現に必要な技術しか分かってないとここが弱点になる訳ですね。

traP内では基本的にやり取りが全てオープンなので、やりたいこと(やって欲しいこと)に照らしてそれを誰にどこで頼めばいいか比較的楽に判断できました。

もちろんこうした情報は必ずしも分かりやすく見えているとは限りません。しかし、多少オープンな組織であればどこかしらには組織図などが掲示してありますし、そして人のやり取りの流れなど他の情報からそうした構造に起因する関係や雰囲気などを垣間見れることもあると思います。聞けそうなことは聞いてしまうのも手でしょう。こうした関係や状況を理解するのは面倒かもしれませんが、人の集団と関わって何かを為すにはとても重要なことです。

技術を理解する

人が何かを行う際には大抵何かしらの技術が行使されています。traPのSysAd班であればサーバー管理のためのインフラ技術やソフトウェア開発技術を行使しています。イラストレーターは絵を描く技術を行使していますし、学校の給食室のおばちゃんは料理の技術を行使しているでしょう。組織の部署・役職は仕事をしており、そこには何かしら専門の技術があります。

相手に何かを頼むとき、その相手の用いる技術を完全に理解している必要まではありません。しかし自分が思うに、相手に行使してもらう技術の基礎的な部分は理解しているのが理想だと思います。それは頼む相手への敬意という面もありますが、「何が簡単で何が難しいのか」を共有するためという意味も大きいです。

誰かから何かを頼まれるにあたって、勝手に自分の仕事を簡単と思われれば人は腹が立ちます。そうすればそこには摩擦が発生してしまうでしょう。かと思えば、こちらが勝手に難しいと思っていたことが実は技術的には簡単で、チャンスを逃してしまうこともありえます。誠意と会話力しかない人はここが弱点になる訳ですね。

繰り返し言いますが、相手の使う技術を完全に理解する必要まではないと思います。そうだとすれば、他人に頼ることで知力や労力を委譲する意味が薄まってしまうからです。しかし、基礎的な言葉を理解していれば意思の交換に役立ちます。技術的問題がある場合も状況を共有できます。技術者は人間であり、その言葉が分からないとすれば語彙を共有していないだけです。明確な言葉が交わせるならばよりスムーズに仕事が進みますし、協力できるところは協力することができるでしょう。

相手の技術を理解するべきなのはもう一つ重要な理由があるので、これは後述します。

他の実利or大義名分を主張する

少し発展的かもしれませんが、何かを頼むにあたってはそれをやることによる実利や大義名分を提示するのも重要だと思います。

組織やその部署というのは、人のまとまりな訳ですから、まとまるために大抵何かしらの目指す方向、お題目があります。traPであれば「デジタル創作」ですね。そしてその中のSysAd班であれば「部員の創作活動の各種インフラによる支援」みたいなのがあります。

そうしたお題目と自分のやりたいこと、お願いしたいことがずれていたらどうでしょう。技術的に、また部署の裁量的に可能だとしても、そこには「なんでそれやるの？」という問題が残ります。であれば、その答えは用意すべきです。「これをやればこういう目的が達成できる」みたいな大義名分とか、「これをやれば既存の困りごとを解消できる」みたいな実利を提示できれば、ぽっと出の提案でもお互い動機を持って目標を共有できるはずです。

自分の例で言うと例えば、「部内インフラにこういう機能を付ければ部員の作品制作や学習に役立つと思います」とか、部室のネットワーク環境の整備においては「部室にある他の機器向けにも役立ちます」みたいな話をしたりしました。

まあ自分の場合だとサークルの中なので普段から話してる仲が多いのと、traPの人は節介焼き優しい人が多いので、ここまで説明しなくてもどうにかなった可能性はあります。ですがやはり、大義名分を出せるなら出した方がきっと良いです。相手の立場に立って物を考える素振り練習にもなります。

一番重要なこと

上に挙げた3つのことはどれも重要ですが、それらよりもっと前提として重要なこともあります。

敬意を払う

すっごい大事ですね。 何かをやってもらうわけで、しかも普段とは違うことを頼むわけですから、当然相手にコストを払わせています。そして自分にはできないことをやってもらうのですから、謙虚な態度で臨み、やってもらったらありがとうというべきです。

何をやってほしいのか明確にする

もう一つ大事なのがこれです。当たり前ですが、何かを頼むなら何をやって欲しいのか明確にする必要があります。これは実はやれてると思ってると案外出来てないことが多いです。

「良い感じにして！」ではどうしようもないのはお分かりですね。で、「あれをこうしてほしい」くらいの感じにはなる訳ですが、いざそのように頼んでみるとおおかた全然具体性が足りてないことが分かります。これは何に起因するかと言うと、技術的な理解度の差により見えている変数の数が違うからです。

「豚骨ラーメンを食べたい」と言ったら「麺の硬さは？」「スープの濃さは？」とか聞かれるようなものです。そう聞かれて何が違うのか分からなければ、結局「良い感じにして！」が発生してしまう。するとヒアリングが始まり、時間を食ってしまいます。「相手の技術を理解した方がいい」と上述したもう一つの理由はこのためです。技術への理解が多少なりあればあらかじめある程度の「決めるべき変数」が見え、やり取りの回数を減らすことができます。

しかし実のところ、「良い感じにして！」→「ヒアリング」を完全に避けるのは無理です。技術への解像度が違うのですから。なので非専門家として最低限やるべきことは、抽象的な大義名分などを用意することよりも前に、まず自分の中で具体的な目的とやる理由を十分明確にしておくことです。その明確化すら出来なければ、やり取りしていく内に「あれ？何で頼み事をしてるんだっけ？何をやりたかったんだっけ？」となることでしょう。そしてその自問自答は、あらかじめ自分の中で終わらせるべきだったものです。

余談

XY問題という有名な問題があります。

これは簡単に言えば、技術的な理解度の低い人が「Yをしたいのだがやり方が分からない。どうすればいいか？」という質問をして、しかしYをしたい理由を聞くと真の動機Xがあり、「XをするにはYではなく別の手段を取った方がいい」と返される、というお話です。これは本当にあるあるで、一般的には「最初から動機Xを共有した方がいい」というのが教訓とされています。

しかしこの記事では、「組織の中でしかるべき人にしかるべき形で頼み事をすることで迅速に事を為す」という話をしています。ここで恐れるべきことは「動機XのためにYをしたくて、Yができる担当部署Y'に頼み事をしたが、Yではなく別の手段Zを選んだ方がいいことが分かる」というものです。Zがすぐわかり、ZもY'が担当しているならまだ良いのですが、そうでない場合大変です。

• Zを担当する部署Z'が別にある
• Z'がどこなのか分からない
• Z'は存在しないので新たに設立する必要がある
• Zは自組織でどうこうできる問題ではない

...みたいな事態がありえます。Xに対するZがそもそも分からないのもありそうですね。そういう時は個人で勉強するか、十分な技術と信頼関係のある人(たち)にXを言うほかありません。^[5]

この記事では、あまりにもひどいレベルのXY問題は発生しない想定で書いています。目的が明確にあって、それに必要な道筋の大筋までは見誤らない想定です。「頼み方と同時に基礎的な技術も学べ」というのをことさらに強調しているのは、そういう前提の補強のためでもあります。

終わりに

ここに書いたような内容は、きっと大学のサークルという極端に柔軟性に富む組織だから言える部分もあるのではないかと思います。会社とかならお金や責任の問題が強く絡んでくるでしょうし、お役所なら法律・条例という外付けのルールブックで挙動が定義されていたりします。

しかし、人間がやってる限りどこかしらに変化を受け止める部分があるはずです。ルールがあったとしても、ルールを変更するためのルールもきっとどこかしらに定義されています。

ずっと同じことを繰り返すのって面白くないと思いませんか？あなたもぜひでたらめな新しいことにチャレンジしてみましょう！