個人の効率の差と、知と、チームの開発で成果が生まれるメカニズム

この記事は、↓の記事の続きです。

https://zenn.dev/339/articles/6a874b197a2fb5

前の記事では、個人差に基づいて給与を支払うべきなのかという事にフォーカスを当てていたのですが、この記事では、開発チームがどのようなメカニズムで効果的に機能するかという事を考えていきます。

要約をすると...作業の速さと知の2つの概念を分離した上で、チームにおいては必ずしも個人の作業量だけが貢献ではないことを示し、知がどのように蓄えられるものか、どういった性質を持つかという仮説について述べます。そのような知の蓄積については、個人に還元して考えることにはあまり本質がなく、チームとして機能する状態を作るのが重要で、その意味で作業量（だけ）を全てとする"成果主義"では部分最適になってしまう、という事が一つの結論です。この知の蓄積は「森」のメンタルモデルで表現でき、事業やチームを拡大していく場合はどこかで「森」を作るという戦略に切り替えていく必要があります。

というような内容です。では、具体的に見ていきましょう。
※目次がアウトラインになっているので、ざっくり論旨を見たい方は目次を一度眺めてみてください。

ソフトウェア開発の仕事の性質

まず、今後の考察に必要となる、いくつかの重要なソフトウェア開発の仕事の性質をまとめます。
ここで述べる性質は、個人で個別に作業をする場合の性質です。

作業可能な量の個人差が大きい

前回の記事で述べたとおりです。この差が、先天的/後天的、あるいは教育で埋められる/埋められないという事は私にはわかりませんが、無為に作業を依頼すると個人の間で大きな差が出ることはわかっています。
これは、特にサボっているという事ではなくて、真面目に作業をしている（つもりの）場合においても発生します。

タスクがある難易度を超えると、突然作業が進まない人が発生する

ある個人に様々な難易度のタスクを依頼することを考えます。このとき、タスクの難しさを上昇させていくと、ある水準を超える難しいタスクになった途端に進捗が発生しなくなる、という現象があります。しばらくは難しさに"比例"して進捗が落ち、ある水準でぱったりと0になるようなイメージです。まるでどこかに見えない壁でもあるかのような振る舞いを感じます。
この進捗しなくなる水準の壁は、人によって大きく異なります。
この事象の主要因は、おそらく知識にある場合が多いのではないかと感じていますが、はっきりとわかっていません。

知によって結果・時間・質が大きく異なる場合がある（例：車輪の再発明）

わかりやすい例としては「車輪の再発明」という言葉がありますが、例えば言語標準で実装されている機能が独自の劣化実装によって実現されている、というようなケースがしばしば見受けられます。
ライブラリの使い方、そもそもライブラリを選定すること、エディタや統合環境の使い方。こういったものも知です。触っているプロダクトにおける典型的なコードの書き方、みたいなものも知の一種と言えるでしょう。作業している個人がこうした知を引き出せないことで、成果が出なかったり、品質が下がったりという事があります。
この知は、個人の作業可能な量の概念とはまた別のものです。

（工数を切り売りしていない限り）開発者の作業は大局的にはレバレッジが効く

開発者の作業によって、ソフトウェアができますが、ソフトウェアは壊れない限りは基本的にずっと使い続ける事ができます。一般の機械と同様、サービスの構成要素のメンテナンス（バージョンアップ）作業は発生するものの、事実上の資産として蓄積される/レバレッジが効くような構造になっています。
一方、例えば一般の仕事のうち、コンビニ店員のサービス提供のような種類の仕事は、その人が一定時間勤務することによってのみ対価が発生するような構造であって、レバレッジは効きません。（これは、レバレッジが効かないから良いとか悪いとかいう事ではなくて、その作業の効果についての違いを述べています。）

（システム販売等による商売でない限り）開発完了時点ですぐ売上が一括計上される訳ではない

