私はコーポレートエンジニアとして業務フローの見直しや改善、自動化やツール導入支援または開発などを行っているのですが、問題点と解決策としてやってきたことも本サイトに綴っていこうと思います。
解決策……？対応策かもしれない。いや、もしかしたら苦肉の策かも……。
この記事はポエムを書く場合もあるだろうし、個人的な愚痴も含まれています。
また、認識を改めたら少しずつ追記して磨いていきます。
なお、設計や開発の手法とかそういう話ではなく、働き方とかに近い部分が中心です。
だから十中八九共感できなかったり、「それは違うだろ」と思う点があるかと思います。
それは当然だと思うので、「自分はこうすべきだと思う」と考えるきっかけになれば幸いと考え書いています。
では本題です。
今回は「導入or作成したツールが使われない問題」について。
問題点
キャッチアップするリソースがない
まずこれ。新しいツールのキャッチアップをするリソースがない場合。
業務改善を依頼してくる部署は工数削減したいところが多いわけで、それは今の業務量が許容量を超えそうまたは超えているからだったりします。
そうなると、当然新しいツールのキャッチアップにリソースなんて割けないこともある。
これはもうツール云々以前に組織体制の問題だったりします。
改善するにも当然工数やリソースは必要なわけで、現場に一切の負担なく改善を実現することはほぼ不可能です。
惰性
これもかなり多い問題です。リソースがひっぱくしてつらい思いをしているはずなのに、「これまで何とかなったから」という意識が無意識であれ働きやすいのが人間というもの。
正直新しいことは面倒臭いってことですよね。常に学習が必要なエンジニアという立場からしたら希薄な価値観かもしれませんが、自然な感覚ではあると思います。
メリットが感じられない
自分にとってメリットがないものを使うというのはかなり無理があるもの。
負担だけが増えるのであれば、誰も協力しようとは思えません。
ちゃんと現場にメリットがあるツールであってもこの問題は起こり得ます。
ポイントは「メリットがない」ではなく「メリットが感じられない」です。
つまり伝わっていない、わかっていない。です。
自分が関わることだと分かってない（話を聞いてない）
これも結構いる。部署全員を含めたミーティングと開くと基本中心人物以外は聞いてないです。
私も同じ立場だったら70%聞いてないです。そんなもん。
自分の仕事が奪われると思っている
昨今AIの台頭もあって、こういう意識を持っている人が結構いるように感じられます。
- 自分の仕事に自信がない
- ITに対する過信(?)
- 保身
的な心理が働いているように（個人的な所感としては）感じられるのですが、変化自体を強く嫌う人がいるケースも多いです。
エモくない
意外と多い問題点。
なんか仕事にエモさを持ち込む人が結構います。
よく聞くのは業務に対して「人の温かみを感じられない」とかですね。
自分の仕事に情熱を傾けるのは尊敬できるんだけど、業務そのものに対してもこういう意味不明なことを言う方もいます。
問題解決できていない
一番気をつけなくちゃいけないことであり、一番はまってはいけない点でもあります。
開発者観点では論理的に解決できていると思っていても、実は現場の抱えている問題の解決になっていないことはよくあります。
一生悩む点なんですよね。これが頻発するほど開発者と現場の溝は深まっていきます。誰も幸せになれん。
解決策
とにかくヒアリング
コーポレートエンジニアの仕事はほとんどこれで決まると思います。
相手はエンジニアリングの素人であるという前提で聞くのが良いでしょう。
自信の業務の根っこの問題点を言葉にできていないことも往々にしてあります。
相手の言うことを鵜呑みにせず、かといって軽視せずしっかり聞くしかない。
そして聞いたことしっかりと図や表、資料に起こしてあげる。
そのうえで自分がきちんと設計して、どういう問題をどう解決してどんなメリットを生み出すかを明確にする。とても難しい。
結構重要になるのが、仕事の起点と依頼部署の業務が完了したその後です。
バックオフィス業務は部署間でよく連携しているので、トリガーになるデータや処理後のデータがどうなるかまで把握しないと、全体最適化にはつながらずいつか限界を迎えます。
ヒアリングはこの仕事をしていて一番大切で苦痛な部分だと思っています。
リソースや組織体制はちゃんと相談する
当然の話ですが、その組織のマネジメント担当に「この組織改善するリソースすらなさそうだよ」と共有・相談します。
もちろんそんな部署は内部からもアラートはたくさん出ているとは思いますが、外部のチームや組織から言われると少し意味が変わってきます。
伝え方はもちろん大切ですが、こういう基礎的なコミュニケーションをおろそかにしたら自分の成果物も相応の扱いを受けるんですよね。
あとこういう話をちゃんとしておくと、現場と仲良くなりやすいです。
「改善するんだからやれよ」みたいなスタンスのエンジニアは秒で嫌われます。
こういう面倒なコミュニケーションをちゃんと取っているかで仕事のやりやすさはかなり変わります。
現場のメリット・ベネフィットをできる限り明確にする
業務改善においては、どうやって問題を解決するか以上に、それがなぜ現場の業務改善につながるか、それによってどのような恩恵が得られるかが重要です。
もちろん解決手法やその過程は開発者内で重要になるものなので蔑ろにはできませんが。
「この問題を解決するためにこのツールを導入します」だと全然足りなくて、
「このツールをこうやって使えばこの仕事がN秒、ワンクリックで完了します」ぐらいには落とし込まないといけません。
さらには、「浮いた時間でこういう業務に専念できますね」とか、「この処理が行われている間に同時進行でこういうことができます」とか、「自動でやってくれるので、この日この時間に絶対出勤しなきゃいけないといった縛りから開放されるます」のような、その先のベネフィットまでイメージして話せると理想。
現場の業務に影響があることを明言し、業務フローまで考える
自分の仕事に影響があるとわかってやっと人はその問題について頭を使います。
それまでは他人事なのが当然です。
なので、早い段階でひとりひとりに影響があることを名言し、可能であれば業務改善後の業務フローをざっくりとでも作成することが大切です。
しかも業務フローも作るだけでは絶対に見てもらえません。読み合わせしましょう。
さらに、「どの部署・チーム、誰がやるか」と言った点まで明記します。それで名指しされて初めて人は動きます。
私ならそこまでされないと絶対に動かない自信があります。そういうものです。
強制力・権力
どうしても聞く耳を持ってくれない方はいます。
人間関係的に好かれていないとか、やりたくないから足を引っ張るとか。
仕事に私情を挟む人は少なくありません。
相手が動かない理由を聞いて、それが理に叶っていないのであればどうしようもありません。
そうなったらもう上からの強制力に頼るしかありません。
マネージャー、役員、場合によっては経営者にまで相談して、多くの人を巻き込みましょう。
納得してもらえる言葉を用意しておく
話せばわかる人は沢山います。
まずは論理的にしっかり話して、価値が伝わればそれで十分協力的になってくれる方が大半だと思います。
多少エモい言葉が必要な相手であれば、
「これはあなたの仕事を奪うものではなく、過剰な労働を抑えるための施策です」
「業務改善を通して、あなたが最も価値を生み出せる仕事に専念してください」
「あなたの業務アシスタントとしてAIがあります。要は何言っても許される部下です。」
（どんなシチュエーションでの言葉かはご想像にお任せします）
みたいな言葉をストックしておきましょう。
エモいと揶揄するのは簡単ですが、相手の感情に寄り添ってスムーズに仕事が進むのであればそれに越したことはありません。
スルー
最後はスルースキルをフルに活かしましょう。
相手の言葉を「草」で片付けないといけないシチュエーションは必ずあります。
最後はこれ。必須スキル。
意識したいチェックポイント
ここまでマインドやメンタリティに近い話ばかりだったので、ここからは少しだけ真面目に業務上意識していることを書きます。
私が業務をするうえで意識しているチェックリストを挙げてみました。
軽微な改善であれば場当たり的に進められるのですが、重たい案件になるほどこれらがクリアできていないと失敗しやすくなると考えています。
- 現場の体制・オペレーションは図や資料で明確に定義されているか
- 改善対象の業務の前後にある業務まで明確になっているか
- 自分は現場の業務を必要十分に理解できているか
- システムの導入・開発前にオペレーションで解決できないか
- 現場は改善のインパクトを受容できるか
- 問題点と認識している箇所は本当に根本的なボトルネックなのか
- 改善したら何がどう良くなるか説明できるか
- 改善することでどのようなメリットがあるか
- コスト感の認識共有ができているか
- 開発・導入の納期の認識共有ができているか
- 現場担当者はシステムの導入・開発を適切に認識しているか
- 仕様だけでなく、「これぐらい簡単に改善できるでしょ」のような歪んだ認知はないか
もし他にも重要なポイントがあればぜひコメント等でご教示ください。
クロスファンクショナルチームを作る
さて、いろいろとそれっぽいことをつらつら書きましたが、業務改善において組織としてできる取り組みとしては、クロスファンクショナルチームの結成です。
クロスファンクショナルチームは異なる部門・職位からメンバーを集めたチームのことを言います。
業務改善・DXにおいてであれば、各部署・現場から代表者を選出して改善のやりとりをすることとなります。
代表者を選出することのメリットは以下のとおり。
- 現場メリット
- 当事者意識の特に強い人材ができる
- 担当者はITリテラシーが高くなり、継続的な改善の主体になれる
- 改善の過程で現場の声を差し込める
- エンジニアを味方にできる人材がチーム内にできる
- コーポレートエンジニア側のメリット
- ヒアリング対象が明確になり、かつ相手ごとのITリテラシーや業務知識のムラを意識せずに済む
- 現場知識があり、かつ自分と共通言語を持った相手ができる
- 各種業務の割り振りがしやすい
- 組織のメリット
- 各部署に一定のITリテラシーを持った人材ができる
- 各部署に業務改善を主体的に実行し得る人材ができる
- 継続的な改善文化ができる
- 改善を個人の意欲に依存する体制からの脱却
業務改善やDXにおいて、クロスファンクショナルチームはかなり有効な手段だと考えていますし、実際継続的にやりとりする相手がいるチームの業務改善は加速度的に進みやすいと実感しています。
DX推進、業務改善をしたい組織であれば、クロスファンクショナルチームを作ることは必須と言えるでしょう。
色んな人がいるよね
コーポレートエンジニアは業務改善の都合で様々な人と接する機会が得られるのですが、やっぱり色んな人がいるものです。
「エンジニアになれば良いのに……」と思うほどITリテラシーが高い方もいますし、人格者もいればその逆も多くいます。
みんな自分の仕事や立場や価値観や人格を守るためにさまざまな思想のもと行動しています。
エンジニアとして論理的に正論を突きつけるのが正しいのではなく、どんな過程を経ていようが適切なシステムを最小限のコストで導入するのが正しいと気づけるのに私は時間がかかりました。
尊重はしつつ適度に不要な情報や感情は切り捨てて、うまいことハンドリングする。本当に面倒臭い。
でも改善や成果を最も間近で見られる職種ですし、やりがいもそれなりにあるお仕事です。
