アラフォーサラリーマンの報告

アラフォーサラリーマンの日々の愚痴などを吐き出してます。

Press Enter

Press EnterというWEBの連載物のコラムがあります。

現在、「飛田ショウマの憂鬱」というシリーズが掲載されていますが、それが今の会社を参考にしているのではないかと思うほど似ています。 今週の内容に「協力会社を技術力ではなく、単価で決める」という内容があり、あまりにも同じなので驚きました。

他にも、「人形つかい(5)システムエンジニアとSQL」に出てくる橋本さんは、SQLのJOINが使えないし、プログラムも新人研修でしか経験がない。 これも、今の会社の人と同じですし、「人形つかい(1) 未知との遭遇」や「高慢と偏見(6) いつかの誰かのためのドキュメント」にあるように、ステップ数で管理するもの同じです。 上記のコラムが掲載された時は別会社に勤めており、「こんな会社あるのか?」という感想でしたが、今の会社に転職するとは当時は予想だにしませんでした。

このような読み物があるということは、他のSIerもプログラムは外部に依頼し、社内の人間は協力会社管理と顧客の御用聞きがメインで エクセルの毎日なのかと疑ってしまいます。

技術力を強みにせずに、「外注管理が得意です。」という企業をIT企業と呼ぶべきか疑問です。

今の会社

今の会社に転職して3年が経過しました。 結果としては、完全な失敗です。

自分と合わない点は、以下の通り。

技術に興味が無い

 新卒で入社した会社は、入社3年くらいはプログラムをメインとして、設計は自分達で行い、自社の開発ツールを作成したりして、技術に興味がないというイメージがありませんでした。

 しかし、今の会社は設計から全て協力会社に任せており、よく言われる典型的なSIerです。

 協力会社は金額が安い会社を探すので、基本的に中国系の協力会社が多いです。日本人の協力会社の場合、自社の名刺を作成し、顧客対応等も依頼しています。

 正社員の技術力がおどろくほど低く、SQLも掛けない人が普通にいます。自称・技術力が高いという上級マネージャーが、JavaScriptがサーバーで動作するのか、クライアントで動作するのか分かっていません。もちろん、Node.js などの事を知っているはずがありません。

 2016年の新規プロジェクトでJava6を利用し、Strutsを採用しています。なお、先に上げた上級マネージャーは、StrutsをStructと呼んでいます。

 自社パッケージ開発ですら、設計から協力会社に依頼しています。こちらからの要望が曖昧で、協力会社からスケジュール調整の依頼があった時も、上級マネージャーは声を荒げてました。もはや、一般のエンドユーザーと同じで、IT企業とは思えません。

 転職当初、ER図を作成していのたですが、上級マネージャーに「下流の仕事は、協力会社に任せれば良い」と言われたことがあります。自分たちの仕事の方が価値があると思っているのでしょうけど、やっていることはただの伝言役です。

管理方法が古い

 設計からテストまで、協力会社に任せているため会社として協力会社管理に力を入れています。

 必ず設計書等のレビューを行うのですが、1ページに付き指摘事項何個以上という品質基準があります。しかし、指摘事項は日本語の間違いを指摘する程度です。

 そのため、出来上がった製品は、動けば良いレベルのものばかりが多くなります。たとえば、

  • 同じ画面なのに呼出し元が違うと個別で作成。
  • 保守フェーズでは別協力会社になっている事が多く、修正漏れが発生。
  • 検索と登録を同じ画面で作成し、CSSを駆使して、画面の描写を切り替える。こちらも、保守フェーズで別協力会社の修正に時間が掛かる。
  • 社員マスタを呼び出すのに共通化せず、しかも微妙に条件が違う こちらも、保守フェーズで・・・  

 テストについても、ステップ数に対応して不具合数、重大不具合数が決まっています。

 設計書基準ではなくステップ数基準なので、テスト数をこなし、品質良好となっていても、フル桁入力で桁あふれが発生したりします。

 なお、品質基準の外れると、後に記述する品質報告会で理由を説明する必要があります。

会議が多い

 毎週開催される会議は、部門ミーティング・予算会議、毎月開催される会議としては、品質報告会(部門・本部・事業部)、適時開催が、見積レビュー(部門・本部・事業部)など

 部門ミーティングは他企業でもあると思いますが、ヒラ社員なのに予算会議に毎週出席し、予算未達の場合、今後の対応方法を報告する必要があります。今の会社は、各PM(ヒラ社員)に予算がついていて部長はそのサマリーでしかありません。

 品質報告会も、先に上げたプロジェクトの不具合等の報告書やスケジュール・プロジェクト予算の見通しを報告します。それを部門・本部・事業部とバラバラに行うため、ほぼ毎週報告する形になります。

 見積レビューも同じで部門の承認を得てから、本部・事業部と続きます。たかだか500万の見積であっても本部レベルの承認が必要です。

 新卒で入社した会社だと課長レベルで承認する金額が、部長、さらには事業部長の承認が必要になるため、見積を提出するまで時間を要します。

 なお、見積にはステップ数の算出が必須となっています。プログラムができない人間がどのようにステップ数を算出しているのか不思議です。

 もちろん、単体テストのレビュー時に実績ステップ数を出して、見積との乖離を説明します。何がしたいのか未だに理解できません。

社内政治

 どの会社でもあることかもしれませんが、社内政治が上手い人は、上記の報告会やレビューを行わなくても問題ありません。不具合が起きても、報告しなければ評価は下がりません。

 真面目に不具合を報告した場合、改善策のレポート提出と品質管理委員会への報告など余計な仕事が増え、評価が下がります。

 今まで在籍したどの企業よりも社内政治の力が重要と感じます。

エクセル管理が大好き

 WBS単体テスト不具合票、単体テスト不具合一覧、結合テスト不具合票、結合テスト不具合一覧、課題管理表、リスク管理票、プロジェクト総括管理票、プロジェクト見積時見込み表、プロジェクト予実管理票など、全て会社標準のマクロ付きエクセルです。

 プロジェクト予実くらいWEBで管理すればいいと思うのですが、エクセルです。WEB化する計画があったらしいのですが、協力会社が出した見積と金額がアンマッチだったようです。自社システムでさえ、協力会社頼みです。

まとめ

 新卒時は、5000人規模のSIerに入社に、その後、コンサル業界に辿り着きました。

 コンサルからの転職理由としては、業務内容に飽きてしまったためです。大手SIerは、管理だけで開発をしない方向にシフトしていると聞いていたので、社員数も数百人規模のSIerに転職したのですが、驚くほど開発をしません。というか、開発をする気がありません。

 転職先の企業では、これまでの企業と比較してはいけないと分かっているのですが、プログラムは誰にでもできる仕事と考える風土や品質を担保するための考えが私とは真逆にあります。私としては、品質は管理やテストで担保するものではなく、設計・開発で決まると考えています。

 もし、他のSIerも今の会社と同じなのであれば、私はSIerに向いていないのでしょうね。

IT企業だと思っていたのですが、もはや派遣社員紹介管理会社です。