レバレッジに関する議論の裏返しですが、受託開発やカスタマイズ対応など、システム開発に直接的に売上が発生する場合を除き、開発が完了/リリースした時点で直ちに売上が一括計上されるという事はありません。

ソフトウェアの種類によって、プログラマが直接的に課題を理解しやすいか否かが変わってくる

OSSなどでは、技術そのものに興味がある人は、そのソフトウェアの課題を理解しやすい傾向があるように感じています。言い方を変えると、webサービスの開発においては、いくら技術そのものに興味があったとしても、そのサービスが本質的にどういった課題を解決するのか・どういったアプローチがビジネス的に適切なのか・どういった運用を想定して開発すべきなのかといった事を理解するのが難しい場合があります。技術に関する知だけでは必ずしも効果的に振る舞えない場合がある、ということです。

チーム作業によるソフトウェア開発の"メリット"

上述の性質を踏まえて、チームで作業をする場合に、個別で開発するよりも効果的に開発できるポイントやそのメカニズムについて述べます。
もちろん、うまく行っていないチームでは、ここに挙げたメリットを享受できない場合もあります。うまく行っているチームではどのような事が起こるのか、というのがここで述べたいことです。

知の共有がスムーズにできる

ソフトウェア開発の場合、知をインターネットに存在するドキュメントや実装内容などから得ることができますが、チーム開発の場合にはチームのメンバーから直接的に知を得ることもできます。これによって、同じ個人でもチームで作業をしない場合とチームで作業をする場合とで最終的に得られる成果の品質が変わったり、特定の作業速度が改善したりする事があります。
この知は、一度個人が獲得するとある程度は記憶され、再び知が必要になった場合には速やかに利用されるようになります。

会話や相談によって問題解決ができる

知の共有の"応用"として、会話をしながら問題を解決する方法を探っていくような場合があります。
ラバーダッキングのように、一人で会話に似た行動を取ることで整理される場合もありますが、適切な相談相手と話をすることで、それぞれの人が個人で作業をするよりも効率的に整理が進む場合があります。
特に、実装作業を進めたり検討を進めたりする場合には、最初に考案した本人は自分が考案したものを想像したり見たりすることによって、良くも悪くも学習が進んでしまいます。学習が進んでいないフレッシュな立場の人は、思い込み等をある程度排した状態で検討をすることができるので、問題の検出や新しいアイデアの付加などで一人で考えるよりも質が高まります。
この会話や相談による問題解決は、相談する二人の間に作業量の個人差があったとしても、知が十分であれば成立します。

ただし、前提となる知の水準があまりに違うと、会話・仕事をしにくくなる

しかしながら、いかに知の共有がスムーズにできるといっても、前提となる知の内容や水準が違っていると、会話が成立しにくくなり、逆に仕事を進める上での障壁となってしまいます。
この前提となる知の事は、しばしば常識などと言われます。
チームによって必要とされる知は異なりますが、この知の獲得は、基本的には先天的な要素ではなく、ほぼほぼ「読み書き」の延長にあるものと思います。

総じて、個人の作業の効率によらず、知の共有（＝それぞれの人の知の獲得）がスムーズに行われることによって、それぞれの作業が効率的になり、また場面によっては相談を通じて効率的に問題解決ができます。

分業による効果

分業をすることによるチーム構造的な効果もあります。
これは、必ずしも知の共有を前提としない、あるいは知の共有とは"反する"ような部分もあります。

各人が得意分野において専門家的に振る舞うことで　「メンバーの良いとこどり」ができる

チームを構成する各メンバーが、それぞれ自分の得意分野を作る「ラストマン戦略」という考え方があります。これは、その仕事、全部やめてみようという本で紹介されている、「チームメンバーそれぞれの能力のレーダーチャートを重ね合わせたものが、チーム全体の能力のレーダーチャートとなる」という考え方のもとに、「この分野に関しては、チームの中でこの人に聞くと一番良い」と言えるような分野をそれぞれの人が持つ＝その分野のラストマンになる事でバリューを出し、結果的にチーム全体の力を向上させるというような考え方です。

