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

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

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

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

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

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

• 例

  • 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行要約

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

「チケット駆動開発」案件から感じるヤバさ

ウォーターフォールでもアジャイル系でもその他のプロセスでもなく、単に「チケット駆動開発」とだけ書いてる案件たまにあるけど、ほぼヤバさしか感じないのだが...

要するに、アジャイル的な変化への対応や自己組織化をマスターしてるわけでもなく、かといってWF＋PMBOK 的な計画ベースのプロジェクト管理スキル持ってるわけでもなく、出来ること出来ないことの区別もないまま、ビジネス側＝神の声に為すすべもなくただ振り回されてるだけの集団が、「何もわかりませんし何もできません」って素直に認めるのもアレだから、「そういえば Jira 使ってたなあ」だとか、ふと思い出してチケット駆動開発って言ってるだけなんじゃないの、どうせ？

なんて、まあ想像だけど疑ってしまう。

別に「チケット駆動開発」それ自体には、若干のモヤモヤを除けばあまり文句はない。

関わりたくないのは例えば、アジャイルについてまともに調べた事もなく、ウワサの又聞きの雰囲気の伝聞程度の知識と、下手につまみ食いして下手に失敗した下手くそな体験で「完全理解！」気分になったテックリードが、無知の上にいろんな勘違いを積み重ねて「うちは仕様や方針の変化が多いからアジャイルは向いてない」とか言ってドヤっちゃうみたいな現場の「チケット駆動開発」。

そういう勉強も研究もしないのがデフォな現場だと、冒頭に書いたように、計画ベースの管理と変化への順応のどちらにも対応する能力がない上に、チケット駆動としても初期の提唱者達が謳ってたような効果を得るには程遠いものにしかなりようがない。ルールも徹底されないから、なんとなく思いついたところから Jira に起票して、思い出したらプルリクに書いとくくらいが関の山。（なぜか決まって Jira なんだよな）

あと、こないだ書いた「プログラミングとはSEが書いた設計書に従ってPG＝IT土方が黙って手を動かす作業である」って文化的遺伝子が、大半のメンバーに受け継がれてるような低スキル志向な現場での「チケット駆動開発」だと更にやばい。

そういうとこで認識されている「チケット駆動開発」とは、「チケットに書いてる作業だけ、所定のフローに従ってとっとと処理して回してくこと」だから、自分にアサインされてないチケットには我関せずで、自然と他人に構うのは損という価値観になる。

チーム全体の現状や目標についても無関心になってくるし、しまいには出社してチケットだけ見ながら仕事して、誰とも話さず退社する人も出てきたりする。チケットがむしろコミュニケーション分断の道具になって、個室のタコツボに閉じ込められて仕事してる感じになってしまう。

つうわけで、やっぱ却下だわな。

----
モヤモヤ１: たかが「コミットをチケットに関連付ける」ってだけのルールを、わざわざ○○駆動開発って言うのは大げさな気がする

モヤモヤ２：かといってタスク管理フローとチケットの重要度を上げると、「プロセスやツールよりも個人と対話」に逆行して、売りになってる「アジャイルとの親和性」も損なわれる気がするし

低スキル志向な現場とは何か

低スキルと言っても、上には上、下には下がいるわけで、高いところと比べたら低いといった相対的な程度問題ではない。ベクトルの大きさではなく向きが、いろいろ正反対になっていたりする。

なんと言うか「ソフトウェア開発とは低レベルな人間を集めてやる苦業」という、半ば無意識だけど強固なメンタルモデルがまずあって、それに即して人が集められ、技術が選定され、開発プロセスやコーディングルールが策定され、さらにそうした信念を再生産する形で世代交代もなされていくような。

そういう現場を、ここでは差し当たり低スキル志向な現場と呼んでみたい。

----

低スキル志向な現場の特徴は、まずルールやガイドラインに分かりやすく現れる。とにかく初心者、新人、未経験者、不勉強者、老害といった、低スキルサイドに基準が置かれる。

