ひょっとしたら時間をかけることなのかもしれない。
そんなことをMGをしながら【内省】していた熊本MGでした。
この【内省】っていう資質は面白いもので、考えること自体が行動することと同義みたいなものなんです。
MGではよく行動が先！と伝えていますが、【内省】が上位資質だと行動する前にまず考えたい。
でもMGでは急かされるので、最初の頃はちょっとモヤッとしたりする時もあったりして。
これは本題から逸れるような気がするので、深入りする前に話を戻そうかと思います。
これはこれで、面白い題材なんですけれどもね。
そんなMGの講義で見積書の話になって、見積もりを出す時って結構考えたりするということがある、らしいです。
らしいって言ってしまうのもアレなのですが、わたし自身があまり見積もりというものを出したことがないんです。
システムエンジニア時代はもちろん出していました。
顧客の状況に合わせてちょっとしたシステムを開発する仕事をしていたので、顧客ごとに作業内容が異なります。
従来のやり方ならばいちいち概算工数を割り出してエンジニアの人件費を算出し、そこから見積もり金額を計算するところです。
特にわたしの場合は自分では開発を行わず、専任のプログラマにシステムを作ってもらうので尚更です。
でも、わたしは飲食業からの転身組。
IT業界の慣習なんてどこ吹く風で、自分の好むやり方でしれっと見積もりを作ってました。
ものぐさなわたしは毎回見積もり金額を出すために時間をかけるのが嫌で、導入する機能ごとに定価を決めました。
本来は作成する機能をプログラマと打ち合わせをし、かかる時間を想定し、見積もり金額を出す工程があるはず。
その工程を完全にすっ飛ばして、半自動的に見積もりを出せるように、顧客と交渉をさせてもらったんです。
もちろん、その際にはしれっと単価をアップしました。
その頃から自分で価格を決めるようにしていたな、って思い返しています。
各機能ごとの収支で言えば、時には赤字になることもあります。
見積もりで出した金額よりも、エンジニアの人件費（というよりは外注費）の方が高いということです。
でも、トータルの年計で見たらMQを右肩上がりに推移させていたので、間違ってはいないなという感覚でした。
数字による成果を集計していたので、正しい意思決定かどうかが明確になっていたのが良かったです。
これで右肩下がりだったら、自分の意思決定が間違っているという事実を突きつけられるところでした。
しかも見積もり作成の為の打ち合わせ時間をなくしたので、プログラマも開発に専念できるというものです。
わたしの得意なところは、こんな感じに業務のめんどくさいところを排除していくことなんだなって感じた瞬間でもあったかも。
何がいいたいか。
一度本筋に戻しても、再度わき道に逸れる時ってありますよね(笑)。
でも、今回はこんな感じかもしれません。
業務改善って、実はめんどくさいから始まるんです。