改革と改善の閾値

前回のエントリで改革と改善の違いをざっくり書きましたが、今回は、もう少し具体的な話で考えてみようかなと思ったので、書いてみます。

例えば、下記のようなテーマがあるとします。

「あなたの月間支出をxx%削減してください」

20%削減してください・・・と言われれば、改善っぽいですよね？

また、何をやればいいのか何となくイメージが湧いてきます。

今の支出項目を眺めて、無駄を見つけて切り詰めるイメージです。

では、改革テーマとなると、どうでしょう？

何となく・・・

50%削減してください。半減してください。

と言われたら、改善ではなく、根本的に変えなくてはいけないな・・・と思うのではないでしょうか？

また具体的なやり方も、簡単には出てこない感じです。

例えば、実家に帰る・・・。

そうすれば、家賃、光熱費、食費が全部ゼロになるよね。

みたいな、今までと全く違ったライフスタイルが求められそうな感じがします。

これって本当にこの生活に変えてしまっていいの？・・・という決断が必要になったりするので、なかなか実現は難しいです。

と、身近な例に例えると、改革案を出す難しさと、それを実行する時の意思決定、決断力が求められる・・・と難易度が格段に上がっていることが理解できるかと思います。

なので、ここに果敢にチャレンジできる社風や会社は、普通にすごいなと思います。

また、そんな会社も、チャレンジできるように様々な仕掛けがあったりするので、その辺はとても勉強になります。

改革がしたいのか、改善がしたいのか？

DXなど流行のキーワードをテーマに予算がついて、着手したい、やりたい・・・という話が来た時に、面白いなあと思うことがあります。

それが、タイトルにある「改革がしたいのか、改善がしたいのか？」です。

ざっくり言ってしまえば、改善がしたいのであれば、As IsとTo beのギャップ埋め。

改革がしたいのであれば、ターゲットとする目標にどうたどり着くのか考える。

例えば今回のDXというテーマであれば、経産省の定義では「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」とあります。

上記定義でいくならば、改善ではなく、改革に近い意味合いとなります。

となると、現場を調査して、現在のお困りごとや問題点を整理して改善していくことよりも、経営層、トップがテーマと目標を選択、決定する・・・流れが自然。

なのですが、意外と、この選択、決定が胆力がいるせいなのか、できない、難しい。

これは一緒に伴走するために提案する会社も同じだったりします。

（どのテーマが響くのか、読めない、わからない、外したくない。）

当然、改革テーマは改善テーマと比較して、実現可能性も読みにくい。

ますます改善テーマが具体的なイメージが湧きやすくて、そちらに流れてしまう・・・みたいな展開もあるあるなのかなと思っています。

私達は社内で「さん付け」で呼んでいるぐらい風通しの良い会社ですって言っている会社ほど、それを意識しているぐらい、階層を気にしている・・・そもそも気にしていない会社、風通しの良い会社は、さん付けを意識しないで空気のように使っている・・・のと同じようにDXができているところは、DXって言われる前から、DXをやっていたりしますが、こういったところも、DXが推進できるか否かのポイントになるかもなあと思っています。

計画を守るとは？

これまで仕事をしてきた中で、当初の計画、最初の計画が守られたことはどれだけあったでしょうか？

ここで言う計画とはQCD（Quality/Cost/Delivery）のことです。

と、振り返ると、意外と守られていることはなかったような・・・。

と言うべきなのか、進めていくうちにQuality（必要となる品質や仕様）が見えてきて、CostやDeliveryが固まってくるような・・・。

そのような感じがします。

個人的な感覚を例え話で表現すると、仕事における計画とは、プラモデルの設計図というより彫刻を作るようなものかなと。

プラモデルを作る場合、全てがはっきり記載されていないと、組み立てられません。

しかし実際は、そのような細かい所まで見えているものではなく、彫刻のように少しずつ削って輪郭が見えてくる、ハッキリしてくるものなのかなと。

となると、計画というものは常に変更・修正が求められるもので、QCDのうち、どこがどれくらいまで変更可能なのか、変更が許容できるのか・・・というものを見極め、調整しながら進めていくものなのかもしれません。

と、ここで面白いのは何社かとお付き合いさせて頂く中で、特徴が見えてきたことです。

例えばDelivery。この期間必達という縛りが強くない所は、読みかえると可能な限り早くしてねという意味だったりするので、余計なバッファもなく、結果的に最短最速で達成していたりします。

遅れたら刺されるようなカルチャーの会社だと、余計なバッファがあったり、Qualityが保守的だったりして、結果的に期限は守られるが、品質は最低限だったり・・・みたいな傾向が出がちかなと感じます。