たとえば 2007年ごろに C# が3.0になったときも、低スキル志向現場ではラムダ式が禁止された。もっと昔には、C++ のプロジェクトに参入してきたC言語プログラマのために、OOPの技法（特にポリモーフィズム）が禁止されたという。最近では、Scala の現場で、OOPすら怪しいレベルの Java プログラマ達に合わせて、Cats などを用いた高度な関数型プログラミングが禁止されたりする。

「フレームワークとはなんぞや」といったそもそも論レベルでも考え方が全然違う。元来はそれなりに分かっている人間が、ドメイン固有部分とテクノロジー共通部分を切り分けて関心事を分離するために使っていたはずの道具が、いつの間にか、いくらでも交換可能な無知蒙昧なIT土方軍団を、拘束して矯正するための型枠として使われるようになった
※（個人的には Terasoluna なども、少なくとも現場ではそうした思想で使われていたように思う。

こうしたルールは、その時点で中級以上の技術の使用を禁止しているだけじゃなく、低レベラーもいつか中レベラー以上になりうるという成長の可能性までをも事実上制限してしまっている。だから、そういう現場でいくら年数を詰んでもスキルは伸びないのだけど、困ったことに、年数が経てばスキルは低いまま肩書だけナントカリーダとかナントカマネージャに昇格して、ルール策定やチーム作りを主導するようになるから、低レベラーの輪廻が永遠に続くということになる。

また低スキル志向な現場では、周囲の生態系も低スキル志向になりがちで、例えば人材市場へのチャンネルでも、正味のスキルは等閑視されたまま、注文分の頭数がなるべく早く安く調達できるような人材業者が重宝されようになる。

高スキル志向な組織では、日頃から世の中のデキる技術者を探してつながりを作るような働きかけをしていて、採用面談なんかもそれなりの高倍率になるものだけど、低スキル志向な現場では、業者から供給されるままに受け入れて、頭数だけそろえばOKということになる。また離職率も高いから、早く安くタイプの人材業者とのつながりがますます強化されることになる。

こう書くと、なんだかいかにも受託SIer の現場風景ぽいけど、最近では自社サービスのWeb開発業界でもめちゃくちゃ多い。

思い起こせば、サーバーサイドJavaが興隆した2000年前後に、大手 SIer 系の現場にいわゆる「VB厨」や「コボラー」が大量に流れ込んできたのが、個人的には低スキル志向な現場の原風景だったりする。ああいう環境に浸って中堅くらいまで育ってきた叩き上げが、特に反省も勉強もないまま世渡りしてるうちに、何かの拍子で自社サービスWeb業界に入り込むパターンが多い昨今なのだと想像する。

とは言っても、実は、個人的には全否定するつもりはない。それで雇用が生まれて世の中が回っているという面もあるけど、それはそれで別としても、技術者として敢えて低スキル志向な現場に入ってみるメリットもなくはないと思う。

• 糞コードへの耐性ができる: きれいなコードばかり読み書きしていると、汚いコードが本当に全然読めなくなる。現代人が泥水を飲んだり腐肉や芋虫を食べたりできないのと似ているかもしれない。
  
  実は高スキル志向な現場でも、トレードオフスライダーの定め方によっては読みにくいコードが仕方なくコミットされることはある。職業プログラマとしては、そうした現場に途中参加してもスムーズに適応するための耐久力がほしい。
  
  低スキル志向な現場では、美しいコードなんか生まれてこの方考えたことも見たこともないようなプログラマが、なんなら「コードなど汚いほどプロっぽい」みたいな謎の価値観に則って、猛烈な糞コードを日夜積み上げているから、定期的にそういうのに接すると免疫力向上に効果がある。
  
  
• 当たり前な事をあえて省みる機会になる: 例えば「コードは読みやすいほうが良い」とか、「関心事は分離したほうが良い」とか、「パフォーマンス改善のためには計測が必要だ」とか、「チームメンバーは互いにコミュニケーションをとった方が良い」などといったことは、ふだん当たり前すぎていちいち疑問を持ったりしない。
  
  こうした事も、低スキル志向なチームの面々と話すときにはちゃんと言語化する必要がある。ときには根拠の根拠の根拠の根拠くらいから説明することにもなるので、ある意味、哲学とも言えそうな思考の訓練になる。
  
  
