批判は「事柄・仕組み」に対するフィードバック
批判というのは「事柄・仕組み」に対するフィードバックとしてするべきで、「個人」への批判は意味がない。「個人」への批判されても気に病む必要などなく、どうやったら仕組みを改善できるかを考えればいい。
たまに「個人」に対しての批判をしてくる輩は見当違いも甚だしいので相手にする必要もないし、ましてや仕返しなんかで己の手を汚すなんてまっぴらごめんだ。
Who cares？（誰も気にしないよ、どうでもいいじゃない、だから何？）そんな心境。
最後に笑えればそれでいい。
共感性・客観性を養う
相手を理解しようとする姿勢が大事だが、最終的には相手の気持は想像するしかない。
相手の話をよくよく傾聴して、自分の場合どんな気持になるか、そしてどれだけ相手の気持に近いのかを確かめていく。実のところ、共感することは、自分の気持を知ることと表裏一体なのかもしれない。
そのあたりが客観性を養う点に繋がる。自分のことを客観視するには、自分の気持ちの動きを、他人として観てみる。あるいは全体を俯瞰して、自分をその一部として観る。今この瞬間、「あ、イライラしているな」「ワクワクしているな」と考えてみる。もっと具体的に内面を捉えるようにしていく。
最良のパフォーマンスで臨めるように、何をすべきか
いま現在、来年度の転職に向けて活動を始めている。環境を変化させようという試みは、ワクワクする気持ちもある一方で不安な気持ちも溢れている。何かに悩みごとがあると、注意力が散漫になる。自分に意識が向いていると、話が頭の中に入ってこない。今回は後悔しない選択をしたい。全力で最良のパフォーマンスで臨めるように、何をすべきか。
部屋の掃除をする。
モノが溢れているとそちらに注意が行って気が散る。集中力を減らすものをなくして、自分と向き合う空間を創る。自分がどういった部分で落ち込みやすいのかを考えてみる。その部分を理解すること、それだけでも、気分の落ち込みを緩和させることができるはず。
感情的にならない。
怒りや悲しみにとらわれると、考え方が偏る。自分に意識が向いている状態になる。批判的な意見を言われても、相手は相手、自分は自分として、「考え方は人それぞれある」と心がけて、前向きな気持で会話をする。
目を見て話を聞く。
話し相手の目を見て話すというのは、周囲の雑音や気になる動きに気を取られることを軽減させる効果がある。
相手の視線を追いかけて集中するだけでも、話が聞きやすくなる。
確認をしっかりとる。
話を要約して相手に確認をする。多分こんな話だったと話をすすめない。ちょっとしつこいくらいに確認したほうがむしろビジネスの場面では信頼関係を保つためにも良い。
外で運動をする。
できるだけ軽い運動をする。深い深呼吸をする。太陽の光を浴びる。
PHP 参照渡しのキホン
参照渡しはアンパサンド「&」を代入元の変数の「$」の前に付ける。
$a = 'Red'; $b = $a; // 値渡し $c = &$a; // 参照渡し echo "代入直後 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL; $b = 'Blue'; echo "変数b(値渡し)を変更 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL; $c = 'Green'; echo "変数c(参照渡し)を変更 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL;
実行結果:
代入直後 -> a(元の値):Red,b(値渡し):Red,c(参照渡し):Red 変数b(値渡し)を変更 -> a(元の値):Red,b(値渡し):Blue,c(参照渡し):Red 変数c(参照渡し)を変更 -> a(元の値):Green,b(値渡し):Blue,c(参照渡し):Green
値渡しは、変数$bのみ変わるが、参照渡しの場合、$aが変われば$cも変わる。
参照渡しはforeachでも応用できるので、うまく使いこなせばかなりスマートなコードになる（かもしれない。）
foreach ($array as &$value){
$value = (ここで代入した値が$arrayに反映される)
}
ちなみに、オブジェクトはデフォルトで参照渡しになる。オブジェクトで値渡しをしたい場合はcloneを使う。
$a = new stdclass(); // オブジェクトとして生成 $a->test = 'Red'; $b = clone $a; //値渡し $c = $a; //参照渡し echo "代入直後 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL; // 変数b(値渡し)を変更する $b->test = 'Blue'; echo "変数b(値渡し)を変更 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL; // 変数c(参照渡し)を変更する $c->test = 'Green'; echo "変数c(参照渡し)を変更 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL;
実行結果:
代入直後 -> a(元の値):Red,b(値渡し):Red,c(参照渡し):Red 変数b(値渡し)を変更 -> a(元の値):Red,b(値渡し):Blue,c(参照渡し):Red 変数c(参照渡し)を変更 -> a(元の値):Green,b(値渡し):Blue,c(参照渡し):Green
管理職≠マネジャー
マネジャーとは地位ではなく役割であるということを考えてみる。
管理職≠マネジャー
管理職≠マネジャーとして切り離して考える。古い組織環境で管理職とマネジメントが混同している場合、職場環境は上意下達の形になる。経営者の命令を、中間管理職が噛み砕いて部下に伝えるだけで、ほとんどメッセンジャーと変わらない。こういった環境では、上からの命令をどれだけ忠実に評価の対象になり、社内のことばかりを考えてエンドユーザを蔑ろにするような傾向になる。
どんな役割であるべきか
本業とは別にフリーでやっているプロジェクトにおいても作業を細分化して担当者に差配する人がいる。通常の会社組織では上司の仕事だが、この仕組においては、会社組織ではないので、上司ではない。純粋に地位ではなく役割としてマネジメントを行っている。当然、この人の意見が絶対ではなく、お互いに意見交換の上で物事を決めている。
1.現在の状態を明確にし、問題と課題を定義する
目標・目的地を明確にしておくこと。そのうえで、何が問題・課題となっているのかを考える。何があれば解決するのかを絞る。
2.対策を講じる
課題を特定した上での選択肢を複数だし、効果的な案を選択する。思いつきで着手すると徒労になることが多いので、できるだけ多くの手段を上げておくこと。
3.メンバーが成果を出すためのプロセス作る
前回の作業結果から、出来たところ、出来なかったところを抽出して、次回どのようにすればより効率が上がるかを考える。「出来ないこと」はメンバーの問題ではなくプロセスにあることをまず考えて、改善策を出して次のアクションに結びつける。 定量的に数値で把握し可視化する。
マネジャーがもつ権限に給与や査定などの人事権のような権力まで握られると、マネジャーの人となりにより、意見交換が阻害されることもある。自由闊達な意見交換ができる環境で仕事ができればいいと思う。
それでは、優れたマネジャーの要件はなんだろうと考えていたところ、Google re:Work（リワーク）での記載が腑に落ちたので、引用させていただく。
- 良いコーチである。
- チーム任せ、細かく管理しない。
- チームの仕事面の成果だけでなく、健康を含めた充足に配慮しインクルーシブ(包括的)なチーム環境を作る。
- 生産性が高く、結果を重視する。
- 効果的なコミニュケーションをする-人の話をよく聞き、情報を共有する。
- キャリア開発をサポートし、パフォーマンスについて話し合う。
- 明確なビジョンや戦略をもち、チームと共有する。
- チームにアドバイスできる専門知識がある。
- 部門の枠を越えて、コラボレーションをおこなう。
- 決断力がある。
Google re:Work(https://rework.withgoogle.com/jp/)のサイトには参考になりそうな記事が掲載されていたので年末年始あたりで熟読してみたい。