と、QCDの観点から、自分が関与している仕事の計画が、どのような変更が行われているか追っていくと、なかなか面白い示唆が得られるかもしれません。

できる営業は何をしている？

できる営業は、自ら話をするのではなく、お客様に話をさせますよね？

ということで、この話はいろいろな所で言われており、実際そうなんだと思います。

また、できる営業は、お客様のことをよく見ている。

共感する力もすごいし、気が利く、細かいことに気が付く。

そうそう、それそれ！と思わず唸ってしまいます。

自分が接してきた、できる営業の方達を見て真似をしてみよう、良いところを取り入れてみようとは思うのですが、正直、自分は、他人を観察する力がなく、共感したり、気が利くみたいなアクションはニガテ。

苦手なことを克服するのは、なかなか難しい。

そこで、考えたのが、質問力です。

自ら会話するのではなく、お客様に話をしてもらう・・・となると、説明する力よりも傾聴、質問する力を磨いた方が良さそうだ。

ということで、質問するよう心がけるのですが、当然、質問が詰問になってはいけません。

また関係ができてから突っ込んだ質問を・・・ということでアイスブレイクみたいな会話、パーソナリティを知ってから・・・みたいな世界もありますが、背景や文化が全く異なる世界では通用しなさそうだなというのと、個人的に、そのような時間をもったいなく感じたり、相手のパーソナリティや自分のパーソナリティを共有することに全く興味がないこともあって、仕事に関係のあることだけで、済ませたい。

と思いながら、あれこれ試行錯誤をしてきました。

その結果がこちら！

と体系立てて整理されていれば、いいのですが、この世界はまだまだ未熟なままのような気もします。

ストレス対処法

私はよく「仕事でストレス溜まらないんですね」と言われる方なのですが、なぜそうなのか？

理由を聞かれると「ダメだったら、契約解除、クビにしてもらえばいいから」と答えています。

その答えを聞くと、ビックリする方が多いのですが、本当にそのような気持ちでいます。

このような気持ちでいられるのも、仕事はたくさんあるから。

何も評価されない相手と無理に付き合わなくても、評価してくれる、活躍してくれる場は世の中に転がっています。

というカラクリなのですが、これって経験を積んで自信をつけないとなかなか思うことは難しいですよね。

ということで、若かりし新人の時に、ストレスを溜めないよう考えていたことがこちら。

しょせん仕事。

どういうことかというと、地方クライアントの仕事をしていたある日のこと。

仕事を終えて、帰る際に離陸をした飛行機の窓から外を見ると、眼下にクライアントオフィスが見えました。

ああ、あんなちっぽけな場所で行われていることなんだ。。。

世界は広く大きい。

そう思うと、悩んだり苦しんだりすることが馬鹿馬鹿しくなってきました。

というキッカケから、経験と実績を積んでいくことで、冒頭のような考えに繋がっていったのだと思います。

ということで、ストレス対処にはいいのですが、一方で、会社を大きくしていく、世の中にインパクトを与えていくという視点から見ると、また違った悩みがあって、これはまた機会があれば。

スキルとテクニック

スキルとテクニックの違いって何でしょうか？

言葉の定義をしないと会話にならないことは重々承知の上、そこまで固い話をしようとは思っていないので、ライトにいきます。

自分が過去に身に付けたテクニックで今も十分使えているものは何だろう？

自分が過去に身に付けたスキルで今も十分使えているものは何だろう？

このように問いかけた時に、テクニックが陳腐化していることが多いのは気のせいでしょうか？

テクニックはテクノロジーの進化で代替できていることが多いような・・・。

ということで、言葉の定義をしなくても何となーく自分が身に付けたものをスキルとテクニックに振り分けて見てみると、 面白い発見があるかもしれません。

温故知新

社会人生活が長くなり、10年20年単位で語れるようになってくると、世の中のトレンドも一周回って過去に経験してきたことが流行りだすような感覚が最近あります。

それが何で、どうなるんだと細かい話をしろと言われると困るのですが、何となく感覚として新しいようで、どこか懐かしいような。

もしかすると本質的に同じもので、トレンドがどうこうというのは関係ないものかもしれません。

もしかすると、これまでの経験の積み重ねが、新しいものに対して臆することなく対応できているだけなのかもしれません。

これが歳を重ねることなのかもなあと思いながら、新しいことにはチャレンジしていきたいです。

 

コミュニケーションの変化

コロナのおかげで、忘年会、新年会、歓送迎会といった類に全く呼ばれなくなった＆開催されなくなって、しばらく経ちますが、その間、仕事にどのような影響があったか、改めて振り返ってみました。

結果、個人的には全く影響ないなと。

