転職するにあたり、SIerでどんな仕事をしてきたのかを語る必要があります。
SIerのプロジェクトマネージャーが語るIT論は抽象的かつ感情論的な部分が多く、フワフワとしているのですが、そういう部分も含めてSIerなので、しっかりと理解して置かなければいけません。
今回読んだ『失敗しないITマネジャーが語る プロフェッショナルPMの神髄』は某SIerのプロジェクトマネージャーの中では聖書のように扱われている本です。著者も「失敗しないマネージャー」を自称しています。
本書を読めば、SIerでの業務がどのように進められているのかがなんとなく見えてくるかもしれません。
そして読む人によっては
「君からはコードの匂いがしない」
とディスりたくなってしまうかもしれません。
とにかく『失敗しないITマネジャーが語る プロフェッショナルPMの神髄』からはコードの匂いがしません。
エンジニアリングの要素は一つもありません。
「プロジェクトマネジメント」を科学的に捉えるわけでもなく、精神論が多めです。
この本を読んで「プロジェクトマネジメントがうまくできるようになる人がいるのか」と聞かれると、「NO」というしかないでしょう。
とにかく、著者が顧客に誠実に、たくさん残業しながら、一生懸命仕事をしてきたことだけはよくわかります。
SIerでPM志向の人が、仕事のモチベーションを上げるための本です。
人が働く動機
13章に「働く動機というのは、割と単純」という節があります。
メンバーが働く動機には、3つの「好き」があります、と著者は言います。
- やっている仕事が好き。やりがいを感じて仕事をしている状態です
- 顧客が好き。メンバーは大好きな顧客のために一生懸命に仕事をします
- PM、または一緒に働く仲間が好き。あなたのためだったら一生懸命に頑張る
この節を読んだ時、私は唖然としました。
「こいつ、何もわかってない」
と。
SIerの社員が働く動機は99%、「金」です。
給料のために働いています。それ以外ないです。
給料が増えて、雇用が安定しているからSIerで働いているのです。
成長したかったり、スキルを身につけたいと本気で思っているなら、SIerに5年以上いる意味はありません。
SIerで働いても別に成長もしないし、スキルも身につかないからです。
たまにSIerの激務をこなして「成長してる」と誇らしげにする人もいますが、そういう人は成長が何なのかを真剣に考えたことがない人です。
それは成長でも何でもなく、単なる慣れです。
できなかったことが早くできるようになるのはたしかに成長ですが、「プロフェッショナルの成長」は市場価値を結びついていなければいけません。
あなたが一生懸命残業してやった仕事は、職務経歴書で輝く仕事ですか？
夜なべして一生懸命資料を作りました。それって何か利益になってるんですか？
業務経歴に書けますか？
話がそれましたが、著者が精神論で仕事を語る割に、人間の精神性を全く理解できていないことの少なからず驚きを覚えました。
お前が好きでみんな死ぬほど残業してたと思っているのかよ…発注側と受注側の事情がなければ働かねえだろ…
お前がプレッシャーかけてたんだろうよ…
というのは著者と働いたことがなくても容易に想像できることなのですが、「部下やパートナー企業の人が身を粉にして働いてくれるのは俺のことが好きだからだ」と勘違いできることもPMの重要な素養なのかもしれません。
アジャイル開発の本質はオブジェクト指向にあると思います
4章でアジャイル開発について語る節があります。
そこではこんなことが書かれていました。
アジャイル開発の本質は、オブジェクト指向にあると思います。
オブジェクト指向の最大の特徴は、構成される各オブジェクトが独立していることです。
オブジェクト指向は「データと手続きを一体化して取り扱う」という考え方で、これは極めて自然です。
しかし、継承するにはオブジェクトの階層化が何層にもなるため、これまで現実のシステムで動作させるにはハードウェアの面で限界があったのだと思います。
ただ、著しいハードウェアの進歩と非機能要件を超越するクラウドの進展により、IT業界は大きく変化しようとしています。
人工知能もそうですが、20年以上前には夢物語にすぎず、机上の空論でしかなかった技術の適用がいよいよ始まったと思います。
はて、この本が書かれたのは1990年代だったかな？と出版年を見てみたら、なんと2016年でした。
2016年に「アジャイルの本質はオブジェクト指向にあります（キリッ）」などと書かれているのです。
SIerで神のように扱われているプロジェクトマネージャーの御神託が
「アジャイルの本質はオブジェクト指向です」
なのです。
アジャイルの本質が何か、と問われると答えるのは難しいでしょう
有名なアジャイルソフトウェア開発宣言では以下のように書かれています。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
「変化への適応」がアジャイルの本質的な価値だと私は考えます。
上流の計画を変更できないウォーターフォールへのアンチテーゼにもなっているように思います。
何がアジャイルの本質かは議論が分かれると思いますが、少なくとも「オブジェクト指向」ではありません。
おそらく著者はオブジェクト指向が何なのかもわかってないし、オブジェクト指向でコードを書いたこともないのだと思います。
『失敗しないITマネジャーが語る プロフェッショナルPMの神髄』で語るプロジェクトもおそらくCOBOLのプロジェクトをベースに書かれています。
オブジェクトを組み合わせてプログラムを組んでいくのはごく自然な作業で、特別なことでも何でもありません。
しかしコードを全く書かない人からすると、オブジェクト指向が魔法か銀の弾丸のように見えるのかもしれません。
今後はオブジェクト指向が広まっていく？
4章で
「今後、間違いなくオブジェクト指向開発は広まっていくと思いますので、要件定義・設計方式を見直す必要があります」
と書かれていました。
この文章が書かれたのは2016年です。
1983年にSmallTalkが世の中に出て30年。
1993年にRubyが世の中に出て20年。
「今後はオブジェクト指向が広まっていく」
などと書かれると、この人はいつの時代から来たのだろうか？と、まっとうなエンジニアだったら疑問を抱くはずです。
著者のソフトウェア開発が1990年代で止まっていることがよくわかる一節でした。
ちなみに著書では
「メンテナンスを考えるとドキュメントの標準化は必須です」
と書かれています。
アジャイルではよくドキュメントがやり玉に挙げられますよね。
アジャイル開発ではドキュメントを作らないわけではないのですが、よくわかってないSIerのプロマネは
「アジャイルはドキュメントを書かないから駄目だ」
と断罪していたりします。
そういう人がマネジメントするプロジェクトのドキュメントに限って、無残に陳腐化していたりするものです。
ソフトウェアとソースコードは切り離せません。
ソースコードこそが、ソフトウェアの本質です。
ソースコードこそが、ソフトウェアを最も雄弁に語るドキュメントなのです。
SIerのマネージャーはソースコードが嫌いすぎて、読めなすぎて、とにかくドキュメントを集めようとします。
動いているのはソースコードなのに、ドキュメントこそが品質を担保するものだと思いこんでいます。
ドキュメントを「レビュー」してその「指摘件数」によって品質を評価するものだと言っています。
違いますよ。
ソフトウェアの品質はソースコードによって担保されるものです。
品質を担保したいのであれば、設計書レビューの「指摘件数」を見るのではなく、ソースコードを読みなさい。
テストコードを書きなさい。テストを回しなさい。テストコードで品質を担保しなさい。
そもそも「指摘件数」なんて曖昧な基準でソフトウェアの品質をどう担保するというのでしょうか。
著者は「レビュー時間」や「指摘件数」で品質を保証しているそうですが、レビュー時間なんて時間を投入すればいくらでも増えるし、指摘が妥当かどうかなんてわかりません。
何の責任もなく、プロジェクトの事情を知らない人間が、自分が一切動くことなく、レビュー会議に参加して、好き放題言っているわけです。
その人の「指摘件数」が品質につながるなんて、中学生でも「おかしい」と気付くのではないでしょうか。
そんなおかしなことを真面目に語っているのが『失敗しないITマネジャーが語る プロフェッショナルPMの神髄』なのです。
プロジェクト計画書の書き方
この本ではプロジェクト計画書の構成なども余さず紹介されているので、SIerでプロジェクトマネージャーをやりたい人には本当に役に立つと思う。
目次レベルで雛形を作ってくれているので、これをコピペすれば君もSIerで大規模PMになれる！
これまで散々SIerをディスりまくってきたけど、郷に入りては郷に従えであって、SIerで生きていくならこの本はマジで役に立つ。
SIerの外から見て「ばーか」と石を投げたく気持ちはもちろんあるのだが、中の人はいたって真面目にやっているのだ。
頑張ってダラダラとたくさんの資料を作って人生を無駄にしてほしい。
頑張れ！
ITプロジェクトの三種の神器
ITプロジェクトには三種の神器があるらしいです。
- サブシステム構成図
- スケジュール
- 体制図
この3つがプロジェクトを成功させるための神器です。
ステップ数（笑）
「1つのサブシステムが40万ステップから50万ステップだと大き過ぎで、メンテナンスを考えると20万ステップが目安になると思います」
などと書かれていて、
「おお…ステップ数だ…！」
と感動したました。
本書ではいたるところに「ステップ数」という単語が登場します。
SIerがいかにステップ数を大切にしているかがよくわかります。
【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明
まとめ
プロジェクトとは「独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」なので、再現性がないのは仕方がないのですが、それを差し引いても、あまりにも精神論に寄りすぎていて、読者のプロジェクトで活かせる部分は少ないように思います。
『失敗しないITマネジャーが語る プロフェッショナルPMの神髄』を読んだプロジェクトマネージャーが失敗せずにプロジェクトを回せるかというと、「厳しいんじゃないすかね」と言わざるを得ません。
実プロジェクトで活かせる部分は少ないように見えます。
一方でプロマネとして顧客を大切にする姿勢であったりだとか、プロジェクトに向き合う心構えだとか、モチベーションの部分では大いに刺激を受けるものでもあるので、「プロジェクトマネージャーがんばりたいなぁ」と思っている人にはおすすめの本です。
