以下のどれかのお悩みに該当する方は、ご一読をおすすめします。

  1. 煩雑なやり方をしてるけど、どこから手を付けて業務改善をしたらよいか、わからない。
  2. 開発会社に業務システムを委託しているけど、思ったように進まず難航している。
  3. 業務改善の検討を社内で開始して担当者になったが、何から初めて良いか困っている。

ITを使って課題を解決するには、理論武装が必要

このコンテンツは、「社内で業務改善の構想立案を行って、会社のみんなに新しい働き方を届けたいけど、あまり技術に詳しくない」という方に向けて書かれています。業務改善を行うには、適切な理論武装をもって周りを説得し巻き込んでいかないと成功率が上がりません。それがこのページの骨子です。

一番重要なことは、以下の通りです。

事業会社において業務改善の成功と失敗の分かれ道は、業務を掌握しているマネージャの視座です。

マネージャの視座が大切な理由は、とても単純です。知識と体験によって得られる視座によって、運用できる業務のレベル、正確にはITを使ってテコ入れすることができる内容に差が出るからです。ITを導入すること自体は簡単です。買うだけならできます。問題はあとからやってきます。あれはどうしたこれはどうなったと言う諸問題が噴出します。

ゴルフで例えるとわかりやすいんですけど、ITマネージャはキャディのような存在です。コースは業務、プレイヤーはメンバーです。コースの特徴やメンバーのレベルを知っていれば「コースマネジメント」ができます。ただ、多くの会社はキャディが必要なことを認識していないので、ピンの方向にスタンスを構えて打てもしないドライバーを構え、大叩きをしているように思えます。

このコンテンツは、業務を掌握してる中小企業のマネージャ層に、ITによる業務改善をどう進めていくかの視座を提供することを、目的にしています。外部のITマネージャとしてコンサルティングしていく中で、ITマネージャの育成が一番重要だと感じています。

業務改善にみんなを巻き込む「IT企画」

ITを使うのにいちばん大切なのは、適切な要求を明文化すること。自分たちがどんな家に住みたいかをハウスメーカーなどに伝えるのに例えられます。どんな家に住みたいかを適切に伝えるのは結構難しいですよね、新居には住んでもいませんから。それに、ITの難しいところは生活導線を伝えたとしても、建物の特徴や配管の取り回し、電気の配線など、目に見えない所で導線の動き方が決まるところです。生活導線が業務で、配管の取り回しがデータです。この両輪が回らないといけません。

IT企画の成功可否を分けるポイントは、生活導線と配管の取り回し、業務の流れとデータの流れを同時に考慮しているかどうかで決まっちゃいます。この点を、まずご認識ください。

IT企画とは、ITシステムを導入することで皆さんの働き方を変える企画のことです。この企画の立て方をキチンと説明しているのは、恐らく当社のこのコンテンツしか無いと思います。IT企画の立て方は以下の流れに沿って行います。

  1. 現状分析
  2. 構想立案
  3. ITデザイン
  4. 運用開始

それでは、1つずつ見ていきましょう。

現状分析の内容を説明できますか?

「何がやりたいんですか?」

こんなことを開発会社さんやそれに準ずる業者さんに聞かれた方は多いと思います。言い方はここまでストレートではないと思いますけど、この質問はNGワード。現状分析ができたことにつながりません。

現状を分析したとは、どういう状況のことを指すのか。説明できないシステム屋さんも多いです。それを端的に表現したのが、下記の図になります。

現状を分析できたというのは、業務の塊を作業に分解し、作業実施の上で不都合な現象を課題としてピックアップし、課題解決に必要なことがイメージできた状態を指します。

業務改善を推進する場合、把握しなければならないのは「課題」です。同じ会社で働いているのに不思議なんですが、「課題と認識している現象」が人によって様々です。認識のズレというか、なぜか接点がないような状態です。立場が違えば見えるものも違うし、手放したくないものも違う。まず、この課題認識のズレを実感することがスタート地点になるでしょう。

課題を見つけるには、どうしたらいいか。答えは1つです。作業を観察することです。

仮説は要らない。事実を深堀りする。

システムの開発や導入を依頼したことがある場合、必ずヒアリングの時間を取られます。私共もそのお時間を頂いています。

ヒアリングで「何をしたい」「何が欲しい」「課題はなんですか」という種の話を延々としていたら、良い時間にはなりません。ヒアリングで答えを求めているためで、往々にして間違いのもとです。課題認識の立脚点がズレてしまいます。なぜそれが欲しいかを問うのではなく、「なぜ、そういう状況のままにしておくことができないのか」について、明文化しましょう。そこを深堀りするのがヒアリングの肝。

