最重要
- 実行に重きを置く
- やらないで後悔するよりも、やって反省する。
- 反省は成長を産み生産的だが、後悔は精神の無駄な消費。
- 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。
- 正しい反省の方法とは何か、考え続けること。
- 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。
- 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。
- Done is Better Than Perfect
- ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。
- 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意識する。
- 「やる内容」ではなく「たどり着くべき結果」が大切だということを忘れないために、問題の特定と問題解決の実行にフェーズの概念を持ち込む。やりたいから仕事をやるのではなく、解決するにはこの仕事をやるべきだからやる、ということをチーム全員で意識する。
- いつでも行動を取れるよう、自己を印象づけておきつつ周囲との繋がりを育てておく。
- ひとりで完結する仕事はない。
- やらないで後悔するよりも、やって反省する。
人との交わり方
-
推測の扱い
- 議論の仮説にできる「建設的な推測」と根拠の無い「不安や期待」を分けて扱う。
- 議論の仮説はあくまでも「仮説」であり、「前提」ではない。状況に応じてアップデートされるべき。
- 不安や期待は上司あるいは信頼できる人に1on1で話す。それ以外の人と場所には話さない。マネジメントに限らず後輩を持つ身なら意識したい/させたいポイント。
- 不安はコミュニケーション不足を表すシグナルであることが多い。
-
ヒューマンスキル
- という、横文字に惑わされないこと。「みんなが幸せ」になるにはどうするか考えて行動しようという話。それだけ。
- 「幸せの定義」「何をもって満足するか」「情報の非対称性」「優先度の違い」「面子」「私生活」などなど様々な変数が絡むのでわかりにくくなる。
- 私は年上・目上に対して(本人にその気はないのに)面子を潰しに行く傾向にあるので自重する。日本人に対するコミュニケーションが下手だ(要らん遠慮をする)という説もある。
エンジニアとしての心構え
-
技術的・ビジネス的な流行り廃りとのつきあいかた
武器を増やすための研究は個人で、武器を磨くための追求は仕事で
- 課題はそれの解決に必要な武器を教えてくれない(教えてくれたとして、それからキャッチアップしているのでは遅いことがしばしば)。仕事が始まる時点で武器を知っているために、予め広い視野を持って武器を増やしておく。
- JVMは数少ない「教えてもらった」武器。新人にはOJTでも良いので、何かひとつは渡すようにする。責任を持たせることにも繋がる。
- ASM, Findbugs, AMD (RequireJS), Maven, Grunt, SLF4J, npm, CI, OOP, FP は自ら研究しておいたことで業務においてリードする立場になれた。
- LLVM, GAE, Vagrant, PMD, Chef はまだ役だってないが、考察のための視野を育む上で役立った。
- enchant.js, Travis CI, Golang, Android, Intel Edison については今のところ全く役立っていない。百発百中である必要はない。
- 深い理解や応用は要求によって育まれる。個人で作れるツールやライブラリとは比べ物にならない要求と資源(時間)を、業務では使うことができる。
- 重要なのは、この原則を他人に求めないこと。すべて仕事で完結させるのも正しい選択で、だから教育や自動化(人手の排除)が必要。
- 課題はそれの解決に必要な武器を教えてくれない(教えてくれたとして、それからキャッチアップしているのでは遅いことがしばしば)。仕事が始まる時点で武器を知っているために、予め広い視野を持って武器を増やしておく。
目指すべきは専門家でも何でも屋でもない
- エキスパートになることで、組織の部品として問題解決の手段として使いやすくなる。問題を持ち込まれやすくなる=活躍の機会が増える。
- 何でも屋になることで、問題の本質を見抜き迅速な解決が可能になる。問題を発見したり、切り分け前の問題を持ち込まれやすくなる。
- 真になるべきは、周囲のやる気と関心を引き出しチームとしての問題解決に貢献できる人。エキスパートとしての自分や何でも屋としての自分は道具であり手段。時には他のエキスパートにdispatchしたり、他の何でも屋に意見を求める。
「技術できます」と言ってしまう
- 自分を超える超級エンジニアが山のようにいらっしゃることをわかった上で、あえて「技術できます」と言う。
- ”技術できる”の定義なんて存在しないので気にしない。”技術に詳しいらしい”ということを知ってもらうだけで、組織に貢献できる機会は増える。沈黙や謙遜は個人の美徳であって、チームや組織にはリターンがない。
- ヒューマンスキル上のリスクはある。またビジネスがわからないのではという不安を持たれるので、行動で示していく。
マネジメントとしての心構え
とにかく聞いて話す
- 日本人とは飲み会、中国人とは昼ごはん、というのが今のところの経験則。業務の枠を超えないと業務を向上させることはできない。
- くどいようだが人種でなく背景、背景よりも個人にフォーカスする。
- 自分がどう成長したいかわかっていない人がほとんどなので、3-6ヶ月かかっても良いから1on1を通じて意識を作っておく。
- 日本人とは飲み会、中国人とは昼ごはん、というのが今のところの経験則。業務の枠を超えないと業務を向上させることはできない。
組織として目指しているのはどこか、チームとして目指すべきはどこかを明確にする。他のチームの目標と現場も可能な限り伝える。
- 「自分には何ができるか?」常に考えてもらう。
- 例)Stand-up Meetingは報告の場ではなく共有の場であり、共有された問題に対して動くべきは自分であると認識させる。
- 「自分には何ができるか?」常に考えてもらう。
戦略とビジネスモデルはシンプルであるべき
- 判断基準となるこれらは、シンプルでなければ使いまわせない。
- 今やっているタスクが技術的に特異なことであればあるほど、基本となる「目標」を意識すること。
被マネジメントとしての心構え
要求を明確に上げる
- 「〜だったらいいな」「〜なのは嫌だな」ではなく「XXという問題がありYYで解決したいのでZZをください」と言う。「AAな理由がわからないのですが、BBなのでしょうか」と理解を確認するのも可。
- 私の場合「仕事がつまらない」と感じたら即座に「何をやるべきと考えているか」伝えるべき。すぐに自分が思っている以上のパフォーマンス低下が出る。
自分で判断せず、判断基準を提供する
- 高台にいる人のほうが視野が広いのは当然。高台にいては見えないこと、自分だからわかることを論理的に言語化して伝える。論理的でないと、マネジメントが他のマネジメントや上司に伝えられない。
- 判断はマネジメントに下してもらい、その判断に意見はしても文句は言わない。文句があるなら自分でマネジメントする。
目標を求める
- 目標が与えられずタスクだけ降ってくる状況は、中長期的に見てまず良いことがない。
- 結局何をやることが顧客のため組織のためになるのか、マネジメントに考えさせる。マネジメントをマネジメントする。
「マネジメントがXX(技術、自分、状況 その他)を分かってない」と言うのは非生産的
- マネジメントにわからせろ!
- マネジメントがそれをわかっていないのは、マネジメント個人の問題ではなく組織構造や自分の情報の扱いに起因する問題であるとも考えられる。
まとめ
- 実行せよ
- 正しく実行するためには、実行の目標とプロセスに関心を払い、役割を正しく演じよ
- 個人と組織の成長を促すため、常に会話し、顧客や仲間を幸せにし続けよ