元々、そういった場所でコミュニケーションを取るタイプではないことが主な要因だと思います。

従って、飲みニケーションは不要だとか、そういうことを言うつもりはなく、むしろ今まで飲み会を重視していた方が、この変化にどう対応していったのか、そちらに興味があったりします。

これは在宅ワークが増えたこととも関係するかもですが、コミュニケーションのやり方・手段の変化がどう影響したのか？

個人的には、よりアウトプット・成果物を意識するようになっています。

直接、顔を合わさないリモートとなると、何で評価されるのか？

そこを意識すると、アウトプットで評価してもらうしかなく、そこは以前と比較して強調するようになっています。

とはいえ、一度も対面であったことなく、先方が顔出しNGで、その顔もわからず、声だけで仕事を進めて終わってしまう・・・というのも、なかなか面白いですよね。

あけましておめでとうございます。

あけましておめでとうございます。

今年も、無事挨拶できました。

多くの方に喜ばれるような仕事ができるよう頑張っていきたいと思います。

ジョブディスクリプションの必要性

ジョブディスクリプションと言う言葉は知っていますでしょうか？

ざっくり言うと職務の内容を詳しく記述した文書のことですが、これがあるのと、ないのとでどう違ってくるのでしょうか？

あまり日本企業が外資がと言うつもりはないのですが、総合職的なゼネラリスト的な人材が活躍している会社とプロジェクトを行うと、割とジョブディスクリプションが曖昧で進んでいるような気がしています。

そうした時にどうなっているのかというと、みんな気が利いて周りを良く見て仕事をしています。

自分の責任範囲が曖昧のため、周辺の関連する仕事を気が付いた人がやると言った文化、進め方だったりします。

気が利くので、とても仕事が出来る感じがします。

その人にどんどん仕事が集まっていきます。
人に仕事が張り付くイメージです。

と、個人で見ると、とても良いのですが、仕事の規模感が大きくなると、どうなるのか？

自分ができる範囲は限られるので、どうしても他の人達と連携する必要が出てきます。

誰が何をやるのか定義が事前にされているわけではないので、進めようとすると、結果として人の重なりが増えます。
つながりが見えにくいため、全体像を把握するために、多くの人を集めなければならなくなる。

とならないように、ドキュメント化が大事だよねと言うのは簡単ですが、実際には難しい。
なぜならば書いたり残したりするインセンティブが直接的にはないからです。

裁量や責任が明確ではないため、自分がやりたいことをどんどん行う、スキルを身に付けるには良い環境なのかもしれませんが、一方で、裁量や責任が明確ではないと言うことは評価が難しいとも言えます。

その辺のバランスも含めて、組織のあり方って正解はないですね。

ドキュメント化の重要性

最近ドキュメント化の重要性を痛感したので、備忘として書き記しておこうと思います。

と言いつつ、正確に言うと、ドキュメント化とテンプレート化の2つだったりします。

システム開発において、ドキュメントって大事ですよね。

そのシステムがどのようなものなのか、データフロー図であったり、データベースの設計書であったり。

クラウドサービスが主流となる中、自社開発を行わないのであれば、実はあまり意識をしなくても良い所かもしれません。

そして、ドキュメント化なんて当たり前のことで、何を今更って感じですよね。

では、なぜ今回、その当たり前を書き記しておこうと思ったのか？

それは素晴らしいコンセプトも形になっていなければ全く意味がないと思ったからです。

データの流れとかデータベースって、放っておくと、どんどん肥大化、複雑化していきます。

そうならないような素晴らしいコンセプト、思想、方針があったとします。

が、この方針も、ドキュメントを作って、形に残していかないと結局、肥大化、複雑化していってしまう。

（肥大化、複雑化していくってことは、そもそものコンセプトがいけてないからじゃない？と言う疑問もあるかもしれないですが・・・。）

ということで、様々な人が形に残していくのですが、ドキュメントがテンプレート化して共有されていないと、十人十色のドキュメントが出てきて、どれが正しいのかわからなくなってしまう。

システムってゼロイチの世界で曖昧さがない世界のはずなのに、何だかわからない。。。

と言う興味深い現象が起こったりします。

そうなると、どうなるか？

ドキュメントではなく、それを知っている（担当している）人達が、正しい（内容が理解できる）人となり、開発・保守がベンダー固定になってしまったり、その人がいなくなった途端、誰も理解できない状態になり、バグ潰しや、アップグレードの難易度が上がってしまったり・・・みたいな未来が想像されます。

ということで、当たり前を当たり前に行なっていく大切さを改めて書き残しておきました。

パソコンに見る社風

いろいろな会社と一緒に仕事を行なってきて、一つ感じることがあります。