ヒアリングで聞かねばならないのは「当事者の体験」と「その体験が引き起こされた環境」です。お尋ねしたいことは、御社が欲しいものではありません。自分が「本当に」ほしいものなんて、知りません。観察から洞察を生み出します。そのためには、当事者の体験した事実を深堀りしましょう。

社内でシステム導入を検討しているのに、現場の担当者に社内ですらヒアリングを行っていないケースが結構あります。海図を持たずに航海に出るようなものです。

社内で話の流れを整理したり、参加者の認識の一致を確認して、合意形成や相互理解ができないのに、どうやって外部の会社とうまくやれるというのか。

自分の言葉で課題を語らないことには、自分ごとになりません。

業務改善のコアは「未知の良さ」です。ある程度イメージできている場合もあるでしょうが、今は持っていなくて、明確に言葉にできないけど、何かが欲しいという状況。でも現場は困っている。業務改善を推進するというのは、火中の栗を拾うような行いですので、明確な方向性を打ち出してリードしていく姿勢がとにかく重要です。

さて、現状分析のまとめです。

現状を分析できたというのは、業務の塊を作業に分解し、作業実施の上で不都合な現象を課題としてピックアップし、課題に対する解決策の方向性がイメージできた状態、を指します。

分析のインプットは、作業を観察することで、「理想と現実との距離」が課題としてあぶり出されます。そこまで煮詰めましょう。

楽しもう、構想立案

業務改善を念頭に置いたITシステムの導入で成果を出すためのポイントは、相場が決まっています。

O

一言で言えば「省力化」と「可視化」を目指します。

業務改善をしなくては、会社の働き方を変えなくては・・・という状況にある場合、セットになっているのが「手順の煩雑さゆえに属人化している」です。どこかしらそういう状況になるものです。

煩雑になってしまう原因は様々ですが、やり方が煩雑になって整備できていないから体で覚えてしまい、作業を自分で分解できなくなる。他人が紐解くにも難航する。こういう状態が属人化した状態です。業務の受け渡しが属人化したら、そこがボトルネックになります。ボトルネックに蓋をしても改善できません。

ボトルネックを可視化するのが構想立案の立脚点です。

可視化が進むと、何が起こるかといえば、業務の標準化です。ある一定のルールが形成され、それがみんなで共有できるようになります。属人化が進んでしまうと「バッドノウハウ」が溜まります。生産性は全然高くないけども、目の前の仕事をやっつける問題解決のために必要になるノウハウのことです。蓄積しても組織としては何のメリットもないので、バッドノウハウを駆逐しましょう!

Less is More.

Less is Moreは「より少ない労力で、より多くのことを成し遂げよう」というメッセージです。業務改善のコアはここにあるからです。

よくある間違いとして、より多くの労力でより多くのことを実現しようとすることが挙げられます。More and More、とでも言いましょうか。これはあたり前のことであって、改善とは言えません。労力と成果を正比例させようとすると、間違ったやり方で正しい結果を出そうとします。

Why→How→Whatの順番で考える

構想立案で詰まってしまう最大の原因は、考える手順を踏んでいないからです。下の図は「ゴールデンサークル」と言われるもので、「Why」の次に「How」が来るのがポイントです。

例えば「在庫の管理ができてない。なぜなんだろう?」がWhyに当たります。思い当たるWhyを探していくうちに「システムにXXする機能がないから」「委託倉庫との在庫と合わせる作業にミスが有ったから」みたいな現象が出てくる。ここのネタが拡散すればするほど、後の絞り込みが有効になります。

で、そのWhyを解決するにはどうすればよいか、がHowです。このHowの炙り出しができていれば、マラソンで言ったら折返し地点は余裕で超えて、30kmぐらいまで来ています。

ゴールデンサークル

このHowは「XXはやめて、YYに統一する」みたいなフォーマットがベストです。

だって、やめるしかないですよね、問題を生み出しているあり方を。

その方法や体制・進め方を進めるのは誰も望まないから辞めるしかない、別の道に切り替えるしか無いというコンセンサスが生まれない程度のお話であれば、現場の反発は大きくなりやすいですから。

上手くいく会社さんの例を見ていても、やっぱりこの部分がしっかりしてる(ぶれない)なので、前に進む推進力が反発を乗り越えています。

未知の良さを言語化しよう

構想立案のまとめに入ります。ボトルネックを可視化することで、既知の問題がよりクリアになると思います。ぼんやりとした改善の方向性がクッキリに変わるはずです。

構想立案の難しさは、他人に「自分の考えていることを図式化・言語化して」伝えることです。伝えると伝わるは全然違います。伝わるを実現するためには、理論武装が必要です。

