2018.11.17

システム開発企業のスリム化戦略

 開発スタイルの革新が進行している。3人の設計専任者がExcelで仕様書を書いて10人の実装専任者が1年かけてプログラミングしていた――そんな案件を3人が半年で完成させてしまった。そんな事例が今日もどこかで生まれている。その特徴は、プログラミングの手間を大幅削減する合理化ツールを用いた「プロトタイピング」が核になっている点だ。ツールから出力できるのでExcel仕様書を書く必要がない。設計できさえすれば片手間で実装できるので実装専任者も要らない。

 その種の合理化ツールを活用している開発企業に関する興味深い話を聞いた。その会社では従来型のスタイルで開発する組織と合理化ツールを使う開発組織とを分けて、後者には有能な新人を多く送り込んだそうだ。偏見のない目で合理化ツールに取り組んでもらうためだ。

 それから数年たった現在、驚くことが起きている。人数の多い旧組織では以前から赤字が続いていたが、人数の少ない新組織がその赤字を補填する以上の黒字を出している。しかも、旧組織では昔から残業時間が長いのだが、新組織では定時を過ぎると誰もいなくなるという。合理化ツールはソフト技術者の働き方改革の主役でもあったのだ。

 開発プロセスが合理化されたことだけが新組織の好調さの原因ではない。技術者が営業活動に協力することの効果が大きいという。営業担当者が探し出した見込み客の目の前で、要件にもとづいてデータモデリングして、動くシステムを作ってデモしてしまう。そのように技術力を示せば、成約率は確実に上がる。こういうことが可能なのも、合理化ツール活用の前提となる設計スキルを身につけていることが、新組織のメンバーであることの強みだからだ(それが出来るようになることが、新組織に受け入れられるための要件でもある)。

 いつもこの事例のようにうまくいくとは限らないが、それでもここには開発企業が合理化ツールを導入する際のある問題を解決するためのヒントがある。合理化ツールの導入にともなって生まれる大量の余剰人員をどうするかという問題だ。多くの開発企業の経営者が合理化ツールの威力や脅威を理解し始めてはいるのだが、稼働率の低下を恐れてなかなか導入できないでいる。なにしろ同じ受注量を少数精鋭だけでこなせるのに、日本では余剰人員を簡単にクビにできない(ゆえに会社は雇用に消極的にならざるを得ないので派遣業が繁栄する)。どう対処すればいいのだろう。

 手順はこうだ。まずは希望者を募って、合理化ツールを活用する小さな開発組織を立ち上げる。その際、給与レベルはそれぞれの組織の業績に連動することを宣言する(この意味で事業部制に近い)。数年たてば、新組織はしっかり稼げるようになるので約束どおり給与レベルを上げ、赤字の続く旧組織の給与レベルを下げる。

 いや、新組織が赤字で旧組織が黒字になるのかもしれない。ここで大事なことは「開発手法」毎に組織と給与レベルを分ける点だ。だから「アジャイル開発部」や「ドメイン駆動開発部」があってもいい。それぞれの技術者が自分が望む開発スタイルを主体的に選ぶ。つまり、「なんでウチはアジャイルでやらないのか」などと愚痴をこぼす前に、アジャイルでやる組織を立ち上げてとっとと稼げばいいのである。

 それぞれの「開発手法別組織」の業績に差がつけば、状況は勝手に変化してゆくだろう。稼げる組織には好待遇ゆえに有能な人材が流入するいっぽう、稼げない組織はメンバーが増えない(自然減にまかせてゆっくり消えてもらうことになるが、薄給が嫌われて案外早く消えるかもしれない)。つまりこのやり方で「余剰人員」だけでなく、「有能な人材がなかなか来てくれない」という問題や、開発手法に関する社内の異論にも対処できる。最終的に会社の経営方針は「大人数でいかに売上を増やすか」から「少人数でいかに利益を増やすか」に切り替わる。

 なお、「合理化ツール活用型組織」の育成方針について補足すれば、メンバーには簿記やDB設計といったオーソドックスな設計スキルをしっかり教えたほうがいい。そのことには実務に役立つ以上の効果があるからだ。どんな合理化ツールにも一定のクセがあるもので、自分の実装手段が特定ツールに限定されることに抵抗を感じる技術者もいる。それゆえ、汎用的な設計スキルを有することが、特定ツールの専門家になることへの不安を和らげてくれる。設計スキルさえあれば、他の合理化ツールや実装手段への移行は容易なのだから。

 また、合理化ツールを使うということは「開発経験の蓄積速度」が高まるということでもある。新人でも数年もたてば立派なデータモデルを描けるようになるだろう。私は断言するが、そうなればどの開発会社に移ろうがフリーランスだろうが食べていける。逆説的ではあるが、その自信は技術者が特定企業で安心して働き続けるための動機になってくれるだろう。

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

«「試算表テーブル」を設計する?