2019年3月10日日曜日

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

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

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

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

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

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

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

0 件のコメント:

コメントを投稿