2019年から適用され始めている働き方改革。
サラリーマンであればほぼすべての人が耳にしたことがあるワードでしょう。
でも実際はどうでしょう？なんか変わってますか？
多分、働き方改革の前後ではさほど大きな変化はない・・というのが現状ではないでしょうか。
今回は、働き方改革ってどうやったら実現できるの？
という質問に対して、私なりの見解を出していきます。
そもそも働き方改革は何を実現する？
働き方改革の目的は、
働く方の置かれた個々の事情に応じ、多様な働き方を選択できる社会を実現し、働く方一人ひとりがより良い将来の展望を持てるようにすること。
と厚生労働省が述べています。
具体的には、
・長時間労働の是正
・柔軟な働き方がしやすい環境整備
などなど
詳細は以下の記事で詳しく説明しています。
実際に実現しようとすると、ぶっちゃけかなり難しいことです。
だって、長時間労働なんて昔から問題視されていたわけで、簡単に解決できるのであれば今更取り組みませんよ。
実際にあなたの職場では解決されていますか？
多分解決されていない、よくある働き方改革の勘違い例
よし！働き方改革だ！
みんな早く帰ろう！リモートワークをする日を作ろう！
と言って、取り組みとしては、
・時差出勤を行う
・定時退社日をつくる
・テレワーク（リモートワーク）デイをつくる
の３つが代表的なよくある内容だと思います。
これで働き方改革を実現だぁぁぁぁぁ！
・・・って、本当に実現していますか？
確かに仕事にメリハリがついて、幾分効率は良くなるでしょう。
これらの取り組み自体を否定するつもりはありませんし、継続するべきだとも思います。
けれども、現実は以下なのでは？
・時差出勤したけど、結局その分帰宅する時間が遅くなっただけ
・定時退社日にちゃんと定時で帰るけど、結局他の日の残業時間が増しただけ
・リモートワークをしようと思ったけど、打ち合わせが多く結局会社に行った
うーん、残念ですね。
そこで必須になるのが業務プロセス改善。
業務プロセス改善とは？
業務プロセス改善と言っても、規模は様々です。
企業レベルでのシステム開発
大きな話からすると、大手企業などではよくシステム開発をIT企業に発注してます。
既存の業務をシステム化して、業務を効率化することが大きな目的です。
これがおそらく、最も大きな業務プロセス改善のカテゴリだと思います。
プロジェクトの全体ルール系
世の中には様々なプロジェクトが存在するわけですが、必ずみんなが従う作業ルールがいくつか規定されているはずです。
この作業は○○さんがやって、その確認は✗✗さんがやって・・など。
働き方改革で最も重要なのはここのプロセスなんですよね。
ここのプロセスがイケていないと、チームの中で無駄な作業が発生したり、メンバーの待ち時間が発生したり、進めるべき仕事が思うように進まなかったり。
その結果、仕事が急に忙しくなったりして残業だらけに・・という状況が生み出されてしまいます。
ではどのように対策をうっていけば良いのか、具体的に見ていきましょう。
例えばシステム開発のプロジェクトでは、設計⇨プログラミング⇨試験
という順番で行っていきます。
その中の”試験”では、プログラミングにバグがないかどうかをテストするのですが、バグが出たときに誰が何をして誰が何を判断するのか、というのがルール化されているのが大半です。
試験をする人（Aさんら複数）は、バグを発見したときに、バグの内容報告書を書く。それをチームリーダ（Bさん）に報告。
チームリーダー（Bさん）はバグの内容を見て、修正方法を決定する。それをAさんに指示する。
Aさんは修正し、もう一度テストを実施し、バグの完了報告を書いてBさんに報告。
というプロセスが定義されていたとしましょう。
ステップ１ 問題点を明確にする
よくある光景ですが、このプロセスの中にメンバーを忙しくさせてしまう要因が隠れていることって、結構あるんです。
でも、それって絶対解はなくてプロジェクトの状況やメンバの能力などによって問題点は様々。
今回のケースですと、
・そのままのプロセスでうまくいくこともある
・試験をする人の作業が思っていたよりも遅く、時間がかかっている
・チームリーダーの判断が遅く、時間がかかっている
などが起こりうる事象として考えられます。
業務プロセス改善の大切なことは、そのプロセスで仕事を進めていくにあたって、「なにか問題はないのか？」を明確にすることです。
これが結構難しいんですね。
みなさん、仕事をするときには一生懸命になって、なんとか終わらせないと・・とのめり込み気味になってしまうのですが、実は問題点を議論して改善策を撮っていくほうが結果として早く仕事が終わるなんていうことがよくあります。
ステップ２ 原因を特定する
さて、今回は仮定で「チームリーダーの判断が遅く、時間がかかっている」ことが問題だったとしましょう。
問題点を出したあとは、原因の特定です。
なぜ、「チームリーダー（Bさん）の判断が遅く、時間がかかっている」のかを特定するということです。
今回のケースですと、Bさんがバグを修正する方法を検討・決定しているという状況でして、原因を特定するためにBさんの状況をヒアリングすると、
・Bさんは他の業務もあり多忙状態になっている
・そもそもBさんはバグの修正検討が得意ではなくパフォーマンスが悪い
という問題点に対する原因がわかりました。
ステップ３ 改善方法を決定する
まず、Bさんはすでにタスク超過の状態であり、バグの修正検討が不得意ということでそのタスクから外すことになります。
でもそのタスクは誰かがやる必要があります。
試験をする人（Aさんら複数）が、修正検討する能力がある人たちであれば、彼らに検討を任せ、決定事項だけをチームリーダに伝えるというプロセスにするのもアリ。
一方、修正検討する人が別に必要になる場合、試験をする人とチームリーダの間に人を入れるのもありで、報告ルートを試験をする人（Aさんら複数）⇨バグ修正検討者（Cさん）⇨チームリーダー（Bさん）というプロセスにする。
どちらの回答もOKで、その時のメンバやタスク状況次第で改善方法を決定していくことになります。
・・・ということが業務プロセス改善なのです。
書いていることは一見簡単そうに見えますが、実際やろうとすると結構大変。
なぜなら上記を考えるにあたっては結構時間を必要とします。でもみなさん、基本的に忙しいはず。
また、個人的には業務プロセス改善を主導することができる人は相当限られていると思い、サラリーマンの1割もいないと思います。
ルーティンワークのツール化
これも代表的な業務プロセス改善で、分かりやすいですよね。
日々行っている業務の中で、同じような作業があればその自動化を検討する、ということです。
例えばエクセルに毎日決まったファイルからデータを転記し、決まったルールに則り計算を行い、決まったデータフォーマットに出力する、というようなのが一般的。
ですので、「それって決まった作業だから自動化しようよ」と判断できる人がいることが大切。
IT企業で働いている人からすると当然のような話ですが、IT企業ではない企業では決まった作業を日々繰り返し実施している人って結構な数います。
個々人レベルの稼働時間の削減なので、一つ一つのインパクトは大きくはないものの、チリツモなので日々意識することは重要です。
非IT企業などでは、IT人材を一人会社に投入するだけで結構な効果生まれるんじゃないの・・？と思います。
最近はフリーランスの人材に簡単に仕事を依頼できますし。
真の意味で実行できるのは一握りしかいない
業務プロセス改善で、みなさんの労働時間の改善に最も効果があるのは、プロジェクトの全体ルール系のプロセス改善です。
でも、これって実は実行できる人が限られているんですよ。
理由としては、
・そもそもこのレベルの業務プロセス改善はレベルが高い
・指示命令系統（リーダー）を担う人でないと実行が難しい
からです。
というように考えると、働き方改革って言ってますが、それを実現できるかどうかは一部の人間に委ねられているということです。
多分、頑張って働き方改革しようと思っている人もいると思うのですが、真の意味で実現するのはハードルが高すぎます。
実現したいのであれば、まずは今の仕事のポジションでリーダーのポジションに就きつつ、今の仕事の問題点と解決策を立案するタスクを自分に課すのがベスト。
もしくは、リーダーが優秀であれば、今の仕事の問題点と解決策を提案してみるのも全然アリ。
むしろそういった人材はリーダーからすれば重宝したいですし、チームとしてのパワーが強くなるので理想形ですね。
ただリーダーがポンコツだと、せっかく良い提案をしたのに実行に移されないとか萎えまくりな状況になるので止めたほうが良いです笑
働き方改革を実現するためには
・今の仕事のポジションでリーダーのポジションに就きつつ、プロジェクトの全体ルール系の業務プロセス改善を実行しよう
・リーダーが優秀であれば、プロジェクトの全体ルール系の業務プロセス改善を提案しよう
ですね。
この記事へのコメントはありません。