0.はじめに
本稿ではボトムアップで業務効率化をするにはどうしたら良いかを記載します。「全社的にRPAツールを導入するにはどうしたらいいか」とかそういう話ではありません。ただ**「日々の業務を効率的に（楽に）行いたい。そのためにはどうしたらいいのだろう」というレベルの内容**です。
また、本稿は「チーム論」と「方法論」の二章立てです。
なお、参考文献は最後にリンクを貼っています。気になった人は是非。
なんで書いたの？
今般、業務効率化という言葉が跋扈しており、トップダウンでRPAを導入した企業も多くあると思います。ですが、現場レベルだと使いにくかったり、カスタマイズが効かなかったりで「んｗ微妙ｗ」という事態も発生しているのではないでしょうか？それよりも、現場レベルで相談しながら自動化ツールを作ったり、既存ツールを導入したりして、ボトムアップさせた方が遥かに有用だと思い、この記事を書かせていただきました。
想定読者
・業務・案件リーダーとかで「なんか効率的に仕事回せないかなー」って思ってる。
・一般エンジニアとかで「作業楽にしたいなー」って思ってる。
だけど、どうしたらいいかわからない人。
1 チーム論編
「なぜ業務効率化にチーム論が必要なのか？」と不思議に思っている方もいるかもしれません。理由を述べると、大半の業務効率化のアイデアは１人で考えて一人で実行するのは難しいですし、効果的ではありません。メンバ各々が業務効率化のアイデアを発信でき、それをチームで洗練・実行した方が効果的だからです。
これについては、_「組織集団における創造革新性パラドックスの発生メカニズムと克服方略に関する研究（２）―創造的アイディアの履行（実現）プロセスー 古川（2014)）」や「組織行動研究の展望～パラドックスを抱えた組織と個人を意識して～ 古川(2018)」_が参考になると思います。
1.1チーム論 is 何
チーム論とは端的に言うと『効果的なチームを作るにはどうしたら良いか』という話です。では、チームとは何かというと、簡単にいうと「ある目標に向かって集まった組織体」の事を指します。
企業で言うならば、最も大きな単位としては「会社」になりますし、小さい単位ならば「小規模な案件」と言えます。
（その他、『部単位』、『業務単位』、『委託先単位』、『プロジェクト単位』等々あると考えます）
1.2 理想の「効果的なチーム」
具体的に「効果的なチーム」とは何でしょうか。これには諸説ありますが、おおよそ以下の要素が揃っているチームが「良い」と言われる傾向にあります。
・目標がチームで共有されており、これに対するメンバの達成意欲が高い。
・役職等に関わらず、チーム内で本音が言える。
・各々のメンバが自主性をもって動く
・誰かが困った時は他のメンバがサポートする。
これらを備えたチームは高い生産性を上げられるはずです。（理想論）
1.3 現実的に「効果的なチームの条件」を調査したgoogle re:work
少し前の話になりますが、google re:workによる「効果的なチームとは何かを知る」という記事が話題になりました。途中経過等は記事を見ていただくとして、結果として以下の事がわかりました。
その結果、リサーチチームは、真に重要なのは「誰がチームのメンバーであるか」よりも「チームがどのように協力しているか」であることを突き止めました。チームの効果性に影響する因子を重要な順に示すと次のようになります。
心理的安全性: 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。
相互信頼: 相互信頼の高いチームのメンバーは、クオリティの高い仕事を時間内に仕上げます（これに対し、相互信頼の低いチームのメンバーは責任を転嫁します）。
構造と明確さ: 効果的なチームをつくるには、職務上で要求されていること、その要求を満たすためのプロセス、そしてメンバーの行動がもたらす成果について、個々のメンバーが理解していることが重要となります。目標は、個人レベルで設定することもグループレベルで設定することもできますが、具体的で取り組みがいがあり、なおかつ達成可能な内容でなければなりません。Google では、短期的な目標と長期的な目標を設定してメンバーに周知するために、「目標と成果指標（OKR）」という手法が広く使われています。
仕事の意味: チームの効果性を向上するためには、仕事そのもの、またはその成果に対して目的意識を感じられる必要があります。仕事の意味は属人的なものであり、経済的な安定を得る、家族を支える、チームの成功を助ける、自己表現するなど、人によってさまざまです。
インパクト: 自分の仕事には意義があるとメンバーが主観的に思えるかどうかは、チームにとって重要なことです。個人の仕事が組織の目標達成に貢献していることを可視化すると、個人の仕事のインパクトを把握しやすくなります。
また、google re:workでは以下の事柄はチームの効果性に影響していないともしています。
リサーチチームは、Google 社内のチームの効果性にそれほど影響していない変数も明らかにしています。
チームメンバーの働き場所（同じオフィスで近くに座り働くこと）
合意に基づく意思決定
チームメンバーが外交的であること
チームメンバー個人のパフォーマンス
仕事量
先任順位
チームの規模
在職期間
ただし注意点として、google社員が働いている環境がわからないですし、google社員である時点で相当優秀な人材である事は前提だと思うので、単に鵜呑みにしてはいけないとは思いますが、非常に参考になる研究だと思います。
この中で最も重要とされる「心理的安全性」について以下記載します。
1.4 心理的安全性とは
上記の引用文にから大事な文を１つ選ぶとしたら以下の部分だと思います。
「自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地がある状態」
上記のようにメンバが思える状態こそ、「心理的安全性が担保された状態である」と言えます。また同時に、これは努力や学習をしなくても良いヌルい職場（チーム）という意味合いではないということも十分に理解する必要があります。
（効果的なチームを作るための土台なので当たり前の話ですが、よく勘違いされるらしいです）
つまりは、チームとして高い成果を出すためには心理的安全性が担保された状態であると共に、高い基準の仕事を目標とする必要があります。ですが、本稿では「高い基準の仕事云々」については業務効率化とは別の話になるので割愛します。
（気になる人はチーム論を勉強しましょう。）
また、心理的安全性についてはところてん氏のスライド（※）が参考になると思いますので一読をお勧めします。
（※：心理的安全性の構造、チャットコミュニケーションの問題と心理的安全性の課題）
1.5 心理的安全性のあるチームを作るには
では具体的に心理的安全性のあるチームを作るにはどうしたら良いのでしょう。
「頼む～。心理的安全性の担保されたチームになってくれ～」と願っても何も起きません。（当たり前ですが）
自分から行動や言葉を通じて啓蒙していかないといけません。
株式会社ZENTechならびに慶應義塾大学システムデザイン・マネジメント研究科の調査結果を参考にすると、日本の組織においては、以下の因子がある時に心理的安全性が感じられるといわれています。
１．話しやすいさ
２．助け合い
３．挑戦
４．新奇歓迎
_「心理的安全性のつくりかた～「心理的柔軟性」が困難を乗り越えるチームに変える～(2020)」_によればそれぞれの行動例としては以下があげられます。
話しやすさ
話す、聞く、相槌を打つ、報告する、目を見て報告を聞く、雑談する、報告という行動自体を（内容とは切り分けて）ほめる
助け合い
相談する、 相談に乗る、 問題を見つける、 自分一人では対応できないことを認める、 トラブルを楽しむ、 ピンチをチャンスへ変える、アイデアを出し合う、解決のためのアイデアを広く募る、個人ではなくチームの成果を考える
挑戦
挑戦する、機会を掴む、機会をつくる・与える、試す、実験する、模索する、仮説・検証、改善する、工夫する、新しいことをする、変化を歓迎する、世の中・顧客の変化に直面する、挑戦自体を褒め・歓迎する、失敗を歓迎する、現実のフィードバックを受け入れる、常識を疑う
新奇歓迎
個性を発揮する、個性を歓迎する、強みに応じて役割を与える、常識に固執しない、ステレオタイプを避け本人の行動を見る、月並みを拒否する、批判を一時脇に置く、自分自身のものの観方をフラットに共有する・される、違いを良い・悪いではなくただ違いとして認める
1.6 心理的安全性は一日にしてならず
上記の行動をしたからとして、すぐに心理的安全性を確保できるわけではありません。先にも引用した_「心理的安全性のつくりかた」_にも以下の記載があります。
組織・チーム は「歴史」を背負っています。歴史とは、一人一人の行動や結果と、組織や周囲の対応の積み重ねです。
人は他人を観察しており、行動を人それぞれに対して変えるものです。日々の会話・文面・出来事から、「この人（チーム、組織）に対してはこうした方がいい」というのを学習します。これは一日でどうこうする出来るものではありませんし、命令しても、いきなり変えられるものではありません。日々の行動に気を付けて、人に観察してもらうしかありません。
1.7 具体的に何をすれば良いのか
正直わかりません。
人の性格はそれぞれですし、全員に対しての正解行動というのは存在しないのではないでしょうか。方針としては_「Team Geek -googleのギーク達はいかにしてチームを作るか」（2013）_のHRTの三本柱に準じた行動をするのが良いと思います。なおHRTとは謙虚(Huminity)・尊敬(Respect)・信頼(Trust)の頭文字です。
という事を頭に置いていただいたうえで、本項では私が「心理的安全性」をもってもらうために、気を付けようと思っていることをつらつらと書いていきます。もう一度言いますが、これが正解とは限らないですし、もしかしたら逆効果かもしれません。本当に参考までに。
人が何かをアイデアや情報を発信したときに、小さくてもいいので何かしらのリアクションをとる。（emojiとか）
⇒何もリアクションが無いと、私はモチベが下がって発信したくなくなります。ですが、同意や批判等、なにかリアクションされるとちょっと承認欲求を満たされた気分になります。なのでやってます。
もちろん暴言だったり、意味不明な批判だとモチベは下がりますが。（Twitterでよく見る光景）
他人の意見は最後まで聞いて理解しようとする。
⇒最終的にその意見が没になるかは別として、人の意見は最後まで聞いて十分に理解した（しようとした）上で賛成や反対を示しましょう。相手に話を聞いてもらって理解してくれようとした。という体験をしてもらうのが大事だと思います。意見に不明点があれば聞きましょう。「この人に意見を話しても意味がない」と思われたら終わりです。
可能な限りフランクにいる
⇒~~私がフランクでいたいだけです。~~話しかけやすいようにしたいだけです。なんかガチっぽい雰囲気だされると話かけにくく感じるので、できるだけ余裕を持ってる雰囲気にしようと心掛けてます。
メールのP.S.で雑談を挟む
⇒対個人限定ですが、ある程度つきあいが出来たと思ったら、本件とは別にP.S.で雑談とか入れたりします。自分の方から「私はあなたにこれぐらい気を許している」と思わせる作戦です。
人のミスを怒らない
⇒人はミスをする生き物です。起きちゃったものは仕方ないので、フォローして解決した方が良いのは当たり前ですね。ミス起きた経緯を聞く時も怒るより、寄り添ってあげた方が建前じゃなくて正直に答えてくれます。というか私はそうします。
そうした方が正確な対策を打てます。
1.8 甘えてくる人への対応
自分への心理的安全性を高い状態にしようとすると、だいたい甘えてくる人が発生します。そこはしっかりと説法を説きましょう。ただの「都合の良い人」にならないように！もちろん自分自身も他人に甘えてしまわないようにしましょう。
これについては_「Temm Geek」_に記載されている「有害な人への対処法」（※）を参考にすると良いと思います。
（※：本書内で、**排除すべきは人ではなく"振る舞い”**と強く記載されていますので、その点補足させていただきます）
1.9 チーム論についてのまとめ
つまりは**心理的安全性を持ってもらえたら業務効率化のアイデアが出してもらいやすくなります。**チーム単位はもちろん、１：１の関係でも一緒です。
とりあえず近年のチーム論を学ぶ上で、_「Team Geek」_は必読といえる本なので是非読みましょう。
2 方法論
上記の「良いチーム」が出来れば違うのかもしれないですが、普通の職場において、自分から業務効率化しようという人は稀だと思います。なので、業務効率化は**「誰かがやってくれる」等という希望は抱かず、自分から動く事が大事だと思います。なお、ボトムアップ式業務効率化において一番大事なのは「楽をしたいマインド」だと思います。作業・案件担当者が仕事を楽するにあたって「業務効率化」は最高の建前**です。ガンガン使っていきましょう！
システム知識が少ない人へ
情報系出身以外や上流工程担当だと、既存ツールの導入も難しいですし、ツールの作成も難しいです。しかし、動かなくては始まりません。「よくわっかんねーな」と思いながら頑張りましょう。
（少なくとも私はそうです。システムまったくわからん）
そのような人の為の方法論です。参考にしていただければ幸いです。
2.1 業務効率化の定義
本稿では「業務効率化」を**「業務遂行時におけるムダな作業を無くす。尚且つミスを減らす事（最悪でも増やさない）」** もしくは、**「業務遂行時におけるミスを減らす。尚且つ作業量を減らす（最悪でも増やさない）」**と定義します。
2.2 業務効率化できる箇所を考える
まずは業務効率化できそうな箇所を特定するために以下の事をしましょう。
業務遂行方法を分析する
まずは問題（改善点）を発見するために現状を分析して以下の4点を確認します。
・必要のない作業を実施していないか。
・ミスの可能性のある（高い）作業はないか。
・自動化できる作業はないか。
・システムやツールを利用して業務フローを簡易的にできないか。
それぞれ見ていきます。
必要のない作業を実施していないか
「昔の手順書やお作法ではあるけれども、現在においては実は不要の作業」
というものが対象です。影響確認は十分にしつつもさっさと手順書を改訂しましょう。
必要ならば業務フロー自体を変えてしまうのも手です。
お作法？理屈でぶち壊しましょう。
ミスの可能性がある（高い）作業はないか
人間は生き物なので、ミスをして当たり前です。これに対する対処として多くの場合「多人数チェック」による対処がよく用いられますが、可能な限りシステム的なチェックを行う方法に切り替える方法を考えましょう。
※多人数チェック方式についてはトリプルチェック以上は逆効果であるという研究結果が出ています。
参考：多重チェックでエラーは防げるの誤解
システム化できる作業はないか
作業の発生頻度やヒューマンエラーリスクと自動化のコストを天秤にかける事になります。定性面・定量面の両面から検討し、上位者にコスパが良い話であることを示しましょう。
…というのが正道の考え方ですが、ここに一つの名言があります。
「許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgiveness ) 」
（正しくは、「事前に許可を得るより、あとで許してもらうほうが楽」らしいですが…）
これに対する考え方は色々とあるかと思いますが、私の意見としては所謂「守破離」の破や離の部分に当たると思うので、十分な経験と知識を持っていない限りはしない方が良いと思います。
ツールを利用して業務フローを簡略にできないか
ツールを利用し、業務フローを簡易的にすることで、ヒューマンミスや作業効率を上げようという考えです。具体的な話をいうと押印手回し等をしている業務に、チケット管理システムを導入する等が当てはまります。
業務効率化に使いやすい既存ツールおすすめ一覧
有名どころを簡単な概要と利用例と共に書いていきます。
折りたたんでいるので、見たい人はクリックして展開してください。
（ここでは無料でも使えるものを紹介してます）
概要・利用例
＜概要＞ OSSのプロジェクト管理システム。 チケット管理・ガントチャート・wiki等も備えている。 オンプレミス環境に構築できるので、 セキュリティにうるさい会社でも比較的容易に入れられるのが魅力。しかもOSSなので無料でいける。強い。 また、プロジェクト管理システムだからと言って、プロジェクト管理に使う必要は全くない。 必要な機能だけ使えば良い。 ＜利用例＞ ・”依頼される仕事”において、依頼方法をチケット制とする。 ⇒紙やエクセル管理等に比べて、「うっかり忘れた」という事態を避ける事ができる。 ⇒チケット管理システム is 何 という人は[こちらを参考に](https://it-trend.jp/project_management/article/33-0025#:~:text=%E5%AE%9F%E6%96%BD%E3%81%99%E3%82%8B%E3%81%B9%E3%81%8D%E4%BD%9C%E6%A5%AD%E3%82%92,%E6%89%8B%E6%AE%B5%E3%81%A8%E3%81%97%E3%81%A6%E6%B4%BB%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82) ・wikiを利用して社内・部内での知識共有を図る。 ⇒「〇〇さんだけが知っている」という状況をできるだけ避けるためにwikiを利用するというもの。 業務やシステムのわかりにくい事やどこにも書いてないような内容を書いておくだけで、 業務引継ぎや問い合わせ対応がグッと楽になる。概要・利用例
＜概要＞ 一言でいえばシステム（ソース）の変更管理・課題管理・CI/CDしてくれるツール。 OSSなので無料。さらにオンプレミスにおけるのが強い。 gitなので勿論二重修正にも対応している。 GitHubの独立版ぐらいの気持ちでもいいかも（有識者に怒られそう） 新規システム開発には非常に便利だが、既存の大型システムに対して適応するのはなかなか大変だと思う。 gitの文化が無い現場だとなかなかしんどいかも。 git is 何 という方は以下の記事を参考にしてください。 [[初心者向け]Gitの理解/Githubの初pushまで](https://qiita.com/Toshimatu/items/f71a935612a55d6e674e) ＜利用例＞ ・開発におけるコードレビュ等はすべてGitlab内で完結させる。 ⇒変更箇所の確認やレビュ管理をGitlab内で完結させる事ができるので、開発における管理が楽。 ⇒修正による二次災害やリリース後の障害において原因特定がしやすい。概要・利用例
＜概要＞ ツールというかホットキー割り当てとかができるスクリプト言語。 つまりは自動化のお供。 無料でインストール不要なのでかなり使うハードルが低いのがポイント。 ただし、プログラミングは頑張らないといけないし、複雑な関数はないのでちょっとそこらへんは不便。 非SEにはちょっと使うのは難しいかもしれない。誰か得意な人に作ってもらおう。 ＜利用例＞ ・自動化ツール作る時のお供。だいたいどうにかなる。概要・利用例
＜概要＞ オンプレ用のslackクローン。 クラウドにつなげないからslackは無理…＞＜ と思ってもmattermostなら出来ます。 ただしslackより少し機能は落ちますし、日本語ドキュメントがほぼないです。 とりあえずメール文化を滅ぼしたい時にどうぞ。 （チャット文化が根付くとは言っていない） ＜利用例＞ ・slackとほぼ同機能なので省略。・Fess
概要・利用例
＜概要＞ 全文検索ツール。 wordやpdfとかに対しても全文検索ができる。偉い。 ElasticSearchと一緒に使う。 （fessがフロント、ElasticSearchが検索エンジン） これもOSSなので無料。さらにオンプレミスにもおけるのが強い。 ＜利用例＞ ・クロール対象を自社サーバーに設定しておけば、 問い合わせ等でフォルダ・ファイルネームではわからないレベルでの情報検索で超便利2.3 自動化する優先順位
ここからは主に「作業の自動化」について記載していきます。
一般論ですが、自動化の優先順位については、
・定型化しやすい作業
・発生頻度が高い作業
の２つを優先的に自動化の対象にするのが良いです。
前者はツールを簡単に作りやすいですし、後者は自動化した時に高い効果が期待できます。
2.4 自動化に適した言語の紹介
自動化するにはプログラムを作る必要があります。得意なプログラム言語がある人はそれで良いと思いますが、比較的簡単なやつを２つ紹介します。
VBA
大抵の事はエクセルVBAでマクロを作ればどうにかなります。VBAの記事はネットに大量に転がっているので、やりたいことも大体すぐに見つかるのもGOOD。他のoffice商品(outlookやAccess)に簡単に連携できるのも良い。ただし、いちいちエクセルを立ち上げないといけないので、起動が遅くて面倒なのが難点です。
利用例：VBAで定例メール文章を作成しておいて、ワンクリックでメールを送れるようにしておく。
ブラウザ等のComObjectを取得して、ブラウザ上で行う作業を勝手に実行してもらう。
AutoHotKey
ツール紹介のところでも紹介したスクリプト言語です。作業の自動化という意味ではかなり有用です。windowの操作、ホットキーの設定はもちろん、各種windowの操作やツールを常駐させて的な作業サポートもしてもらう事もできます。凄い。ただし、日本語がサポートされていないところがあったり、日本語の情報が少ないのが難点です。
利用例：フォルダを常駐監視させて、ファイルが入ったら自動的に作業を行うようにする。
ホットキーを押すとGUIを出すようにして、GUIに各種作業の自動化ボタンを配置する。
（定例メールの送信、定例作業の実行等）
2.5 自動化ツールを作ろう
案件じゃないなら要件定義や設計なんてものはありません。さっさとツールを作ってしまうのが早いです。ここからはその手順を紹介します。
自動化ツール作成時に意識するべき事
自動化ツール作成の際は以下の事を意識した方が良いと思います。
・利用ユーザーとは密接に連絡を取る
⇒認識相違があると面倒なので、各手順が終わった段階で「こんな感じでイメージあってます？」と確認しておくと良いでしょう。
・可能な限り直感的・最小手順に利用できるようにする
⇒利用ユーザーは、基本的にドキュメントは読まないと思った方が良いです。
また利用まで面倒だと大体廃れます。
・ソースの可読性・拡張性は上げておく
⇒自分が全部メンテするのは面倒なので可読性と拡張性は上げておいて、
他の人でも簡単にメンテやカスタマイズができるようにしておくと良いでしょう。
・ソースは誰でも見れるようにしておく。
⇒ツールを公開した時点で、ソースは関係者が見れるようにしておくと良いでしょう。
モノ好きな人が処理の最適化や機能拡張をしてくれるかもしれません。
そのためにも上記の可読性等は上げておくべきでしょう。
（GithubやGilab等使うのが吉だと思います）
またソースを書く前に、_「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック-(2012) 」_を読む事を強くお勧めします。
手順1.作業フローの整理
**自動化ツールを作るにあたって一番大事なのは作業フローの整理です。**いつも人間がやっている作業をザクっとフローに落とし込みます。大体以下の内容が整理できていれば良いと思います。
・インプット（スタートサイン）は何か
・作業に分岐が発生する場合、その判断材料は何か
・最終的に何をアウトプットするのか
作業フローを整理したら、これを実現するに適した言語を選択、利用できそうなツール等を探します。
（利用できそうなツールというのは例えば「pdfをtxtに変換できたら自動化できそう」とかそういうのです）
手順2.プロトタイプを作る
上記が終わったら、プロトタイプを作ります。この段階のゴールはインプットに対して想定したロジックを通って正しいアウトプットが出てくることになります。ここを適当にやりすぎると次で死ぬのでデバックはちゃんとやりましょう。
手順3.自動化ツールを作る
プロトタイプが問題なければ、インプットやアウトプットの種類に応じてプログラムを拡張しましょう。この段階で可読性や拡張性が低いなと思ったら、修正した方が良いです。また、自分以外の人が修正する可能性も考えてコメントもちゃんと書きましょう。
各種インプットやアウトプット、エラーに対してテストして問題なく実行できたら自動化ツールは完成です。
手順4.ドキュメントを作る
自動化ツール作成が終わったらドキュメントを作りましょう。大体以下の内容を記載しておけば大丈夫だと思います。
・利用方法
・ツール動作内容説明（簡易）
・メンテ手順・注意点
・連絡先
あとは自動化ツール（とソース）を公開して終わりです。
お疲れ様でした。
2.6 方法論についてのまとめ
・要らない作業はなくす！
・使える既存ツールを使ってフローを簡略化する！
・自動化できる作業は自動化する！
3 終わりに
最後に私の仕事へのスタンスを述べて終わりにしたいと思います。
「自分（達）が楽をするために、頑張る」
長い文章をお読みいただき、ありがとうございました。
＜参考文献＞
本：Team Geek -googleのギーク達はいかにしてチームを作るか」（2003）
本：心理的安全性の作り方（「心理的柔軟性」が困難を乗り越えるチームに変える)(2020)
本：リーラブルコード -より良いコードを書くためのシンプルで実践的なテクニック- (2012)
論文：組織集団における創造革新性パラドックスの発生メカニズムと克服方略に関する研究（２）―創造的アイディアの履行（実現）プロセスー 古川（2014)
論文：組織行動研究の展望～パラドックスを抱えた組織と個人を意識して～(2018)