低スキル志向なチームの育て方３選

先日、低スキル志向なチームについて考えてみた。

それは、ある時点で比べたらたまたま高スキルなチームよりは相対的にレベル低かったというものではなく、落ちるべくして低スキル方向に転がっていくという性質をもったチームだった。

今回は低スキル志向チームをより低スキルに育てるポンコツ育成プラクティスを考えてみる。

■ 低スキル側に合わせてルールを設定する

• あるプログラミングテクニックやライブラリについて、初心者には無理だとか、以前にだれかが間違った使い方をしたといった理由で、全面禁止とする文化。
• 実行しながら学習する文化、上手に失敗しながら成長する文化が醸成されず、低いレベルで成長が頭打ちになる。
• 出来るメンバーからアホらしくなって離脱してチームのスキルレベルが下がる一方となり、ルール設定がさらに低スキル向けになって負の強化ループが発生。
• 「メンバーのレベルが上がったら解禁しよう」などと言うが、そんな機会は永遠に来ない。

• 例

  • VC++ と MFC を使った Windows アプリ開発に、クラサバ業界から Cプログラマや Pro*Cプログラマが流れ込んできた時、オブジェクト指向がわからないといった理由でポリモーフィズムが禁止されたり、IDEが使えないからといった理由で小さな関数の禁止といったルールが定められた。
  • Java のサーバサード開発の普及期の現場に、大量の COBOLer や VB厨の軍団が流れ込んできた時にも、小さなクラスやメソッドの禁止だとか、ポリモーフィズムを活用したデザインパターンが禁止された。
  • 最近では Scala 開発で Cats や Scalaz などの圏論ライブラリ禁止や、Shapeless などを用いた型レベルプログラミングが禁止されたりする。
  • 一般的には、小学校のテストの「可換則使用禁止問題」などと同根。

■ テッキー君に「共通コード」を担当させる

• そこそこプログラミングが好きなメンバーに、共通コードや、ラッパーフレームワークを書かせる。で、人材市場で安くかき集めたポンコツ人海戦術軍団に、その共通コードを使った「業務ロジック」を、書かせる。
• 実は人海戦術軍団の中にもレベルの高低ムラがあり、中には共通コード担当のテッキー君と同等以上のメンバーが含まれることもあるが、組織の空気として、人海戦術軍団には技術面は期待しないという暗黙のメッセージが常に発せられているので、レベル高めのメンバーから順にチームを離れていく。
• テッキー君自身も、技術的アンテナの感度が高くて向上心をあればあるほど、劣化する一方のチームの淀んだ空気にも、自分自身の井の中の蛙的ポジションにも耐えられなくなり、早晩離脱する。後釜のテッキー君はさらに劣化したテッキー君になるので、テッキーポジション自体も劣化する。
• Eric Evans が 青い DDD本で言ってたような、「Apply top talent to the CORE DOMAIN, and recruit accordingly.」といった高スキルチーム向けのガイドラインは、邪念として却下する。
• 反省: 自分もプログラマになりたての、サーバーサイド Java に Servlet と JSP しかなかった頃に、こうしたテッキー君ポジションで、ポンコツ軍団向けフレームワークを書いたことがあるが、今では後悔している。業務ロジックチームでメンバーに直接スキル移譲しながら、ドメインのコードを直接洗練させるべきだった。

■ チケット駆動開発「だけ」しかやらない