それは使っているPC端末に社風が表れるなあと。

弘法筆を選ばずという言葉がありますが、端末は馬車と車ぐらい進化の激しいものだと思います。

さらにクラウドサービスと繋げると、その効果、効率性は大きく異なります。

従って、どの端末を選定するか、どのクラウドサービスを利用しているかなどに個性が出てきます。

レンタル品で安いのはいいが、すぐにキーボードが壊れてしまう。

メモリが低くて処理が遅いので、複数端末で同時利用している。

常にその時の最新版を購入して、快適利用。

学習コストはかかるが、常に最新のクラウドサービスを利用して効率化。

と、先端を走る会社と、そうでない会社の動きは思った以上に大きいです。

とは言え、どの会社もなくなってきたなあというものもあります。

・人数分、印刷しての会議（パワポやエクセルの印刷書式の設定とは？？？印刷自体、久しく行っていないので、ドライバインストールなどのあれやこれ、トラブル関連がなくなりました。）

・版管理（これはまだ完全になくなっていないですが、例えばGoogleスライド、スプレッドシートなどを利用する会社であれば、版はGoogleさんが全部管理してくれる＆デグレのトラブルも随分なくなりました。）

・メールでのやりとり（ファイルのやりとりに関連するあれやこれやの問題もあるので、今はチャットサービスでグループを作ってやりとり。ファイルはクラウドストレージで共有。これもまだ完全にはなくなっていないですが、最初や最後の挨拶など冗長なやりとりがなくなってきているのは良い兆し）

と、簡単に何個か挙げてみましたが、このように記録に残しておいて、数年後、読み返してみると、そのギャップがとても面白いです。

自責と他責

何か嫌なことがあった時に誰かのせいにしたくなりますよね？

そのような時にちょっとした自己啓発書には、他責ではなく自責で考えてみよう・・・みたいなポジティブシンキングが提示されていたりします。

おそらくそれは正解だとは思うのですが、個人的にはもう少し踏み込んで考えるのもアリかなと思っています。

それは、感情ではなく、行動にフォーカスすることです。

感情の問題なので、ぶっちゃけ他人のせいにして大いに怒り狂ってもいいのかなと。

ただ、その怒りのままだと、同じことは繰り返されるし、結果も変わらない。

従って、感情は赴くままでいいが、同じ結果にならないように、自分には何ができるか考えてみる、そして行動してみる・・・のが大事だと思います。

というのを、他責ではなく、自責で考えた結果、自分が悪い、自分のせいだ・・・と、一人で勝手に落ち込んで、何もできなくなっている人を慰めながら、気が付きました。

人材の底上げ

個人的に感じていることですが、もし自分が試行錯誤や努力をして、今のスキルや立場などを手に入れたとしたら、後に続く人に同じことを強要したらいけないと思っています。

強要というと言葉が悪いですが、自分の経験をもとに、どうすればうまくいくか・・・という説明も、もしかしたら良いことではないかもしれない。（つまりアドバイスも・・・です。）

そう感じたのは、再現性の視点からです。

アドバイスやコツを聞かれたりする・・・としたら、それは成功しているからとなります。

その成功は誰でも実現できるのか？

実現できる人が少ないから、目立つし、アドバイスやコツを求められるのではないか？

となると、伝えるべきは、そのまま自分が取り組んだことではなく、自分がやったことよりもより早く、より確実に再現できるようにすることではないか？

試行錯誤や努力をしたからこそ、知っていることを仕組みやノウハウとして構築するべきではないか？

と考えていたりします。

一方で、秘伝のタレみたいな隠すことは何もないので、アドバイスを求められた時に、無邪気にそのまま答えてしまう自分もいたりするのですが、なかなか深いテーマだったりします。

何を持って売上をあげるか？

最近のトレンドと言うべきなのか、様々なサービスを見ていて感じるのは、以前は、モノを所有する、購入することでお金をもらっていたのが、今は、そのモノを使って得られる価値に対してお金をもらう・・・というものが増えてきています。

（わかりやすいもので言えば、レンタルやシェアリング系のサービスの価値はこの辺りですよね。）

となると、Webサービスなどで、システム機能について顧客要望があがってくるのは、よっぽどのこと・・・と考えるのは競争優位を作る上で一つの視点として持っていても面白いかもしれません。

顧客要望があがってくると言うことは、使用することによって得られる価値にお金を払っているのに、その使用ができない・・・と言えます。

となると、普段からお客様がどのように使用しているのか、何に価値を感じているのか、何に困っているのか・・・とお客様の立場を考えざるを得なくなります。

これって素晴らしい取り組みですよね。

