Sphereとともにスマートフォン用の表示で見るSphereとともにscalaとかplayframeworkとか。技術ブログにしたいなと。声優さん情報が混ざります。最近ちょっとClojure触りました。この広告は、90日以上更新していないブログに表示しています。恐れずに挑戦するやること自体が自身の成長につながると信じられるかバイアスを外すにはなぜ人は失敗を恐れるのかおそらく複合的な要因があるが、いくつかの可能性を探ってみる。過去に失敗したときに叱られた経験で、失敗することで不利益を被ることを恐れるようになっている。現状維持バイアス、損失回避バイアスが強くかかっている。現状維持バイアス・損失回避バイアスなにか変化を起こした際に起こる変化をリスクとして捉え、そのリスクを受け入れられない。損失回避バイアス)たとえば、転職活動をするか否かという問題。転職したほうがいいと思いつつもなかなか行動に移せない。単純に忙しくて時間がないというのもあるだろうが、一方で「転職したら今より悪くなるかもしれない。良くなる保証はどこにもない。最悪の場合、今の生活を失うかもしれない。」と考えると、そのリスクを受け入れられないから行動に移せない。失敗したら評価を下げる。いう評価制度だと思われてしまうと、人々は挑戦をしなくなる。基本的に評価は下げたくないと思うのが人の心理である。なにも挑戦しなかったことに対して評価を下げる制度になっていると良いのかも。失敗した人間を徹底的に責めるという組織風土であれば、失敗を恐れて行動しなくなる。失敗を恐れずに挑戦する失敗したからといって誰かの命を奪うわけでも、罪を背負うわけでもない。安心して失敗できる組織づくりTweet広告を非表示にするもっと読むコメントを書く2018-12-08エンジニアリングマネージャーとしての道マネジメントアドベントカレンダー12月8日の記事です。Qiitaのアドベントカレンダーだけど、自分のブログに書いてるしポエム寄りでも許されるよね。qiita.comアウトラインマネージャーとは諸注意チームとは組織とは必要なことマネージャーになるためにマネージャーが危惧することマネージャーからスクラムマスターへジョブチェンジマネージャーとはエンジニアリングマネージャーにおいて重要なことはチームで働くことのパフォーマンスを最大化することである。注意すべきはマイクロマネジメントをすることが必ずしも正しいマネジメントではないということ。トップダウンで命令を下すのも正しいマネジメントとは言えない。(そういった組織を目指すなら別だが、自分はそんな組織を作りたくない)また、すべての責任を負うことが良いマネージャーではない。良いマネージャーであろうとすると、メンバーの期待に応えようとして自分の首を絞めることがある。メンバーとしてマネージャーであればマネージャーが「責任は俺が取るからあとは自由にやれ」というマネージャーを望むのは間違ってはいないが、マネージャーからすればメンバー自身が責任を負う覚悟をしているかどうかは重要である。甘やかすことと守ることは違う。守るべきときは守り、突き放すべきときは突き放すことができなければならない。マネージャーとはかくあるべきとメンバーから言われることもあるが、真に受けてはいけない。チームとはなぜチームで働くのかを考えてみてほしい。チームとはどんなものなのかを考えてみてほしい。私が死んでも代わりはいるものチームで働くということは、互いが互いの代わりができるようにあるべきである。集団で働いているということがすなわちチームではない。複数人で協調し仕事をしていれば、お互いの欠点を補い合える。休暇を取りやすくなる。お互いにサポートしあっていれば、休暇を取るのに気を使う必要はない。あなたが休暇を取得したとしても、同僚が「以前自分が休暇とったときに代わりにいろいろとやってくれていたし、今度は自分がサポートしてあげよう。」という気持ちになっていれば互いに気持ちよくいられる。一人で働いていたり、集団で働いているが協調していないとすれば上記のメリットは得られない全員で協調し、互いの欠点を補いあうことこそがチームである。チームであるには誰かがやってくれているから自分は関わらなくても良いや。いう考えを各自が捨てること。組織とは人の集まりである人の集まりであるということはそこに感情が存在するまた、互いに相手がどんな背景で何を考えて発言をしているのかを完璧に把握することはできない。そのため、メンバー間で軋轢が生まれる。軋轢が生じないようにすること、軋轢が生じた際にそれを解決することもマネージャーの期待される役割である。自分自身マネージャーになりたいと思ったことはほぼ無い。振り返るとこんな感じだよなーというのをつらつらと。結局は信頼貯金だとは思うので、これがすべてではない。何かを成し遂げるためには関係各位への説明と、説得が必要となる場面は往々にして存在する最後まで責任をもってやり遂げる感情と論理の切り分け上司に責任を取らせず、自分で責任を負う覚悟を決めるマネージャーが危惧すること組織が破壊されること組織を保てなくなること一人ひとりのやりたいことや、なりたい姿を目指すことを応援しサポートするが、組織を維持し続けることが前提である。自分がメンバーであった頃はどんどん新技術を取り入れるべきだ!それこそエンジニアだ!と息巻いていたころもあった。自分自身マネージャーになってわかったが、非常に無責任な発言である。新しい技術を取り入れるということは、その組織としてそれを維持し続けるということである。新しい技術を取り入れたいというものの、それを維持し続けるための仕組みづくりは放り投げられるものである。新しい技術を取り入れたい人は取り入れたことに満足してしまいがちだからである。マネージャーからスクラムマスターへジョブチェンジ一番戸惑うのは指示しないこと。トップダウンでのやり方はチームの成長につながらないので、やってはいけない行為。誰かが指示して動く組織は、指示する人間の能力がキャップになる。指示者を超える組織は期待出来ないということである。会社組織上のマネージャーはどうしてもトップダウンで命令を下すことを要求される場面は避けられない。チームをリードして成果を出す責任があるからだ。スクラムにおいてチームの責任はチームにある。責任を持たないマネージャーが口出しをすることはあってはならない。自分が気をつけたいと思って書き残したものは以下の通り。見ると、ひたすら似たようなことを書いている。課題だと思ったことはまず書き出して、その何が課題であるのかを深掘りして手を打つ。課題の本質を見極める。気をつけるが、実践できるかどうかはまた別の話。マネジメント研修を受けて再考したのが以下スクラムマスターとマネージャーは相反する関係か?マネジメントの研修を受けると今まで自分の考えていたマネージャー像は自分の観測範囲内のマネージャー像であり、スクラムマスターとも必ずしも相反するものでもないことに気づく。あって、必ずしもトップダウンで指示を下すことではない。そのために、部下に裁量を与えその範囲内で自由にやってもらうのだ。権限と責任について考えてみよう。裁量(遂行権限)を与えられた部下には遂行責任と報告の義務が発生する。報告の義務が発生するのは何故か。管理監督者には管理監督責任があるからだ。権限がないといことはよく聞くことばではあるが、権限とはなんであろうか?権限には責任が伴う。責任とは社内における責任、対外的な責任がある。メンバーがどんなに権限を要求したところでどうしても渡せない権限が存在するということだ。それが管理監督者は(対外的に)管理監督責任と結果責任を負っているからだ。スクラムにおいてチームは遂行責任を負うが、果たして結果責任まで負うのだろうか?誤解のないように正しく表現をしよう。マネージャーもスクラムマスターもチームの成果を最大化することが目的であると言って差し支えないのではないだろうか。目的が同一だとして違いがあるとすればどこにあるのか。管理監督者であるかどうかが一つの鍵ではないだろうか。スクラムマスターに果たして管理監督責任はあるのだろうか?スクラムマスターはチームの成果を最大化するために尽力する存在であって、マネージャー(管理者)ではない。マネージャーとは違う呼び方を敢えてするのかはそういったところにもあるのだろう。スクラムマスターはチームに指示は出さない。なにかを成し遂げられなかったときの責任はチームにあるのだろうか、スクラムマスターにあるのだろうか。それともPOだろうか。問題が発生したときに対外的に責任を取るのは誰だろうか?問題が発生したとき、責任の所在が曖昧になっては困る。つまるところ相反するものがあるとすれば「対外的な管理監督責任」である。対外的に管理監督責任のないスクラムマスターにはマネージャーはどうしたってなり得ないのかもしれない。一方でマネージャーのみが持つ権限(たとえば人事権)も存在するとすればスクラムマスターは行動が制限されていることになり、チームのために効率よく最善の手を打つことができるだろうか?シャーデンフロイデところで、なぜ責任をとるのは管理者でなければならないのか。チームメンバーの首にその価値はないのだろうか?なにかを成し遂げられなかった責任が、サービスの終了につながったりして職を失うとしたらメンバーはその責任を負っていると言えないのだろうか。大臣が問題を起こしたとき「総理が責任を取れ!」という発言を聞いたことはないだろうか?総理が預かり知らぬところで大臣が問題を起こしたとして、それが大臣個人の問題だったとして人々にとってそんなことは関係ないのだ。任命責任がなどとそれらしい理由をのたまうが、結局のところ権力者をその椅子から引きずり下ろしたくてたまらないのだ。このとき得られる感情は「シャーデンフロイデ」という。これが人間心理に組み込まれている以上、責任者は必要なのかもしれない。Eテレ「オイコノミア〜多数決だけじゃない!決め方の経済学〜」を観て。多数決ドラマって・・。voting単記移譲式投票シュルツ方式コンドルセ方式の一種であり、IT業界で良く使われている投票手法。この方式を使用している。票割れを防ぐことが可能フランス大統領選挙や国内の大きな政党の党首選などで使用。ボルダルール配点式の決め方の1つ選択肢が3つの場合、1位に3点、2位に2点、3位に1点を各自が投票するボルダルールのメリットは、2位以下の選択肢にも意見を反映できること。多数決では拾えない意見がすくい上げられる決め方。自由割当ルール投票者の持ち点合計を決めておき、候補者の判断で持ち点を異なる候補者に割り振らせる方式である。結果的に、多くの点を獲得したものが勝者となる。選択肢が多数あっても、2つの選択肢同士に対して投票を行い、どちらが優位にあるかを全パターンで実施し、最終的勝者を判断する方法。21:09決め方Tweet広告を非表示にするもっと読むコメントを書く2018-11-05Kotlinのこと1ミリくらいしか知らないけどKtorを使ってみるはじめにhttps://www.publickey1.jp/blog/18/kotlin_13javavmkotlinnative.htmlこの記事を見て、Kotlinいいのでは?と少し思えるようになったので使ってみることにした。IDEAの組み合わせは完璧なんだろうなと期待を抱いてスタート。Worldまで到達だいたいなんとかなることがわかった。IDEAのプラグインが存在するそしてそれを利用するとめちゃくちゃ簡単にKtorプロジェクトを開始できる。22:30macで入れるといいアプリTweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:FScowardscalaとかplayframeworkとか。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。