13c622fec8d1c11042d9d41d20acb5a9

20181118 muraiCreated on 2018-11-18 by murai

    other

    目的思考の人は仕事が早いらしい。
    なにがゴールなのか考えるみたいな。

    読み物

    コミュ力もリーダーシップもいらない。元Google社員が語る、本当に“優秀な人材“とは

    会社自体に心理的安全性があるみたいな。
    あとはとがった人ほど環境さえ用意されてればすごい結果を出してくれるよとかの話。
    大きい会社でこういう考え方してるの珍しいなあっておもった。
    日本で働いてるからってだけかな。

    成長過程における自己評価を下げすぎないために気をつけること
    昨日の自分と比べて他人と比べるなと。
    その行動は昨日の自分にできましたか!!
    ウオオオオオオオ

    リモートワーク×ホラクラシー型組織の給与評価制度を作りました
    やっと読んだ。
    人が人を評価しないはなるほどー!ってなった。
    今の会社の不安なところは経営者が「俺は人を見る目がある」って結構な自負があるっぽいところなんよな。
    まだそんな気がするってだけだけど。
    給与額も経営者が決めてるっぽいのでそこが気にある。
    人でなくルールで決めるのは安心すると思う。
    ルールもオープンだし、あと役割で人を見るっていうのも理にかなってそう。

    エンジニアは全員技術記事を書くことを習慣化した方がいいぞ
    ブログ始めてみようかな。
    ずっとどうしようかなあって思ってるんよな。
    アウトプットしたくて日報とかいろいろ試してきたけど、もっと詳細に書いたほうがいいのかな。
    ローカルにいっぱいQiita記事みたいなのあるし、公開してみうようか。

    IT実務のアンチパターン

    1章 使う技術から組み立てちゃう

    目的と手段がいっしょにならないこと。
    目的を自分のやりたいことと混同しないこと。
    今のところプロジェクトでなすべきことで考えようとで来てると思う。
    けどいつうっかり道を間違えるかわからんのでよくよく覚えておこう。

    2章 ずっと技術調査してる

    目的に対して今必要な行動か?を考えられるようになれってことかな。
    早く終わったからって追加で調査するのが必ずいいとは限らない話はなるほどなーだった。

    3章 技術検証せず着手しちゃう

    コラムの、何を知りたいかによってアプローチが違うっていうのなるほど。
    臨機応変って苦手意識あるけど、設計構築やるかもなのでどういう手法があるかとかちょっと見ておく。
    予想外の事態による損害を減らすために検証をする。
    損害は後になるほど大きくなる、プログラミング修正で終わるのか、ハードの修正まで及ぶのかなど。
    ただ、プロジェクトによって大事なものが違うので気を付ける。
    時間が大事なのか士気が大事なのか。
    大事なものの損害を少なくする。

    IT実務のってタイトルに入れているのは上手だと思った。