• ちょっとした冒険になる：若干中二っぽいが、科学も人権も存在しない古代〜中世の異国に、文明の利器を持たずにタイムスリップしてサバイバルするような冒険心をくすぐる体験ができる。
  
  現代社会では当たり前の技術や考え方が通用しないので、いろいろ工夫が必要になるし、低スキル志向な現場ならではの人間模様やドラマもあって興奮させられる。特に、チーミングの面で昨年流行った「一人から始めて越境する」的なやつも実践できたりして、わりとまじで勉強になることも少なくない。
  

デメリットとしては、自分のスキルまで落ちてしまうのが大きい。宇宙飛行士の筋肉のようなものかもしれない。変な話、プライベートな時間に10個の知識を独習している一方で、勤務時間に20個の知識が溶けていく感じになる。世の中の進歩から取り残される不安がどんどん迫ってきて、これは結構怖い。
※ 書籍『Learn Better』には、全然使わない知識は母国語ですら忘れてしまうという事例が紹介されている。

だから、もし低スキル志向の現場をやるとしたら、半年を越えないくらいの任期で、なおかつ高スキル志向な現場の任期との比率が2:1以下くらいになるように、案件を選ぶと良いと思う。

ただし業界に初めて入って来てから、高モチベなメンバーに囲まれた楽しいチームしか知らないようなアジャイルネイティブな若者は、こういう現場に入ってきても単に心が折れて変なんなっちゃう可能性もあるので要注意。経験豊富な中堅以上で、ある程度自由の効くフリーランス向け。

ドメイン軽視のメンタルモデル

自分はわりとシステム開発の対象とする問題領域、つまりドメインをどうモデリングするかについて関心がある方なので、ツイッターのTLなんかでも、ドメインのモデリング／コーディングについて熱心に語っているツイートが自然と多くなる。なので例えば DDD を応用して日々研鑽している人が多いなあという感想をもってしまいそうになる。

ところが、世間一般ではかならずしもそうではない。

一応それなりに高スキルなメンバーを集めたチームですら、ドメインを扱う技能は意外と重視されない。そもそも高スキルチームを目指してのメンバー集めの段階で、インフラ〜ミドルウェアにかけての最新プロダクトやライブラリの経験が評価されることはあっても、ドメインのモデリングについて触れられることはまず無い。

技術者評価の面でも、ドメイン以外に関するスキルだけが注目される。大規模で複雑なドメインの中に適切に境界を定めて粒度と整合性のトレードオフを解決したとか、関心事の分離を徹底してドメインのコードをより純化したとか、そういったことは話題にもあがらない。ドメインモデリングに関する功績や努力はほぼ常に無視される。

ましてや低スキルチームでは、そのチーム内では若干マシなプログラマが「共通コード」やら「フレームワーク周り」やらを担当する一方で、コードベース全体のその他 90〜95%くらいを占めるビジネスロジックを、人材市場でかき集めた十把一絡げの人材と、経験１・２年の初心者で構成された、何にも知らない人海戦術軍団で対処することになる。

そうした現場では、ドメインモデルなど最初から最後まで一瞬も考慮されることなく、DBアクセスとHTTP入出力のあいだに、うず高く積まれた手続き型コピペコードからなる糞コードの大山脈が形成されるが、低スキルチームでは管理職以下だれもがそれで当たり前だと思ってる。ビジネスロジックのコーディングとはそういうものだと、上から下まで普通に認識されている。

ちなみに DDD の Eric Evansはこう言っている。

Apply top talent to the CORE DOMAIN, and recruit accordingly.

これが真逆だから、チームのスキルバランスもおかしくなる。成果物となるプログラムの大部分はドメイン固有のコードなわけで、時間もマンパワーも大部分そこに費やされるのだから、ドメイン層にこそ知識や技術や経験や才能を集めて洗練させるのが本来優先になる。「フレームワーク周り」の層なんか、ドメインを洗練する初期の過程で必要性が高いものから自然に形成されれば良い。

