2018.06.20

少数精鋭でやれない場合にどうするか

■「抱き合わせ派遣」の問題

 設計と実装を分業するとロクなことはない。それぞれの専任要員を配置するようなことをすれば、仕様書という名の実装作業指示書をまとめるための手間が激増するだけでなく、伝言ゲームの結果のような低品質アプリが続々と生み出される。とくに仕様書をExcelあたりで書く場合には、仕様書を維持するための手間があまりに膨大なので、設計担当者が増員されて設計品質までが急降下してゆく。

 そのような悪循環から脱却するにはどうしたらよいか。(1)設計・実装の合理化ツールを導入すると同時に、(2)プロジェクトメンバーを少数精鋭で固めることだ。こうすることで、少数精鋭だけで設計から実装まで担えるので、生産性も品質レベルも劇的に向上する。また、一人当たりの利益が増えるので、給与レベルも上がる。なによりも、安く早く良いシステムが手に入るのでユーザ企業に喜んでもらえる。良いことづくめだ。

 この話をしたら、SIerで働く友人に「それはそうだと思いますが、精鋭だけで固めたくてもそれが出来ない事情がSIerにはあるんですよ」と諭された。協力会社に精鋭技術者の手配を求めると、精鋭でない要員を何人も含めた「抱き合わせ」での派遣契約が求められるのだという。しかも、精鋭を確保するための頼みの綱が協力会社であるゆえに、精鋭以外は不要などとは言えないらしい。他のSIerでもそっくりな話を聞いたので、よくある話なのだろう。開発案件が協力会社にとっての「OJT教材」にされてしまっている。

 このように説明すると、いかにも協力会社の問題に思えるが、もとをただせば発注側(一次請けのSIer側)の問題である。かつて、一次請けできる大手SIerはこぞって社内要員全員を「PM専任」に仕立てた。PM単価を高く設定できるゆえに効率的に稼げるからだ。この「全員PM主義」は当然ながら技術の空洞化を招く。その結果、開発実務を外部業者に頼る状況が生まれ、遅かれ早かれ外部業者の意向に逆らえなくなる。

 実状はもっと危うい。二次請けくらいに位置するSIerは、一次請けもやることがふつうだ。ゆえに彼らも実態としては「全員PM主義」で、開発実務家の調達を外部業者に頼っている。かくして、三次請けや四次請けの要員が実際のDB設計を担当していたりする。彼らがうまく設計できないとは限らないが、クライアントや一次請けが要員のスキルレベルをコントロールできないという意味で問題がありすぎる。

■少数精鋭にPM専任は要らない

 そもそも、「PM専任」という役回りは人海戦術においてこそ必要になる。その仕事の多くの部分は「無駄に多い外注要員の労務管理」であって、これは少数精鋭プロジェクトでは不要だ。メンバーがごく少数なので、チーフエンジニアが(本来の)PM作業を兼任できるからだ。わずか4、5名のチームの1名がPM専任であることの不自然さを想像してみてほしい。

 それゆえ、SIerが少数精鋭体制を実現するためには、社内要員をPM専任から開発実務家に職種転換することから始めなければいけない。とくに大手のSIerには有能な人材が多いので、想像するほど難しいことではない(宝の山と言ってもいい)。同時に協力会社にもその旨を伝え、彼ら自身にも少数精鋭体制への移行に努めてもらおう。基本的に内作するとはいえ、いざという時の要員のバッファーとして協力会社は欠かせないからだ。

 とはいえ、協力会社ともども少数精鋭体制を布くには時間がかかるので、当面は「抱き合わせ派遣」を受け入れざるを得ない。そこで、精鋭ではない要員(サポート要員と呼んでおこう)に何をやってもらうか(何をやらせてはいけないか)を見定める必要がある。

■異常なスキルレベル分布

 話は替わるが、こういった主張をすると「技術者が精鋭であることを前提にして考えても現実的ではない。"ふつう"の技術者を前提として考えるべきだ」といった突っ込みがあるかもしれない。しかし私が「精鋭」を強調するのには理由がある。松下幸之助が指摘したことで有名な2:6:2の法則に従うと、スキルの高い上位2割が「精鋭」で、「ふつう」は真ん中の6割に相当する。これらを合わせた8割が「組織にとって許容できるスキルレベル」を満たす。図示すると次のようになる。

▼図1 一般的な技術組織のスキルレベル分布
20180618_1

 これは一般的な組織での例であるが、業務システム開発の現場では様子が違う。就職氷河期を含めた長い期間、この業界は「若年労働者の失業対策」と揶揄されながら、大量の労働者を受け入れ続けた。しかも、大手SIerが採用する有能な新卒はことごとく「PM専任」に仕立てられた。その結果、開発実務のスキルレベル分布は低スキル側に偏った形になった。とくに人数ばかりが多い大規模プロジェクトでは、図2のようになってしまっている。

