2024-05-15

良くない体制はずっと治らない

組織体制を変えるのは難しいことなんだなと思った。

IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。

SESを脱退し、そこそこ大手IT企業正社員になれた。しかし、そこはこれまでのSES客先常駐していたような企業とは違い、あまり体制的には良くはなかった。

工数管理

工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。

工数管理をしなかったのである

1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。

工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計実装/単体テスト結合テスト総合テスト、などのサブ番号に分割して、工数登録することである

さらセキュリティ教育などは個々の案件無関係なことが多いので、維持管理用の工数番号が振られていることもある。

リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。

さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業たかを15分単位などで記載する。

工数管理のいいところは、作業サボりにくくなることだ。作業効率客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。

工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベル工数を消費する。あとトイレなどにつける工数などもない。

当社の工数管理

工数管理はないと言ったが、実はある。

しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。

その形式上すら煩わしいらしく、若手の意見バリバリ言う人から

工数管理は全く意味がない。適当工数入力していても誰もチェックしていないのか、何も言ってこない。

工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システム不要である工数管理システムと勤怠システムを一本化すべきだ。

などの意見が出ていた。

月末にテキトー工数入力することすら煩わしいらしい。

そりゃあ工数管理根付いてない企業工数管理を行えばそうなるでしょう。

工数管理業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。

結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。

まり、当社はよく言えば従業員意見が通りやすい、悪く言えば従業員わがままが通ってしま企業なのだ

従業員意見尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務改善できない。

これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。

工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員わがままが通ってしまうのだ。

(まあ当社の工数管理はテキトーからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的業務改善していたと思うが。)

当社はPDCAを回さな

PDCAはPlan, Do, Check, Action頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。

実行した後は必ず振り返り(Check)を行いなさい。

それらをした上で次の作業を行いなさい(Action)。

という意味である

当社もPDCA概念はあるし、週報という形でそれを実現している。

しかしその概念根付いておらず、週報以外ではPDCA無視している。

まり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。

振り返りも当然実施しない。実行のみがある。Do, Do, Doである

これは作業レベルでそうであるし、案件レベルでもそうだ。案件はたしか最後には振り返りの資料作成する必要がある。しかし、これは単に作成しなきゃいけないか作成してるだけで、綺麗事をまとめた振り返りである

本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去グダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽対策記載される。

当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。

私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの?」と詰められて終わりだ。指摘するなら十分な資料作成と具体的な対応策の準備、そして責任人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。

当社はマニュアルを作らない。

驚いたのが部の方針説明会の時だ。

業務改善必要だ。

個々のチームで業務改善に取り組んでほしい。」

と書かれていた。

本来は、業務改善は個々のチームだけの問題ではないので、上層部マニュアル化してルール化すべきではないのか?

アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか?

それをなぜ、個々のチームに依頼する?

業務改善といえばマニュアル作成設計フォーマット作成だ。

マニュアルがなぜ必要か?

それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである

それすなわち業務改善である

しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。

また、当社には設計書のフォーマットはない。

フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。

当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。

これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者相談やすくもなる。

こういった業務改善本来上層部が率先して枠組みを作るべきだ。しかしやらない。

上層部知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。

まとめ

当社はとにかく従業員の声が大きい。強い。

業務改善などの施策を出しても、従業員が納得しないと続かない。

そういう組織文化なのだと思う。

そういう文化を変えるのは並大抵のことでは出来ない。

環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。

仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。

仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。

追記

2024/05/15 10:48

工数管理の是非について:

実装者は成果物作成する側だからサボりにくいのよね。

工数管理すべきなのは成果物ではなくサービス提供する人なのかもしれない。例えばPMなど。

当社の開発チームは、開発者PM以外にも、君必要なの?何やってる人なの?打ち合わせには参加してるけど、ただの工数食い虫じゃね?みたいな人もいるのです。

あと外注さんにも何の工数管理しないのはやばいと思う。外注さんリモートワークだから案件掛け持ちされてる疑惑も出てたし。

  • 工数管理しなくてもプルリク数とか別の指標があればいいんじゃない?

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん