このブログを検索

2022/02/10

なぜIT業界のプロジェクトはうまくいかないのか

私はIT業界で30年以上仕事をしてきた。

30年前に「IT」という呼ばれ方はされていず、「情報処理」とか「OA(Office Automation)」などと言われ、もっと柔らかい言い方だと「コンピューター関係」とか「ソフト開発」とかいう風に言ったり言われたりしていた。

「IT」という呼称が一般化したのは2000年ごろだろうか。森総理大臣がそれを「イット」と読んだことがニュースになったのが2000年である。

わたしのキャリアの1/3くらいはまだITとは呼ばれなかった時期ということになるが、ここではその時期を含めて「IT業界」という言葉を使う。

30年ほどこの業界にかかわってきてずっと、この業界のプロジェクトは成功した例があるのだろうか?と感じていた。

あらゆるプロジェクトが計画通りに進まず、仕様が途中で変更あるいは追加され、無謀なスケジュールと不均等な業務分担が当たり前だった。

わたしはこの業界以外を知らないが、たとえば自動車を製造する、ビルを建築する、お菓子の製品を開発して販売するといったプロジェクトでは絶対にこんなひどくはないはずだという確信がある。

IT業界が特殊な理由として私が考えていたのは、まずそれが成熟していない新しい産業であるということだ。コンピューターというもの自体が実用化され始めたのは1950年代ごろだろうか。

私は1990年代初めにこの業界で仕事を始めた。最初に入った会社は「XXシステム開発」という名前で、ソフトウェア開発を主業務としていた。その会社はある企業のシステム部門が独立した会社だった。

私が入社した時(最初は契約社員だった)、机の上にパソコンはなかった。
灰皿があった(と思う)。

私が入社して2年くらいして喫煙室ができたので、それまでは室内で吸っていたはずだ。

プログラミングするときは、コーディング用紙に鉛筆(シャーペン)で書いて、完成してから端末で入力した。

コードを入力できる端末はそのオフィスには確か3台くらいしかないので、交代で使用するのである。

その端末は本当に「端末」だった。

今の人は「タンマツ」といっても通じないか。

タンマツというのは、ホストコンピュータに接続されてディスプレイとキーボードをそなえたものであり、一見現在使用されているデスクトップコンピュータのようだが、実際に処理が行われているのはホストコンピュータであり、「端末」は入出力装置にすぎない。だから「端末(Terminal)」なのである。

私の所属していた部署は「オフコン」を使用するシステム開発をする部署であった。
「オフコン」とはオフィスコンピュータの略であるが、いわゆるメインフレームと言われる大型のコンピュータと同様の機能を持っているが小型でオフィス等におけるくらいの人の腰の高さくらいの大きさのコンピュータである。

ドキュメント類も鉛筆と定規を使って手書きで書いていた。
フローチャートとか、ファイル定義とか。

1992年くらいからか、職場に自分のノートパソコンを持ち込む人が現れ始めた。
そしてオフコンを使ったシステムの需要は急速に減少していき、仕事が暇になった。
そして1995年に私はその会社を辞めた。

Windows95が発売された年である。

5年ほどいたその会社でかかわったプロジェクトでうまくいったと言えるものはほとんどなかった。比較的うまくいったプロジェクトは、要件があいまいなままなんとなくだらだら続けたものか、ガチガチに要件を固めて客に有無を言わせず作ったものかのどちらかだった。

それからはソフトウェア開発からインフラ構築とか検証とか運用のような業務をするようになっていったが常にキーボードをたたいて何かしらのコマンドを実行したりコードを入力することをしていて、自分は「SE(システムエンジニア)」であると自覚していた。

1995年のWindows95の登場をきっかけに家庭や企業でのインターネット利用が本格的に普及しはじめ、職場では一人1台パソコンを使用するようになっていった。

そして私はネットワークを主に担当するネットワークエンジニアとなっていった。

ネットワークはソフトウェア開発とは多少異なるが、やはり要件定義、設計、構築(実装)、試験(検証)、運用というフェーズを経るのは同じだった。

