理屈で説得ではなくて、行動で感化させる
成功するためには、できない理由を考えるよりどうしたらやれるのか考えること、そして失敗することを恐れずにチャレンジすることが、大事だと思っています。
もちろん、どう考えても計算があわないことを精神論で取り組むべきではありません。とはいえ、成功するためには、精度の高いオペレーションだけではダメです。不確実性があることにチャレンジするからリターンがあるのです。
不確実性性を乗り越えるには、頭と足を使い目の前に現れる課題を解決し続ける必要があります。成功するためには、課題がないことではなくて、課題を解決することが、大事な仕事です。
ただし、そんな理屈を話すことよりも、経営者である自分が、目の前に現れる課題にワクワクして取り組んで望み、みんなが自然に感化されて行くことが大事なのではないかと、最近思うことがありました。
もし言い訳が周りに多いいのだとすると、まずは自らがワクワクと取り組む姿勢を見せて行きたいものです。
クソはクソだという文化
ダメなサービス、プロダクト、ソースコード、仕事のやり方を、クソだと指摘する文化、指摘を気持ちよく受け止める文化を作りたいです。
そして個人攻撃は絶対にせずに、最高のサービス、プロダクト、ソースコード、仕事のやり方へ、一緒に改善したいという前向きな気持ちで言う文化にしたいです。
そして、どんなに頑張って作ったサービス、プロダクト、ソースコード、仕事のやり方でも、クソだと指摘された時に、喜んで指摘が聞けて、一緒に改善していける文化にしたいです。
会社というのは、効果的な仕事のやり方、考え抜かれたソースコード、価値を提供できるサービスやプロダクトがあって、お客さまからお金をいただけるものです。まただから、みんなに手厚くお金を配分できるものです。
部下や上司や同僚の目を気にして、クソがあることを指摘せずに、お客さまの目の前にクソがそびえ立つままにして、みんなの未来はあるわけない。
とにかく、社長こそが、内向きにならず、使う人の視点で、クソは見つけられる人でありたいです。
チャンス&チャレンジ
ディレクションをすると、正しい可能性はあるが正しいかどうか確実ではないことは避けてしまうのに、明らかに正しくないことを選んだり続けてしまったりすることがあります。
ビジネスは一般論的な確実性が低いものほどちゃんとやれば大きなチャンスがあります。ただ、人間は未知のものには怖さを感じるので、つい避けてしまいます。
ビジネスの基本は、まだ誰も顧客のニーズをちゃんと解決しきれていないことを、ちゃんと解決してあげることにつきると思っています。
特にリソースが少ない組織には、ニーズがまだ顕在化できていない、ニーズを解決できる決定打が出ていない、という不確定な状況にこそ、勝ち可能性があるのだと思っています。
ちょっと計算すると明らかに間違えた戦略をとってしまう要因の一つは、慣れ親しんだ分野ややり方に固執しているからだと思っています。
いつになってもチャンスを見極めて常にチャレンジしていきたいと考えています。
社長の、会社内の、人間関係
事業形態・社長のパーソナリティによるものとあるとは思いますが、社長と社内のメンバーの人間関係は、ウェットにせずに、距離感があった方がいいと思っています。
例えて言うならば、プライベートでは一切付き合わずに仲が悪いように見えるお笑い芸人のコンビが、舞台では絶妙なボケとツッコミのチームワークを見せるのが理想だと思っています。
毎日飲みに行くような仲の良さは、逆にお互いの甘えや依存を生み出す。さらには、言うべきことが言いあえなくなる可能性があります。
社内で必要なのは、友だち感覚な仲の良さではなくて、プライベートでは適切な距離感をとり、仕事上では指摘すべきことが、しっかり指摘しあえることだと思っています。
また、いくら距離感を作って言うべきことが言いあえる人間関係が作れてても、会社内の人間関係は、役割や上下関係から逃れられないし、同じ場所で同じ視点で見ている者同士なので、視野が狭まり浅くなり、経営判断のミスにつながると思っています。
なので、社外役員や、株主や、顧問や、ブレーンなど、少し利害関係はあるが、あくまでも対等な人間関係を、さらに広げていきたいと思っております。
エンジニアとしてのファーストステップ
エンジニアとして成長するには、まず、たくさん手を動かすこと、次に全体を把握して引き出しを増やすこと、最後にパイプライン全体をエンジニアリングの対象として捉えることだと思っています。
まず、初心者が成長するためのファーストステップは、ひたすらコードを書く。見よう見まねでいいし、大したことがないものでいいので、手を動かしてコードを書くのが、おススメです。
本でも、イーラーニングでも、なんでもいいので、チュートリアルを見ながら、写経をしてコードを書く。そして、ビルドと実行をする。可能な限り、コピペではなくて、写経したいです。また、量が多くてコピペする際は、自分のプロジェクトの命名規則にあった形に修正してみてください。
写経してビルドして実行したコードはかなりの確率でエラーが出ます。ここからが大事です。サンプルと自分のコードをにらめっこして間違いを探す。自分の入力エラーを見つけて修正して、ちゃんと動作するようにすることが、大事です。
この繰り返しで、エラーにびっくりせずに、エラーが起きても自分の入力間違いかもしれないと思えて、根気よく自分のコードとにらめっこできる習慣をつけられます。
仕事の見える化
先週から毎日の仕事を数値で見える化してます。時間・重要度・緊急度・進捗を入力して、適当な計算式で評価ポイントを算出。一日の評価ポイントの合計を出して、今日は進んだなーとか、進まなかったなーと言いうのを見ています。
見える化といっても、完璧なログを取っているわけではなく、ある程度雑な感じでとっています。完璧にやろうとすると続けられなくなるので！
見える化をやってよかったのは、重要な仕事へ時間を使うことが多くなったことです。
どうしても、周りから投げられる重要度は高くないが、緊急度が高い案件に振り回されて、一日があっという間に終わることが多かったのが、かなり改善されたと感じています。
新しいプロジェクト頑張るぞ！
会議の質をあげる
チームに必要なコミュニケーション
今日、週次のマネージャー会議をしましたが、まだまだ生産性に課題があります。
以前禅太郎さんに「すごい会議」をコーチングしてもらったことがあります。
時間がかかって中身のない会議と、短い時間で意味がある会議の違いは、明確化のための質問・リクエスト・代替案の提示の三つのコミュニケーションに絞られているか、それともそれ以外の曖昧なコミュニケーションにあふれているかにかかっているようです。
参考資料: http://zakkicho.g.hatena.ne.jp/task/19/42
個人的には、普段の会議であれば、それに一つ追加&優先順位をつけて四つのコミュニケーションが必要だと思っています。
- 問題の浮き彫り化
- リソースかアクションのリクエスト
- 目標を達成するための代替案の提案
- 5W2Hを明確化するための質問
問題の浮き彫り化
予算と実績、方針と実情、認識と現実、戦略と現場、ルールと実際などの理想と現実の乖離を、見て見ぬ振りをせずに、気がついた人が、気がついた時に、速やかに言うことが大事だと思っています。
ダメなことをダメと指摘しない。ダメなことを指摘されると空気が悪くなるチームは絶対にうまくいかない。
リソースかアクションのリクエスト
相手に空気を読ませて、もしくは今どき風に言うと忖度させるのは最悪。ヒト（時間）・モノ・カネのリソースを相手に要求するか、相手に何をしてもらいたいか明確なリクエストをすることが大事だと思っています。
目標を達成するための代替案の提案
会議で時間を取る以上、目標の達成につながる、問題解決につながるアイデアの出しあいが大事です。
また、アイデアも漠然としたコンセプトや夢ではなくて、前に書いた現実的なリクエストである必要があると思います。
他人のリクエストに対しては、ジャッジ、意見や否定することではなくて、対案を出すことが大事です。
5W2Hを明確化するための質問
質問の形した持論の語りや、空気読みの強制は、チームの中の誤解が生まれたり、なんの解決策が明確に至らないまま会議のやった感で終わったりします。
質問する際は、誰か、何か、なぜか、いつまでか、どこか、いくらか、どのようにかを、具体的に明確にすることが重要だと思っています。