コンテキストスイッチが減る/即時対応可能なタスクが増える

ラストマン戦略は各人の技術、能力、知といった要素が異なる前提ですが、仮にそうしたものに全く差がなかったとしても、分業することで各人に発生するコンテキストスイッチを減らして一つの作業に集中できるようになります。それによって効率が上がります。
また、必ずしも緊急ではない作業を担当するメンバーが増えることにより、緊急タスクが発生した場合の対応がしやすくなります。つまり、即時対応が可能になり、緊急のタスクについてのいわゆるフロー効率が改善します。

「分業による最適化のパズル」を"解きすぎる"罠

チームで仕事を遂行するとき、その成果を最適化するためには、状況をモデル化して抽象的に把握し、数理的に最適化することが有効な場合があります。ちょっと形式的な言い方をしましたが、少し言い方を変えると、「算数の問題に帰着させる事ができれば、算数の問題を解くのと同じようにチームメンバーにタスクを割り振ったり配置をしたりできる」という事です。

では、チームでの成果の最適化についてはどのようにモデル化するのがよいでしょうか？

各メンバーを、純粋に分業をこなすロボット的な存在としてモデル化すると、上述の「分業による効果」の部分に特化した最適化が得られます。これは、例えば「工数を減らす」とか「リソース効率が良くなるように作業をさせる」といった事を考える上では有効な最適化です。
ただ、そのことだけを考えていてもうまく行きません。というのは、分業に最適化した解は、必ずしもメンバーが周辺知識を得て成長したり、それによって新しい種類の仕事ができるようになるといった事を考慮したものではないからです。

例えば、プルリクエスト（PR）レビューの目的を「そのPRの品質向上」として捉える場合、レビュアーを増やしても必ずしもPRの品質を効率的に 向上させる事はできず、いつもレビュアーを増やすという判断はされない事が多いように思います（少なくとも私はそうでした）。特にメンバーAとメンバーBの能力や知識に差があってメンバーBの指摘は全てメンバーAの指摘に含まれるといった場合、AとBの両方が時間を取ってレビューをするのは、単純にそのPRの品質を考えるならば倍の工数をかけることになり、無駄と思えます。
しかし、PRレビューには「レビューを通して知を獲得する」という意味もあり、それを目的とするならば工数的な意味での"無駄"をむしろ積極的に取り入れる必要があります。
もちろん、長い目で見れば"無駄"ではないので、後で実際に生きる価値まで含めて工数として評価する、というのが理屈としては正しいと思います。ただ、分業の効果を狙いすぎると、どうしてもその時点で直接的に評価しきれない知の共有の効果を失う事になりがちです。分業と知の共有は、必ずしも排他的な概念ではないですし、"真に"分業最適化を目指すならば知の共有が必要になるものの、普通に分業最適化を目指そうとすると知の共有の扱いがどうしても軽くなってしまうように思います。（私個人としては。）

分業最適化していても広く成長できるメンバー

この問題を一層ややこしくしているのは、分業最適化が進んだ体制の中であっても個人として積極的に周辺知識を取り入れ、狭義の自分の専門分野以外についても成長できるメンバーが存在する、ということです。
個としてはこのような在り方は素晴らしく、しばしば模範とされる場合もありますが、これを模範にしてしまうと周辺知識を取り入れようとする個人の姿勢に成長が依存してしまい、結果的に知の共有をうまく行えなくなる事があります。
傾向的には、そのような場面での成長速度は作業量と相関があるように感じますが、よくわかりません。ある程度のノルマや分業最適化した業務をこなした上で、さらに周辺知識を取り入れる余力があるという事なので、必然的に作業量が多い（速い）人になるのかもしれません。

プロジェクトと非プロジェクト的なプロダクト開発の違い

