はてなブックマーク

「ドメイン駆動設計のためのマネジメント入門」でお話しました。 ご参加いただいた皆さま、ありがとうございました！ modeling-how-to-learn.connpass.com 本エントリにて、イベントの資料を公開します。 セッション概要 マネジメントの基礎的・基本的な知識は、ソフトウェア開発においても役に立つスキルです。ソフトウェア開発は事業を実現する手段の一つであり、事業とマネジメントは切っても切れない関係でしょう。 本セッションでは、「ソフトウェア開発と組織」「ソフトウェア開発と事業」という観点で、ソフトウェア開発の全体像を俯瞰します。 セッション資料 speakerdeck.com マネジメントの知識がドメイン駆動設計を加速する イベントにて、増田亨さんより「マネジメントの知識とドメイン駆動設計とのかかわり」について紹介がありました。 「組織」や「事業戦略」の知識を広げることは

カンバンとは？ カンバンとはメタプロセスであり、プロセスを改善するためのプロセスである。 カンバンを用いることからカンバンと言われる。 カンバンのイメージ カンバンは作業者ではなく作業にフォーカスする。"作業の流れ"を良くしていく。 「始めるのをやめて、終わらせるのを始めよう！」が合言葉。 簡単なはじめ方 ボード上の列でワークフローを示す。 カンバン上にチームのタスクをすべて並べる（付箋などに書き出す）。 タスクの進捗（ワークフローの進行）でタスクを移動していく。 カンバンの原則 カンバンの原則に沿ってこそ効果を発揮する。カンバンには3つの原則がある。 見える化 WIPの制限 流れの管理 1. 見える化 仕事を見える化して自分たちの仕事を理解する。 「仕事がどう進むか」を学び、改善の可能性を発見する。 作業項目が見える ワークフローが見える 個々の項目の状態が見える チームのポリシーが見え

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 Job description」というプレゼン資料です。 このプレゼン資料を作成したときの状況は以下のとおりです。 Engineering Manager Meetup のコミュニティで、 Engineering Manager の Job description を作成するというプロジェクト成果報告 プロジェクトメンバーが複数回の議論をとおして、情報整理が少し進んだが議論の結論に至ってはいない Engineerin

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

タイトルだけで絶対におもしろいと思い、即買いしてしまった本です。 エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング 作者: 広木大地 出版社/メーカー: 技術評論社 発売日: 2018/02/22 メディア: Kindle版 この商品を含むブログを見る 広木さんもサピエンス全史の4倍おもしろいと言っていましたｗ 本を書きました。控えめに言って、名著です。サピエンス全史の4倍、反脆弱性の2倍、面白いです。https://t.co/SE1dvTn6FB— ひろきのだいち (@hiroki_daichi) 2018年2月2日 あざます！— ひろきのだいち (@hiroki_daichi) 2018年2月21日 感想 ここ数年の組織や技術に関する事項の総集編といった内容でした。 私自身勉強していることや、自分の中でモヤっと理解していたことが、明確な論理で書かれていま

おすすめの工数見積もり方法についてのお話です。 （前置き）ストーリーポイントと相対見積もりについて 本題の前に相対見積もりとストーリーポイントについて少し触れましょう。 私は人日／人月などの絶対見積もりは使わず、相対見積もりによってストーリーポイントをつけています。 ストーリーポイントは、ユーザーストーリーやフィーチャーの規模感を表す単位です。 そして、基準となるユーザーストーリーのストーリーポイントに対して、どれくらい大きい／小さいかを見積もるのが相対見積もりです。 本エントリの見積もり単位もストーリーポイントを使用して説明します。 2点見積もりとは 「最小工数」と「最大工数」の2つを算出して見積もる方法のことです。 見積もるプロジェクト規模が大きい、あるいは不確定要素があるという時に効果を発揮するでしょう。 hirokidaichi さんの記事に、2点見積もりのことがさらに詳しくまとま

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