▼図2 大人数プロジェクトでのスキルレベル分布
20180618_2

 図2における「ふつう」は、図1での"ふつう"ではない。組織にとって許容できるレベルを満たす要員は、図2では4割しかいない。その人数比の小ささゆえに、私はかれらを「精鋭」と呼ぶのである。いっぽうサポート要員は、スキルレベルでは正規分布した場合の劣後2割と同等でありながら、人数では6割を占める。

 この状況がもたらした困った思い込みがある。「業務システム開発は、マニュアルに従ってこなせば誰でもやれる簡単なお仕事である」というものだ。医者や建築家や音楽家や政治家のような専門職には、職業適性が厳然としてある。当然ながら業務システム開発者にもそれが問われるのだが、多勢に無勢でそのことが曖昧になっている。まずは、「開発要員には適性もセンスも要る」という冷徹な事実を受け入れよう。有効な組織改革はそこからしか始まらない。

■サポート要員を生かす

 サポート要員にどんな役割を担ってもらうべきかの話に戻そう。少数精鋭が担う工程を、"設計や実装の品質に直接影響を与える"という意味で「クリティカル工程」と呼んでおく。クリティカル工程をサポート要員に担当してもらうわけにはいかないが、それでも工夫の余地はある。

 たとえば、旧システムのデータを新しいDBに移行させるには、調査やクリーニングやスクリプティングといったこまごました作業が要る。また、本番モジュールが出来上がってくるとシステムテストの人工(にんく)が要るが、これも多ければ多いほどよい。こういった「手間はかかるが、システムそのものの品質には直接影響を与えない(つまり間接的には影響を与える)仕事」、すなわち「非クリティカル工程」を、彼らに担ってもらえばよい。

 言うまでもないが、データ移行やシステムテストは格の低い仕事ではない。業務システム開発に携わろうと思う者ならば、早いうちに何度も経験しておきたい工程だ。データモデルの読解のような基本的なスキルが身につくだけでなく、業務知識の必要性も身にしみてわかってくる。その経験がさらなる成長やキャリアアップの機会をもたらすだろう。

 この分業体制は育成の観点でも参考になる。将来的に協力会社からサポート要員を押し付けられることがなくなれば、非クリティカル工程を担うのは社内の新人で固めたらよい。システム品質への攪乱を最小限に抑えながら、新人に実務経験を積んでもらうためだ。

■置き換え困難な"ふつう"を目指そう

 重要な工程であるとはいえ、非クリティカル工程を担う要員は「置き換え可能」である点が、クリティカル工程とは違っている。必然的に、プロジェクト内、組織内での待遇も違ってくる。マイケル・ジャクソンの待遇が破格なのは、彼の演奏が多くの人に満足を与えるだけでなく、要員として置き換え困難であるからだ。

 ようするに、開発実務のスキルレベルに従って要員の待遇や配置を決めたらいい(*1)、という話だ。けっして、「多人数でやれば文殊の知恵が発揮されるだろう」などと考えて、設計作業にサポート要員を投入してはいけない。それは「オンチでも100人くらい集めて歌わせれば、きれいなハーモニーになるだろう」と期待するようなものだ。どうしてもサポート要員をクリティカル工程に配置するのなら、リスク要因としてシビアに管理されなければいけない。

 あらためて言うまでもないが、サポート要員や新人の配置を工夫することよりもはるかに重大かつ困難な課題が、少数精鋭の開発実務家を調達することだ。それが無理ならば下手の考え休むに似たりで、プロジェクトそのものをあきらめたほうがいい。どんなに優秀なPM専任が揃っていようが、少数の精鋭技術者さえ手配できないとしたら、技術組織としてすでに機能不全に陥っているということだ。

 ただし、所属組織の変革の遅れを嘆いている暇などない。精鋭(つまり図1での"ふつう")であることの良さは、どこに行っても食える気楽さにある。精鋭として生き延びるために、PMスキルでもなく実装スキルでもなく設計スキルの習得を優先させよう。今後は実装が楽になるばかりで、結果的にチームが少数精鋭化するため、設計担当者が実装とPMを兼任できるからだ。そして、設計スキルは一朝一夕では身につかないゆえに、人材として貴重であり続けるからだ。


*1.そのためには、技術者のスキルレベルをいかに評価するかが課題になる。自己評価と他者評価を突き合わせて判定してもいいし、試験を含めた審査制度を整備してもいい。しかし、いずれにせよ完全に客観的ではあり得ないので、その組織での自分の評価が満足できないのであれば、淡々と河岸を替えたらいい。

<本記事の内容に関連するイベントのお知らせ>
「超高速開発で上流工程は従来とどう変わるのか」
(技術者5人による事例発表とパネルディスカッション)
2018年7月5日(木) 14:00~17:00 神田エッサム1号館301
お申し込みはこちら

| | コメント (0) | トラックバック (0)

«オリンピックをモデリングしよう