このブログを検索

ラベル プロジェクトマネジメント の投稿を表示しています。 すべての投稿を表示
ラベル プロジェクトマネジメント の投稿を表示しています。 すべての投稿を表示

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業界ではしなくていいという先入観、これが根本原因ではないだろうか。

2020/02/15

ある暴露話について感じたこと

twitterであるプロジェクトの暴露話が話題になった。

それに関して感じたことを書いておきたい。

どこまで本当の話かわからないし、ブログの筆者、かれが非難している「PM」なる人に対して批判や反論をしたいわけではないので、リンク等は一切貼らない。

暴露した人は結局耐え切れずにプロジェクトを抜けており、
一方的にプロジェクトを、そしてその「PM」を非難しているので、
どこまで信用できるかわからないが、それほど事実とことなる話ではなさそうに感じた。

同情する点、自分も反省しないとと思わされた点もあったが、彼の言い分に同意できない部分もあった。

この話で完全に否定されている「PM」と呼ばれている人物が誰なのかとても知りたくて、
この話にまつわるtweetを読み漁り特定のキーワードで検索した結果、誰なのか(twitterのアカウント)がわかった。

けっこう有名人らしく、確かに大規模案件を成功させてきた実績のある人らしい。

本人も自分のことだと認めるような発言をしていた。
(ただしもちろんブログの内容自体を認めているわけではない)

私は彼のツイートも読み漁った。

ブログにはプロジェクトの参画者をツイッターで募ったもののそのツイートが非常識で時代錯誤なものであったため誰も集まらなかったと書いてあるのだが、その求人ツイートも確認できた。

その後プロジェクトが難航して参画者が「逃げた」ので仕切り直しになったということもツイートしており、ブログに書かれていることがおおまかに事実であることがわかった。

このプロジェクトはDBを使ったアプリケーションの開発のようで、私の仕事とは少し違う分野なのだが、私の仕事でも「PM」、「仕様と実装」みたいなものがあるのは同じである。

かなり古い時代だが、DBを使ったアプリケーション構築もしたことがある。

そして、批判されている「PM」は、私と同年代であり、
批判している人は若く、せいぜい30代くらいと思われる。

そのことが、私に彼への批判をそのまま受け取りにくくさせた。

面倒なので、ブログを書いた人をA君、批判された「PM」をB氏としよう。

さっきからずっと「PM」とカッコにくくっているが、それはA君はあまりにPM(プロジェクトマネージャー)の役割やあるべき姿に対して固定観念を持ちすぎであると感じたからだ。

A君が思い描いていたPMの姿、それはどこから得たものかわからない。本で読んだのか、過去に参画したPM達の仕事ぶりからの一般論なのか。

確かにプロジェクトマネジメントに関する資格はあり、その保持者でないとPMになれない、というプロジェクトもあるが、医師、弁護士、会計士、税理士といった資格とは違って、「よく勉強している人」程度のものでしかなく、PMの資格をもっていないとシステム開発をおこなえないわけではない。

この話で一番感じたのがこのA君の一方的なPM像についての違和感である。

そして次に、この話のタイトルにもなっている、大規模プロジェクトを少人数で担当したという点である。

A君はプロジェクトの規模が大きいことを金額で示した。

これにも違和感がある。

そもそも彼が書いている「数億円」という規模は、B氏が受注した金額ではなく、
他の有名企業が見積もった金額らしい。

そしてB氏はそれをはるかに下回る金額と短納期で受注したようなのだ。

私はあまり工数や費用の見積もりに詳しくないが、
ことITに関しては非常に難しく、開発する側の立場としてはほとんどの場合過剰に高額に見積もられていると感じる。

それは多分多くの人が自覚している。私も、『こんなことでこんなに貰えるならもっと安い金額で自分でやろうかな』と思ったことが何度もある。

おそらくB氏は私が思っただけで終わってしまったことを実行に移したのである。

どうやらB氏はPMだけでなく営業もしており、さらに企業の社長であり講演などもおこなっている。そしてもともと自分自身で手を動かし開発してきた技術者であり、いまでも自身で開発業務もおこなっているようである。

現在私の職場では、PMという役割は基本的に技術的なことにタッチしない。ほとんどのPMは技術者あがりで自分は手を動かさないものの技術的なことを理解はしている。

しかし中には、ほとんど技術的なことを理解しておらず、自分以外の誰かに仕事を割り当てて顧客の要求をそのまま横流しするようなPMやPLを見かける。
この話もそのようなことなのかなと思った。

私も、「仕様のないプロジェクト」というものに参画したことがある。
「仕様がなくてはできません」と文句を言ったこともある。

