orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

なぜアプリケーション開発業務は労働集約型になりがちなのか

f:id:orangeitems:20180807122742j:plain

 

IT業界は労働集約型産業か

過激な表現で話題となる、「木村岳史の極言暴論!」の最新記事に少し思うところがあるので記事にしておきます。

 

tech.nikkeibp.co.jp

日本のIT業界の関係者は、自分たちの業界が建設業界によく似ていると思っている。さらに心ある人は「ITはハイテク産業のはずなのに労働集約型の建設と同じだから、日本のIT業界はダメなんだ」と嘆く。確かに多重下請け構造は建設業界にそっくり。米グーグル(Google)や米アマゾン・ドット・コム(Amazon.com)などの巨大プラットフォーマーが主導し、知識集約型あるいは資本集約型の産業として進化を続ける米国のIT業界と比べて、ため息をつくしかない。

 しかし、建設業界の人から言わせると「冗談じゃない!」ということらしい。

 

考察

私も、建築業者のプロジェクトマネジメントを目にしたことがあります。マンションの大規模修繕の際にちょうど理事会の役員をしていて、施工についての報告を受けたのですが、本当にWBS通りに物事が進んでいきました。もちろん天候等で遅れが生じる場合があるのですが、予見して土日に作業したりして調整していました。確かに建築業界のプロジェクト管理と比べるとIT業界のそれは、劣っているのは確かだという実感はあります。

ただ、IT業界の方々のプロジェクトマネジメントに対する知識や経験が未熟だとは決して思いません。この業界も昔に比べるとかなり成熟してきましたし無茶なプロジェクトも昔よりは減ったと思います。しかし、存在はすると思います。

本文中ではITに理解のない顧客側が無茶な要求をベンダーに行い、これを受けてしまうからと分析がされています。私はもう1つ重要な観点があると思っています。もともと非効率で労働集約的なプロセスだからこそ、システム化したいと顧客が思っているということです。完全にシステム化してしまえばそれはシステム化の成果ですが、そのシステムを作るまでは、属人的で非効率な仕事の仕方を分析し見える化しなければいけません。要件定義や設計などの上流工程は、お客様の真の目的を理解するために、非効率なプロセスであってもしっかり向き合わなければいけません。そしてプログラミングというのはその非効率なプロセスをコーディングして自動化する仕事なのです。総じて思うのは、非効率を効率化するまでは、手間がかかり時間がかかるので、労働集約型にならざるを得ないということです。

もっと具体的にしましょう。例えば駅の自動改札のシステムを考えます。このシステムが全くなかった時は、駅員が改札に立っていました。そして駅員がどんな仕事をするのかヒアリングします。ヒアリング時に要件を聞き出します。その要件を組み合わせて要件定義とし顧客のシステム担当者と打ち合わせします。漏れがないかを確認したうえでシステム設計に入ります。設計ができた時点で顧客に再度説明すると、「あれ、これだとこうなりませんか??」という疑問をぶつけられます。しかし要件定義ではそんな話は出ていませんでした。再度、現場の改札業務を行っている職員に話を聞くと、確かにその仕事はやっているということでした。というふうに、せっかく上流からシステム化進めようとしても、途中でひっくり返ることが良くあります。これは、顧客側が認識していないなんらかの仕組みがあり、システム化する中で気づかされることがあるからです。この暗黙的な仕組みは、「経験による知恵」という形で属人化されシステム化の抵抗であるとも言えます。システム化が失敗するのは、どんな工程であってもこのような後から出てくる隠れ要件がどんどん発生し、手戻りが起こり工数が膨らんでいきます。

建物の建築のように、設計が決まればそのまま建物まで落とし込むことに波乱がないのであればいいのですが、システム開発はそうは行きません。要件定義がそのままシステムテストまで流れる場合は、パッケージ開発などよほど要件が決まり切っている場合しかないと思います。今システム開発の世界で成功しているのはパッケージベンダーで、パッケージに合わせて業務を作り替えるということを顧客が承認している場合に限られると思います。スクラッチでシステム開発する場合は隠れ要件による波乱の連続でデスマーチ化しやすいとも言えます。また官公庁はスクラッチ開発が多いことも合わせて述べておきたいと思います。この点で木村氏とは意見が合致します。

 

まとめ

SIという仕事については、顧客があってベンダーがあって、その間に要件があります。スクラッチによるシステム開発を続ける限りは、労働集約的になるのは致し方ないと思います。なぜならば顧客が要件自身に気づいていないことが多いからです。

一方で、パッケージ導入の場合はすでにパッケージ側で要件が決まっていて、これに業務を合わせていくフローとなりますので、欧米型のSIはこのパターンです。ここでカスタマイズを大量にし出すとせっかくパッケージを使う意味が無くなりスクラッチと同じことになります。そもそもパッケージとは、他社の効率化事例の標準化の結果であり、これに合わせて業務プロセスを改革するのが本来です。日本は現場が仕事の方法を変えたがらず、現場に合わせてシステムを作ろうとしてしまいがちです。そのプロセスは総じて非効率なので、これに付き合うシステム開発は労働集約的であるという結論です。

この辺りの話は、日本でも理解されつつありパッケージベンダーの業績も伸びていますので、だんだんとスクラッチSIはじり貧になっていくのではないか、と思っています。

 

 

図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ (Panda Publishing)