Sphereとともに

scalaとかplayframeworkとか。技術ブログにしたいなと。環境は Windows7x64, mac です。たまに声優さん情報が混ざります。最近ちょっとClojure触りました。

AVIOT TE-D01b レビュー

AVIOT TE-D01b

https://amzn.to/2Ci25AD

音の特徴

とにかく圧倒的な低音

これを使ったあとue900sで聴くと低音がスッカスカに感じるくらいには圧倒的低音

とにかく低音が支配する

いわゆるドンシャリかというとそうではなく、ほんとに只々低音

ボワついた(締まりのない)低音

音場ははっきり言って狭い

これが 日本の音 だと言うならただただ残念

電車とか外で使う分にはまぁ良いとは思うのと、圧倒的な低音が好きなら良いんじゃないかと

接続状態

接続が不安定になるタイミングが正直よくわからない

朝の電車内では不安定になることはない

渋谷駅のホームは不安定

全然人が周りにいない状況でも不安定になることがある

接続が完全に切れるというようなことはない

# 安心して失敗できる組織づくり

なぜ人は失敗を恐れるのか

おそらく複合的な要因があるが、いくつかの可能性を探ってみる。

内部要因

  • 過去に失敗したときに叱られた経験で、失敗することで不利益を被ることを恐れるようになっている。
  • 現状維持バイアス、損失回避バイアスが強くかかっている。

現状維持バイアス・損失回避バイアス

  • なにか変化を起こした際に起こる変化をリスクとして捉え、そのリスクを受け入れられない。(プロスペクト理論 - 損失回避バイアス)

たとえば、転職活動をするか否かという問題。 転職したほうがいいと思いつつもなかなか行動に移せない。 単純に忙しくて時間がないというのもあるだろうが、一方で「転職したら今より悪くなるかもしれない。良くなる保証はどこにもない。最悪の場合、今の生活を失うかもしれない。」と考えると、そのリスクを受け入れられないから行動に移せない。

責任感というのも、損失回避バイアスを増幅させる要因のひとつかもしれない。

外部要因

人事・評価制度

  • 成果を上げれば評価する。でも失敗したら評価を下げる。などという評価制度だと思われてしまうと、人々は挑戦をしなくなる。基本的に評価は下げたくないと思うのが人の心理である。
  • なにも挑戦しなかったことに対して評価を下げる制度になっていると良いのかも。(要実験)

組織風土

  • 失敗した人間を徹底的に責めるという組織風土であれば、失敗を恐れて行動しなくなる。

失敗を恐れずに挑戦する

失敗したからといって誰かの命を奪うわけでも、罪を背負うわけでもない。

やること自体が自身の成長につながると信じられるか

そもそも自身の成長につながると思えなければ挑戦はしない

バイアスを外すには

  • 定量的に評価できるようになる
  • リスクを適切に判断できるようにする
  • メリットを過大に表現する
  • 挑戦したことを評価し、挑戦しなかったことが評価を下げると認識させる制度にする

実践 行動経済学

実践 行動経済学

エンジニアリングマネージャーとしての道

アドベントカレンダー12月8日の記事です。 Qiitaのアドベントカレンダーだけど、自分のブログに書いてるしポエム寄りでも許されるよね。

qiita.com

アウトライン

  • マネージャーとは
    • 諸注意
    • チームとは
    • 組織とは
    • 必要なこと
  • マネージャーになるために
  • マネージャーが危惧すること
  • マネージャーからスクラムマスターへジョブチェンジ

マネージャーとは

エンジニアリングマネージャーにおいて重要なことはチームで働くことのパフォーマンスを最大化することである。

諸注意

注意すべきはマイクロマネジメントをすることが必ずしも正しいマネジメントではないということ。

トップダウンで命令を下すのも正しいマネジメントとは言えない。(そういった組織を目指すなら別だが、自分はそんな組織を作りたくない)

また、すべての責任を負うことが良いマネージャーではない。

良いマネージャーであろうとすると、メンバーの期待に応えようとして自分の首を絞めることがある。

たとえば、メンバーとしてマネージャーであればマネージャーが「責任は俺が取るからあとは自由にやれ」というマネージャーを望むのは間違ってはいないが、マネージャーからすればメンバー自身が責任を負う覚悟をしているかどうかは重要である。甘やかすことと守ることは違う。

守るべきときは守り、突き放すべきときは突き放すことができなければならない。

マネージャーとはかくあるべきとメンバーから言われることもあるが、真に受けてはいけない。

チームとは

なぜチームで働くのかを考えてみてほしい。

また、チームとはどんなものなのかを考えてみてほしい。

私が死んでも代わりはいるもの

