ノリックのIT生産性向上、ライフハック、プロマネのお仕事備忘録

IT系の仕事の事とか役立つツールとかプロジェクトマネジメントの事とかを記載していきます。

根本的に仕事のやり方を間違えていたのかもしれない

 5月になって定時で帰ることができなくなってきている。1月に今の会社に転職してからそろそろ6ヶ月目に入るというのにこの体たらくである。転職して最初の頃は、自分の仕事が遅いのは、まだこの会社のやり方や取り扱っているパッケージの仕様を把握していないから時間がかかるのであって、時間が解決する問題だろうと思っていた。

 

システムエンジニアのノルマ

 営業をしている人にはノルマがあるというのはよく聞く。今勤めている会社ではシステムエンジニアにもノルマがある。それはEVM(アーンド・バリュー・マネジメント)で言うところのEVを一ヶ月で80人時間、新規開発のプロジェクトで稼がなくてはいけない。かいつまむと1ヶ月で0.5人月分の予定している成果物を作ればよいのだ。そんなの余裕だろうと思われるだろうが、それ以外に既存顧客のサポートをしなければならない。私はまだ既存客が1社しか無いのだが、他の人はひっきりなしにサポート依頼の電話がなっている印象だ。それで仕事を中断しながらやるのだから集中できない。何より、見積工数が異常に少ないのである。某ドイツの有名パッケージメーカーが改元対応で数百万の見積を出してきて、私もそのくらいはするだろうなと思ったら、うちの会社の見積もりは10分の1ぐらいなのである。なんでそんなに激安なのか不思議だ。入社して最初のプロジェクトで見せてもらった見積は、

(私)

この見積の単位は人月ですか?

(上司)

いえw、人時間ですw

 あまりの安さに空いた口が塞がらなかったが平然と説明を続ける上司。過去の経験でも人月の見積もりかなと思ったら人日だったということはあるが、人月と人時を間違えたのは初めてであった。これは大変な会社に入ってしまったかもしれないなと思った。

 ただ入社してしばらくは最初に言ったノルマも免除されているので、そこまで切羽詰まった状況でもなかった。しかし今月から本来のノルマの半分が課されるようになり、夏になると私も80時間分の成果物を作成しなければならないのだ。しかも私から見たら人月単位でしょ?というような見積でである。このままではまずいなと思い始め残業が増えつつある。来月にあるプレゼン大会の私のテーマは「私の生産性革命による残業削減」なのだが、このテーマでプレゼンするは気がひけるくらい残業をしているのである。

 

過去に成功したやり方に縛られていないか?

 システムエンジニアとして20年以上働き、それなりの成果を上げてきたつもりである。トラブルプロジェクトに私が参画して仕事が進むようになり、平常運転に戻して他のメンバーから感謝の言葉をもらったこともある。ただ、よくよく考えたら私の今までの経験は比較的規模が大きいプロジェクトでウォーターフォールでの作業プロセスで成果を上げてきたのである。

 今勤めている会社は中小企業でお客様も中小企業。ITのことを全然わからない社長と話さないといけないし、いま苦戦しているプロジェクトは150人も従業員がいてIT担当の人が一人しかいない、今話題の一人情シスのお客様だ。

 前の会社での成功体験を、今勤めている会社でやってないから同じことをやれば生産性が上がるのではないかと思っていた。テストの自動化、フェーズごとの終了判定、品質分析、形式手法による設計。改善する兆しは見えない。今は一ヶ月かかって40時間分の成果を上げるのがやっとである。しかも入社2年目の若者に

松本さんの設計書は分かりづらいです!

とダメ出しを食らってしまった。そ、そうか、設計にはちょっと自信があったのだが、その自信も打ち砕かれた。

 

自分のこだわりを捨てて他の人の枠にハマってみる

 入社してからこうやったほうが良いのではないか?と思いながらやっていたが、変に改善を試みず、そのまま一回真似をしてみようかと思い始めている。こんなテスト設計ではバリエーションが十分じゃないからもっとケースを増やしてテストをしたほうが良いとか考えていた。でも今日一緒に上司とテストをしたのだが、テスト設計書には簡単な内容が箇条書きされているだけ。それでどんどん動かして行く。それで十分なテストなのかどうかはわからないのだが、長年やっているのだからそれでなんとかしてきたのだろう。

 Google先生に聞けば何か得られるかと思ったが、アジャイル開発手法がヒットするだけで、アジャイル(素早い)開発だからなにか特別な事があるのかと思うが、別に目新しいものは無い。ウォーターフォール開発でも普通にやっているようなことがかいてあった。

 

アジャイルソフトウェア開発宣言

http://agilemanifesto.org/iso/ja/manifesto.html

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

 

 ググっていて心に残った文章が上の文章だ。自分は包括的なドキュメントを書くことに力を入れるタイプなのだが、今日一緒にテストをした上司のやり方は動くソフトウェアを重視するやり方に感じた。また、私の書くプログラム仕様書はロジックについても詳細を記載する。そうするとプログラマが書きたいようにはかけない。入社2年目の若者が私に言ったクレームもドキュメント化しすぎているのかもしれない。

 

 同じような悩みを抱えていそうな人がいそうなものだが、転職のコツとか書いてある記事は見つかるのだが、大企業と中小企業の仕事のギャップの乗り越え方まで書いている記事はなかなか見当たらない。ということはそれを書けば、このブログもバズるだろうか。来年のプレゼンテーション大会のテーマは、中小企業に転職し悪戦苦闘するも、逆転サヨナラ満塁ホームランで脱社畜化した話で優勝出来るようにしたいものだ。

 

 そういえば来月中途採用の人が入るそうだ。やっぱり私だけではまだ足りないと思われたようだね。 

  

 以下の記事で作ったドキュメントが若者から批判があった設計書の作り方です。書き直しかな。。トホホ

www.norick-matsumoto.com