上述のような知の共有と分業のバランス・あるべき姿については、開発の体制がプロジェクトであるか、それとも非プロジェクトであるかによっても違ってきます。ここでプロジェクト/非プロジェクトと言っているのは、特に期日が決まっているかどうか＝有期性か否かです。
プロジェクト的な開発の場合には、期日に間に合わせる事が重要で、分業最適化の方に圧が加わる事が多いです。一方、非プロジェクト的な開発の場合には、必ずしも特定の期日に間に合わせる事が重要ではないため、チーム全体の長期的な視点での作業効率を高めるために知を集めることの合理性が高まります。
単純に最終的な生産量を増やすうえでは、たとえプロジェクト的な開発であっても長期的視点で作業効率を高めるべきですが、期日が制約条件になる事によって、長期的視点での作業効率を高める戦略を取りにくくなるということです。

知と作業のバランス - メンバーに求めるのは知の量か、知を獲得する能力か

これまでの考察でしばしば触れた知というものが、仕事にどのように影響するのかをもう少し詳しく見ていきます。まず一般論として、作業と知の組み合わせによって仕事が為されます。
そのため、チームのメンバーを選ぶ場合には、"機能面"では次のような事を測る必要があります。（それが全てとは限りません）

• 作業の量
  • 仕事に関係する作業の量
• 知の量
  • 仕事に関係する知の量
• 知を獲得する能力
  • チームメンバーから知を獲得する
  • 外部コミュニティなどから知を獲得する
  • ドキュメントや実装などから知を獲得する
  • 自分で考えて独自の知を獲得する

育成的なメンバーの採用では、相対的に作業の量や知を獲得する能力に比重が置かれます。一方、参画直後から即戦力的に活動できる事を意識すると、知の量（および質）が相対的に重要になります。
また、チームまたはビジネスの規模が大きくなると、いくつかの理由により作業の量の比重が小さくなるように感じています。

• 規模が大きくなると専門家が増えるが、高度に抽象化された知を作業のように行うのは難しく、従って専門家の間の作業の差が小さくなる
  • 高度な技術がかかわる場合、作業が大量に必要になるというより、ピンポイントに正しく適用する事が重要になる
  • コードを書く場合にも関係者＝メンテ/確認する人が増えるので沢山書けるより設計が整っている事が重要になる
• 他に作業の量が多いメンバーが存在する場合、その人に適切な知を伝えることができればチームとしては十分な効果が生まれる

個人的な経験としては、作業の量には差が出やすく、かつその作業量の差は永続的なものであるように感じています。他人のN倍の作業ができる優秀な人と普通の人を比べる時、もし二人が同じ知を持っていたとすれば、その作業の差は常に概ね一定であると思っています。ただ、仕事が難しくなればなるほど、その成果は作業では測りにくくなり、作業ではない思考・推論の影響が大きくなります。
また、より重要なこととして、知を共有する前提においては 知を持つ人の効果はチーム規模が大きくなるほど増すということがあります。その人が一専門家として作業をするだけであればチーム規模が成果に直接影響することはありませんが、もしその人が知を共有するとすれば、その効果はチームの全員に及び、同じ作業で他の人が得られる成果が増える事になり、それによってチームの成果が向上することになります。
このような構造によって、「作業が速くはないが知を持っている」というメンバーの価値が生じます。

知はどこにどうやって蓄えられるか - メンタルモデル「森」