お客様目線を忘れないように。

（と言わないとできないのではなく、言われなくても自然とやっているようにならないと・・・ですね。）

言行一致の難しさ

元々、役職に関係なく「さん」付けで呼び合う会社で仕事をしていることが多かったせいか、「弊社は役職に関係なく、「さん」づけで呼び合うくらいフランクな会社です」みたいな案内をしているような会社にいくと、ちょっとした違和感を感じることがあります。

本当にフランクではなく「意識して」フランクな状態であるため、仕事をしていると、役職を意識して発言したり、しなかったり、忖度したり、しなかったりと風通しが良くないことを感じることがありました。

言われなくても自然とできていることが、その会社の本当の強みと考えると「経営者意識を持って考えよう」みたいな声がけは、自分達の現在地と目指す方向性を示すと言う意味で、言い続ける＆実施のチャレンジを続けていく必要性があるなと強く感じました。

当事者意識を持った仕事ぶりの危険性

今まで、こんな場面に出会ったことはありませんでしょうか？

仕事でちょっとしたミスがあった時に・・・

「もっと当事者意識を持って仕事をすれば防げたはず・・・。」

もし自分がミスした時に、そう思っていたり、誰かがミスをした時に、このような注意をしていたら、個人的にはとても危険だと思います。

なぜ危険なのか？

それは、品質が全く安定しないからです。

意識で品質が変わる・・・と言うことは仕組みができていない証拠。

個人的に過去に経験したのは、当事者意識がとても高い方が、当事者意識を持っていないようなミスをしていたことでした。

なぜそのようなミスをしてしまったのか？

理由はとても簡単。単純に多忙で、周りを見る余裕がなかったからです。

普段、しっかりしている方でも疲れて疲労が溜まるとミスをする。

当たり前のことが起こったまでです。

これを本人の意識が足りないと叱責するのは、責任者の立場からすると簡単ですが、言われた本人にしてみれば、納得もいかないし、やる気も削がれてしまいます。（という悲しい場面を見てしまったことがあります。）

だからこそ、ミスが起こらないチェック体制や、仕事が集中しない組織体制、役割分担、業務分解などなど、責任者にはやることがたくさんありますよね。

ROI重視の開発

間近で見ていて思う所があったので、記録に残しておきます。

例えばクラウドサービスを提供していて、新機能を追加する際に、どのような基準で決めるといいでしょうか？

一つの決め方としてROIがあるかと思います。

投資した額を上回るリターンがあればGoというやつです。

シンプルでわかりやすいですよね？

が、この基準、法人サービスの場合だとしたら、どうでしょう？

売上の大きい会社の声が反映されがち。

ということで、その声を拾い続けた結果、クラウドサービスがその会社独自の色が付いて整合性が付かなくなり、とても使い勝手が悪いものになっていました。

また、売上の大きくない会社を担当している人達が、なんとか顧客要望を反映させようとして必死に開発メンバーやマネジメント層を巻き込んで頑張っていました。

ただやはりROIという一言で終わってしまい、反映されず。

社内では、色々な意見は言える風通しは良かったかもしれませんが、諦めみたいなムードもあり、正直、空気は良くありません。

・・・みたいな会社がある一方、顧客が要望をあげる前に、機能改善をどんどん進めてフィードバックをもらっている会社がありました。

こちらは、要望をもらって開発というよりも、開発結果の評価（フィードバッグ）をしてもらう感じです。

前者がROIの妥当性を・・・と検討を続けていて、顧客目線で見ると、機能が一向に変わらない一方、後者は常に変化がある。（そして顧客要望で良い方向に変化していく）

当然、後者はハズレの開発をしてしまう可能性が高いので、確実にいくには前者なのですが、顧客全員の満足度や、社内の雰囲気などを見ると、進むべきは後者なのかなと思っています。

後者の開発も、失敗を繰り返すことで顧客の勘所が掴めるようになり精度がどんどん上がっていっていました。

時代の変化に対応できる組織という意味でも、机上であれこれ言うだけの時間をどれだけ減らせるかと言うのは見逃せないポイントだと思っています。

新しいクラウドサービスを利用した方がいい理由

最近、何社かのクラウドサービスを利用してきて、新しいクラウドサービスはどんどん利用した方がいいかなと考えています。

今回はなぜそう思ったのか、ざっくりと理由を残しておきます。

理由は

・基本的にこれまでの問題、課題、不便、不満などを解決したものだから

既存サービスをアップデートしたものが多いので、学習コスト、スイッチングコストを上回るメリットがあることが多いです。

・サポートが充実している

カスタマーサクセス担当なる人がいたり、サポートが至れり尽くせりだったりします。