理論武装とは、自分の主張している内容を、理由と根拠で補完すること。このコンテンツは、皆さんが理論武装できるようにという願いも込められています。

ITで業務が変わるワクワクをデザインしよう

ITデザインというのは、自社の最適な業務システムを作ってみる、という工程です。

自分たちが描いた構想が正しいかを検証するには、ソフトウェアを使ってみる。それ以外の方法はない!

構想の検証は実物で行うしか無い。そして、描いた構想はまず"一発ツモ"とはいかず、ある程度二転三転して煮詰まっていきます。想定と現実は違いますので、エンドユーザーが自分で改修できる余地がふんだんにあるツールが適しています。

ITシステム導入の形について

令和の時代、色んな業務システムがWebサービスとして公開されており、全てに精通するのは私共ITプロフェッショナルでも到底不可能です。どれか1個に絞ってノウハウを貯める必要があり、私共は業務システムを設計・デザインして、自分の好きなシステムが最も安価に作れるサイボウズ社のKintoneを、選択しました。

Kintoneはちょっと・・・というケースでも、システム屋が業務システムを作っていく考え方や過程は、皆さんの業務改善を成功させるインプットになると思います。ぜひご覧ください。

当社では、業務システムを内製するツールとして、サイボウズ社のKintoneを選択しています。理由は以下のとおりです。

  1. PaaSサービスでの国内マーケットシェアが高く、ユーザー数が増加している。
  2. エンドユーザーでも改修できるが、プログラミングを行い上級者が手を入れることが出来る。
  3. プラグインが豊富にあり、拡張性が高い。
  4. 運用はサイボウズ社におまかせでき、ユーザーはアプリケーションの運用だけに専念できる。

どうやってシステムを作るの?

社会人1年目でITシステム開発を体験した時、「システムの作り方を考えろ」と言われても考えられませんでした。先輩が設計した画面があって、それを再現できるように写経して覚えました。業務システムの設計については私共が設計を行い、実装を少しづつ行って頂いて作り方を覚えて頂くようにしています。

皆さんがシステムを作ってみて、ユーザーの要望に対して「これは、どうすべきだろう?どういう手段を取ればいいのだろう?」という局面を迎えるのを楽しみにしています。そこに向き合って解決できた時が、一番楽しい瞬間ですから。

会社の中で「その伝え方では何がしたいかわからん」とか「こんなのが欲しいっていうけど、言うほど使わないだろ」とか「そこを変更するにはこっちも変更せなあかんので、こういうのじゃだめ?」等の議論を重ねてください。その積み重ねで、社内のIT企画力が上がってきて「こんなことできないの?」というアイデアが出てくるようになります。

入力画面から始めよう

プログラミングを除けば(デザインした画面がちゃんと動いて、データ操作ができる状態にもっていく)、画面をデザインすることは誰でも出来ます。kintoneのようなツールを使えば、画面をデザインすればデータの入力が可能になって、みんなで使えるシステムが出来ます。

使うパーツはとりあえず4つ

パーツ用途
テキストボックスユーザーが自分で入力すべきもの
プルダウン選択肢から1つを選ぶもの
ルックアップ他のアプリからデータをコピーするもの
テーブル同じ質のデータを何行も登録するもの

ルックアップは、他のアプリを先に作っていないと引っ張れないので、まだ参照先のアプリがない場合は一旦テキストボックスで良いです。

作業の流れに沿って、画面遷移を考えてみよう

起点となる入力画面を作ったら、次は画面遷移です。

上記のように、画面名、その画面に出すデータ、画面で可能な操作を書きます。システム会社さんと要件を詰める際にも、先方にこのフォーマットに落として提供すれば、議論も弾みます。というのも、現役の開発者である私がこの情報を欲しているためです(笑)

また、データについても「顧客情報」「見積明細」「原価」みたいな感じで、まとめてもらってもいいです。質が違う情報が必要であることを定義しておくのもGood。

画面遷移は、システムの骨格にあたるものです。画面のデザイン並びに操作性が、筋肉に該当します。後者についてはツールを使う以上ある程度の制限がありますが、一般的な業務システムであれば問題にはならないでしょう。

さぁ、検証しよう

ITシステムを作って終わりなのは開発者だけで、エンドユーザーはITシステムを手に入れてからが始まりです。ITシステムで描いた構想立案が実現できているかを検証しましょう。ユーザーのフィードバックをもらいましょう。

このコンテンツによって、皆さんの知恵を出し合った業務システムが生まれて、少しでも良い働き方を実現する一助になれば幸いです。

業務改善の一例です。アイデアの一助にどうぞ。