これまで、作業量と対照的な概念として知を紹介してきました。
では、この知というものは、チームにおいて どこに、どのように 蓄えられるのでしょうか？
知の蓄積を表現する一つのメンタルモデルは、ダムであると思います。つまり、図書館における本が、ダムにおける水に相当して、知識が水のようにダムに蓄えられるというような考え方です。
一方、私は、同じ知識を水として蓄えるようなメンタルモデルで表現するとしたら、ダムとは別のメンタルモデルを持つ方が良いと思っています。そのメンタルモデルとは、森 です。
このモデルにおいても、水によって知識を表現します。森には保水力があって、森が水を蓄えるように知識を蓄えるというニュアンスです。このときの知識＝水は、森を構成するそれぞれの木であったり、木と木が根を張った間にある土であったり、といった領域に蓄えられます。つまり、ダムにおける水のような蓄積とは形が違って、目に見えやすいわけでもなく、液体として取り出しやすくもなく、かつ構成員にも部分的に保持されながら、十分な構成員が集まることによってその領域に保持されるようになり、例えば一人二人と欠けても知は保持されるし、逆に一人二人では森は成立しない。
そういったメンタルモデルです。
知を蓄えられるチームを作っていくということは、個別に極度に最適化された分業体制をつくるという事ではなくて、知の共有が自然となされる場を作る、このような「森」を作っていくという事なのだと思いました。

知についてのその他の性質や仮説

知がどのような性質をもっているのか、という事について、その他の性質や仮説を述べていきます。

単位時間あたりに知を得る根本的な能力は、作業量ほどの差はない

個人的な主観ですが、純粋に新しい知を得るためにかかる時間は、それまでに体得している知と強く関連していて、かつ作業量ほどの個人差はないように感じています。これは、プログラマー脳で述べられている、熟達した技術者であってもランダムな語を覚える能力が初心者と比較して大きく優れているわけではなく、しかしチャンク化された知識や自動化された知識については熟達者と初心者の間に大きな差がある、といった話と整合的なのかなと思います。（ただ、本当のところはわかりません。もっと根本的な差があったりするかもしれません。）

しかし、どのような知を積極的に得ようとするかという好奇心や執着心は大きな差がある

一般論として、個人の興味、つまり何の圧もなかったときにどういった知を積極的に得ようとするか、という事には大きな差があるように感じます。また、何らかの新しい知を得ようとする事への執着心もまた、個人に大きな差があるように感じられます。
しばしば、「エンジニアは学習の連続であり、学習を特別な努力・苦労として感じないような人がいる」というような事が述べられます。そのように知識を求める事に苦がないどころか趣味として楽しめるような人もいれば、自然には興味が生じない物事に対して苦しんで勉強をするような人もいて、自然に発生する好奇心や執着心の向き先には差があると言えるでしょう。

一つ一つの知は事実の集積であって、多くの場合難しくない

知は、様々な事実の羅列と捉えることができます。時には論理的な飛躍を含む難しい内容もあるでしょうが、ステップを追って一つずつ身につける分には、そこまで難しくない場合が多いです。
もちろん、短時間で多くの知をまとまって身につけるという事には、おそらく向き不向きがあって、人によってそれなりの差があるように感じますが、知を一つ一つ分解すると、多くの場合は難しくなくなります。（これは主観的な評価で、そうはいっても難しいという解釈もあると思います。）

思考停止をしていない限りは、時間の経過に伴い誰もが何らかの知を身につける

それぞれの人が完全に思考停止していない限りでは、時間を過ごすに従ってそれぞれの人は必ず何らかの知を身に着けます。もちろん、質や量には一般には差があると思いますが、バッドノウハウや学習性無気力のようなものも含め、必ず何らかの知が身につきます。

環境の効果によって、意識しなくても身につく知がある

例えばあるチームのメンバーが同じ場所で時間を過ごす時、様々な情報が飛び交いますが、この飛び交う情報によって少しずつ知を得ることができます。特別に記憶をしようと考えていなくても、そうした情報の何割かは自然と身についたりします。漠然と過ごすだけでは、全ての知が整理されて身につくという事はないとは思いますが、しかし断片的な事実として知が少しずつ集積していきます。こうやって獲得される暗黙知や無意識的な知が、そのチームの仕事を底上げしている場合もあります。
私個人は、こうした知は必ずしも顔を付き合わせて仕事をしなくても得られると思っていますが、しかしこのような知の獲得にはリモートワークよりもオフィスワークの方が向いているように感じる瞬間はあります。

特定の環境でしか使えない・通じない知と、ある程度広い範囲で通じる知がある