• チーミングの工夫や、コミュニケーションの活性化はいっさい無視して、とにかくチケットだけ回しておけばOK、それしかないのだ、それで充分だと思い込む。なにもかも JIRA / Github のコメントだけで仕事を進めようとする。
• アジャイルを参考にすると、マニフェストの「プロセスやツールよりも個人と対話を」という価値観に抵触してしまうので、アジャイルは禁教とする。
• フェイス・トゥ・フェイスのコミュニケーションはムダな時間として廃止。自分にアサインされたタスクに無関係な情報には耳をふさぎ、他人の仕事には我関せずを貫徹する。
• 浸透的（osmotic）コミュニーケーションが発生せず、自然なスキルの伝播が起きないので、チーム全体のスキル向上が伸び悩む。
• 誰もが無言で働くようになり、沈黙を破る心理的障壁がたかまる。雰囲気も悪くなって、行き場所のあるレベル高めメンバーからチームを離脱していく。
• 高スキルメンバー離脱 → チームの平均スキル低下 → リソース逼迫 → コミュニケーション省略で負のループが加速。
• 補足：いろんな現場で話を聞くと、「うちは仕様や計画の変更が多いからアジャイルは向かない」なんて真逆すぎるアジャイル理解の発言を聞くことが最近は多いが、そうした無知・無策にも程がある現場で「そういえばJIRA使ってたなあ、てことはチケット駆動開発になるのかなあ」みたいな適当な流れで、ちゃんとチケット駆動開発を研究することもなく謳われるのが、低スキル志向現場のチケット駆動開発。

■ 逆3行要約

• 禁止ルールで縛るより上手に失敗しながら成長しよう
• スキル高い人こそ「業務ロジック（≒コア・ドメイン）」にアサインしよう
• チケット管理ツール使うならチーミングも工夫しよう

ドメイン層にメタデータは入れないでね

某社内フレームワークがOSS化されたという記事が出て、ツイッターでいろいろつっこまれていたが、低スキル志向な組織では結構普遍性がある話なので、ちょっとメモしておこう。

どういうものかというと、「DDDを意識した」と謳ってる Scala フレームワークで、全てのエンティティの基底となる trait として EntityModel なるものが定義されていて、以下の属性を持つという。

• エンティティのIDを表す id
• データ更新日を表す updatedAt
• データ作成日を表す createdAt

まあ、ID をエンティティに含めるかどうかについては、最近の関数型DDD界隈では議論があるけど、一応ここでは良しとしておこう。でも、データ更新日とデータ作成日はないわな。メタデータやんけ。

注文日時とか支払い日時とかならわかるけど、データ生成日って・・・どうしてこうなった？

百歩ゆずって、「データ○○日」がユビキタス言語になるような、ある種のドメインのある種のエンティティがあったとしても、そんなのむしろ特殊ケースだわな。全ての DDD エンティティの共通属性なんかにはならない。まして OSSとか・・・

要するにこれ、永続化層の都合で考えてるんじゃないのかね。ドメイン駆動とは正反対に。

なんか関連記事では「DDDを意識した」とか言ってるけど、むしろ逆にドメインモデリングなんか全然意識したこともなく、まして Persistence Ignorance とか聞いたこともない感じの技術者が、エンティティを「DBテーブルの受け皿」くらいにしか認識できてないまま、社内標準共通カラムとかをケースクラスに反映させちゃうときにやらかす、ありがちパターンなんだが。

こういう、下手くそなフレームワークを作って組織内に展開すると、ずっとこれ使うことが強制される部下たちが可哀そうなんだよな。

「プロダクトの標準化」とか言っても低レベル側に倒してるだけだから、これだとスキルが高い側に淘汰圧がかかって、低スキルメンバーしか残らなくなる。出来るメンバーからアホらしくて抜けていくから、組織的にも良くないだろうし。

もしオフショアやら若手やらでスキルムラが酷すぎて、標準化目的のフレームワークで型にはまった金太郎飴を作らせざるを得ないってあれなら、まず安易な人材調達から改善しないとダメだろうな。高スキルメンバーだけで数十〜数百人集めてる組織だってあるわけだし。

三行要約

• メタデータをドメイン層に入れるのは止めましょう
• DDD って言いたいだけで DDD って言うのは止めましょう
• ポンコツフレームワークを社内展開するのは止めましょう

補足

• メタデータがドメインモデルに含まれないのは当然として、関数型DDD界隈では、エンティティは自分の ID を持つべきではないという流派もある。（参考)
• ツイッターで突っ込まれていたのは ID の型の指定の仕方だったが、ドメイン層にメタデータを混入させてしまっている事の方が余程ひどい問題。
• フレームワークを標準化目的---プログラマを型にはめるために作ったり使ったりするのって、本当に酷い愚行で、組織学習の強烈な阻害要因だと思うけど、別の機会に書きたい。