2019年ふりかえり
やったこと
タイムライン
- 1月
- DevLOVE関西で心理的安全性ゲーム
- 2月
- スクラム道関西
- Scrum Fest Osaka 2019
- 営業研修開始
- 3月
- ストレングスファインダー実施
- 4月
- 新規参入メンバーとデリゲーションボード
- Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説！
- 5月
- OODAループを知る
- 6月
- 営業研修修了
- 7月
- 組織横断的なお仕事が徐々に増える
- なにげないツイートがバズる
- 8月
- 妻実家に帰省。海釣り、海水浴、BBQ
- 京都鉄道博物館
- Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！
- 9月
- 10月
- 11月
- 12月
読書
- モデルベース要件定義テクニック
- 【読了】HIGH OUTPUT MANAGEMENT
- 【読了】OKR(オーケーアール)
- 【読了】職場の問題地図
- 【読了】エッセンシャル思考 最小の時間で成果を最大にする
- 【読了】人を育てるアドラー心理学 最強のチームはどう作られるのか
- 【読了】世界No.1プレゼン術
- 【読了】1分で話せ
- 【読了】管理ゼロで成果はあがる~「見直す・なくす・やめる」で組織を変えよう
- 【読了】子どもの「やってみたい」をぐいぐい引き出す! 「自己肯定感」育成入門
- 【読了】正しいものを正しくつくる
- 【読了】マインドマップから始めるソフトウェアテスト
- 【読了】スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本
- 【読了】今日からしつけをやめてみた
- 【読了】人と組織の「アイデア実行力」を高める ― OST実践ガイド
- 【読了】脳が知っている 怒らないコツ
- レガシーコードからの脱却 ★1
- 【読了】プレー経験ゼロでもできる実践的ゲームモデルの作り方
- ソフトウェア・ファースト ★2
- Design It! ★3
★1〜3は年末年始の課題図書
アウトプット
- ブログ：10回
- 社内メンター：コーチング4回
わかったこと
2019年のやることリストの結果
- 心身ともに健康
- 9月までは順調だが、最後の最後で大崩れ
- データ収集と見える化
- チームが学びを最大にする活動
- ふりかえりのファシリテートは足りなかったと反省
- 1on1でデリゲーションボードを使って権限委譲を進めることができた。頻度について改善する。
- 何のために学ぶかをもっと明確に共有したい。
- 好奇心を持つ
新たにわかったこと
- マネジメントの面白さ
- マネジメント対象を明確にすると状態や行動も見えてくる
- 視野・視座を時には大きく、時には小さく
- 具体と抽象
- 40歳を超えての体調管理の難しさ
- イライラしやすい
- 壊しやすく治りにくい
- 睡眠大事
- アウトプット不足
- RDRAを取り入れたり、業務への転化はできたと思う
- 上司との1on1にて活動内容を社内へアピールするように勧められる。
- 勉強会のアウトプットはほぼ100%達成できているけど、読書したものを消化してアウトプットしたい
次やること
事業の推進者となる
役割として明確に求められるようになってきたのもあり、マネジメントの面白さを感じてきたのもあり目指して行きたいと思う。
ただ、完全にビジネス寄りではなく実現するところも含めたエンジニアでありたい。
顧客・ユーザーの役に立つものを企画提案し、顧客・ユーザーと共創して行きたいと思う。
エンタープライズアジャイルのあり方については継続して勉強したい。
教育者となる
親としてもいちエンジニアとしても、良き導き手ーー相手を動機付けし、自律的な活動を促すようなサーバントリーダーでありたい。
アジャイルなマインドセットと価値観を大切にし理性的な振る舞いができるように心身を整える。
学習者であり続ける
ストレングスファインダーでわかった強みである学習欲を活かして学び続けたい。学ぶ場を作り仲間を増やしたい。
社内勉強会の企画・運営に挑戦する。
もうかりまっか？Agile Japan 2019 大阪サテライト に参加した
昨年は東京で参加したので2年ぶりのサテライト参加。 僕がアジャイルを知り深くハマるきっかけになったイベントです。
今回のテーマは『アジャイルでビジネス価値を向上させる』となります。
開発者が新たなビジネス価値を生み出すために、どのような取り組みをしているかを関西を中心に西日本で活躍されている方々から、お話を伺いました。
Agile Japan 2019基調講演「マネージャー不在の洞窟型組織」
GROOVE X 株式会社 代表取締役 林 要 氏
講演資料は以下のページから参照可能。
LOVOTについて
300億を溶かし続けて開発したという、先端技術の塊です。 日本発のカワイイは海外でウケる。心をサポートするロボット。
マネージャ不在の洞窟型コンセプト
早く試して早く学ぶ
未知なものに対する不安は大きい。 不安のマネジメントが重要である。 そのためには、見える化をして不安をセルフマネジメントする。
スコープがよく変わる
「オペレーションミスを減らすためのヒエラルキー組織で、「失敗しても良い」と掛け声をかけても、成功しない」
「スコープが変わってもルールが変わらない場合、各人の“責任感“と”不安”で、各領域の守備範囲が自然縮小」
というお話は実感します。 さらに、
「しっかりフィードバックするしかない」
このあたりのお話も確かにあるあると思いました。後ほどの質疑応答でも
とのことでしたので、説明責任を果たすことは重要ですね。
Agile Japan 2019特別講演「”Agility-Native”を実現するITマネージメント」
SOMPOシステムズ株式会社 代表取締役社長 損害保険ジャパン日本興亜株式会社 取締役常務執行役員 浦川 伸一 氏
なぜAgility-Nativeか
ユーザーIT部門の危機感
- ソリューションのサイロ化
- マルチクラウド
- AI
- マネジメント変革が必要
- 経団連のAIガイドライン
- アジャイルが根付かない
Agility-Native化 (アジャイル型組織運営)
2019年度より、3カ年計画で、全社導入を予定。
とのことでしたので、まだ道半ばというところでしょうか。 様々な取り組みの中で目に止まったのは、「組織構造の変革」の部分でSpotifyモデルかな？と思いました。 全体を通してかなりトップダウンに進められている様子でしたので、現場の人の意見を聞いてみたいなとも思いました。
アジャイル開発におけるITベンダー・メーカーの品質保証／検査の取り組み
パナソニック株式会社 水田 恵子 氏 島﨑 尚史 氏
資料公開がNGということなので、どこまで言及していいのか。。。
アジャイル・スクラムやろう！ではなく、きちんとゴールから逆算し何をすべきか？ どの部分を改善すべきか？に真摯に取り組まれており、とても参考になる発表でした。
懇親会でも島崎さんとお話させていただき、取り組みについての詳細を伺うことができました。 参考にしていきたいと思います。
田舎で11年スクラム
リコーITソリューションズ株式会社 福田 朋紀 氏
信頼が揺らぎそうな時をチームで察知できるように
自分たちのプレーに再現性がない
という課題を持たれており、それをゲームモデルによって解決するというアプローチです。
「サッカーから学ぼう」というアプローチはサッカーをやってきた僕には受け入れやすいですし、 なにより「マイクロマネジメントでなく再現性のあるチームにしていくためにどのような指針を伝えればよいのか」というところで悩んでいたのでとても良かったです。
ゲームモデル作ってみたいと思います。
あたらしいビジネスとアジャイル
西日本電信電話株式会社 太田 敦士 氏
2017年サテライトのときにも聴かせていただきましたが、切れ味はお変わりありませんでした。
- 座右の銘：無下にせず、真に受けず
- おっさんが若者に勝てるのは経験だけ
- 経験を呼べるキーワード：かけっこ（感謝・謙虚・好奇心）
LT
- 匿名希望さん：「はげちゃびん問題について考える」
- 自分がはげちゃびんにならないように気をつけよう。。。
- @radiocat さん：「Re:ゼロから始めるアジャイル開発」
- いにしえのエクセル方眼紙は辛い。。。異世界で早く死んで早く学ぶ方法。
- kyon_mmさん：「進化論からのアジャイル」
- ドキッ！欺瞞だらけのアジャイル開発
- 玉田雄大さん：「中途社員１人の開発チームにオンボーディングを持ち込んだ話」
- 今まさに中途の人と働いているので刺さる内容でした。
まとめ
開発手法はウォーターフォールでも振る舞いはアジャイルになれると思う。
— mono(0w0) (@msts_0w0) 2019年9月7日
ウォーターフォールの問題じゃなくて組織的な問題で上手くいかないことが多いんだよなー
#AgileJapanOsaka
パナさん、ちんもさんの現場感のあるお話が聞けて良い。
— mono(0w0) (@msts_0w0) 2019年9月7日
自分でも困っている部分なのでやってみよう。
#AgileJapanOsaka
懇親会でスピーカーの方とお話できたのももちろん良かったですが、2年前のサテライトで登壇されていた久保さんとお話しできたのが嬉しかったです。
— mono(0w0) (@msts_0w0) 2019年9月7日
#AgileJapanOsaka
Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス に参加した
現場でDDDを取り入れて2年くらいになるので半分答え合わせ、半分もっといい方法がないかなという期待で参加しました。
基調講演 ドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイル from 増田 亨
www.slideshare.net
増田 亨さんの基調講演。 自分がDDDを始めるきっかけになった方ですし、始めた時もメンバーにこの本の通りに作るからといって始めたくらい密かにお世話になった方です。
設計スタイル
ドメインオブジェクトに振り切った設計というのが印象的でした。 増田さんの本を参考にDDDを始めて、最も効果が大きかったのがここに現れています。 入出力を切り離すことで得られる恩恵はとても大きい。 クラス数はとても多くなるけれども一つのクラスはとても小さい。 循環的複雑度も最大で10くらい（Checkstyleで縛りいれた）になっている。 一つで何やっているかはとても良くわかるけど、全体として何やっているかを理解するのはちょっと手間。
- 関心の分離
- モジュール構造
- 20:80のとらえ方
- ドメインロジックの設計が80%に影響する
- ビジネスルールに登場する値・種類に注目
- 現場で戦いが起きる。負け戦だけど
ドメインロジックにフォーカス
この章で印象に残ったのは、「ユーザーは詳細な仕様に関心がない」ということ。 「そのために詳細仕様を補完し提案する。ユーザーからフィードバックをもらう。」の部分では首肯しまくり。
ユーザーは詳細な仕様に関心がない。聞いても出てこない。
— mono(0w0) (@msts_0w0) 2019年8月31日
だから補完と提案する。フィードバックもらう。
これは本当に現場のメンバーにやってほしいところ。
#mixleap #genbadeddd
ちょうど最近、メンバーがシステムの挙動についてユーザーにヒアリングする場面があり、それはユーザーに聞くのではなく、「この仕様でいきますが問題ありませんか」という提案型に変えようとアドバイスしたばかり。聞いても明確な答え得られないから。 他にも「ビジネスエキスパートから出てこないことが、契約書、利用規約、業務規約などから読み取れる。」などのノウハウも。
- ドメインの知識を学び続ける
- 要求の意味が理解できる
- 関係性や構造が見えてくる
- 詳細仕様の補完力と提案力が増す
- 時間とともに変化し続ける
- ドメイン知識のコード表現を継続的な改善
- fact、rule、goal
- 独自の型を定義
- 構造と秩序、バグ減らす
- 名前がコードの意図を表現
- 可読性の向上とコードの追跡しやすさ向上は実感しやすい
- ドメインロジック → ビジネスロジック
- ドメイン知識 → ビジネスルール
- 学び方
現場での結果と考察
ここも首肯しきり。 個人的な実感としては、長い間トランザクションスクリプトに馴染み切った人ほど脱却に時間がかかる。最初に躓く。 一方、若い人は素直に受け入れる。でも、その先に完全に思考を切り替えて定着させられる人はまた一部。 長いことやっているのでこのメリットをどれくらい感じているかメンバーに聞いてみようと思った。
- 考えて書く人
- 伝わる
- 入出力フォーカス設計スタイルは個人差
- 書かない人
- 言葉では無理
- 全員に伝えるのは無理く
- 相手の見たいものを見せる
- パッケージ構造に意識が向けられたらレベルアップの証拠
パッケージ構造に意識が向けられたらレベルアップの証拠。
— mono(0w0) (@msts_0w0) 2019年8月31日
この壁は高い、、、
#mixleap #genbadeddd
この辺が放置気味なので今後の課題。
DDDのモデリングとは何なのか、そしてどうコードに落とすのか
松岡 幸一郎さん
モデリングとは
- モデル：文脈によって異なる
- DDD reference参考
- ドメインモデル
- 問題解決のためのモデル
- データモデル
- 永続化のためのモデル
どうやってモデリングするのか
little-hands.hatenablog.com 参考サイトにも記載されていますが、個人的に「ユースケース記述」と「ルール・制約（＝ドメイン知識）」を併用する設計の仕方はうちのチームにマッチしそうな気がします。 重厚なドキュメントになりすぎず、設計を議論できるものが記載されているのが良さそう。もっと詳細化が必要であればクラス図やシーケンス図として表現したり、そのままコードに落とし込んだりできそう。
- RDRAとかユースケース駆動分析設計
- ユースケースとドメインモデル図で設計
- ユースケースの必要性
- 誰としてそのユースケースが必要なのかを定義する
- スコープの定義に使用する
- ドメインモデル図
- 集約の設計もここでやる
- ルール・ロジックは文章で設計する
モデルからどうコードに落とすか
形から入るの推奨。僕も以下を参考にしました。 github.com
- 形から入る
- 1ユースケースのお手本を用意しておく
- イメージできてから横展開が楽
- データモデルっぽいやつからリファクタリングしていく
- ルールはどこに実装しているか
- アプリケーション層にあるロジックをドメイン層に移す
- コーディング ⇄ モデリング
QA
ブログに質問への回答を記載されております。 参考になります。
- ORMはテーブルと一対一でない方がオススメ
- モデリング時間は1時間くらい
- 短いサイクルで繰り返す
- 実践DDDに集約とトランザクションは切り離せないとある
- 制約とかルールが明確なら値オブジェクト。無理に作る必要はない派
- アプリケーション層の入り口でトランザクションはる
- ユースケースでの記述とルール・制約は分ける
- エンティティからリポジトリは使用しない方が良い（アプリケーション層からにした方がいいんではないかな）
現場でドメイン駆動設計を広げるには何をすれば良いか？
安西 剛さん
インプット < アウトプット
参加者にアウトプットさせるようファシリテートをされていました。 隣の人と「なぜ今日来たか」「つらみの共有」「今後どうしたいか」などを短い時間（30秒程度）で共有しました。
DDDの広げ方
前半は経歴（つらみ）のリアルなお話があり、そこからタイトルの通り段階的に個人・仲間・組織へDDDを広めていくやり方について聞くことができました。 今の自分の課題は「本当に共感して仲間になってくれる人」を見つけてその人を中心にして「組織へ広げていく」ことと感じました。
- 誰もやってない
- 黙ってやる
- プロダクトコードで練習
- 自分はやっている
- 仲間を選択する
- 共感する人
- 話せばわかる人
- わからない人は巻き込まない
- 仲間を選択する
- 複数人でやっている
- 理解を広げる、深める
- 勉強会
- 上司を味方に
- 有識者に教えを請う
- 理解を広げる、深める
- チームでやっている
- いきなり全体でなく、チームを広げる
- チームをのれん分け
- 失敗しても影響がないところから
- 組織の2割を目指す
- いきなり全体でなく、チームを広げる
- 大きな絵を描く（戦略を作る）
- 整理整頓する
- 分ける
- 名前をつける
- 世界地図からつくる
- 横に分ける:パッケージを分ける
- 縦に分ける:アーキテクチャ
- クラスを作る
- やり方・あり方の両方を意識する
- 戦略と実装を行ったり来たりする
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
www.slideshare.net
ほげさん
導入
- 初学者に優しくない
- フレーズに抵抗
- 「君のドメイン層からは業務を感じない」
笑ってはいけないかと思うのですが、そのフレーズ最高でした。
試行錯誤
ほぼ独力で試行錯誤の軌跡がすごい。
印象に残ったアプローチが「インプット → メソッド名 → アウトプットを意地でも埋める（void消す）」というもの。 名詞＝クラス、動詞＝メソッド名とするのはロバストネス分析かな。この辺は一つのノウハウになりそうな感じ。
- 名詞を探す
- データの箱になる
- ドメイン層に集める
- テストが辛い
- 動詞を探す（voidを消す）
- イン → メソッド名 → アウト
- 意地でも埋める
- やっと絵がそれらしくなる（ここまでに2年から2年半くらいかかっている）
- returnするクラスが必要だ
ブレイクスルーの先へ
おまけと今後やりたいこと
エラー設計については色々悩んだところであるのでぜひ最終結果を見てみたい。
過去の失敗例から再考するモデル駆動設計
かとじゅんさん
とにかく「値オブジェクトの設計に注力」「ドメインオブジェクトに凝集させる」のアプローチ
軽量DDDでつまづいた
この中で印象に残ったのは「ユビキタス言語にない実装都合の用語で作られたオブジェクト」です。 おるわーって思っていました。
あとはRDRAは積んでいるのでしっかり読めってことですね。
- 通訳が必要になった
- エンティティ＝データ
- トランザクションスクリプト亜種
- ドメインモデル貧血症
- ユビキタス言語にない実装都合の用語で作られたオブジェクト
- RDRAで分析
- 値オブジェクトに注力
- 要件と行ったり来たり
- 値オブジェクトで扱えた方が表現力あがる
- ファーストコレクションで意図を表現する
- スケーラブルな設計
- ドメイン上の値はプリミティブでない
- 値の範囲、ルール、計算能力を持つ
- 値オブジェクトは不変にすること
- 予測可能な設計を作り出せる
- ドメイン上の値はプリミティブでない
集約の境界定義に試行錯誤
- 全部集約
- ルールと振る舞いが分離
- 集約を１つに
- 説明が難しいモデル
- 実装も大きくなる
- I/Oコストも大きい
- 説明が難しいモデル
まとめ
- PDR:Prep・Do・Review
- 設計もFail Fast
- コミュニティ活用
まとめ
ビジネス戦略・知識 と ソースコードの間を「行ったり来たり」早く失敗して、早く改善する。
— mono(0w0) (@msts_0w0) August 31, 2019
ビジネスエキスパートから表現されない部分を補完して提案してフィードバック得てまた作る。
とても実りある1日でした。
本日はありがとうございました。
#mixleap #genbadeddd
子どものほめ方・叱り方を学ぶ
娘の幼稚園で日曜参観の後に講師の方をお招きして講演がありました。子育てに関わることで上手なほめ方・叱り方を教えていただきました。 正直、一緒に仕事する大人にも当てはまる、参考になるなあと思ったので記録しておきます。
講師は、女性ライフサイクル研究所 Felianの桑田 道子さん。
子どもは
- たくさんのお世話と関心を必要とする
- 好奇心が旺盛
- できる以上のことに挑戦したがり失敗する
- 何度も同じことを言ってきかせる必要がある
- 子どもは自己主張をする
「子どもが子どもらしくあるだけで大人をイライラさせることはある」
人格の発達
エリクソンの発達段階。 小学校上がるまでに三段階、最終的に八段階の人格形成のステージがある。
- 基本的信頼
- できたことを認める
- アクナレッジ
- 自律性
- 気持ちを受け止めて言葉にする
- 感情と行動を区別する
- 他者を認めつつ行動できるようになる
- 自発性
子どもの好奇心に全て完璧に答えないこと「なんで？」に対しては「なんでだと思う？」のように考えさせるように問い返すことも必要。
大人のすることは魅力的。能力の多寡は考えずにやりたい気持ちが湧く。
大人からすると同じことでも場面が違うと応用ができない。そのため何度同じことを言わせるの⁉︎となりやすい。
子供の自己主張を成長の階段を登る途中と考える。
上手な叱り方
「しつけ」とは「親の価値観を伝える」ことである。
大切な価値観と言われるとアジャイルマニフェストとかモダンアジャイルを思い浮かべてしまうw
- みんなを喜ばす、尊重する
- 安全であること、安全にすること
- 挑戦・失敗・学習・再挑戦
- 継続すること
自律性を育む
怒られるからダメという理解では、「他者コントロール」にとどまっている状態。
上手に自律性を身につけるために
- 理由を尋ねる（問い詰め口調はNG）
- 気持ちを受け止める
- 子どもが気持ちを表現する機会
- 行動の変化を促す
- 次はどうできるかの相談
- 注意したあとのフォロー
気持ちと行動の区別を教えることが自律性を育む
叱るコツ
- 一度に１つだけ
- 過去のことは持ち出さない
- 行動について叱り、子ども自身を否定しない
- 短く切り上げる
- 「〜しない」よりも「〜する」言い方
- 選択させる
- たくさんほめる、すかさずほめる、うまく言っていることを見逃さない
まとめ
子育てには子育ての難しさが、エンジニアリングマネジメントにはエンジニアリングマネジメントの難しさがありますが、どちらも人に向きあってこそ成し得るものだなと再確認できた日でした。
やるべきことにフォーカスする エッセンシャル思考読んでみた
- 作者: グレッグマキューン,高橋璃子
- 出版社/メーカー: かんき出版
- 発売日: 2014/11/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (19件) を見る
プロジェクトリーダーという役割柄、時間の使い方を見直す必要性は常々感じていました。 しかし、「時間が足りない」「分身できたらいいのに」という言い訳をしながら、力技で仕事を続けてしまう癖が抜けず、2015年から始まったプロジェクトで心身ともにかなりやられてしまいました。
2017年にアジャイルに触れてからは仕事だけでなく、家族との時間や個人的な時間の使い方も大切にしなければという思いが強くなってきたのもあり、「エッセンシャル思考」という言葉だけはどこかで聞いたことがあったので本を取ってみました。
一番刺さったのは、2章の 「選ぶ」ことを選ぶというもの。
ふと、「何ができるか」という思考から「何をしたいか」という思考に変わってきたなぁと思った。
— mono(0w0) (@msts_0w0) 2019年4月16日
自分の枠を広げたり、越境したりという意識・感覚を持ててるのかなー。
こんな風に思える様になったのも、自分で選んだからだと感じています。
また、この本を読んでいる時にジャンプで見たハイキューの一コマもグッときました。
自分がコントロールできるものに集中することを意識することで日々の仕事への取り組み方が変わってきました。 やるべきことが無限に湧いてくる様に感じているかつての僕みたいな人に読んでもらいたいです。
以下、読書メモ。
エッセンシャル思考とは何か
１．エッセンシャル思考と非エッセンシャル思考
- より少なく、より良く
- 自分で優先順位を決めなければ、他人の言いなりになってしまう
- 規律なき拡大は失敗への道
- 最高の成果
- 正しい理由（Why）
- 正しいこと（What）
- 正しい時期（When）
２．選択
- 選ぶ力を取り戻す。
- 「選ぶ」ことを選ぶ。
- 選ぶ能力は誰にも奪えない。ただ、本人が手放してしまうだけだ。
３．ノイズ
- 大多数のものは無価値である。
- 80対20の法則（パレートの法則）
- 決定的に重要なことだけをとる。
４．トレードオフ
見極める技術
５．孤独
- 考えるためのスペース・余裕をつくる。
- 集中するためには、集中せざるを得ない状況に自分を置くしかない。
- 本を読む時間をつくる。
６．洞察
- 情報の本質をつかみとる。
- ノイズの中のシグナルを探す。
- 語られないことに耳を傾ける。
- ジャーナリストの目
- 日記をつける
- 現場を見る
- 普通を知り、逸脱を探す
- 問題を明確にする
７．遊び
- 内なる子供の声を聴く。遊びが不可欠・重要だと知る。
- 遊びが大切な理由
- 選択肢を広げてくれる
- ストレスを軽減してくれる
- 脳の高度な機能を活性化する
- 遊びは本質を探求するのに役立つだけでなく、それ自体がどこまでも本質的である。
８．睡眠
- 1時間の眠りが数時間分の成果を生む。
- 自分自身という資産を守る。
- 現在人の最優先課題は、優先順位づけの能力をキープすることだ。
- 睡眠がそれを可能にする。
９．選抜
捨てる技術
10．目標
- 最終形を明確にする。
- 意味があり、心に残る本質目標。
- 本質を見据えて生きる。
11．拒否
- 断固として上手に断る。
- 上手にノーという技術
- 断り方のレパートリー
- とりあえず黙る
- 代替案を出す
- 予定を確認して折り返します
- 自動返信メール
- どの仕事を後回しにしますか
- 冗談めかして断る
- 肯定を使って否定する
- 別の人を紹介する
12．キャンセル
- 過去の損失を切り捨てる。
- もしまだ投資していないとしたら、今この企画に投資するだろうか？
- 途中で辞めることは難しい
- 授かり効果（所有することで価値が上がると感じる心理的バイアス）
- もったいないを克服する。
- 逆プロトタイプ（やめてみたときの影響を検証する）
13．編集
- 余剰を削り、本質を取り出す。
- 編集の4原則
- 削除する
- 凝縮する
- 修正する
- 抑制する（手を出しすぎない）
14．線引
- 境界を決めると自由になれる。
- 境界を決めることで本当の力が発揮できる。
- ノーと言わなくても良いようにあらかじめルールを設定する。
しくみ化の技術
15．バッファ
- 最悪の事態を想定する。
- 準備と計画に全力を注ぐ。
- 見積もりは1.5倍で考える
- リスクマネジメント戦略
- どのようなリスクがあるか？
- 最悪の場合、どのようなことになりうるか？
- 周囲の人への影響はどのようなものがあるか？
- そのリスクは自分（会社）にとってどの程度の経済的負担となるか？
- リスク軽減のために、どのような投資を行うべきか？
- リスク軽減のための投資＝バッファ
16．削減
17．前進
- 感情・モチベーション・認知を高める要素の中で最も重要なのは「進歩している手応え」である。
- 「終わらせること」を始める。最小限の進歩を積み重ねる。
- 「早く小さく」始める。
- 進歩を目に見える形にする。
18．習慣
- 本質的な行動を無意識化する。
- 正しい習慣を通じて自然に達成する。
- 重要なことをやるのが普通の状態。
- 悪い癖を正しい習慣に変える方法
- 行動を引き起こすトリガーを知る
- 新しいトリガーを作る
- 難しいことから手をつける
- 曜日ごとにやることを変える
- 習慣づくりはひとつずつ
19．集中
- 「今、何が重要か」を考える
- 集中の対象をひとつに決める
- 未来を頭の中に抱えない
- 優先順位をつける
- マインドフルネス
- タスクフォーカス
- 自分がコントロールできるのは、自分の思考と行動だけ
- 重要なのは常に「次自分にできる事とすべき事」
20．未来
- 自分の中心にエッセンシャル思考を据える
- 考え方が心の底までしみこんだとき、それは自分を内側から変える力となる
- 本質を知り、本質を生きる
- 迷わない
- 流されない
- 日々が楽しくなる
21．エッセンシャル思考のリーダーシップ
- 少数のことをより良くやる
- 正しい情報を正しい人に正しいタイミングで伝える
- 意思決定のスピードと質を追求する
| 項目 | エッセンシャル思考 |
|---|---|
| 方針 | より少なく、より良く |
| 人材 | 選別にこだわり、邪魔な人材は排除 |
| 戦略 | 何かひとつだけしかできないときに何をするか |
| タスク分担 | メンバー特性と目標に適材適所 |
| コミュニケーション | 耳を傾け、本質を見抜く |
| 部下育成 | 小さな進捗を重ねているか適切にチェック |
| 成果 | チームがまとまり、決めた方向で飛躍的な成果を上げる |
自分の強みを活かすためにストレングス・ファインダーやってみた
さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0
- 作者: トム・ラス,古屋博子
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2017/04/13
- メディア: 単行本
- この商品を含むブログ (2件) を見る
職務経歴書やリーダー・マネジャーの自己開示資料に自分の強みや嗜好（指向？）みたいなものを書いておこうと考えていたのでやってみました。
結果は以下の5つ。
- 収集心：「戦略的思考力」
- 学習欲：「戦略的思考力」
- 達成欲：「実行力」
- 個別化：「人間関係構築力」
- 分析思考：「戦略的思考力」
思いのほかズバリと自分の傾向を言葉にして表現されて驚いた。 強みとして表明しやすくなるし、傾向を知ることで注意する点もわかって良い。 戦略的思考力が多いのでそういう役割とか向いてるのかも。
- 情報やデータを重視し、収集・分析によって戦略を立て論理的・現実的な方法で問題・課題を解決に導きます。
- メンバーの強みを活かし、チームや組織をつくり育てることで成果を出すことができます。
- 継続的な学習を重視し、個人やチームの成長を促進し、組織を安定させること、拡大することに貢献できます。
わあ、優秀な人っぽいwww
以下、分析内容と感想メモ。
収集心
あなたは何らかの特定のグループ内で最も賢い人または最も博識な人として高く評価されたいと思っているかもしれません。
承認欲求が強い、かつ、他者と比較した評価に陥りやすいのは注意しておかないと病みやすい。自己肯定感を強めていきたい。
あなたは、 良質な本を読んだり、記事に夢中になったり、インターネットで情報を集めたりすることにより、日常生活の緊張、圧力、ストレスなどから逃避することができます。
ストレスが高まると漫画や小説を読む量が増えていた気はする。
生まれながらにして、あなたは、 物事を自分のペースでやるのが好きです。
嫁によく言われる。計画外や予想外のことを嫌う。
自戒
— mono(0w0) (@msts_0w0) 2019年3月28日
* 自分の不満や要望をきちんと言葉にして表明する。我慢し続けてからキレない。
* 予定や予想を覆されて固まらない。現状把握と優先順位からアクション決める
* 自他ともに失敗を重く受け止めすぎない。早く立ち上がって挽回する方に努力する。
学習欲
あなたは学ぶことが大好きです。
最近、特にそう感じる。
自分に知る権利がある、あるいは知る必要があると思っていることを他の人があなたに伝え忘れたり、伝えることを拒否したりすると、動揺することがあります。
期待値のすり合わせが必要なんだろうなと思っています。役割に応じた責務と権限をきちんと整理したい派。自分がそうされたいので部下にもそう接していこう。
あなたの活発な精神は、毎日同じことを同じように行っているとうんざりしてくるのでしょう。
ルーチンワークは苦手。アイテム収集のため同じルートをひたすら周回するのに耐えられない。でも、程度によるかも。
グループの一員として仕事をすることを好みます。 興味のある活動や挑戦を行っているチームに惹かれます。
1人で黙々はあんまりやらない。同志がいると張り切る。外に目を向ける、人から学ぶことは大切。これを理解するまでにだいぶ時間かかったな。
達成欲
あなたは、 通常、自分自身を実務的で現実的であると考えています。
理想があって現実的な方法で解決したい。
あなたは、 所属しているチーム、クラス、またはワークグループが目標に到達するために長時間働くという評判を得ているでしょう。
長時間労働はやめたい。短い時間で確かな成果を出せるようにしたい。
どんなに今日は休もうと思っていたとしても、何も達成することなくその日が過ぎてしまうと、あなたにはわずかにでも満たされない思いが残るでしょう。 〜 達成欲の旺盛なあなたは、このわずかに満たされない気持ちとうまくつきあっていけるようにしなければなりません。
納得せざるを得ない。 小さな達成感を多頻度に得られるようにハードルを下げて習慣化するところからやろう。
あなたは職場のペースメーカーとなり、生産性のレベルを上げることができます。
やります。
個別化
あなたは、 困っている人を支援することで、大きな喜びを得ます。
そんな役割や組織で働きたいと強く思うようになった。
あなたはほかの人の強みをとても鋭く観察する人なので、ひとりひとりの最もよいところを引き出すことができます。
なかなか自分では自覚できない。メンバーの評価の時にその手の感想を言われたことがあったけど本人は全然わからない。雰囲気でやっている。
あなたは優秀なチーム作りの秘訣は、各自が得意なことを充分に発揮できるような、強みに基づく配役である、ということを本能的に知っています。
本能的に知っていたら過去の失敗はなかったかもねー。失敗したから本気で考える様になったのだけど。 ともあれ、やりたいことと強みが一致しているのは嬉しい。
分析思考
あなたは、 グループの計画に論理的な視点をもたらします。
ロジカルであることは重要だし好きですが、最近は感覚的なところもあるかな。
多くの場合、あなたは、 勝敗を決める何らかの特定の状況に対して、実践的で現実的な方法を取るようです。
実践的・現実的がまた出てきたので、絵に描いた餅は嫌いなんだろうな。形からでも役に立つHowに飛びつきやすい。
あなたは必ずしも他人のアイデアを壊したいわけではないのですが、彼らの理論が堅固であることを強く求めます。あなたは自分自身を、客観的で公平であると考えています。 あなたの分析結果を伝える時、できれば決して厳し過ぎないようにしましょう
新人の時に参加したプロジェクトの品質分析手法を徹底されていたので染み付いてしまってる感ある。強要されたことは他人に強要しやすいので気をつけよう。
あなたはデータを好みます。データは人々の考えに左右されず、ありのままだからです。
事象と推測と意見は分けてくださいとはよく言う。
Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説！ に参加した
内容が濃すぎてつぶやく暇もなく。ドメイン駆動設計始めようとしてるチームに支援に行くので伝えよう。すでに増田さんの本は推薦しておいたし。 #mixleap
— mono(0w0) (@msts_0w0) 2019年4月4日
以下、当日とったメモ。整理しきれていないけどこのままだといつまでも書けないと思ったのでそのまま。自分用に残す。
Mix Leap Studyについて
- 情報共有を定期的に行う場
- Yahoo社員・社会人・学生の交流
プラットフォームとサービスを支える設計
- クラウドネイティブ
- ヤフーもクラウドネイティブへの移行を進めている
- スクラム(開発プロセス)
- 問題発生のリスク
- 変更が怖い
- スケールできない
- マイクロサービスが密結合
- ドメイン駆動設計
- 設計に洞察力を与えてくれる
思いやりのある命名をしよう
- エヴァンス本：諦める
- 実践ドメイン駆動設計：
- 命名にどれだけ時間使いますか？
- 自分の書いたコードを理解できるようにするため
- 他の人(未来の自分も)がコードを理解できるようにするため
- 良い命名：仕様のどの部分を表現しているかわかりやすい
- 下地
- よく使われる命名を覚える
- ルールを決める
- アンチパターンの場合は、Howを考えて直す
- コードとの距離が遠くなれば情報の鮮度が落ちる
- 伝える方法は目的に応じて選択する
DDDサンプルのお話
- 作った理由：コードが一番具体的、質問も具体的になる
- 核心にある複雑さに立ち向かう
- 設計の大原則：関心の分離・モジュール構造の工夫
- 3つのキーワード
- 要点を絞り込む
- ビジネスルール：データモデルで頑張ろうは書いてない(エヴァンス本)
- 計算モデル：
- 型指向のプログラミング：
- 関心の分離の工夫
- 計算(ビジネスルール)を実行するモジュール群
- データを入出力するモジュール群
- この２つを徹底的に分ける
- モジュール構造の工夫
- サンプルは給与計算アプリケーション
- 給与：Payroll
- ドメイン層
- アプリケーション層
- ビジネスルールの記述を独立させる
- 理論的にはアプリケーション層はシンプルになる
- 現実は複雑な記述が残りやすい
- 要素分解
- Factoryサービス：計算モデルのインスタンスを生成する：データソース層で事実を元に生成
- Queryサービス：計算結果を返す：プレゼンテーション層へ
- Operationサービス：計算結果を記録/通知する：データソース層へ
- 複合サービス(要素サービスをDI)→要素サービス(repositoryをDI)
- 複合はcoordinator：repositoryは見ない
- QA
- データソース層とデータベース
- 計算モデルとデータモデルのマッピング
- 事実としてどのように記録する ことと 事実をどのようにして計算する かはそんなにインピーダンスミスマッチ無いよ
- SELECTの実行＝計算用のオブジェクト生成
- 記録すべき事実を持ったオブジェクト＝INSERTの実行
- RDBの設計は特定のアプリケーションから独立させる
- イミュータブルデータモデル：事実の履歴＋最新状態
- UPDATEは使わない
- 川島さんのスライド
- 制約指向：NOT NULL制約、外部キー制約
- DBに日本語命名が良い
- Mybatisの実装でas句を記載するとresultMapタグがなくなる★
- QA
- coordinatorがまとめて取得してという性能
- データベースの箇所には大量データとの戦いがある
- 業務に本当に必要なのか考える
- プレゼンテーション層