知には、ある特定の環境でしか使えない・通じないものと、ある程度の一般性があって広い範囲で通じるものとがあります。もちろん二種類に単純に分類できるという事ではなくて、実態としてはグラデーションのようなものではあると思いますが、ある仕事をするために必要な知が特殊なものなのか一般的なものなのか、という事をざっくり考える事によって、例えばその知を獲得するには一般論を学ぶべきなのか現場の個別の知識を学ぶべきなのか、といった戦略を検討できます。

知を"維持"すれば、いつか誰かが解決してくれる事もある - 維持・継続の価値

現在の知では解決できないような問題があったときにも、誰かが知をさらに深堀りすることで、解決できるようになる場合があります。そのような場合は、知を単純に維持するという事にも価値があります。ものすごく極端に言えば、仮に知を維持する人がその場で何の直接的な成果も挙げなかったとしても（それは作業みたいな事だけではなくてマネジメントのような事も含めて今の時点では全く成果が挙がらなかったとしても）、単に知を維持・継続する存在が居るということ、それだけで価値がある事になります。「森」を維持するだけでも価値がある。
もちろん、これは極端な話で、実際には本当に全く成果が挙がらないという事は少ないのではないかと思います。

単純に要素還元的には評価できないチームの機能・価値

これまで、チームで成果がうまく上がるパターンについて、必ずしも分業・分担のみならず、知を介して成果の内容・質が変わり得るという事を説明し、知の性質について掘り下げました。こうした議論を踏まえて、今度はチームの成果、あるいは機能や価値を要素還元的に評価できるかを少し考えてみます。
話を簡単にするため、仮にマネージャーが存在しなくて 実装を行う開発者だけの自律的なチーム であったとしましょう。そのような場合であっても、チームの機能や価値を単純に作業量だけで要素還元的に考えることはできない、という事を述べていきます。

「知を維持していること」の価値

上で述べたように、仮に今現在は技術等の理由で解決できない問題があったとしても、そうした問題が存在するという知・問題意識を語り継ぐ事によって、将来的に問題解決ができる場合があります。これは、知を維持することそのものにある種の価値があるということですが、直接的に何らかの成果・貢献があったと測れるものではないです。維持をしている時点ではいつ課題が解決するかも、解決にどんな価値があるかも、あるいはそもそもその知がどんな課題に関連するかすらも分からないからです。
（未来にある課題が解決した場合に遡って報酬を与えるという考え方もあるかもしれませんが、少なくとも現時点では運用が難しいと思います。ストックオプションなどは、ある意味ではそれに近い構造の報酬かもしれませんが。）

「今まさに手が空いている人がいること」の価値

いくら優秀な人であったとしても、急ぎの実装を複数"同時"に行うことはできず、順番に対処していく事が必要になります。もし他に人がいれば、たとえその人の作業効率が悪かったとしてもすぐに着手できます。これは、提供までのスピードが重要な課題においては重要な価値となります。

ここで見たような、知を維持することも、今まさに手が空いている人がいることも、そのチームのメンバーであれば原則として"存在するだけで行われること"ですが、それ自体に意義があります。これらは広義では成果かもしれませんが、普通は成果とは呼ばず、しかしチームが機能するためにはとても重要なことです。

小話 - JRPGのパーティではあまりできない種類の相談

前の10倍給与問題の記事を書いたとき、「ドラクエのようなものをイメージするとよいのではないか」という趣旨のブコメを見かけました。私自身、普段からレバレッジの効く種類の仕事についてはバイキルトとか言っていて、また職能別の分担（≒ラストマン戦略）みたいな事も考えているのですが、前の記事で考えていたのは単純な職能パーティというよりは「パーティに強い戦士と弱い戦士がいて、弱い戦士がほぼほぼ強い戦士の下位互換/劣化型であったときに、2人の戦士を個としてどう評価すべきなのか」というような事でした。そのパーティが魔王を"ギリギリ"倒したとしたら、強い戦士も弱い戦士も魔王を倒すのに不可欠であった。それは間違いなくそうです。ただ、その分け前はどうすればいいのか？
この問は、しばしば分け前の話を超えて、アイデンティティに関する問になる事があります。弱い戦士は、いつも強い戦士の2歩ぐらい後ろを歩いている。自分はこのまま戦士をやるべきなのかと考えたり（ラストマン戦略の応用）、強い戦士と比べて自分はできないと塞ぎ込む。強い戦士は、そうやって弱い戦士がスポイルされるのを見ると哀しく、時に自分は弱い戦士をスポイルするための存在なのだろうかと思い悩む。「お労しや兄上」

仕事の内容が多様であったなら、様々な軸でメンバーを比較することができて、「完全上位互換」となる場合は少ないと思います。しかし、仕事の内容があまり多様でない場合には、仕事の成果で比較をして「自分は他人の下位互換なのではないか」と思ってしまう場合があるでしょう。JRPGは、キャラクターのタイプに多少の類型はあれど、基本的には"多様"であり、"多様"なジョブから代表を選んで職能的なパーティを組みます。全員が同じ職業について全員でひたすら同じことをし続けるのはFF3の竜騎士や忍者やたまねぎ剣士ぐらいです。
JRPGにありがちなバラバラの職能チームではあまり発生しない種類の悩みこそが、私の気になっていたことでした。JRPGは戦士10人、それもパラメータがバラバラのメンバーでパーティを組むことは普通ないですが、大きなプロダクトを作ろうと思うとエンジニア10人でチームを組む事は普通にありえて、エンジニア10人に振るタスクの質が戦士、赤魔道士、シーフ、吟遊詩人...とバラバラになる事は稀で、しかし同じ仕事でもメンバーの一部のパラメータはバラバラです。場合によっては、時短で働く人も、定時までで働く人も、残業し放題の人も、シフトがずれている人もいます。JRPGでこのシチュエーションに近いのは、ドラゴンボールZの「激神フリーザ」というゲームでしょうか。最終的に、圧倒的な強さの悟空がフリーザと戦うだけで、他のキャラを最高のレベルまで鍛えても悟空とは必殺技の能力が違いすぎるという、ある意味で原作を踏襲した、しかしちょっとアレなゲームバランス。このときチャオズはどうやれば活きるのか、チャオズの分け前とはなんなのか。チャオズがイメージしにくければ、ヤムチャでもいいです。
※お助けカードを使って時間をかけさえすればチャオズでもフリーザは倒せますが、そういう事ではないです。

そのような状況で"効率良く仕事をするゲーム"をするとき、極端に職能/分業最適に振ろうとすると、あまり上手くいっている感じがしませんでした。「この人のパラメータなら今はこの仕事を効率的にこなせる」「とにかく効率的に仕事をする」というやり方をすると、何というか 低レベルクリア に発想が寄っていって、効率的だが脆弱 という状況になっていったように思います。実際、もし本当に各人がラストマン、つまり換えがきかないということであれば、それは 至るところに単一障害点が存在する という事でもあり、それに依存して事業をギリギリで回しているとしたらそれは脆弱です。脆弱でない安定した開発が行えるチームを作るには、知の共有を含め、単純な効率の意味で最速ではない状況 を目指す必要があります。これは、プレイ時間を短くして出入りする金額や経験値を少なくすると、自然と低レベルクリアになっていって、難易度がどんどん上がっていった、というようなイメージですね！
（というか、冗長構成にするとコストアップになるのは当たり前なので、どうしてそんな当たり前の事に今まで気づかなかったんだろう、と思いながらこの文章を書いています。。。）

この構造について難しいと思うのは、単純に作業の効率だけを考えると「作業量が多くない人の知を増やす」という判断をできない場合があることです。というのは、知を増やしても作業量が増えなければ、作業量の意味ではペイしない/しにくい場合があって、そのためにずっと知を増やすという判断ができない場合があります。作業が直接的にお金に変わるような構造のビジネスの場合は特にそれを感じます。

「ただ、一度そういう作業効率で考えることを止めてしまって、もっと知の維持の方を強化してもいいかもしれない。
もちろんバランスがどこかにあるのだろうとは思うけれど、作業効率は唯一の指標ではない。」

めちゃくちゃ当たり前の事を書いているのかもしれませんが、具体的な給与の額はさておき、知を維持するだけでもそれだけで価値があるんだな、という"可能性"に理屈で納得することができたのがとても嬉しくて、それでこの記事を書きたくなったのでした。これまで、なんとなく信じてきた事を説明できる可能性が見つかった嬉しさ。

※ちなみに、私は、もし自分の完全上位互換が居たらいまやりたくてもやれてないことをどんどん出来るようになるので、10人でも100人でも完全上位互換が欲しいです。自分の相対的な格みたいなものは個人的にはどうでもよくて、ただ考え事をしながら思った事を実現して、誰かから感謝されるに足ることができれば、それだけで十分に楽しいと思います。私の夢は「ざしきわらし」になることです！

ラストマン戦略と冗長化の両立 - 最低限の事業成立にはラストマン戦略を含めない

ところで、ラストマン戦略と、冗長化/継続性の考え方を両立する、両者のアウフヘーベンはどこにあるのでしょうか？
私の考えでは、次のような事なのだと思っています。

• 「現在の事業を最低限成立させる」という点においては、経営的にはラストマンに依存してはいけない
  • ラストマンの作業量や知を前提にして事業を組み立てると、それは単一障害点になり経営的に破綻する
• ただし、事業の拡張・成長については、ラストマン戦略を大いに活用していく
  • ラストマンを前提にはしないが、しかし居るときに生み出される価値は利用していく
  • 例えば新しい知を生み出す瞬間はラストマンが居てもいい

「チームメンバーそれぞれの能力のレーダーチャートを重ね合わせたものが、チーム全体の能力のレーダーチャートとなる」
これは必ずしも間違ってはいないと思いますが、この重ね合わせたチャートの限界の部分に依存するような構造を作ってしまうと、脆弱になります。また一方でチームがうまく機能するための要素には能力だけではなくて知も存在しており、知をうまく蓄積・共有する事ができれば、単一障害点がなくなり脆弱ではなくなります。
従って、知を蓄積させるにあたってはラストマン戦略を意識して、それぞれの構成員の好奇心や執着心によって生まれる知をレーダーチャートのように重ねていき、そうして蓄積した知をもとにチームとして仕事を進めていけば、個人の作業量の違いはあれど、盤石の体制で業務が進みます。

チームの人数が少ない場合や立ち上げの時には、脆弱な体制であっても効率が必要となるタイミングがあると思いますが、もし立ち上げたチームを拡大していく事を考えるなら、作業量・効率重視から知の蓄積によって成果が出るスタイルへのパラダイムシフトが必要なのだろうと感じます。

むすび

いかがでしたか？

人によってはものすごく当たり前のことだったかもしれないのですが、個人的には数年に一度の気付きであるように感じています。こんなの当たり前だという方、あるいはもっと進んだ考え方を知っているという方、ぜひどこでどうやってその考え方を身に着けたのか、教えて欲しいです。
私は、社会人としてのキャリアの最初で、かなり強烈に自分自身のコストや工数というものへの考え方を身に着けさせられたのと、もともと効率的なゲームプレイが好きだったので、効率パズルに全振りして低レベルクリア に挑み続けていたのだと思います。この低レベルクリア技術は、お金がない状況ではとても重要で、この先もそれなりには使うと思いますが、しかし第一に考えるべき事では無くなってくるのだろうなと思っています。
違ったキャリアがあれば違った学びがあって、そこには私の知らない考え方があるのだろうと思うと、ぜひお話を聞いてみたいなあと思います。