SIerの問題点への補記
問題点の考察を行うこと自体は良いと思うのですけど、それを内省にだけ求めてしまうと世の中ブラック一直線だったりするので、問題解決については広い視野から考えるのが大事だと常々思っているわけです。
面白かったのですけど、もうちょい考察を深めても良い話なので、視点を追加した考察をオッサンが書きたく思います。
それは本当にSIerの問題点なのか？
さて、元記事で挙げられている問題をピックアップします
- 技術力向上のインセンティブが少ない
- ソフトウェア開発の技術力に対するコモンセンスがない
- 基本的に外注である
- プロセス重視である
問題点を分析することは良いことですが、ではなぜそれが存在するか、が実は問題だったりします。それについてちょっとだけ追記したく。
今回挙げられている問題点ですけど、一番肝心なプレイヤー「顧客」が存在してません。SIerも商売ですので、当たり前ですがお客さんがいます。その客抜きで問題点を議論しても答えはミスリードとなるだけじゃあないかと思います。
技術力のインセンティブは顧客訴求力に依存する
まず「１」の技術力へのインセンティブですが、端的に言ってしまえばその技術はお客が求めているのか、ってのがいつも問題になります。
まあ、よくある話なんですけど、エンドユーザにとって新技術は素晴らしい、導入したいって言ってくることは少ないんですよね。
お客は「どんなサービスができるのか」「どんな新機能が使えるのか」「どれだけ費用対効果を発揮するのか」みたいな機能要件に対しての関心は強い半面、非機能要件である生産性や保守性については無関心なことも珍しくないです。技術が好きなお客さんは、トコトン好きですけどね。
となると、そういった新技術導入といった非機能要件についてはお金が取れない案件となり、ときとしてベンダ側の持ち出し、技術教育投資として対応することもまああります。
また、元記事の内容を見るに、単金なんて言葉が出てくることから、請負契約結んで他社のプロジェクトに対して技術提供を行う仕事しているのかな、なんて読み取れます。
ここで問題になるのは、「持っている技術が比較優位を保っているか」。
例えば、技術を提供しようとしている相手が自分よりもスキルが高かったら？
もしくは、今現在のプロジェクトで役に立たないスキルだったら？
この場合、持っている技術が相手の需要にあってないため、価格訴求力として役立たなくなる可能性があります。
わりとよくある話なんですけど、元請け側の人間がアーキテクチャの設計ができたり、インフラの設計ができたりすると、そういった部分の設計については元請け側のスキルでやってしまったりすることがあります。
となると、そこの仕事に請負で参画した場合、同一方向のスキルを持っていたとしても発揮できないことがしばしあります。
となれば、別方向のスキルを提供できなければ単価をあげれないんじゃないかな、と思います。
例えばセキュリティのスペシャリストなど、特定分野のスペシャリストの場合は非常に仕事の単価が高い、なんて聞いたりもします。
技術力のインセンティブが無いってのは、お客が技術に金を払ってくれないっていう状況の裏返しだったり、「晴れの日に傘を売る」状況だったりするわけですね。。。
そういった状況を見ると、また考え方も変わるかと思います。
「測定できないものは制御できない」
さて、「２」ですが、「なんだかわからないので評価できない」のではなく、デマルコ、ドラッカーの言葉を借りるのであれば「測定できないものは制御できない」となります。
でも、オッサンが思うにコレをお偉方が判断出来ないと嘆くのはちょっと筋違いかな。
オッサンも新技術を導入することよくありますが、新技術を導入してほんとうに効果が出たのかどうか、を測定する義務が導入者である自身にあると思ってます。
成果が出ていればよいですけど、成果が出てなかったり、成果が導入コストに見合ってなかったりすれば、新たな改善を検討したり、場合によっては新技術を諦めたりすることもときには必要です。
そういった技術をより高めるための振り返りとして、生産性向上や品質向上などの効果測定は必ず行うようにしてます。
導入者が測定しなければ、新技術を有効に活用するための制御ができないってわけですね。
その効果測定の結果は振り返りのさらなる改善活動だけではなく、バシバシお偉方に提示すれば良いんですよ。メンバーで共有すれば良いんですよ。
新技術により生産性が上がった、品質が上がったのであれば、堂々と証拠を示せば良いんですよ。わからない相手をわかるようにすることも仕事だと思いますよ。
あと、元記事では、そういった成果を競争させるべきなんてまとめてますけど、ちょっと違うかなと思います。
ぶっちゃけ、いろいろな新技術や生産性向上施策を試しましたけど、プロジェクトの特性や要件により必ずしも成功するわけじゃあないです。
生産性が良い、効率が良いってのはぶっちゃけ結果なわけで、その知見を得るためには誰かがチャレンジしなければなりません。
チャレンジに対する失敗責任を一方的に負わすだけでは、誰も新技術にチャレンジしなくなりますがな。
マネジメントのセンスがなければ内製でも同じ
続けて「３」ですが、コレは外注だからの問題ではなく、単にマネジメントの組織教育と情報共有の問題でしょう。
というのも、内製でも組織風土の風通しがよくなかったり、ドキュメントなどの形式知を残すという文化がなかったりするため、ノウハウ蓄積共有なんて出来てない組織はザラにあるからです。
まあ、情報共有できないのに外注も内製もへったくれもないです。
ちなみに、人を選べないってのは請負契約だからですね。
でも、請負契約は成果で仕事を判断しなければなりません。人で仕事したら、場合によっては偽装請負となります。
コレはどちらかと言うと仕事をマネジメントするタスクマネジメントの問題だろうなと思います。要は、適切に仕事を割り振る技術があるかどうか。
人に仕事を依頼する技術を向上させれば、円滑な仕事、手戻りもない仕事が実現できたりしますので、偽装請負の様な問題を引き起こさないためにも鍛えておいたほうが良いかと思います。
プロセス重視は武器だったりもする
「４」ですが、この背景は「顧客が求めているから」。
CMMIに代表されるように、SIerの仕事の技術力は統制能力で図られることがよくあります。言い方を変えれば、プロセスを軽視するということはSIerとしての技術が無い、とみなされたりもします。
※まあ、ホントのところ決してそんなことは無いわけですけど。
となると、官公庁や金融機関の一部などのお固い仕事を受託する場合、時にCMMIレベル４以上みたいな、プロセス成熟度が達成できることを求められます。
身も蓋も無い事を言ってしまえば、プロセス重視というのはときとして顧客が求める技術要件である場合もあり、翻っていえば、SIerの武器の一つともいうわけです。
問題点に感じるかもしれませんけど、現実は逆かなあ。
顧客が欲しがっているものが、実は問題と感じている部分にあったりするわけです。
まとめ
さて、元記事の考察に「顧客」の観点を追加してみた感じですが、また違った問題点も見えたかと思います。
ここには記載してませんが、「競合会社」「オフショア」なんかも視点に加えると更に面白い考察ができます。
※コレを加えるとものすごく長くなるので割愛。
まあ、ご参考までにってことで。
以上