またビジネスロジックに永続化層の都合を混在させて Persistence Ignorance を壊したり、ひどい場合は「大規模なドメインでのトランザクションスクリプト」に至ってしまうのも、ドメインの軽視が主因。ビジネスアプリケーションのドメインとはそもそも複雑なものだという認識が足りないからそうなる。

さらに、ドメインモデルは一発で正解を出すものではなく継続的に洞察を深めながら進化させるものだという認識も、ふつうは全く足りないからテストもお気楽に省略される。MVPを厳選してなんとかファーストリリースにこぎつけたとしても、その後早い段階で詰んでしまう。

ちなみにそういう風景って、なんとなく受託 SIer あるある的なイメージだけど、今では自社Webサービス業界でもすごく多い。推測だけど、受託SIer の土建的世界観で育った中堅「SE」が、そのままのメンタルモデルを強固に維持したまま、いわゆる「自社サービス」の「Web業界」に流れてきて同じことをやってるのではないかと思う。

こうしたドメイン軽視のメンタルモデルには共通の起源があるように思うが、別の機会に書きたい。

このギャラ、損か得か？

開発案件のギャラを比べるとき、単純にどっちが得でどっちが損か比較するのは意外と難しかったりする。

難しい理由は、案件の内容だとか契約条件だとかいろいろあるが、今日は、契約条件に含まれる清算方式の違いを解消して比較する方法を考えてみる。

例１）
見込み稼働時間数が 月240h の半炎上プロジェクトで、140h〜180h上下割60万の条件がついたとする。これと等価な単金固定プロジェクトのギャラはいくらか？

答え：
60万 + 60万 ÷ 180h ×（240h−180h） = 80万

言い換えると、これまで 140h〜180h上下割60万で仕事を受けてきた技術者が、見込み月240h の単金固定案件を受けるとすると、80万もらわないと割に合わないということになる。

例２）
単金固定72万の案件の引き合いがあって、プロジェクト内容を聴いたらとっくにデスマ化していて稼働300hに達している。これを140h〜200h上下割に換算するといくらになるか。

答え：
x + x ÷ 200h ×（300h−200h） = 72万
これを解いて、x = 48万。

このご時世、72万なら悪くないと思うかもしれないが、稼働時間によっては、上下割換算で40万台のしょっぱい案件になり得るとわかる。（ちなみに、この例を上限180hで換算すると43万2千円）


比較用に標準的な条件を設定して、複数案件を比較するという手もある。例えば「162h の時給換算」とか。（行政機関の年間営業日243日を採用し、これを12ヶ月で割ると、一月あたりの勤務日数は20.25日となり、これに8時間を書けると162時間となる。）

例３)
他の条件（通勤、やりがい等）が同じとすると、得なのはどれか。
① 60万単金固定 (想定220h)
② 57万(140-200) (想定220h)
③ 55万(140-180) (想定220h)
④ 54万(140-180) (想定200h)

答え：
① 60万 ÷ 220h × 162h =44.1818万

② 57万 × (1 + 20h／200h）=62.7万
　 62.7万 ÷ 220h × 162h =46.17万

③ 55万 × (1 + 40h／180h）=67.2222万
　 67.2222万 ÷ 220h × 162h =49.5万

④ 54万 × (1 + 20h／180h）=60万
　 60万 ÷ 200h × 162h =48.6万

得な順に、③→④→②→①　となる。

①、②、③は清算方式の違いによって、見掛け上の単金と受け取り額の順序が逆転し、従って損得も逆転する。
①と④では、受け取り額が同じだけど、稼働時間の違いにより、損得が逆転する。

====
こんな感じで、案件を比較できる。

（理想的には、8時間働いた後に追加で働く1時間と、12時間働いた後に追加で働く1時間では、同じ1時間でも価値が違うので、これを考慮する変換方式にする必要があるが、かなり複雑になる。）

換算方式を工夫すれば、他の要素も取り込んで標準化して比較できる。特に、通勤にかかる時間は、実は交通費以上に結構大きく影響する。往復30分と3時間では、実質的に失う時間が大きく違うので、比較するには一工夫必要になる。