チームで働くということは、互いが互いの代わりができるようにあるべきである。

集団で働いているということがすなわちチームではない。

複数人で協調し仕事をしていれば、お互いの欠点を補い合える。

さらには、休暇を取りやすくなる。

お互いにサポートしあっていれば、休暇を取るのに気を使う必要はない。

たとえばあなたが休暇を取得したとしても、同僚が「以前自分が休暇とったときに代わりにいろいろとやってくれていたし、今度は自分がサポートしてあげよう。」という気持ちになっていれば互いに気持ちよくいられる。

もし、一人で働いていたり、集団で働いているが協調していないとすれば上記のメリットは得られない

全員で協調し、互いの欠点を補いあうことこそがチームである。

チームであるには

  • 誰かがやってくれているから自分は関わらなくても良いや。という考えを各自が捨てること。

  • ペアプロやモブプロを推奨する

  • 互いに尊敬しあい、誠実に指摘しあえる関係を築く

チームのパフォーマンスを下げる要因

  • 自立していないメンバー
  • コミュニケーションコスト
  • 無計画

組織とは

人の集まりである

人の集まりであるということはそこに感情が存在する

また、互いに相手がどんな背景で何を考えて発言をしているのかを完璧に把握することはできない。

そのため、メンバー間で軋轢が生まれる。

軋轢が生じないようにすること、軋轢が生じた際にそれを解決することもマネージャーの期待される役割である。

必要なこと

  • 1 on 1 を実施し、ティーチング、コーチングを使い分けられること
  • メンバー一人ひとりのなりたい姿を把握し、そこに向かうためのサポートを行えること
    • 会社としてやってほしいことと、本人の目指す姿とのつながりを見出すこと
  • 開発における知識
    • メンバーからの信頼を得られなければマネージャーとしてやっていくのは厳しい
  • コードを自分で書きたくなるが、それをぐっとこらえられる自制心
    • 自分でコードを書くことはSPOFにならないか
    • 自分がボトルネックとなって、チームのパフォーマンスを下げないか

マネージャーになるためには

※ 自分自身マネージャーになりたいと思ったことはほぼ無い。 ※ 振り返るとこんな感じだよなーというのをつらつらと。結局は信頼貯金だとは思うので、これがすべてではない。

  • 自分で考えられること
    • どうしたらいいかわからないことに対してもいくつか自分なりに考えてみる
    • 他者に丸投げしない
  • 率先して動けること
    • 大体の人は誰かがやってくれると思うし、誰かがやってくれていればわざわざそれを奪おうとしない
  • 組織の課題を見つけられること
    • 課題はいくらでも転がっている
    • 課題を作り出すことが目的ではない
    • 課題を見出すことが重要
    • 課題の本質と、その課題を解決したらどうなるか、解決すべき課題なのかを見極める
  • 上司と課題について話し合えること
    • なにが課題なのか
    • なぜそれを課題だと考えるのか
    • その課題を解決するとどうなるのか
    • その課題を解決しないとどうなるのか
  • 長期的な視点を持つこと
    • 持続可能な開発をするために組織も長期的に持続可能でなければならない
    • メンバーであれば短期的な視点でも良いが、マネージャーになるのであれば長期的な視点を持てなければならない
    • 新しい技術を取り入れることはエンジニアにとっては非常に魅力的であるが、その新しい技術を持って今後も開発できるのか、それによって新たな混乱を生まないか、自分は最後まで責任を負えるのか
      • 責任を負うというのは、全員を教育して自分がいなくても回るようにするとかそういったことを含む
  • コミュニケーション能力・交渉力
    • 何かを成し遂げるためには関係各位への説明と、説得が必要となる場面は往々にして存在する
  • 最後まで責任をもってやり遂げる
  • 感情と論理の切り分け
  • 上司に責任を取らせず、自分で責任を負う覚悟を決める

マネージャーが危惧すること

  • 組織が破壊されること
  • 組織を保てなくなること
    • 一人ひとりのやりたいことや、なりたい姿を目指すことを応援しサポートするが、組織を維持し続けることが前提である。

たとえば、自分がメンバーであった頃はどんどん新技術を取り入れるべきだ!それこそエンジニアだ!と息巻いていたころもあった。

自分自身マネージャーになってわかったが、非常に無責任な発言である。

新しい技術を取り入れるということは、その組織としてそれを維持し続けるということである。

大抵は新しい技術を取り入れたいというものの、それを維持し続けるための仕組みづくりは放り投げられるものである。なぜなら、新しい技術を取り入れたい人は取り入れたことに満足してしまいがちだからである。

マネージャーからスクラムマスターへジョブチェンジ

