15年くらい風邪で寝込まない処方術
曖昧だが15年くらい風邪を引いた記憶がない。もちろん、ゴホゴホと咳をしたり、高熱があるのに仕事に行って休んでいない、なんてことはない。
どちらかと言えば、20代なんて休みたくて仕方がなかったし、休んでいた方の口である。
それでどうして風邪（咳や高熱とか）を引かなくなったというと、その前に、休みに対する考え方が変わったところが大きい。まるで虚弱体質のような頃は、半休やら年休を休みで使うことが多かった。
あるときこれはとても勿体無いのでは、と気づき、有給は遊びで使うべきだ、と方向転換したのであった。
つまり、風邪を引いて休むなんてありえない、と自分に対して突きつけたのである。
とは言え、周りがゴホゴホしていたりおでこを赤らめているとそこら中ウイルスだらけだろう。オフィスは乾燥しているし、電車は空間が狭いのでもっとひどいから、貰いかけるときもある。
そうすると体調が『ちょっとおかしいな』と違和感を感じる。これをキャッチできるかどうかに掛かっている。
至る所で眠くなる
電車の中で目の後ろが重くなり眠気を覚えるとか、会議で記憶が飛びそうになるとか、とにかく、目を中心に眠気を覚えたら予兆のサインである。
風邪になる前に対策を始める。
葛根湯
風邪薬は医者に処方してもらうのが一番だと思っている。でも風邪をひいているわけではないが、予兆を緩和させたい。
葛根湯が良い。
有名製薬会社より成分が満量の葛根湯を勧められたのでそれを飲んでいる。
仕事場に常備しておくか携行しておくと良い。
睡眠、睡眠、睡眠
帰宅したら睡眠である。記憶を引っ張り出し、ここ１週間くらいの睡眠時間を並べる。どこかで睡眠時間が短い時が続いているかもしれない。
寝不足が一番よろしくないので、帰宅して済ませることを済ませて寝る。
Dorcy 毛布 もうふ マイクロファイバー毛布 フランネル ふわふわ 柔らかい 軽くて暖かい 洗濯可 (ブラウン, 1シングル：140*200cm)
- 出版社/メーカー: Dorcy
- メディア:
- この商品を含むブログを見る
食事
予兆の段階であるから、まだ食べられるので温かいものを摂る。温かいスープもの、カレーでも良い。食べて寝る。
うどんは相当悪いとき。
栄養剤
ビタミン剤は風邪に効くだとか実は効かないだとか説はあるようだが、飲む。QPαゴールドとチョコラBBを飲む。
モンエナ
エネルギーの積み上げである。食事と一緒に飲む。
サロンパスA
実はこれが効いているのではないかと思っている。風邪に関わらず、体調、胃腸などがよろしくないとき、足の裏に２枚ほど貼り、甲にも1枚貼って寝ると翌朝スッキリする。ツボに働くのだろう。
風邪の予兆のときは、首の筋、リンパ腺のところ、鎖骨の上あたりに左右1枚ずつ貼る。これは風邪の予兆出なくても、普段でもなかなかよろしい。被れる人は避けた方が良い。
だいたいこれで翌日予兆は回避される。ここずっとないが、仮に熱が出ていたら病院に直行である。
50歳くらいでも生き残れるスキル
50歳くらいでそこそこエンジニアとして生き残るために役立っている技術に何があるだろうと、ふと思ったので今使えているスキルを書き出してみる。
基礎スキル
勤勉 成果を出すこと
誠実 正しさではない。インテグリティ。
終わらせる意志 コミットしたら終わらせる。終わらせられないエンジニアはギルティ。
リーダーシップ ああしたい、こうしたいがないと始められない。それを始めるとき、結局リーダーシップを発揮している。スタイルは問わない。
笑顔 一番の武器。
怒らない 怒ると判断を間違える。冷めているくらいがいい。
昼ごはんを誘う 雑談しながら話をきく。
ソフトな言葉遣い べらんめいでキャラ作れているならそれでもいい。相手に相談しやすい雰囲気を醸すことができればOK。
覚悟 見つけてしまい他にやる人がいなければそれをやると決められる意志。
優先順位づけ とは言え全部はできないから順番をつけられることは大事。
裁量 管理する方が簡単。自分でシナリオを書いてトーレスしているか見てあーだこーだ言えばいいのだから。裁量を渡して観察している方が大変。
採用 間違って採用すると採用されたエンジニアが不幸になるので厳しめになる。
チームビルディング 何もしないのが一番。それで機能するチームを作り、維持する。
組織外のリレーション 外に相談できるコネクションは少しずつやっておこう。
技術スキル
プロジェクトマネジメント 企画して、計画を立て、実行（計画を検証しながら）して、終わらせる。その仕組みを自分で作り、実践できる。楽しくないわけはない。
専門的な業務の知識 何でもやりますは何も頼まれない。なにができるかわからない。ここは専門性がある、業務知見がある、など特徴が必要。それを自分の担当にすればいい。
リスクマネジメント 何についても取り付いてくる。形のない、不確かなものづくりをする仕事をしているのだから当然。
プロダクトマネジメント ものを作る所の色々と組み合わせる発想。
他にも色々とありそうだが、思いつかない。多分、それが一番大事なものかもしれない。
『ポケットモンスター ソード・シールド』ダブルパック -Switch【ダブルパック限定特典】ヨーギラスとジャラコとの特別なマックスレイドバトルができるシリアルコード2種
- 出版社/メーカー: 任天堂
- 発売日: 2019/11/15
- メディア: Video Game
- この商品を含むブログを見る
1兆ドルコーチを読んで
気になったので大型書店の店頭に行ったら山積みされていていた。この週末、ざっと斜め読みではあるが読んだので、所感というかそう言ったメモである。
普段、買っては積ん読をするが訳あって読む。読む場所は目次を見て、途中から。夕食後に読んでいないところもパラパラとめくり、ひと通り読み終える。
書籍に取り上げられるくらいだから自分と比較すること自体が馬鹿げているが、人を見抜く力は比べ物にならないと圧倒されるだけだ。
いくつかのことの触りくらいはやっていたこともあるな、と。例えば1on1というか目標設定での面談の時間は過剰なくらい時間を使っていた。あの頃は、とても良いチームだった。今とはまた違うチームなので一概に比較するものではないが。
マネージャもトップでなければ上司がいて、相談することができる。マネージャも人脈があれば外にそうした相談する相手を置くこともできる。でも、実際どれだけの人がやっているだろうか。
そうしたマネージャの中でもトップには相談する上司がいないから孤独であるなと以前から思っていた。世の中にはトップが変な方向に走り出して組織をおかしくすることもある。実際に相談するかどうかはさておき、やはり相談相手は欠かせないと思っていたがやはり、そういう考えは間違っていないのだろう。
ところで、この偉大なコーチは口が悪いらしいがそれを周囲の人は楽しみにしてたのだと書いてある。相談をすると親身になってくれたのだろうことが想像できる。
自分はそう言った口の悪い物言いは好きではない。
この本を読み進めているとき、自分は揉め事を回避するために余計なことを引き起こすような口の悪さを謹んでいるのだと何度か思った。
実際、余計なことをいい、あとで後悔するような体験をしているとやったあとのお釣りの対応がひどく馬鹿らしくやってられない。リスクコントロールをしているようなものだ。
でも実は口の悪ささどうかはさておき、親身になって行動しているときは軸があるからネガティブなリアクションがあっても突き抜けられるし、それを本人が望まないとわかったらスパッと離れることもしていた。
その意味合いでは、随分と凡庸になったのかもしれない。
読んでいて、やってきていたことを別の切る口で言語化されていると思ったのは、事業なり自分の（マネージャとしての）実現したいことを実現するには、チームを機能させなければならないということだ。
これは何度もエントリで書いていることでもあるが、目的を実現するチームは作らなければならないし、チームとしてのパフォーマンスを発揮できるような環境を作らなければならない。
その点だけで読んでよかったと思う。
ダメコンの必要なコミュニケーションしか取れないエンジニア
プロジェクトチームで活動するとき、プロジェクトの目的を達成するために必要なスキルセットをチームで備えなければならない。
そのスキルは技術的なカバーもあるし、技術の能力レベルもあるから、組み合わせで考えなければならない。
一人ひとりのエンジニアは持っているスキルもスキルレベルも違いがある。キャリアとして積んできたいくつかのプロジェクトへの参画は、実務能力として備わる。
技術の専門性とその適用レベルに違いがあるため、エンジニア同士でのコミュニケーションは必須になる。
その意味で、チーム内のコミュニケーションに時間を取るようなエンジニアが1人でも存在すると、チームの進捗や士気に多大な影響を及ぼす。
地味にチームにダメージを与えるコミュニケーションに、次のようなものがある。
- 感情が先にでる
- ぶっきら棒な話し方をする
- 言葉が悪く怖いイメージを与える
- 自分ばかり要求をする
- 自分の価値観でレッテルを貼る
- 約束を守らない
こうしたコミュニケーションを取るエンジニアはいくら貢献していたとしても、なる早でパージした方が良いのだが、影響度合いに比べ、悪影響は顕在化しにくい。
顕在化しにくいからタチが悪い。気付いたときにはチームは相当悪い雰囲気になっているものだ。
こうしたコミュニケーションを取るエンジニアは、貢献していると言ってもその貢献している領域は狭く、難易度の低いアクティビティの数をこなす。露出が増えるので一見、誰もが貢献しているように見えるが、プライオリティの高いアクティビティは意識的にかつ納期直前まで劣後させる。
誰もが納期駆動型で仕事をしているのはわかっているし、それもそのほうが集中して済ませることができるから1人でやっていたとしても労働集約をしているようなものだ。
完了させてるなら。
結局のところ、エンジニアはコミュニケーションの中と言ったことをやりきる能力でチーム内の信頼を気づきあげる。
納期駆動型であったとしても、勤勉で、誠実で、やりきれば信頼される。それは任せて大丈夫だと認知するからである。
前述のコミュニケーションに問題をもつエンジニアは終わらせないために信頼を得られないばかりか、チームに不要なコミュニケーションの時間を使わせる。その時間を使わせる相手はえてしてプロマネやリーダの時間を必要とするエンジニアである。
時間を割くほど持ち合わせていないプロマネやリーダ、いやチームのエンジニアも同じであるが、わからないことを尋ねるのではなく、コミュニケーションの不全を起こして時間を使わせるのは悪影響しか与えない。
ためらわず、早々に退場させる判断をしなければならない。
GREAT BOSS(グレートボス): シリコンバレー式ずけずけ言う力
- 作者: キムスコット,関美和
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2019/03/01
- メディア: 単行本
- この商品を含むブログを見る
程よい緊張感を保てるチーム
チームが仲良しクラブだと成果は出ない。なんだか楽しいイベントは行われ、組織の満足度調査も高い結果が出る。側から見る限りは問題ないように見えるが実際にビジネスに貢献しているかどうかは疑わしい。
自分としては、次のような関係にあるとき成果を一定のスピードと専門家としての品質を確保したアウトプットをできると考える。
- それぞれの専門性を持ち、意見を言う
- 専門性は違いながらお互いに成長しようとしている
- （自分は除き）それぞれの能力が高い
- 尊重している
- 高い要求を望む
この条件を満たす状況でなぜ自分なりにアウトプットできているか。それは程よい緊張を感じられるからである。
緊張はあまり良い意味で取られないことが多い。プレゼンで緊張を克服するために手に一文字を書くとか、プレッシャから緊張して能力を発揮できないなど使われることからもわかる。
でも、ある程度の緊張であれば、それを乗り越えてアウトプットしたとき、達成感は少し多く感じる。
昔話になるが、エンジニアで成果の出せていなかった頃はレビューされるのがとても嫌だった。『てにをは』や体裁で済んでほしいと思っていたものだ。ましてやコードを見られるのは耐え難かった。
あるレビューに参加しているとき、頭の良いエンジニアがレビューアのコメントをよく聴き、指摘内容を確かめ、関心したり、リジェクトしたりしながらやり取りをしている風景に居合わせた。この体験は自分の認識を変えた。
もう一つ、メンバを呼びつけ、一方的に延々と批判をするプロマネを見たことがあった。
前者には良い緊張があり、後者には悪い緊張（プレッシャ）がある。
後者は悪い緊張を体験したことしか残らないだろう。延々と浴びせられた批判は批評されている状況から逃げたいことだけを考えるため、馬耳東風で批判の時間が過ぎることだけ祈っているようなものだ。前者には、レビューイのエンジニアにもレビューアにも気づきがある。
どちらの方がチームとして成果を出すかは自明だと思う。前に進もうとする気持ちとそれぞれの専門性で競い合うチームは、チームとして個々の成果以上に成果を得られる。個々の前に進むマインドは調和し、伸び代を広げるからである。前者のように閉じこもり、萎縮するようなことはない。
『ポケットモンスター ソード・シールド』ダブルパック -Switch【ダブルパック限定特典】ヨーギラスとジャラコとの特別なマックスレイドバトルができるシリアルコード2種
- 出版社/メーカー: 任天堂
- 発売日: 2019/11/15
- メディア: Video Game
- この商品を含むブログを見る
自己満なエンジニアは明日のバリューを毀損する
『今のままでできるからいいや』と頭を過るときはないだろうか。
自分の持っているスキル、つまり仕事で提供する価値はそれまでに身につけていた技術を使う。実際、持っているスキルで成果を出せる。出来上がったアウトプットを眺め、思ったようにできている。
十分じゃないか。確かに、そのアウトプットを必要とする依頼者の立場で言えば、それで十分である。でも、エンジニアとしてそれを続けたらどうなるか。
一番の成長は、やらなければならない仕事の中で実体験を通して学習するときに得られる。
いくら勉強をしても試さなければ、単なる知っていることに過ぎない。勘違いなエンジニアに多いのは、知ってること＝自分で期待したように結果を出せるはずだと無理筋な期待を自分にすることである。素振りさえしていないエンジニアに新しい道具の能力を引き出すことはできない。
『今のままでいいや』と思うのは自己欺瞞でしかない。自分で新しい課題を設定する能力がないのと一緒である。必要に迫られて覚える。教わって結果を出せたからいいじゃないか。とても低コストだし考えなくてもいい。しかし、それは自己満足していると自分を騙しているのではないか。
バリューの出し方は2つある。1つは持っている能力で処理することだ。2つは＋新しい能力を試しながら作り上げる方法だ。結果でみればどちらも同じバリューである。しかし、明日の自分の能力を高めるのはどちらかかは明白である。今日と違う明日、突然環境が変わたとき、どちらが価値を出すことができるか。
価値が出せなくなるときを自分で作ってはいけない。だから、自分を欺いてしまうような自己満足はいけないのである。
勉強会に誘っても行かない部下や後輩エンジニアをそれでも勉強会に行かせたいなら
組織の外の勉強会で得るものがあり、それが仕事で生きた体験につながっていると同じことを勧めたくなる。口コミといえば口コミであるが、他人の人生に余計なものを差し込むのだから、十分お節介である。
勧める方は意図がある。純粋に勧めるよりは、自宅と仕事場の往復をしているだけにしか見えない部下や後輩に能力を向上するような機会を作って自らのエンジニアとしてのレベルをあげて欲しいと言うピュアなものだ。
実際は、それをしなければ仕事が進まないなど困ったことになっていないから、実行されることはない。
無理やり、一緒に申し込みをさせられて、同行させるようなケースでもなければ。
ヒントはここにある。
仕事にすればいい。
勧める側に成功体験があればコネクションとして何人か交友を持っているコミュニティ的なつながりを持っているだろう。
部下や後輩エンジニアに学ぶ機会を作って欲しくても行かないのであれば、組織の、業務の中にそれを作り、スケジュールを確保し、業務として指示すればいい。
声がけするつながりのエンジニアの仕事場が近ければ、ソーシャルネットワークでDMかメッセージを送り『こんなことをやりたい』と伝えればいい。
そのとき、こちらは業務としてやりたいので業務時間内でと伝えると良い。どこの組織でもフィードバックできる程度のアウトプットがあれば業務扱いにしやすいだろう。
声がけするつながりのエンジニア達は全員つながっている必要はない。その場で新しいつながりを作れることは、声がけされたエンジニアにとっても今までなかった体験であるから価値はある。
- 距離的に近いエンジニアと事前にこんなことをやりたいと伝えておく
- 賛同してくれたエンジニアに主旨（事例による技術交流など）を伝える
- 場を設定しinvして日程調整を始める
- 部下や後輩エンジニアのスケジュールの空きを押さえる
- キックオフでは最低限のルールを決める（自由参加、持ち回りなど）
- 関係者外秘とするか、公開前提とするか（関係者外秘、クレンジング）
- ゴールは決めておく（やめるタイミング）
コミュニティの立ち上げ、ファシリテーション、運営、運用、セキュリティなど、テーマ以外まで、目の前でやれば学べることもあるだろう。
水を飲ませたくても引っ張って行くのも大変である。であれば、水を目の前に持ってくればいいのである。
Nintendo Switch 本体 (ニンテンドースイッチ) Joy-Con(L) ネオンブルー/(R) ネオンレッド(バッテリー持続時間が長くなったモデル)
- 出版社/メーカー: 任天堂
- 発売日: 2019/08/30
- メディア: Video Game
- この商品を含むブログを見る