しかし後から振り返ってみれば、私が想定していたピラミッドのようにきれいに階層化されて、上から顧客の要求を注ぎ込むと、あとはコーディングするだけの技術仕様ができるような組織なんて、ユートピアのようなほとんどありえないものだったとわかる。

そのように見えるプロジェクトには必ずスーパーマンがいて、常人の何十倍何百倍の効率で仕事をしている人がいるのだ。その「何百倍」というのは労働時間のことではない。

IT業界で長年にわたり問題になっているのは工数を人数×労働時間「人日」で見積もることである。

どんな業界でも労働時間が生み出す価値に必ずしも比例するものではないが、IT業界、開発業務においてはとくにそれが著しいと思う。

極端な例を言うと、バグだらけのシステムを開発して長い時間をかけて改修し続ければ、納期に間に合わせさえすれば時間をかければかけるほど開発者は多くの報酬を得るのである。

ソフトウェア開発も「設計」、「構築」、「開発」などどという言葉を使うが、物理的な建築物にくらべて制約が極端にゆるく無制限といっていいくらい柔軟な対応ができる。

言語やツールも豊富にありどれを使っても自由だ。

だから、工数などというものも、やる前から見積もるのは非常に難しくほとんど意味がないとさえ言えるのだ。

やりようによっては10人で1か月かかるし、1人で一週間で終わる。

大人数でやると、開発そのものと同じかひどい場合はそれを上回る情報共有や進捗管理の工数が発生する。

私が経験してきたプロジェクトはほとんどが中身に比して人員過剰管理過剰になっていて、それによってかえって労働時間が増え品質も低下していると感じる場合がほとんどだった。

うまくいったプロジェクトは少人数で、ある程度気心のしれたメンバーでとくにルールもなく柔軟に対応していたものだった。

だが、その個人の裁量にまかせる柔軟なやり方は大規模で大人数のプロジェクトではうまくいかない。そういう「わかっている」人達は大規模組織で守るべきプロセスがかったるくて実力もでない。(私の実体験A)

一方、強力な管理体制をしいてプロセスやルールも厳密にしたプロジェクトはほとんど何も知らない人を使っても一応動くが、膨大な無駄な印刷物が発生したり、常識では考えられないミスが見過ごされることがある。(私の実体験B)

私の実体験AとBを比べると、Aの方がマシだった。Aではプロジェクト内に論争が絶えなかったが常に皆が何かを考え改善しようという動きがあった。

Bではニュースになるほどの大規模障害を発生させたことがありその反省から非常事態宣言が発令され、より一層堅固な管理体制がしかれていた。

具体的にはレビューの回数を増やす、作業実施時に確認者に加えてさらにそれを確認する確認者を付けるなど。

私が参画したのはその障害発生後だった。私はそのプロジェクトに参画して数か月くらいたって、障害の原因は管理体制の不十分さではなく、むしろ逆に管理しすぎたことではないかと思っていた。

そのプロジェクトでは私を含め、とにかく楽をしよう、失敗をさけよう、という気持ちが蔓延していて、より良いものを作ろうなどという意識は誰も持てなくなっていた。


暴露話の件に戻る。

もうひとつ、決定的な齟齬を生んでいたと思われるのは、B氏は機能単位で報酬を決めていたのに対し、A君は最初から最後まで時間単位で考えていたと思われるところである。

「(1か月)100時間しか参加できないと伝えていたのにフルタイムということになっていた」
というところにそれが見える。

B氏が受注したのはおそらく人日に基づいて見積もられた金額とスケジュールに対し、機能に基づいて見積もられた金額とスケジュールであったからだろう。
そういうことをツイートしていた。

B氏は必要な機能を完成させさえすれば1時間でも50万払うし、できるまではどれだけかかろうと完成させろということだったのだろう。

契約的にはどれだけかけても完成させるというのは無理だろうから、報酬を出さないとか
減額するとかいうことになるのだろうが、その辺がどうだったのかはわからない。

B氏のとにかく機能が実装できればやり方は問わないという姿勢をA君は理解できず自分が経験してきたあるいは知っている方法でやることにこだわりすぎ最後までかみ合わなかった。

私はB氏と同年代なのだが、仕事に対する考え方はA君に近い。

B氏のようなやり方の人とはあまり相性がよくない。

「指示されたことだけやるのではなく自主的に動け」というのは若いころからよく言われて、『そんなこといったって...』と不満に思いながらも確かに自分の自主性や積極性のなさは欠点だと感じ続けていた。

スティーブジョブズなんかもかなりの曲者だったらしい。

皆がA君が考えているような仕事のしかたをするようになれば楽に働けるようにはなるかもしれない。

でもきっと、そういう職場からはおもしろいモノは生まれないだろうし、働いていても死ぬほど退屈だろうな.... とも思う。