はてなブックマーク

Developers Summit 2019 Summer にて『組織本能の考察と適応』という発表をした。 プレゼンでは話せなかった組織本能というものを考えた背景について書いていこうと思う。 組織本能とは 組織にも、集合体にも本能というものが存在するのではないかという考えから生まれた造語である。 組織の本能ということを考えたきっかけは3つ。 会社にてエンジニアリング組織を広げる活動をしていて、各部門ごとに文化があるのを感じた。そして文化はなかなか変わらない。 組織変更があると人は組織図に忠実に行動をする。昨日の仲間も組織が変わると過去のこと。 人間の本能というものは集団にも濃く反映されているのだが、集団というものは多様性を生まない時もある。 これはどの組織でも聞くような話で、なぜこういったことが起こるのだろうかと考えていた。 かく言う自分も本能的に守りの行動もしてしまい、これも人間の本能的

ドメイン駆動設計本格入門に参加してきました。 devlove.doorkeeper.jp 講師は増田亨(@masuda220)さんでした。 概要説明ではなく、開発現場にドメイン駆動設計を導入し、その効果を最大化するための勘所を実コードを使いながら解説します。 とあるように、抽象の話ではなく具体を学ぶことができる講習でした。 以下、講習の中からとくにドメイン駆動設計にフォーカスして内容をまとめていきます。 ドメイン駆動設計本格入門 from 増田 亨 www.slideshare.net ドメイン駆動設計でなぜつくるのか 3つのキーワード ビジネスルール モデル ビジネスルールのモデリング 値オブジェクト 契約による設計 ロジックを持ったenum コレクションのカプセル化 エヴァンス本のススメ パターンについて 責務のレイヤー マイクロサービス アプリケーション層の複雑さ VETRO Sag

エンジニアリングマネージャーって何者か？というものを考えているのですが、明確な定義は難しいものです。 Engineering Manager Meetup #4 で Job description の話をしてきた #em_meetup - dskst's diary でも発表しましたが、 Job description という方向から攻める一方で、今後は別の切り口からも考えていこうと思います。 さて、今回はエンジニアリングマネージャーの概念に近づけそうなことがあったので整理してみました。 エンジニアリングマネージャーの概念は何か @bufferings さんのブログ 「エンジニアリングマネージャは必要か？」 - Mitsuyuki.Shiiba にて、以下の表現がありました。 組織の形に合わせて今足りない部分を補いつつ複数のロールを担っている人、のことをエンジニアリングマネージャと呼んでい

Engineering Manager Meetup #4 に参加してきました。 engineering-manager-meetup.connpass.com 「em_meetup から生まれる！？ Engineering Manager Job description」というタイトルで発表をしてきました。本記事では、プレゼンでは時間が無くてお話しできなかったことをまとめました。 em_meetup から生まれる！？ Engineering Manager Job description Job description はこれからどうなるのか Job description は能力に制限をかけてしまう！？ コンピテンシーモデルを適用するのか？ 人事制度との深い関わり 今回の発表を通して感じたこと 参考文献 em_meetup から生まれる！？ Engineering Manager Jo

皆さんはどのようにプレゼン資料作成しているのだろう。 プレゼン資料作成は、草案からプレゼン資料という形で具体化していく、不確実性を確実にしていくというエンジニアリングかもしれない。 さて、今回の記事はプレゼン資料の魅せ方ではなく、どのように情報を整理してスライドに落としていっているかをまとめるので参考になれば幸いだ。 はじめに 今回作成したプレゼンのテーマは以下の通り。 Engineering Manager Meetup のコミュニティでの Engineering Manager の Job description を作成するというプロジェクト成果報告 2回のディスカッションから情報整理は少しだけ進んでいる しかし、プロジェクトは途中で Job description は完成せずに議論がまとまっていない状態 難しいのが議論はまとまっていないので何をコアにして、何をみんなに伝えるべきなのか

先日、朝から刺激的な記事をみつけた。 yunon-phys.hatenadiary.com 情報は人のネットワークを通じてどう感染していくのかということである。 ここで興味深いのが、ただ闇雲に情報を発信しても情報は伝わらないということ。 これを頭に置いて組織のことを考えると、色々と工夫できることがありそうな気がします。 良いことも悪いことも人のネットワークで感染する。では、悪いことを止める、良いことを広めるもある程度コントロールできるはず。— daisuke sato/さとうだいすけ (@dskst9) 2018年8月29日 では、情報ではなく別のなにかを伝えるときは？ 人のネットワークも考えた上で、戦略をねることで本当の効果が狙えるのではないか。と考えた。 ※シミュレーションは下記サイトから誰でも試すことができる。 ncase.me 組織でシミュレーションしてみる 仮に下記のような組織体

見積もり際に、ここ最近ずっと2点見積もりを使っている。 今日はそんなおすすめの工数見積もり方法についてのお話。 （前置き）ストーリーポイントと相対見積もりについて 本題の前に相対見積もりとストーリーポイントについて少し触れよう。 私は人日、人月などの絶対見積もりは使わず、相対見積もりにてストーリーポイントをつけている。 そのため本記事もストーリーポイントを使用しているが、よくわからないという方は「相対見積もり」や「ストーリーポイント」でググってもらうと詳しい記事があるのでそちらを見てみてほしい。 2点見積もりとは 最小工数と最大工数の2つを算出して見積もる方法のこと。 見積もり案件規模が大きい、または不確定要素があるという時に効果を発揮する。 hirokidaichi さんの記事に、2点見積もりのことがさらに詳しくまとまっているので、是非一読いただければ思う。 qiita.com 1点見積

Google Play と App Store で有料アプリ（アプリ内課金を含む）を販売するまで、何をしたらいいのか。というのをまとめておく。 Google Play Googleはそんなに障壁はなく設定が可能。 Google Play Developer Console にて販売アカウントのセットアップをする Google Payment Center (Payment Merchant Center?) でお支払い方法に口座情報を登録する 即座に有料アプリ販売は可能になる（以下、収益受取のために対応必要） 3営業日ほどで Google から登録した口座にデポジットが入金される（1$未満） Google Payment Center にて入金されたデポジットの金額を入力する 支払口座が有効になる デポジットはどうするの？ 6のデポジットで返却するの？どうしたらいいの？というのをGoogl

そもそも の、話は id:y_uuki さんのブログがよくまとまっています。 yuuki.hatenablog.com RFCはこちら RFC7540 日本語訳 スポンサーリンク 本題 HTTP2.0 のことは分かったが、結局何をやればいいの？というのを箇条書きにすると以下が必要です。 クライアント側のHTTP2対応 WEBサーバー側のHTTP2対応 TLS通信対応 etc（ここがブラックボックス…） 1. クライアント側のHTTP2対応 HTTP2に対応しているブラウザなどを入れれば使えます。 対応ブラウザ 以下、Wikipediaさんより。 Windows7 以前はダメなんですね。 Google Chrome (30は設定が必要） Mozilla Firefox (34から標準で有効) Windows 10上のInternet Explorer 11 Microsoft Edge Op