このブログを検索

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君が考えているような仕事のしかたをするようになれば楽に働けるようにはなるかもしれない。

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