書きなぐり、仕事の愚痴、ITの仕事ってさ
ちょっとお仕事の愚痴を体裁を整えずに書きなぐる。他に吐き出すところがないので、駄文です。まあ、プログラマやシステムエンジニアっていろんなスキルレベルの人がいるんだって話です。
最初にぶっちゃけておくと、現職は違いますが、元プログラマでシステムエンジニアなんて仕事をしてました。今は現役ではないですが、まあ、適当に仕事して食えてるのでそれなりに幸せです。
ぼかしつつ話すことになるので、フェイクを多分にいれていきます。愚痴の部分だけ本当の話です。
システム屋さんから離れて数年たつのですが、ちょっとしたシステム屋さんの仕事の依頼を受けることになりそう。単純に今の仕事関係の小さなシステム会社さんの納期が延びるので、ちょっと見てきてくれという話になった。別に元システム屋さんであることはかくしてないし、暇つぶしにはいいかなということで、話を聞いて思ったことが愚痴です。
納期短縮と工数短縮をかなり迫られる状態でのプロジェクトだったようで、いくつかの提案をしていたよう、その資料を見て気になったことから
・工数圧縮のために設計書は簡易設計書
・工数の取り方が設計、製造、試験が１：１：１
この話はかなり前に知っていたので、あーこれはこけるなと思っていた。
システムの設計とはなにか？システムの設計は下流工程を円滑に進めるために絶対に手を抜いてはいけないもの、簡易設計書？私の辞書にそんなものは存在しない。必要最低限の設計書ならわかるけど、簡易とは終わっている。一人で作って保守までやるならこの言い方はわかるが、簡易とか言ってる時点で設計の大事さをまったくわかっていない疑惑があった。
工数の比率、私の思う開発の工数のバランスは、設計：製造：試験 ４：２：４、これが最低ライン５：１：４ぐらいの感覚でやるべきだと思っている。これはお金をもらってシステムを納品するなら当然のバランスだと思っている。しかも要件定義の打ち合わせまでするなら ６１３ぐらいでもいいと思う。製造は下流工程だ、もちろん技術検証など必要な場合は比率はあがるかもしれないが、工数の取りかたとしては別に書く必要がある。それでも、設計と試験を製造が超えているようではだめだ。いいものはできない。
もちろん理想ではあるが、よいものを作るという観点に立った場合、コーディングの重みは正直ゼロでいい。８割はだれでもできる２割はできる人に頼めば、この比率は実現できると考えている。
すでにキナ臭かった。おそらく大きなプロジェクトをみたことのないか、個人でやがなかった人かなと感じた。こういう試算をするエンジニアがおそらく泥船をこぎだす。そういう臭いがしていた。
さて、それから数か月、やはり聞こえてきた、間に合わないと、そして、打ち合わせに呼ばれる。ログの出力についての話だった。サーバにすべて集めるという話だったので、エラー発生時サーバにアクセスできないことを考えるとクライアントにもログを置いたほうが良いのではと提案した。なせか工数が増えるので嫌だと言われた。使うのはこちらだイベントログを見て調べる手間を考えると、ログファイルを適時やり取りした方が簡単だ。なぜかそういうミリミリしたことが工数を圧迫するという。
ぶっちゃけ、3行ほどプログラムを追加すればできる話なんだけど、とは言わなかった。
ここで気づいた、まさかと思うがシステム屋さんなのにログ出力のノウハウがないのか？ログ出力の設計をいまからやる気か？経験すらないのか？
システムを作っているといろんなノウハウが蓄積されていく。デバッグ用のエラーログのはき方なんて、経験でどうするのが一番いいかわかってくる。
フラグで、どのレベルまではくか？どこかに集約するか？サーバがいいかローカルがいいかな、そのすみわけなど、ノウハウとして頭にあるだろうし、いくつかの開発環境で個人でモジュールを作成してもっているまであるレベルが普通だと思っている。
一応、相手のエンジニアさんの経験年数は私よりあると聞いてる。それでそんなこともできてないのか？と疑問しか浮かばなかった。いや、呆れた。
さて冒頭に出た簡易設計書というものを見る機会があった、画面設計と各画面の機能が描かれているような、方眼Excelだった。何年ぶりに見たかな、方眼Excel、あほかと、昭和の終わりか平成初期かと、もうね、泥船だった。終わっている。方眼Excelが悪いとはいわないけど、誰向けなのかはっきりしない設計書だった。
要件定義に使う文書というには、エンジニア寄りだが、コーダーがみてもなにもできないという気がした。
ここからは今後の話がだが、画面関係の要件の合意は取れている、データ構成はまだインプットが少し固まっていないらしい。細かい進捗は聞いていないが、見たところ、今決まっている部分が主に画面なので、こちらと共通部分を先に作っていれば、あとはビジネスロジック部分になるが、３人ほどでやるらしいので製造だけならビジネスロジックは２か月もあれば上がりそうに感じだ、GUIが１か月ほど、詳細設計、クラス分けや共通部分の製造をメインのエンジニアが一人でやっても２か月ほどあればある程度形になりそうな量、技術検証は１か月といったところか、となると納品書類もやりつつ工数管理しつつ、残りは１か月ほど試験にかければ作れそうである。試験少ないように思うが、単体試験は製造に入れていると考えてもらえればと思う。
とはいうものの、基本的なクラス分けや共通部品の設計を自分がやれば５日あれば製造工程に流せるかなとちょっと思ってみていた。
先にかいた工数は向こうの出してきた工数に合わせてペース配分した場合、要件が９割入った簡易設計書とやらを見て自分が思った設計工数は１人月、製造検証含めて４人月、試験が２人月ぐらいで、その裏で２人月ぐらいで、ドキュメントそろえながら工程管理すれば３人で納期は４か月あれば行けるかな。まあ他のメンバー次第なところはあるけど、半年後の稼働が間に合わないと焦っていると聞いているが、今作れる部分を先行して走らせれば年内にデータ関係の仕様が決まればいけるだろう。
プログラマの上級職がシステムエンジニアでシステムエンジニアの上級職がプロジェクトマネージャーでプロジェクトマネージャーの上級職が、フリーのコンサルか社内SEなのである。
システムエンジニアどまりで年を取るといいことはなにもない。おそらく今回の相手は、そういう古い小さいプロジェクトで仕事していた人なのかなと感じて、これに話聞いてきてくれって、どういうことをすればいいのかと現在悩んでいるのである。
ちなみに、最初から私が入ってやっていたとしたら、要件９割出てるので、とっとこ設計して、製造に仕事まわしてれば、ビジネスロジック周り以外は８割がたできている時期だと、思うけど、製造工程初めてないとかだったら、ガチギレして帰ってこようと思う。つまり、仕様が固まればあと納期では2ヶ月まできてるぐらいは時間もあったし決めることは決まっている。半年はかからないけどなぁ。
あと、遅れまくってるので、現状は工数よりも信用って段階に入っているので、作れるとこと作って、工数確定していかないとね。ということで、つまり、最初にかいていたことだんだん離れていくけど、結局は、ＩＴエンジニアは変人が多くて、臨機応変にできない人が多い。そこは、いろいろ経験してないとうまくやれない。
プロジェクトマネージャーまでするとわかる、できるシステムエンジニアは結局は営業職なんだと。
今日はかなり適当なことを書いているので、良い子はなにも信じちゃだめだよ。ということで、もしかするとすぐにお手伝いに入る可能性がありかなり憂鬱だなというのと、これ設計から、奪い取ってやった場合、おそらく、またエンジニア仕事に戻りたくなってしまうんだろうなと思うので、あまり手を出したくないという話でした。すでに、簡易設計とやらを見ていて、設計から工程引くまでのシミュレーションはじめてるので、たぶんだめだと思う。
僕は定時で帰る仕事をしたいんだ。