仕事はどこにいるかよりも何をするか、という信念のもとベンチャーへ

そうですね。社員が20人いるかいないかのころ。2015年の入社なので、創業して4年ぐらいですかね。

いえいえ、そんなことはぜんぜん（笑）
それまでベンチャーで働いたことは一度もなかったので、転職活動するなかで「ベンチャー企業巡りでもしてみるか」みたいか軽い気持ちで応募して。
取締役との面接で、「小林さんがやってきた経歴は、今一番うちの会社に足りないところなんです」とめちゃくちゃ食いつかれまして（笑）

それまでやってきていた、業務設計、業務プロセスの開発みたいなところですかね。
結局どこに行っても、自分のやるべきことは変わらないという信念があったので、「お役に立てるならぜひ」と入社を決めました。
もともと、仕事の内容にもこだわりはなくて。どこにいるかよりも、何をするかのほうが大事だと思ってましたから。

このアプリにデータを入力することで何が実現されるかをちゃんと伝える

既存のアプリの改善とか。
直近だと、サイボウズOfficeを解約して、全部kintoneに移行するっていうのをやってました。
サイボウズOfficeは、ワークフローと掲示板しか使ってなかったので、だったらもうkintoneにその機能作って集約しちゃおうよ。もったいないしって（笑）
ただ、単に移行するっていうのができないんですよね。
で、作ったのがこれです。

これはもう僕のこだわりですね。名前とアイコンはすごくこだわって作っています。
アプリの名前だけではなく、背景の色とか、アイコンのテイストで、申請しようとする人が、これからやりたいことがどうしたらできるのか、ほぼ無意識で、自然にできるようになっています。

無駄な問い合わせをするのも、させるのもストレスじゃないですか。
だから、可能な限りそこをわかりやすくしたい。どうせやるなら、もう、圧倒的にやりたいんです。
このアイコンも、遠目から見てもお問い合わせを受けている人に見えるし、クレーム、ゲストの情報、お店の情報とか、一目でわかって迷わないようにしてます。

あと、大事にしているのは、「このアプリにデータを入力することで、何を実現したいんだ」っていうところです。そこをちゃんと伝えられるようにしないと、結局使われなくなっちゃうんで。

危機的状況で、kintoneの三代目の担当者に

いえいえ。担当者としては三代目ぐらいですね。
初代のかたは、きっちりした、たぶんド理系のかたで、色々なことを考えてやられてたと思うんですが、途中で退職されてしまって。
それを引き継いだ二代目のかたは、もともとの業務もあって、片手間でやっていたところがあって。設計思想がない状態で、その場その場でやっていたらぐちゃぐちゃになっちゃって。
アプリはどんどん肥大化するし、管理者が乱立して、知らないうちに勝手に項目が変えられてしまうっていう状況に。

はい。「kintoneのアプリ使いにくいじゃないか！」って苦情まで出る状態に。
このままだとうちの会社潰れちゃう、おかしくなっちゃうって危機感でしたね。
で、「やりましょう！」となって。

会社の業務を言語化し、「アプリの関係図」を作る

まず、うちの会社の業務を全部、言語化するところから始めました。
あの人は何の仕事をしていて、この人は何をやっていてっていうのを、うちのミッションから全部分解して。
それを人ではなく、役割に落として、その任務を遂行するためのツールがあると考えて。
ツール、つまり道具の使い方が間違っているから、こういうことになったんだと分析していきました。

まず自分の頭を整理するために、業務フロー図を書きました。
そこからたとえば、営業チームだったら、見込み顧客、営業情報、受注活動の管理が必要だよねって、「アプリの関係図」を作っていきました。

うちの業務を遂行するのが大前提なので、該当しないアプリはないと思ってました。
実際はやっぱりなかったんですけど。
このアプリの関係図を見て、既存のアプリに目を移してみると、本来はきっとこういうものを作りたかったんだろうなと、前任者の無念さみたいのをすごく感じましたね（笑）