・初期ユーザーとして、文句や要望が言える

先ほどのカスタマーサクセスと関連していますが、成功事例がないと、そのサービスは次がありません。

なので、真摯に話を聞いたり対応してくれることが多いです。

・初期割引が受けられる

事例として出るから、費用を下げて・・・も含めて、色々と割引してもらうことも多いです。

と、こちらのメリットばかり書きましたが、何となく、同じチームとして、サービス利用によるメリットの最大化を目指していく感じでしょうか？

ということで、次はどんなサービスを利用するのか、ワクワクです。

新しいインプットとアウトプットのやり方

ブログを10年、15年と長くやっていると過去の記事がとても懐かしいです。

その頃は動画なんて信じられませんが、今や動画は当たり前。

ということで、入力方法もキーボード入力よりも音声入力の方が早い、正確なものになりつつある（プライベートでのLINEやメッセージは今や音声入力のみだったりします。）ことを考えると、仕事で情報を共有する方法も文字よりも音声や動画の方が早くて確実＆情報量も多かったりするのかなと考え始めています。

その新しい方法を共有できる相手と、できない相手がいるので、これが正解みたいな話にはならないのですが、新しい方法を試してみる価値はありそうなので、取り組んでみようと思います。

明けまして、おめでとうございます

明けまして、おめでとうございます。

本年もよろしくお願いします。

一年の計は元旦にあり・・・とは、使い古された言葉ですが、新たな気持ちでいるのも事実です。

今年も頑張っていきます。

生産性の高さと業績の関係

ある仕事で・・・

ファイルサーバーにファイルがあります。

編集しようとファイルを開けると、誰かが編集中で編集できません。

仕方なく、ファイルをコピーし、編集。後でファイルをマージする。。。

・・・このような経験、今でもしていますでしょうか？？？

実は、お客様によって、このような経験をすることがあり、個人的な印象として、こんな単純なことでも生産性で差が付いているなあと感じます。

生産性が高い会社は、そんなことはしなくて、クラウド上で同時編集をしています。

（なので、個人的には、生産性の高い会社とやりとりする方が仕事に集中できるので、好きです。）

面白いのは、その生産性と業績は関係がないこと。

生産性が高い会社の方が、業界の競争が激しくて、生産性が高くないと生き残れない・・・一方、生産性が高くない会社は規制産業でそこまで厳しくない・・・従って、そこまでやる必要がない・・・みたいな構図があったりします。

そして、生産性を挙げたからと言って業績が上がるかというと、そこも怪しそう・・・となると、ますますやる必要性がなかったりします。

（クラウド移行でサービス利用料がかかって利益ベースで見ると、よろしくなかったりするかも。）

と言いつつ、はっきり言えることは、生産性が上がれば、早く帰れてワークライフバランスは取れる（社員の満足度や健康経営には寄与しそうなんですけどね。）

ポスト資本主義・・・という流れから考えると、生産性は上げていった方がいいだろうなあとは思います。

何をやっているかわかる？わからない？

複数会社の複数プロジェクトを見ていると、単純な比較として、同じ種類の資料を見た時に何をやっているのかわかりやすい会社と、わかりにくい会社があります。（特に計画や方針など未来の話になると、その傾向が強くなったり・・・。）

その違いを今回は残しておこうと思っています。

早速ですが、わかりやすい、わかりにくいの違いは何か？

それは「形容詞・形容動詞の多さ」です。

形容詞・形容動詞の表現が多い会社はわかりにくい。

一方、少ない会社はわかりやすく、また形容詞の代わりとして、数字が使われています。

簡単な例だと・・・。

＜多い＞
・早急に対応する。（早急っていつやねん？）

＜少ない＞
・12日までに対応する。

みたいな感じです。

文章にすると、さもありなんですが、資料ではなく会話でのやりとりになると、この傾向はさらに顕著になったりします。

ということが起こりがちなので、意識して会話する・・・というよりも、資料のフォーマットでその曖昧さをなくしましょう・・・みたいな感じです。

推進プロジェクトを用意しなくても推進する方法

 例え話として、よくこんな話をします。

「私達は社内で役職関係なく「さん」付けで呼び合っているので、風通しがいいですよ」という会社は、めっちゃ縦意識が強い。

本当に風通しがいいところは、そんなの気にしないで普通に「さん」付けで呼び合っている。

・・・という実感を、いろいろな会社を見てきて感じるので、本当に強い会社は、xx推進プロジェクト、社内変革プロジェクト・・・みたいなものを立ち上げて推進するのではなく、自然と普段の業務の中で、そのようなことをやっている・・・みたいな話をします。