そしてネットワークのプロジェクトもだいたい計画通りにいかず仕様変更(要件変更)や追加は当たり前でやっとの思いでプロジェクトを完遂させるのだった。

なぜ、IT業界のプロジェクトはうまくいかないのだろうか。
今、改めてそれを考えている。

私は最初の会社でシステムエンジニアをしていた時に「人月の神話」という本を読んだ。
これは今では当たり前に言われる「プロジェクトマネジメント」について書かれた本であるが、私がこれを読んだ当時プロジェクトマネジメントなどという言葉はほとんど聞いたことがなく、会社にもそのようなポジションはなかった。

SE(システムエンジニア)とPG(プログラマ)があるだけだった。

今年、人月の神話のことを思い出して改めてざっと読んでみたのだが、
結局30年間、この本に書かれているプロジェクト管理についての問題とそれを解決する特効薬のような手段(銀の弾丸)はないというある意味悲観的な結論が正しいというのは変わらなかったのだと再認識した。

IT業界というのはソフトウェアが非常に重要であり、わたしにとってITとはほとんどソフトウェアとイコールである。

コンピュータや通信機器はソフトウェアを入れる箱のようなものであり、ITエンジニア(システムエンジニア)というのは、その箱を作る人ではなく箱の中に入れるものを作る人であると考えている。

30年前から、ソフトウェアなどというものはコンピュータを動かすためのちょっとしたおまじないのようなものだと考えている人がいたが、それは現在も同様である。

ITのプロジェクトが失敗する根本的な原因はソフトウェア軽視なのではないか?

そしてもう一つ、ソフトウェアやプログラミングというものが数学だと思っている人が多い気がするが、一般の企業で社員が使用するようなシステムにおいては、ソフトウェア開発でもネットワークシステム設計においても数学を使用することはほとんどない。

(四則演算とか不等号とか2進数16進数などは必要だがそれは数学というほどのことではない)


「私は文系だからプログラミングができない」
「私は理系だからプログラミング(コンピュータ)のことがわかる」

これは実際に私が職場で聞いた発言であるがどちらを聞いた時も釈然とせず少し憤りをおぼえさえした。

わたしがコンピュータプログラミングに興味を持ったのはテレビでBASIC言語を知り、

if a>0 then goto 10

という構文を見た時だった。

「もし...なら、...しろ」
コンピュータが人間の言葉で動かせるんだ、という驚きである。

つまり、プログラミングは数学ではなくむしろ英語なのである。

(アセンブラとかはもちろん例外)

「理系だから英語が苦手」
「文系だから数学わからない」

それはいいが、だからといって理系だから「if ... then」がわからないとは言えないだろうし
文系だからって「 a > b  」は理解できるだろう。

そしてIT業界(先ほど言ったように一般企業で社員が使うようなシステム)で必要な英語も数学もその程度でしかない。

出身が理系文系かなど関係ないのである。

あと、「数学とプログラミングは論理的思考が必要な点で似ている」とかいうのもよく聞くのだが、数学でなければ論理的思考は必要ないのだろうか?

文章を読んだり書いたりするときに論理的に考えないのだろうか?

そういうことを言う人は「英語や歴史は考えないで丸暗記するから」程度のことしか考えていないのではないか?


ここまで書いてきて、ITプロジェクトがうまくいかない、炎上する、破綻する、頓挫する、終わらない、理由が分かった気がする。

まず、コンピュータやソフトウェアが魔法のツールであるという過信。
それらも人間がプログラミングしデバッグし検証を繰り返すという地道な作業なしに成立しないことへの不理解。

先ほどの文系理系数学英語というものと結び付けて話すことからわかるように、学問や技術についても学校などで教えてもらえば使えるハサミやトンカチのような便利な道具であるとしかとらえていないこと。

つまり、ほかの業界では当然考えたり確認したりするようなことを、IT業界ではしなくていいという先入観、これが根本原因ではないだろうか。