もう、個別最適はやめましょうよ

うちの場合、関係する顧客の対象がものすごく幅広いんですよね。
陶芸教室のように個人でされているところもあれば、地方の自治体みたいなところもあって。
そこが、顧客情報の管理がぐちゃぐちゃになってしまった原因でもあるんですけど。
顧客管理の目的だったはずのアプリを、受注活動まで管理するようにしてしまった。

で、なんかおかしいなとなって、今度は「商談」っていうアプリがいくつも乱立。
それが巡り巡って、月々の売上管理ができなくなり、あげくの果てに「今月、うちの売上達成してるんだっけ？できてないんだっけ？」ていうのがわからなくなって。
売上の速報と最終値がぜんぜん違うみたいなのが、ゴロゴロ出てきてしまってたんですよ。

よくある話だと思うんですけど、どこか怪我しているときって、そこの患部だけに注力してしまうんですよね。
「もう、その個別最適はやめましょうよ。」って言って
僕がやるのは、個別最適じゃなくて、全体最適にしたい。だから、上段から全部設計し直したんです。

行動の大原則は「なぜ？」「なぜ？」「なぜ？」を繰り返す

僕の行動の大原則として、「なぜ？」「なぜ？」「なぜ？」を繰り返す。「まず、原因は何か？」っていうのを突き詰めて考えるんです。

原点はどこかといったら、高専時代にあるのかもしれないですね。
地獄の実験、レポート提出っていうのがありまして（笑）
1つの実験に対して、実験内容と結果、考察を、40枚ぐらいのレポートにするんですけど。
すごいがんばって書いたレポートを、先生がぺらぺらぺらとめくって、「お前のは考察じゃない。やり直し。」って。
そういうのを毎週、毎月やってました。

実験は常に試行錯誤ですからね。
標準的な実験のやりかたって、その通りにやってなぜ失敗したのかを考えるんです。
失敗するのはあたりまえで、なぜ失敗したのかを自分で考えるっていうことを、ひたすら叩き込まれました。

業務改善についてもPDCAを回していけばいいっていうだけ。つまり実験思考。
いつでも、必ずしも理論どおりにはならないので、そこはPDCAを回して、アプリの内容も修正していけばいい。

最初から、がっちがちにパーフェクトに作らないことですかね。
修正するためには余白を設けておかないといけない。
点数で言えば、40～60点ぐらいかな。それぐらいやっていれば実務は回る。残りの40点は柔軟に。現場の人が手を加えるのでもいい。
ただし、もちろん「ここは絶対変えてくれるな」って死守しているところはあります。

変化は発展。停滞しているよりも変化していくことを優先したい

業務改善は自分にとっては息をしているのと同じことなんですよね。停滞していることよりも変化していることのほうが好きなので。
実は、東京生まれ、東京育ちなんです。
なので、道路の形も変わって、ビルもどんどん新しくなってっていう空間で生まれ育っているので、変化していることが当たり前だし、変化っていうのは、発展だと思ってるんです。

なので、変化が早い状況で、変えること、なくなることがストレスにならないですし、日々、息をするように自分の生活にしろ、なんにしろ、全部改善していきたいみたいに思ってます。

苦手なことはシステムにやらせて、得意なことに集中できる環境を作りたい

今後の目標、究極の目標は、うちの従業員のメンバーの業務から、やりたくないことと、やるべきでないことを全部引きはがしたいっていうのがあります。
得意なことだけに集中してもらう環境をどうやって作っていくか、ですね。

役割分担をして、得意なところをやらせてもらっているわけで、決して１人でできたわけではないですから。
得意じゃないところをがんばったって、パフォーマンスなんて絶対出るわけないんですよね。

今だったら、人っていうよりシステムですかね。その一助としてkintoneがあるんだろうし、kintoneで足りないところは他のシステムだったり。
RPAでどこまでできるかっているのは未知数ですけど、目指すべきはそこだろうと。

本当に。今はもう、やりたいことしか、ないですね。