また実際に、普段の業務でやっている会社は「xx推進・・・なんて言っている時点で負けなんだよね・・・」と言っていたり・・・。

では、この両社での違いは何なんでしょうか？

社風ではなく、できている会社と、できていない会社で大きく異なる違いが1点あります。

ということで、今回はその違いを残しておこうと思います。

早速ですが、違いは何か？

それは・・・「お客様のことを見ているか否か？」です。

会社の置かれている状況によって表現や立ち位置は若干異なっているのですが、概ね、できている会社は、お客様主体で会社が運営されています。

例えば・・・

業界の競争が激しく、お客様の声に応え続けていかないとダメになってしまう・・・となると、いやでも変わっていかないといけない。

例えば・・・

カスタマーサクセスが、売上の肝となるサービスを展開している（サブスク系の本質はここですよね）。

などなど。

簡単に言ってしまうと・・・

自社はお客様にどのように評価されているか？（なぜ他社ではなく、自社を選んでくれているのか？）

が答えられるかどうかが、一つの指標になっています。

外の空気に、非常に敏感であるため、できていない会社を見てしまうと、ついつい「緩いなあ」「平和だな」「外に敏感でなくても商売が成り立ってしまうのは、それはそれですごいなあ」と思ってしまう悪い自分がいたりします。

では、できていない会社が悪いのか・・・というと全くそういう話ではなく、意識を変えるというより行動によって環境や意識を変えていく・・・というのが自然な流れであることを考えると、xx推進プロジェクトが立ち上がって行動しているのは、何ら問題ありません。

先ほど書いた通り、結局は置かれている環境によって優先度、重要度の違いから、このような進め方になっている・・・とも言えます。

ただ、どちらが長生きできそうか・・・というと、考えちゃいますよね？

メンバーアサインの難しさ

 メンバーの採用、難しさというのは、永遠に付き纏うのかなあ、正解やゴールはないなあというのは感じていますが、何となく思ったことを整理しておいて、少しでもゴールっぽいものに近づけておこうと、雑感を記述します。

よく採用では「自分より優秀な人を採用せよ」という話も聞かれますが、これが難しい。

これまで生き抜くために、頑張ってくればくるほど、自分はブルーオーシャンにいるはず。

そのブルーオーシャンを超える人・・・というのは難しいよね。（心理的にも、認めるのが難しかったり・・・。）

また、自分より優秀な人・・・ということで、比較しようとすると、どうしても自分が知っている領域に限られます。

となると・・・

比較するなら、具体的な事実ベースで。実績をみる。

比較するというより、自分達が仕事として、求めている結果を明確にし、それができる実績を持った人にする・・・みたいな、意見・印象よりも実績を見る形が良さそうです。

・・・というのと、最近「自分より優秀・・・」よりも「自分の子供を任せたいか（その人の元で働かせたいか）・・・」という思考実験で見た方が、色々とわかる（自分的に納得できる）ような気がしています。

そして何より間違えないようにするのは、白黒を付けるというより、かかるコストも含め、どうすれば組織・チームとして結果の最大化がなされるかということ。

人の優劣を付ける・・・みたいな視点だと、見誤ってしまうなあと思っています。

相手に受け入れられやすいアドバイスの仕方

最近、相手に何かアドバイスを求められている時に意識していて、比較的、良い結果につながっているかなと思うことを備忘録として書いておきます。

それは、アドバイスする時の考え方や伝え方です。

以前はアドバイスを求められた時に、相手のためを思って「こうすべき」「こうしたら？」みたいな話をしていました。

もちろん相手も喜んでくれて、良いアドバイスができたなあと思っていたりしたのですが、結果として、そのアドバイスが実行されることなく・・・みたいな残念な場面が多かったです。

そこで、やり方をちょっと変えてみました。

相手の立場に立って、あるべき姿とのギャップを一緒に見るようにしてあげたのです。

その後にそのギャップを埋めるために、何ができるか一緒に考えてみる。

すると、そのアクションを実行する場面が多くなりました。

ここまでの話をそれっぽくまとめると・・・。

ToBe：「相手のためを思って」べき論→正論なので、反論することができない（説得アプローチ）

AsIs：「相手の立場に立って」ToBeとのFit&Gapを行う→共感が得られやすい（納得アプローチ）

後者の方が、手間や時間がかかるのですが、当事者意識を持ってもらいやすいため、結果が出ることが多いです。

また、会話も前者は、こちらが話すことが多いですが、後者は相手が話す形になり、その辺も本人の頭の整理や、当事者意識に繋がりやすい要素かなと思っています。

