先日、ぶらっとTwitterを眺めていたらこんなつぶやきを見つけました。
システムで絶対にバグを出すな。一件でもバグ出したら料金は払わないみたいなのは、学校のテストで絶対に100点を取らせろ。100点じゃなかったら授業料は返還してもらうと言っているのと同じようなもので無茶苦茶な主張だからやめてほしい。
— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) 2018年1月26日
うん、まあ言いたいことは分かる。なんでも、100%を目指そうとすると、非常にコストが係るので、多少は目をつぶってぇなと言いたくなるのはまれによくある。でも、お仕事としてやっている以上、お客様が100点を要求するのは当然だし、コストの制約があろうとも100点は目指すべきなんだろうと思う。
でもさ、『それで100点を要求するのは無理じゃね？』ってことが、この業界は余りにも多い気がするんだよね。
仕事を試験に例えるのならば、問題を出す側には、最低限この３つを守って欲しい。
1.問題は開始時間までに用意してくれ
試験時間は10:00~10:50。もう10:05になるのに、まだ試験監督がやってこない・・・。試験会場がざわつき始めた中、飛び込んできて『ごっっめーん！なんかプリンターの調子が悪くてさー。遅れちゃって悪かったね！じゃ、そろそろ始めましょっか。えーっと、10分開始にして、終了時刻も11時丁度にするね。じゃ、みんな良いね！？』
良くない。
次の試験が11時から始まるわけだが、トイレ休憩もなしになるの？その辺、次の試験担当と調整するつもり全く無いよね？？っていうか、我々がずっとここでボーッとムダに過ごした件については、何のお詫びもないワケ？
試験で例えるならばこんな感じだけど、こういうことはよくある。作って欲しいシステムの概要なんかの情報が、予定していた期日に間に合わずに待ちぼうけ。納期ずらすから良いじゃん！！と言われましても、既に入っている別の作業は調整頂けます？？あとついでに、手が止まってた期間も発生したエンジニアのコストはどうなります？？
それを『納期が遅れるのはお互い様だもんね』みたいにごまかしちゃうから、生産性が下がり、その分コストが上がる。そういうのはやめにしましょう。
2.問題は開始後に変えないでくれ
やれやれ、やっと始められる。そう思って問題文を読んでいると、試験監督のほうから、素っ頓狂な声が上がる。『あ、やっば！ここの問題差し替えたのが直ってないわ！ちょっとまってね』そう言いながら黒板に、『ここの選択肢の、この部分はこうじゃなくて、こうね！』と書きなぐっていく。『じゃ、みんな良いね！？』
良くない
つーか、その選択肢意味不明だな、と思いながら、もう回答書いちゃったんですけど。あー、やっぱりそうなのかあ・・・という思いはあるけど、おっかしいなあ読み間違えかなあと考え込んでた時間と労力はどうなるの？？
これも試験で例えるとこんな感じになるわけだけど、まあこの程度の修正ならまだマシな方だよね。現実にあるのは、試験終了5分前に、『問い12はなくなりました！新たに問い13を出します！』みたいな、試験問題として考えたら全く理解に苦しむことが良く起きるのがこの業界。
開始時間が間に合うのが大事なんでしょ？とにかく出来上がった部分から、ちゃちゃっと始めてよ！みたいに言われることもあるけども、それぞれが疎に独立しているのであれば良いけど、システムとして一連の一体化した何かである以上、早めに完全系を出してもらわないと困る。
それで『まあこんな進め方だしバグが出るのも仕方ないよね』みたいに誤魔化せるのが有り難い人もいるかもしれないけども、そういうのはやめにしましょう。
3.問題の採点は本文から分かる範囲でしてくれ
しかし酷い試験だった。完全に記憶から消し去りたい。と、思っていた頃に、酷い採点結果が帰って来た。ここはどう考えてもAだと思うのだが、何故か不正解になっている。『いやさー、確かに普通に考えたらAなんだよね。でもさ、問題文の中に入れそこねちゃったんだけど、本文の後ろの方にある指摘も考慮するとBなんだよねー。そういったことも踏まえると、やっぱ不正解って言わざるを得ないの。良いね！？』
良くない
確かに回答書いてて、条件が足りてねーんじゃねーの？と思ったことはあった。余りにも問題としてズレてりゃ、試験中であっても『おかしくね』と指摘することはある。でもまあそれでも一応回答できるのならば、普通そのままするじゃん。
まあ試験で例えるとで、流石にそんなひどいことは無いでしょって感じになるんだけども、割りと良くある。『確かに設計書には、そこの出力結果は整数でって書いたんですけどもぉ、後続のシステムがゼロ埋めなんですぅ。なのでここのテスト結果はNGですねぇ~』みたいな。
『それぐらいならやってくれますよね！？』。うん、納期と費用を調整してくれるならね。
これも『お互い疲れちゃうから、まずは曖昧な感じでGOしちゃおうっか』で上手く行くときもあるけど、何が正しいのかの答えを、採点前まで放置するのはやめにしましょう。
お互いプロでしょ？
システム開発の品質は、技術者のレベルと発注者のレベルの掛け算で決まります。仕事として請け負っている以上、スケジュールや仕様のハンドリングについて、仕切りはシステム屋がすべきだ。
しかし、書かれたシナリオがうまくいくのは、役者がきちんと歌って踊ってくれることが前提で、技術者だけじゃなく発注者も舞台に立たなきゃいけない。
『いやあ・・・その件は、まだ社内調整が出来てなくて』『すみません、別のケースでの業務の検討が不十分でした』『実は、そこの金額の正しい計算式は社内でも知っているひとが居ないんですよね』
みたいなのは全部NG。プロにちゃんと仕事をしてもらいたいなら、お客さん自身も社内の業務に関してはプロである必要がある。
我々だって、仕事としてやる以上、出来るならば100点は目指したい。ならば、お客さんが上手くいっていないときは、目の前の担当に嫌われたとしても、お尻は叩かなきゃいけないときもある。
お互いに『ぼくたち素人なんで！』と傷を舐め合うような仕事の仕方は、気が楽だけど、それじゃあ生産性は上がらないよね。
そこんとこ、肝に銘じながら、お仕事がんばりたいと思います。