一番戸惑うのは指示しないこと。

トップダウンでのやり方はチームの成長につながらないので、やってはいけない行為。

誰かが指示して動く組織は、指示する人間の能力がキャップになる。

指示者を超える組織は期待出来ないということである。

会社組織上のマネージャーはどうしてもトップダウンで命令を下すことを要求される場面は避けられない。チームをリードして成果を出す責任があるからだ。 しかし、スクラムにおいてチームの責任はチームにある。

責任を持たないマネージャーが口出しをすることはあってはならない。

自分が気をつけたいと思って書き残したものは以下の通り。改めて見ると、ひたすら似たようなことを書いている。

- やたらめったら行動しない
  - 行動したくなったら我慢する
- 直接的に手を下すことはしない
  - チームに気づきを与えるのみにする
  - チームの成長の機会を奪っていないか
- 自分の考えを真っ先に開示しない
  - チームを待つ
- 目的が最優先
  - 徹底的に理論武装すること
- 決めつけてはいけない
  - チームには無限の可能性があると信じること
- スクラムマスターの考えを押し付けてはいけない
- 提案・助言に留める
  - 提案するときは理由がなければいけない
  - やってみない?どうかな?とチームに決定は委任する
- 考えたことをチームに伝えない
- 何かをしてもらうときはその理由と期限を明確に
- チームの障害を取り除く
- マネージャーと頭を切り替えること
- 1回のMTGがうまくいくかどうかではなく、その先まで見据える
  - MTG終わったあと、チームがどう失敗・成功するのか
  - それはチームの成長になるのか
- 課題だと思ったことはまず書き出して、その何が課題であるのかを深掘りして手を打つ。課題の本質を見極める。

※ 気をつけるが、実践できるかどうかはまた別の話。


マネジメント研修を受けて再考したのが以下

スクラムマスターとマネージャーは相反する関係か?

マネジメントの研修を受けると今まで自分の考えていたマネージャー像は自分の観測範囲内のマネージャー像であり、スクラムマスターとも必ずしも相反するものでもないことに気づく。

あなたの想像するマネージャーとはいったいどんなことをする人ですか?

相反関係にあるのはプロジェクトマネージャーのことを指してはいませんか?

あなたがマネージャーだと思っている人間はマネジメントについてどれだけの学を持っているのでしょうか?

マネージャーの原理原則に何があるかを理解しているだろうか?

マネジメントとは 部下を通して仕事の成果を上げること であって、必ずしもトップダウンで指示を下すことではない。

仕事の成果とは、組織や職場の目標の達成であり、そのために、 人・モノ・金効果的・効率的 に活用する。

そのために、部下に裁量を与えその範囲内で自由にやってもらうのだ。

権限と責任

少し権限と責任について考えてみよう。

裁量(遂行権限)を与えられた部下には遂行責任と報告の義務が発生する。

報告の義務が発生するのは何故か。管理監督者には管理監督責任があるからだ。

権限がないといことはよく聞くことばではあるが、権限とはなんであろうか?

権限には責任が伴う。責任とは社内における責任、対外的な責任がある。

メンバーがどんなに権限を要求したところでどうしても渡せない権限が存在するということだ。

それが管理監督者は(対外的に)管理監督責任結果責任を負っているからだ。

スクラムにおいてチームは遂行責任を負うが、果たして結果責任まで負うのだろうか?

誤解のないように正しく表現をしよう。”対外的に結果責任を負えるだろうか?”

そういった点において、会社組織上管理監督者は省くことはできない。

マネージャーもスクラムマスターもチームの成果を最大化することが目的であると言って差し支えないのではないだろうか。

目的が同一だとして違いがあるとすればどこにあるのか。

管理監督者であるかどうかが一つの鍵ではないだろうか。

スクラムマスターに果たして管理監督責任はあるのだろうか?

スクラムマスターはチームの成果を最大化するために尽力する存在であって、マネージャー(管理者)ではない。

なぜ、マネージャーとは違う呼び方を敢えてするのかはそういったところにもあるのだろう。

スクラムマスターはチームに指示は出さない。なにかを成し遂げられなかったときの責任はチームにあるのだろうか、スクラムマスターにあるのだろうか。それともPOだろうか。

問題が発生したときに対外的に責任を取るのは誰だろうか?

問題が発生したとき、責任の所在が曖昧になっては困る。

つまるところ相反するものがあるとすれば「対外的な管理監督責任」である。

対外的に管理監督責任のないスクラムマスターにはマネージャーはどうしたってなり得ないのかもしれない。

一方でマネージャーのみが持つ権限(たとえば人事権)も存在するとすればスクラムマスターは行動が制限されていることになり、チームのために効率よく最善の手を打つことができるだろうか?

