「選択と集中」について、最近思っていること - その２

この記事の続きです。

私個人の主観と観測範囲、そして自分がどうしたいかの願望を下敷きにしている文章です。今回も特に結論めいたものはありません。

そもそも、「選択と集中」というのは、何をどう選ぶことなんだろうか？
自分に耳障りの良い、チェリーピッキングな解釈をしていないか？という気もする。

この言葉の由来を自分は知らないが、直感的には元々の趣旨は組織や会社、あるいはビジョン・ミッションなど、もっと大きな主語にかかっている抽象寄りの標語なんだろうなという感じはする。

だから、自分が「選択と集中」について語るのであれば、たぶん組織的な方向づけについての議論が本筋という気はしている。

「その１」では主に個人レベルのタスク・プロジェクトアサインの粒度を調整する話に主眼を置いていたが、そもそもこれって「選択と集中」の話に該当するのだろうか？と疑問に思った。

私自身は、個人のアサイン調整レベルの話も、かなり枝葉寄りではあるが「選択と集中」に該当する話のひとつだと思っている。特に、保守的な性格が薄い、アグレッシブにリソースを投資して価値を生み出したいプロジェクトが複数あるときなどはこれが強く該当すると思う。

ある程度社内システムが成熟した企業の社内SE という現職だと、積極的にドライブしてプラスの付加価値を付けていきたいプロジェクトよりは、どちらかと言えば保守的な性格が強いプロジェクトの方が多い。そういう状況では兼務は仕方がないと思うし、また兼務体制自体も合理的であるケースが多いと思う。

ただ、前述したようにがつがつ進めたいプロジェクトへのリソース配分で個人の兼務を（積極的に）良しとすることは、個人的にはあまり良い結果を生まないと思っている。感覚的には、稼働 n % で兼務する場合は純粋な割り算とコンテキストスイッチのオーバーヘッドの差し引きが最低限発生する。そこからさらに数割の追加デバフがかかる程度にはロスだと思っている。

（補足: そもそも兼務体制によって発生するコミュニケーションロスは個人のリソース効率ではなく、リードタイムなどのフロー効率に対する損失だと考えているので、このようなリソース単位のデバフで表現すること自体に語弊がある気はする。本筋じゃないのでこのへんにしておくが…）

思うに、選択すべき対象というのは個人レベルの特定のタスクということではなく、ビジネスとして達成したいミッションのことを指しているのだと思う。

あるプロジェクトに専念することと、そのプロジェクトで期待される仕事を単一に絞ることはまた違う。
開発者として参画していても、叶えたいゴールや価値創造を最大限達成するために様々な関係者を巻き込んで努力する人と、言われた仕様を受け取ってコードを書くこと「だけ」を仕事として他の役目あるいは境界に触れようとしない人とでは、雲泥の差がある。後者も解釈次第では「選択と集中」と言えるかもしれないが、少なくとも私はそのようなスタンスが「選択と集中」の望ましい在り方とは考えていない。まあ、これは界隈でもよく出てくる「3人のレンガ職人」の話が自分の言いたいことに近いと思う。

要するに、ビジネスの成功に対して目的意識の照準をあわせた状態で「選択と集中」をしよう、という話なんだと思う。個人のアサインとかいうミクロな粒度は「選択と集中」の本質ではない（と、自分としては思っている）。

１つ前の記事では「自分のリソース配分が散らかってしまって、中途半端なプロジェクトが出てしまった」的なことも書いていたような気がするが、ここの懺悔は実際に私が感じたことなので事実ではある。ただ、これを「選択と集中」の文脈に当てはめて反省するのも違和感があった。たぶん、違和感の正体はこういうことなんだろうなと思う。私個人の時間配分の問題と考えてるなら、たぶんそれは本質からズレている。

自分のリソース配分が分散していたことに対しては、（少なくとも自分はがつがつ新しい価値を生み出すことが要求されるプロジェクトをそれほど持っていなかった事情もあったため）ある程度仕方ない側面があったと思う。
とはいえ、兼任が当たり前になってしまうことで、普段の意思決定に対しても「そういう」バイアスが掛かってしまう側面があったんじゃないか？と思う部分もあり、そのへんがモヤモヤすることろである。本当はもっとビジネスに目を向けて大事なプロジェクトを選べたのではなかろうか？とか、兼任する状況が大前提の状態で会話してしまうことで、マクロな視点で議論することが難しくなってしまってはいなかったか…？とか、そういう話。

現状の仕事の仕方が余計なバイアスになって、気が付かないうちにもっと重要なマクロの選択をあらぬ方向に誘導されてるんじゃないか？機会損失してないか？というのが、自分がこれまで「リソース配分の分散」と感じてきたことに対する悶々の正体なのかもしれない。

繰り返しにはなるが、ある程度社内システムが成熟した企業の社内SEという仕事は、性質上どうしたって「塩漬け」に近い扱いになりつつも完全に手放すこともできない、そんなシステム・プロジェクトが発生してしまう。全部が全部ビジネスの付加価値を生み出すわけじゃないし、発生頻度や業務工数、あるいは業務インパクトが小さいものに対して、積極的なパワーなどかけていられない。おそらくそうした事情自体はやむを得ないことだと思っている。

これまで「分散している」と感じてきたことが、どうなれば解消されるのだろうか？少なくとも「集中」させようとしたアクションの結果として私の担当領域（もっと言えばオーナーシップの範囲）が狭まるのは本意じゃないと感じている。

今の自社に関して述べると、エンジニア採用や組織的なエンジニアリング力の底上げといった特定プロジェクトに依らない部分の組織強化に関心がある。こうした現場の「本業」から少し外れた領域は手薄になりがちだと感じるし、組織の課題としても非常に優先度が高いと考えている。ただし、あくまでも「エンジニアとしての自分」が成立しているのが大前提であり、現場で通用するだけの能力・経験・視野が根幹にあってこその活動であるとも思っている。エンジニアとしての感覚が鈍ってしまうのは自分が目指したい姿ではないし、自分が考える「成果」からも遠ざかると考えている。
ちなみに私が思う「成果」はだいたい以下のようなイメージ。

望ましい「成果」の在り方とは、中長期の視点でも結果が出せていて、かつそれが持続できる組織を目指していくことだと（自分なりには）考えている

前回の記事「「選択と集中」について、最近思っていること - その1」から引用

特定のミッションに照準を絞ってリソースを集中投下し、ビジネスを前に進めることに貢献したい・・・という気持ちもあるし、
エンジニアリングだけじゃない、周辺のことにも目を向けてやっていかねば最良の成果は得られない、と考える自分もいる。

自分の意識・直感としては、この2つの考えは矛盾なく両立するはずだと思っている。ただ、まだ自分の中ではハッキリした整理・言語化ができてなくて、相反しているように感じているところもある。まだ自分なりの解答は出ていない。