ここまで書いてきて、圧倒的に後者が正解・・・みたいな感じになっていますが、実際に前者で話をして、即実行→圧倒的な結果を残す・・・という実例も何個かあったりするので、結局は相手をよく見て使い分けるのが肝要だなと痛感しています。

マネジメントに求められるスキル

最近強く痛感するのは、マネジメントは数字に強くないとダメだなあということです。

もう少し具体的に言うと、ダッシュボートというか経営の数字に強くないとダメだなと。

それなりの立場にいるので、数字に弱いわけではないのですが、社員にレポート資料を作らせて報告するのではなく、自らシステムで確認するのがちょうど良いと。

リアルタイムで数字が掴めるし、何よりレポート資料を作成する手間がない。

これが資料を作らせるとなると、資料作成→内部レビュー→修正→報告…と多くの社員の時間を取る事になります。

そのような時間を取るぐらいなら、外＝お客様に目を向け行動してもらった方が余程良い。

これ、意外とできているようで、できていない企業の方が多いのではないかなと思います。

生産性を上げる、ちょっとした方法

生産性を上げる方法と言えば、いろいろあるかと思いますが、ちょっとした方法を一つ挙げておく事にします。

それは何かと言うと、その仕事を始める時に「まずは終わりの時間を決める」ということ。

誰がやってもできるような仕事では当てはまらないのですが、自分だからこそ出せる付加価値みたいな仕事、頭に汗をかくような企画的な仕事、アウトプットが求められるものが対象です。

これはどういうことかというと、仕事を進めていくと、だんだんとわかってきて（検討が進んできて）、あれもやらなきゃ、これもやらなきゃと勝手に仕事を見つけちゃうので、そこでズルズルいかないよう区切りを意識しましょうというお話です。

ちょっとした意識付けではあるのですが、個人的には大きな効果が出ていたりします。

（本当は具体例で説明した方が腹落ち感があるとは思うのですが、実例は出しにくい、一般的な例だと、誰がやってもできる仕事になってしまうので難しく。このエントリは自分向けの備忘録になってしまっていますね。すみません。。。）

メッセージを伝える際に気を付けること

今更ながらではあるのですが、当たり前のことを痛感したので、形に残しておくことにします。

それは何かと言うと「伝えたい順と、伝わる順は違う」ということ。

HPなどを作成していると、いろいろ伝えたい要素があります。

その際にどうしても、自分達が推したいことを先に述べがち。。。

一方、サイト訪問者にとっては初見の場合、前提となる情報を持っていないので、頭が「？」になってしまうわけです。

みたいなサイト構成案を見て、気を付けないといけないなあと。

主語が「自分」より「相手」であること。

相手の立場に立つこと。

自分達の想いが大切なのもわかりますが、それが鬱陶しく感じられないようにするためにも伝わる順番を意識していきたいです。

任せると言うこと・・・

ふとblogシステムの下書きを見た所、公開されていないコンテンツがそこそこありました。

中身を見ると一応、最後まで書いてあるように見えます。
ということで、せっかくなので、それを公開していこうかなと思います。

（2006年10月ごろに書いたと思われる下書き）
-------

メンバーをリーダーにする時、どのように考えるか？

結果を出していることは、もちろん必要かもしれない。
（アイツがリーダーをやるのは結果を出しているから当然だ・・・という空気がないと。）

しかし、その結果を出しているメンバーがリーダーとしてふさわしいかどうかとなると、全く別の問題となる。

リーダーはメンバーを纏める必要があるので、今までと異なるスキルが必要となる。

つまり、スキルセットで今まで結果を出してきたのだが、リーダーに求められるのはマインドセット。

スキルセットでは皆に認められたのだから、今後はマインドセットをしっかりと示さなければならない。

ここで、会社のトップとして、どのようにしてマインドセットがあるかどうか見極めているか？

その1つとしてある質問をしている。

それは、

「リーダー候補に、自分の子供を任せることができるだろうか？」という質問。

それって、主観的かつ自己中心的な考え方では？

という声があるかもしれないが、自分の可愛い子供を任せても安心ならば大丈夫・・という単純な話ではない。

会社に集まってくるメンバーは、とても貴重な人材。

自分の子供ではないからこそ、自分の子供以上に大切に扱ってあげることが必要だと思っている。

だからこそ、自分の子供を最低水準にして考えてみる。

最低水準である自分の子供を任せても安心できないならば、人の子供を任せるなんて、とてもではないができない・・・という考え方。

とは言え、”自覚”が芽生えることで、任せることができるようになるので、大切なことは、バランスの取れた昇格、降格の仕組と公正な評価。

もちろん前提条件として、このような取組ができるだけのビジネスモデルと企業体力。
ここはトップの仕事だから、言い訳はできない。