シャーデンフロイデ

ところで、なぜ責任をとるのは管理者でなければならないのか。

チームメンバーの首にその価値はないのだろうか?

なにかを成し遂げられなかった責任が、サービスの終了につながったりして職を失うとしたらメンバーはその責任を負っていると言えないのだろうか。

たとえば大臣が問題を起こしたとき「総理が責任を取れ!」という発言を聞いたことはないだろうか?

総理が預かり知らぬところで大臣が問題を起こしたとして、それが大臣個人の問題だったとして人々にとってそんなことは関係ないのだ。

任命責任がなどとそれらしい理由をのたまうが、結局のところ権力者をその椅子から引きずり下ろしたくてたまらないのだ。

このとき得られる感情は「シャーデンフロイデ」という。つまり、「メシウマ」だ。

これが人間心理に組み込まれている以上、責任者は必要なのかもしれない。

シャーデンフロイデ: 人の不幸を喜ぶ私たちの闇

シャーデンフロイデ: 人の不幸を喜ぶ私たちの闇

kotlinで web frameworkのktorでtest frameworkにspekを使う

ドキュメントどおりやろうとするとうまく動いてくれない JVM - Spek Framework

spekのサンプルの通りにやるとうまく動く github.com

    maven { url "https://dl.bintray.com/spekframework/spek-dev" }

コメントアウトは外しておく

決め方

票決

参照: Eテレ「オイコノミア〜多数決だけじゃない!決め方の経済学〜」を観て。多数決ドラマって・・。

参照: オイコノミア テーマ:多数決

参照: https://ja.wikipedia.org/wiki/多数決

参照: L2プレゼンテーション評価における全体順位付けの問題―評点調整法および順位調整法の選択が最終順位に与える影響―

多数決

決選投票付き多数決

  • 初回の多数決で過半数に達したものがない場合、上位2つで再度多数決を行う決め方
  • 票割れを防ぐことが可能
  • フランス大統領選挙や国内の大きな政党の党首選などで使用。

ボルダルール

  • 配点式の決め方の1つ
    • 選択肢が3つの場合、1位に3点、2位に2点、3位に1点を各自が投票する
  • ボルダルールのメリットは、2位以下の選択肢にも意見を反映できること。多数決では拾えない意見がすくい上げられる決め方。
  • 満場一致に最も近い選択方法

チャレンジ型多数決

  • 優位候補者をあらかじめシードとして決めておき、最初に劣位候補者同士で対決させ、その勝者と優位候補者を対決させる方法

自由割当ルール

投票者の持ち点合計を決めておき、候補者の判断で持ち点を異なる候補者に割り振らせる方式である。

結果的に、多くの点を獲得したものが勝者となる。

総当たり戦

  • 全候補者同士が対決し、最も勝利数の多いものが勝者となる
  • 事例:スポーツでは多いタイプ W杯のアジア1次予選等

繰り返し最下位消去ルール

  • 何度も多数決を行い最下位を落としていく決め方
  • オリンピック候補地選びなどで使用

コンドルセ・ヤングの最尤法

  • 選択肢が多数あっても、2つの選択肢同士に対して投票を行い、どちらが優位にあるかを全パターンで実施し、最終的勝者を判断する方法。もし、その関係が循環した場合には最も僅差の支配関係を削除し、勝者を選択する

Appendix

社会的選択理論への招待 : 投票と多数決の科学

社会的選択理論への招待 : 投票と多数決の科学

Kotlinのこと1ミリくらいしか知らないけどKtorを使ってみる

はじめに

https://www.publickey1.jp/blog/18/kotlin_13javavmkotlinnative.html

この記事を見て、Kotlinいいのでは?と少し思えるようになったので使ってみることにした。

KotlinとIntellij IDEAの組み合わせは完璧なんだろうなと期待を抱いてスタート。

環境

Mac book Pro

Intellij IDEA

プロジェクトを作ってみる

https://kotlinlang.org/docs/tutorials/getting-started.html

GroupId, ArtifactIdってなんだっけ

https://improve-future.com/what-are-groupid-artifactid.html

Ktorをはじめてみる

https://ktor.io/quickstart/index.html#gradle-setup

正直Gradleもほぼいじったことないけど、コピペを繰り返すことで実際に起動して、Hello Worldまで到達

だいたいなんとかなることがわかった。

そして気づく

https://plugins.jetbrains.com/plugin/10823-ktor

KtorのIntellij IDEAのプラグインが存在する

そしてそれを利用するとめちゃくちゃ簡単にKtorプロジェクトを開始できる。

すごい。

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング