radioc@?

作業管理
作業の標準化
作業管理のために最適な組織形態

この3つ原理で労働者を管理する手法ですが、前出のような働きがいの価値の変化によってこのような労働者を縛り付ける管理手法は欠点があると認識されています。

2要因理論

そしてもう一つ引用されている有名な理論がハーズバーグの2要因理論です。

www.motivation-up.com

満足感を引き出す要因（動機づけ要因）と不満要因（衛生要因）は切り離されたもので別々に対処すべきであるという理論です。職場環境を良くして衛生要因を高めてもそれは不満の解消にしかならず、満足感が引き上げられるわけではないというものです。

達成動機を刺激するモチベーション・マネジメント

達成動機

心理学者マレーの研究

人間は独力を以って高水準の目標を達成しようとする欲求があり、これによって行動が規定されると仮定し、達成動機には成功願望と失敗恐怖の二つの欲求から構成される

成功したいという欲求と失敗を恐れて回避したいという欲求のバランスをマネジメントするということです。

アトキンソンの公式

達成動機の理論に対してアトキンソンが提議した公式です。

www.create-ts.com

達成に向けて喚起されるモチベーション＝Ms（達成動機）×Ps（成功確率）×Is（成功の誘因価）

達成動機のモチベーションを上げるには成功確率や成功の誘因価を高めるマネジメントが求められます。例えばスキルを上げる（成功確率）、達成の意義を説明する（誘因価）などです。

回避に向けて喚起されるモチベーション＝Mf（失敗回避動機）×Pf（失敗確率）×If（失敗の負の誘因価）

回避動機に対しても基本的に同じで、スキルを上げて失敗確率を低めたり、失敗したときの心理的不安を和らげるなどのマネジメントが求められます。

内発的動機づけによるモチベーション・マネジメント

X理論・Y理論

マクレガーが提唱したこれまた超有名な理論です。

X理論はいわゆる「アメとムチ」の理論で、人間は怠け者なのでアメとムチを与えなければ働けないという考え方です。
Y理論は人間はもっと高次元な欲求を持っていて目標に向けて自主的に行動することができるという考え方です。

外発的動機づけと内発的動機づけ

デシ教授の実験により内発的動機づけという考え方が生まれました。

millkeyweb.com

X理論のように外から報酬を与えられることで行動を起こさせることを外発的動機づけと言います。ところが、デシ教授の実験では報酬がなくても熱心にパズルを解く子供が確認され、報酬を与えることでむしろ意欲が低下することもわかっています。

自己を有能で自己決定的であると感知することができるような行動

これが内発的動機づけです。

職務特性モデル

ハックマンとオルダムは内発的動機づけを高める職務特性を5つの要素でまとめました。

www.earthship-c.com

多様性
完結性
重要性
自律性
フィードバック

これら5つの職務特性を知覚することでモチベーションを高く維持できるというものです。

外発的動機づけによるモチベーション・マネジメントの工夫

デシ教授の実験で外発的動機づけの欠点が指摘されたとはいえ、誰しも全てにおいて自己目的的に行動できるわけではなく、外発的動機づけが必要な場面もあります。

自己決定理論

内発的に動機づけられるようになるまでの外発的動機づけの段階を分類した理論です。

learn-tern.com

以下の4段階で内発的動機づけに近づいていきます。

外的統制
取り入れ
同一化
統合

褒め方のモチベーション・マネジメント

ドゥエック氏はパズルの実験で能力を褒めた子供と過程を褒めた子供のグループでは後者のほうがモチベーションを維持して成長できることを発見しました。

wired.jp

原因帰属スタイルでモチベーションを高める

原因帰属理論

失敗の原因を何に帰属させるかという原因帰属のスタイルを統制（内的統制/外的統制）と安定性（安定/不安定）の組み合わせで4つの要因に分類する理論です。

psychologist.x0.com

	内的統制	外的統制
安定的	能力	課題の困難度
変動的	努力	運

安定的というのは変化しないものに原因帰属させることを意味します。例えば内的統制型の人はうまくいかなかった時に「能力が無かった」と考えるとモチベーションが下がります。これを「努力が足りなかったんだ」という変動的に変えることでモチベーションを維持できます。

気分や感情でモチベーションを高める

インナー・ライフ・ワーク

アマビールとクラマーが知的労働者のパフォーマンスを決定づける重要な要因を研究しました。

studyhacker.net

次の3つの要素が影響を及ぼして仕事のパフォーマンスを決定しているとしています。

認識
感情
モチベーション

状況認知でモチベーションを高める

楽観主義と悲観主義

ノレムとキャンターの研究で楽観主義・悲観主義を4つのタイプに分類しています。

diamond.jp

戦略的楽観主義：過去と未来のパフォーマンスに対してポジティブな認識を持つ
防衛的悲観主義：過去のパフォーマンスにはポジティブだが将来には悲観的
非現実的楽観主義：過去のパフォーマンスにネガティブだが将来にはポジティブ
真正の悲観主義：過去にも将来にもネガティブな認識

戦略的楽観主義と防衛的悲観主義が良いパフォーマンスを発揮できるとされています。つまり、必ずしもポジティブな心理状態にすることが良いパフォーマンスを生み出すとは限らず、防衛的悲観主義者の場合はむやみに安心させるようなサポートよりも不安を抱えながらもやりたいことをやり通せるようなサポートが必要になります。

自己認知でモチベーションを高める

学習性無気力感

セリグマンの「オペラント条件づけ」によって提唱されました。

長期にわたってストレスの回避困難な環境に置かれた人や動物は、その状況から逃れようとする努力すら行わなくなるという現象

要するにどうせ頑張っても無駄だという事を学んでしまってやる気を失うことです。

自己効力感

反対にやればできるという期待をモチベーションに変えることが自己効力感です。

heart-quake.com

心理学者のバンデューラは自己効力感を高める4つの方法を提唱しています。

成功体験
モデリング（代理体験）
人からの説得
生理的・感情的状態

自動動機理論

無意識的に動機づけが行われる状態のことを自動動機理論と呼びます。

shuchi.php.co.jp

ランダムに並んだアルファベットの文字列の中から特定の単語を見つけ出す実験で「成功」や「達成」のようなモチベーションを刺激する言葉を見つけたグループはパフォーマンスが高かったという結果が得られたそうです。

関係性によってモチベーションを高める

自己決定はモチベーション向上の重要な要素ですが、日本人の場合は大事な人のために頑張るという傾向もあります。そのため日本的なモチベーション理論では他者との関係性が重要であるとされています。

ピグマリオン効果

期待を伝えることでそのとおりに変容していく効果があるとして、それをピグマリオン効果と呼びます。

agilejapan-osaka.connpass.com

期待することの効果は関係性のうえでも重要だとされています。反対に期待をかけずこの人はだめだというレッテルを貼ることで起こる状態を「ダメージ症候群」と呼び関係性のうえではこのような態度を無意識的に相手に与えてしまわないように注意する必要があります。

目標管理によってモチベーションを高める

目標を設定することでモチベーションを高めるマネジメント手法が目標設定理論です。

フィードバック

目標設定理論を研究したロックとレイサムによると、目標管理の中でモチベーションに影響を与える重要な要素がフィードバックであるとされています。

www.hitachi-systems.com

2019-09-07

【勉強会メモ】もうかりまっか？Agile Japan 2019 大阪サテライト

勉強会アジャイル開発 Scrum

日時：2019/09/07(土) 13:25 〜 19:00
場所：エムオーテックス新大阪ビル

7月に開催されたAgile Japanの大阪サテライトです。私は当日現地で参加したので、その時のレポートを会社のブログに書いています。

tech-blog.rakus.co.jp

また、基調講演と特別講演の資料は公式ページから参照できるようです。

www.agilejapan.org

今回はLT枠にチャレンジしました。LTなので気楽にできると軽い気持ちでエントリーしましたが、アジャイル界のすごい方々に挟まれてしまい重い気持ちでなんとかやりきりました…大きな会場でのLTはめったに無い機会なので良い経験になりました。
最後は懇親会、2次会、3次会と、終電近くまで参加させて頂き、1日通して色々と学ぶことが多く明日からまた頑張ろうと思えるイベントでした。

【映像視聴】Agile Japan 2019基調講演「マネージャー不在の洞窟型組織」

GROOVE X 株式会社代表取締役
林要氏

ラボットの開発

lovot.life

2018年末に発表
日本だけでなく海外でも高反響

マネージャ不在の洞窟コンセプト

マネージャの機能を各役割に分解
一箇所で顔を合わせながら仕事をする
- 週1回テレワークなどはある
スクラムはフラット型組織のほうが相性がいい
未知の領域の仕事では「初期が一番知識がない」

LOVOT開発＝生命の進化プロセスを4年の開発期間で再現

早く試して、早く学ぶ
- 実際にやると大変⇒不安
- コロンブス新大陸発見と同じ⇒不安との戦い
- 見える化して不安解消
  - アジャイルに必要な能力⇒見通しの悪いところで遭難しない能力
スコープがよく変わる
- 曖昧な領域にグレーゾーンが生まれる⇒リカバリに時間がかかる
- フラット型組織はお互いに全体最適化を目指す
  - 横のコミュニケーションコストが小さい
  - 各人が説明責任を負う
  - 変化が多い場合に運営コストが低く失敗が少ない

イノベーションにおいて大切な能力＝Learning agility

Learning agilityが高い人は飽きっぽい人
飽きた人を同じ仕事に縛り付けるとLearning agilityが下がる
最大の敵は「飽き」

⇒積極的に「飽きている」ことを認め、覚悟を決めると、生産性はあげられる

スクラムのメリットまとめ

複雑なプロジェクトの可視化
- 不安を減らし、やるべきことが見えるようにする
船頭を一人に保ちながら、チームの自立性を維持する
- ヒエラルキー型では「服従の心理」の呪縛が抜けない
フラット型組織でスクラムを運営すると、職場に活気がでる
- スクラム運営は難しい、ヒエラルキーとも対立しやすい
本当に概念は簡単、習得は難しい
- アジャイルコーチ、スクラムマスター、研修等にコストをかける

【映像視聴】Agile Japan 2019特別講演「”Agility-Native”を実現するITマネージメント」

SOMPOシステムズ株式会社　代表取締役社長
損害保険ジャパン日本興亜株式会社　取締役常務執行役員
 浦川伸一氏

IT部門
- 70人ぐらい
- エンジニアの大半は子会社

今、なぜAgility-Nativeか

ユーザーIT部門の危機感

日本ではIT人材の70〜80%はIT業界に流れ、ユーザー企業のIT部門は技術が空洞化

ベンダー依存も限界

ソリューションの超サイロ化
マルチクラウド環境の常識化
AI開発の拡大
アジャイル開発へのシフト
Solution-Silo化
ソリューションが多様化、細分化され、多数のベンダー、SIer、ソリューションプロバイダーとお付き合いしないとIT環境が揃わない
AI-Ready化
AI技術そのものの習得に加え、データサイエンス、機械学習工学などの知見を要する

www.keidanren.or.jp

Cloud-Native化
インフラ整備にかかる時間とコストを大幅に短縮、SIer依存度の低減にもつながる
仮想化技術、オーケストレーション機能の統合化で物理環境を意識しないコンピューティング環境
Agility-Native化
ホスト系からオープン系、パッケージ開発など幅広いシステム環境に対応
DX対応を自社にある程度取り戻すために必要

システム変革の取り組み

開発力強化のための主要施策

IT部門戦略の整備
専門職制度の確立
組織の再編
Agility-Native化
採用拡大と自前化

結局のところ、組織力と個の力を高めるしかない

組織の再編とローテーション

IT部門を3レイヤーに再編し、約40%のローテーションを実施

現行システムレイヤー⇒現行システムの維持と高度化
次期システムレイヤー⇒基幹系のオープンテクノロジー化
デジタルレイヤー⇒徹底した最先端技術の習得

人材戦略

Skill Frameworkを決める
スペシャリスト認定制度

アジャイル型組織運営

アジャイル開発を阻む3つの壁

ベンダー依存体質
ユーザーとの距離
漠然とした抵抗感

開発生産性なんて5年間かけても1%も上がっていない実感

Agility-Native化

ビジネスとITが協働する組織
自主的に改善し続ける組織
反復手法による段階的変革

2019年度から3可燃計画で全社導入予定

チームビルディング塾

17時には疲れて帰りたくなるようにする
プロダクティビティ

組織構造の見直し

シンプルかつ専門性を共有する組織構造へ
パートナー社との関係
開発統制の変革
自立型の運営へシフト

課題

パートナー社の理解
リモートアジャイル体制の試行
チームによっては内製化シフト

パートナー社の理解

パートナー側へもアジャイルミラー組織を構成

内製化orフルアウトソーシング化

工程を一部アジャイル化

一部工程のアジャイル化〜フルアジャイルまで4パターン

アジャイルで先行するビジネス部門

デジタル戦略部でのSprint体制
- PoCから本番化まで

IT部門変革の成果

ビジネス&IT部門の一体運営への進化
専門職制度や公的資格取得の定着化
Agitity-Native全面シフトを開始
デジタル/AI実装の自動化

まとめ

事業会社のIT改革は長期戦
経営層がアジャイルが大事だと思わないと進まない
日本の事業会社のITの力を高めなければ経済発展しない

アジャイル開発におけるITベンダー・メーカーの品質保証／検査の取り組み

パナソニック株式会社
インダストリアルソリューションズ社(IS社)
技術本部プロセスデバイス革新センターシステム技術開発部係長
水田恵子氏
パナソニック株式会社
インダストリアルソリューションズ社(IS社)
メカトロニクス事業部技術開発センター主任技師
島﨑尚史氏

資料の公開NGとのことで詳細は割愛。ビジネスゴールから逆算してアジャイルに変えていく取り組みの話でした。多くのユーザーが存在する大企業のメーカーならではの課題と、それに向き合ってアジャイルに取り組むテーマは、古いしがらみに縛られて苦労している現場には参考になる内容だと感じました。

田舎で11年スクラム

リコーITソリューションズ株式会社
福田朋紀氏

前回：田舎で十年スクラム

社内の壁は壁でなくなる＝放置される

長期安定、仕事は不安定
Fearless Changeを地で行く
- 都会にもスクラムがじわる感じに

続けるために

方針を大事に＝ブレずに長期間同じ方を向く
何を褒めるか＝助け合い、技術を発信する
1on1＝「人生という旅」とのすり合わせ
プロダクトマネージャー＝選び選ばれ
ファンづくり＝都会の人と仲良くとにかく仲良く

チームは13年にしてならず

半数が10年戦士
スクラム2つ（6名、4名）
小規模プロジェクト4,5子
- 泡沫（毎年1,2つポシャる）スクラム、できる規模になるのは数年に1つ

13年チームの仕上がり

なんか勝手にやってる
勝手に何か作っている

基本Z戦士たちにおまかせ

SMの挙動

Slackを眺めている
意味もなくうろうろ

Scrumの外縁

営業、契約、予算ぐり
審査承認ｍ
上司とのコミュニケーション
アジャイルの戦略、企画、教育、宣伝

上手く行かない時

「下請け根性」がたまに顔を出す
- どうしたら良いでしょうか？
水浸から作ったプロセスに
- 書いてないのでしてません

POがものすごくがっかりする

肩を組んで進んでたと思ったのに
- あの時一緒に話したじゃん
- そういう返し、期待してない…

SM介入

そもそも僕らは何をしたいんだっけと問う
こういう方法もあるよと選択肢を出す
- こうしたら良いじゃんと言いがち
- Z戦士はスルーしてくれる
POに会いに行って直に話す

13年チームの課題

信頼が揺らぎそうな時を自分たちで察知できるようになりたい
自分たちのプレーに再現性がない
- 状況を的確に捉え、効果的なプレーにつなげたい
- 自分たちのゲームモデルに追加したい

ゲームモデル（サッカー用語）

チームの各選手がゲーム中に共有しておかなくてはならない「脳内映像」
- 局面でのプレー選択の基準
- 例）攻撃時のボール循環

サッカーから学ぼう

不確実性の高いチームスポーツ
スポーツ市場規模世界最大

不確実性

そもそもミスは避けられない
現場で起きることを事前に予測しきれない

サッカーの課題と対応策

クラブの価値観をサッカーの戦術とどうせつぞくするか
ゲームモデル
生態系トレーニング
環境の変化・進化にどう対応するか
研究成果

⇒課題が同じ

ゲームモデル

ビジョン
状況と課題
解決策と結果
行動原則
準原則

ゲームモデルとアジャイル

状況と課題、解決策と結果⇒パターンが使える？
ビジョン、行動原則⇒アジャイル原則

もう少し現場に即していて無意識に落とし込めるイメージ

チームに起きる状況

受注、失注
バグ発生
PO失望
スクラムイベント

状況のモデル化と解決策

フィールドを縦に5レーンに分け、4バックに対して常に2択を迫るみたいなことをしたい

開発チームの原則

Fix it now
- リリース後にバグが出たら全ての作業を止める
リードタイムにこだわる
- 一個流しほど言語化できていない

日常のしごとの進め方につなげる準原則が必要そう

14年チームでやりたいこと

パタンで自分たちのゲームモデル
再現性

次のRSGTまでに完成させる

confengine.com

あたらしいビジネスとアジャイル

西日本電信電話株式会社
太田敦士氏

おっさんが勝てる価値＝経験

唯一の価値
儲かる（勝ちがある）かどうか判断するための自分だけの教師データ
仕事だけではない
芸人さんがいう芸の肥やし的なもの
ぼーっと生きてたら唯一の価値である経験が蓄積できない

経験のためのODD（Okan driven design）おかん駆動設計⇒昔おかんにいろいろ言われたこと

HAY
- ほんなん言うんやったらあんたやりーや
- 当事者意識
Y2U2
- よそはよそ、うちはうち
MTT
- まだ食べれる食べとき
- チャレンジ精神
IES
- いやーそれええと思うわしらんけど
- サーバント・リーダーシップ

かけっこ⇒経験値を呼び寄せるためのキーワード

感謝
謙虚
好奇心

新規事業開発宣言

あらゆる人との対話
小さな実例
社外への提案
変化に敏感に気づくこと

はげちゃびん問題について考える

川口恭伸(YesNo)さん

Agile Japanの応援ビデオメッセージに関する話でした。自分のLTの直前だったのであまりメモを取れていません…

www.youtube.com

技術があんまりよくわからないマネージャや経営層
組織階層の上に行くとどこかではげちゃびんに当たる
わからない人に説明する資料に時間を取られる
- 想定している知識量の差
実は現場とはげちゃびんの中間にいる人がわかっていない
GAFAなどの本当に儲かっている会社ははげちゃびんがいない
はげちゃびんの構造に着目して変えていけば新しい世界が見えるかもしれない

Re:ゼロから始めるアジャイル開発

発表させてもらいました。

進化論からのアジャイル

kyon_mmさん

アジャイルの現場にあるの

チームの構成論
プラクティス
プロセス

効率的に仕事をすすめるため

蟻はなぜこれらを変化させない
人間も固執したりする
雰囲気で蟻と人間を区別している

ダーウィンの進化論

進化心理学
人類は自己欺瞞の生物である

アジャイル開発は政治を耳障りよくした概念

人類の進化でロールをみる

プロダクトオーナー、顧客
- チアリーディングで自己欺瞞して集団を変化させる
SM、ファシリテート
- 献身的な振る舞いにより集団の尊敬と信頼をあつめる
デベロッパー
- 第三者として違反に対する制裁を与える

ほかのことも進化の視点でみる

レトロスペクティブ
- 規範をつくりあげる
ペアプロ、モブプロ
- 同盟を作る

アジャイルプラクティスにたいする懸念は正しそうにみえる

ペアプロ・モブプロは時間をかけすぎ？
プロダクトを作り上げるだけでなく同盟を強固するという目的がつよくはたらいている

1万年前の人類に立脚した手法をつくるの楽しい

中途社員1人の開発チームにオンボーディングを持ち込んだ話

オンボーディング

チームビルディングの手法の1つ
新メンバーを短期間で統合していく

中途社員の3つの壁

職場環境への適応の障壁
意思と担当業務のズレの壁
モチベーション

3つの壁を早期に崩す

プロジェクト化

期間4ヶ月
ガイドライン作成
研修カリキュラム
役割分担（受入体制）
情報集約してwikiへ登録
全社員に向けて共有

中途社員、受け入れ側とも満足

7ヶ月で11名中途採用

2019-08-31

【勉強会メモ】Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！コラボカンファレンス

勉強会 DDD マイクロサービス

yahoo-osaka.connpass.com

日時：2019/08/31(土) 13:00 〜 20:00
場所：ヤフー株式会社大阪グランフロントオフィス

5月に東京で開催されたイベントの再演も含めた大阪特別編が開催されました。ヤフーさん主催だからこそできることだと思いますが、東京で開催されたイベントが大阪でも開催される機会はあまり多くないのでありがたいイベントです。私はチームとしてのDDDの取り組みや教育をテーマにしたものが多かったA会場の発表に興味があったのでメモは全てA会場のものです。

レガシーをぶっつぶせ趣旨説明

DXレポート

www.meti.go.jp

レガシーシステムの問題点

ブラックボックス化
変化に対応できない

ちゃんと設計しよう

ドメイン駆動設計の「成長を続ける」ソフトウェア
きれいな理論というよりは現場のドロドロ感

基調講演：ドメイン駆動設計という設計スタイル

増田亨さん

ドメイン駆動設計という設計スタイル from 増田亨

話すこと

設計スタイルの選択
ドメインロジックに焦点をあわせる
開発現場での実験結果と考察

設計スタイルの選択

設計スタイルの3つの側面

関心の分離のアプローチ
- 何を分けて何を一体化するか
モジュール構造の考え方
- どう分割し、どう組み立てるか
20:80のとらえ方
- 重要な2割が全体の8割に影響を及ぼす
- 2割が大事

設計スタイルの違い

入出力
- トランザクションスクリプト⇒構造化
  - 入出力の設計と実装
ドメインロジック
- ドメインオブジェクトモデル⇒独立したモジュール
  - ドメインロジックの設計と実装⇒全体の2割の秩序を抑える

ドメイン駆動設計のスタイル

ビジネスルールに基づく計算と判断のロジックに焦点を合わせる
ビジネスルールに藤蔵する値の種類に注目して独自の型を定義してロジックを整理する
ビジネスルールを記述する部分の設計と実装がアプリケーション全体の構造と秩序を左右する

ドメインロジックに焦点をあわせる

相互に補完
- ドメインの知識を学び続ける
- ドメイン知識のコード表現と継続的な改善

ドメインロジック、ドメインの知識

意味が広く、あいまい
もっと具体的な対象に焦点を合わせる
ドメインロジック⇒ビジネスロジック
ドメイン知識⇒ビジネスルール

ビジネスの活動
↑制約する／促進する
ビジネスルール
↑ビジネスに基づく計算と判断のロジック
ビジネスロジック

ビジネスルール

ビジネスの活動を成約し促進する決め事
物理法則のような論理的な体系ではない
過去の意思決定の積み重ね
現在のビジネスルール体系は通過点
これからもビジネスルールの追加や変更が続く
- 変更用意性は少し違和感⇒変更を容易にしているわけではない
- どんなものが来てもまあ何とかなるという感じ

ビジネスルールを学び続ける

ビジネスルールの知識を広げると、要求の意味が理解できる
ビジネスルールを深く理解すると、関係性や構造が見えてくる
- 深く理解すると非合理に見えても実は関係していることがわかる
- 精神衛生上良い
詳細な仕様の補完力と提案力が増す
- ビジネス側が本当の中身のことまで言ってくれることはない
- 自分たちで補完してじゃあこうしたらいいですよねと提案する
ビジネスとビジネスルールは時間とともに変化し続ける
- 生きているビジネスを相手にすることは常に勉強してアップデートしていく

現場で役立つビジネスルールの基礎知識

ドメイン層の全体構造を設計する時の指針

文書化（構造化）されたビジネスルール
顧客の利益vs自社の利益
- 折り合いのつけ方の決め事
競争戦略とビジネスルール
ビジネスルールの階層構造

文書化（構造化）されたビジネスルール

説明
契約書
業務マニュアル
簿記・予実管理

↑俯瞰的なものは日常会話からは出てこない

顧客の利益vs自社の利益をどこで折り合いをつけるかの決め事

顧客価値
顧客からみたコスト
顧客の利便性
顧客とのコミュニケーション

競争戦略とビジネスルール

リーダー
チャレンジャー
フォロワー
ニッチャ

↑こだわりポイントが変わる
⇒パッケージ構造が変わる

ビジネスルールの改造構造

ポリシー
約束
運用
能力

ビジネスルールをコードで表現する基本テクニック

ビジネスルールとコード表現

スライド参照

ビジネスルールの構成要素

Fact
Rule
Goal

独自の型を定義する

型は値の種類
型は値の範囲を制限する
型は可能な操作（演算）を制限する
型はプログラムに構造と秩序をもたらす
型の名前がコードの意図を豊かに表現する

現場で役立つ独自の型の設計パターン

値オブジェクト（独自の型）の効果

独自の型はロジックを集約する
- なかなか理解してもらえない
独自の型は可読性を向上する
- わりとすぐ理解してもらえる
独自の型は信頼性を向上する
- 時間がかかる
独自の型はコードの追跡を容易かつ確実にする
- 即効性がある

条件分岐との戦い

if文、booleanで表現された暗黙の区分
レガシーで怪しげなコード体系

型を使った列挙

enumに区分ごとの計算・判定ロジックを寄せる
区分体系のリファクタリング

ビジネスルールの記述にコレクションを使う

Mapを使った料金ルールの早見表
Setを使ったスキルセットのマッチングロジック
Listを使った集約、最適要素の発見
ビジネスロジックを集約した複合型のコレクション

ビジネスルールを独自の型で表現する役立つ技法の学び方

エヴァンス本の拾い読みのススメ

※発表資料参照
リファクタリング
現場で役立つシステム設計の原則

現場で確認できたこと

コードを考えて書く人
- 意図ややり方は確実に伝わる
- サンプル、ツール、ガイドラインも整った
- どのくらいしみついているか？発想が柔軟か？
コードを書かない人
- 言葉で伝えるのは無理
- 設計やその影響に関心を持っている人は一部
- その人の関心の文脈で見せる

コードで確認できる発想の変化

独自の型の量と質
パッケージの構造、パッケージ名
入出力の記述箇所への独自の型の浸透

言葉と会話で確認できる発想の変化

タスク名、ToDo名、コミットログ
質問やアドバイスに登場する言葉
パッケージ名、クラス名、メソッド名の相談
ロジックの置き場所の相談

DeliveryとQualityを両立させるために僕らがやったこと〜トラベルシステムの技術全面刷新〜

関口岳志さん

QualityとDeliveryを両立させるために僕らがやったこと from Takeshi Sekiguchi

レガシー刷新案件の話

制約の中Quality高いものを作り維持し続けること
Quality
- 可用性
- パフォーマンス
- 保守性
制約
- 予算
- 工期
- 技術力

設計の工夫

アーキテクチャのコンセプト
UI/UXとAPIをとにかく汚染させない
きれいにつくって維持し続ける

刷新前

3層構造
- Web…大量のビジネスロジック
- API…役割が重複
  - 役割型
  - 全部取れるIF乱立
Data
- 荒れた構造

まずはAPIをキレイに

DDDのドメイン層
- ビジネスロジックを抽出・整理
- ドメイン単位に分割して抽出

WebとAPIの乖離

在庫ページ…プランと部屋のAPI
オーケストレーション層を設ける
- わかりやすくいうとBFF
- ここでAPIをマッシュアップ
UIUXきれいに

Data

データ定義が荒れているためそれを操作するAPIが腐敗する
先にDataを整理するのはリスク
整理が難解で時間がかかる
APIが固まってから手を入れたほうが良い

インテグレーション層を追加

データ操作をインターフェイスで提供
複数のDBMSを閉じ込めることができる
DBまわりは専門性が違うので分離できるメリットもある

GW系

フロントGW
APIGW層

JobSchedulerはジョブ管理

DDDの話

コンポーネント分割イメージ

API層をDDDで分解
システム全体をDDDは難易度高すぎると考えた

分割の流れ

0) インプット

エヴァンス本
レディマイクロサービス
増田さんのDDDワークショップ

1) 対象コンポーネントとメンバーを決定

対象は「予約」
技術メンバー3人、Dir1名、Cre1名
概念や分割の流れを説明
いびつでいいのでアウトプットを必ず出す
限られた時間でアウトプット

2) 関心事の各自理解

モデル化

3) チームの言語基盤を作る

例）料金なのか金額なのか

4) 骨格を説明する

文章化
重要な順に
論理的な文章が書ける⇒論理的なクラス設計

5) モデルと実装を紐付ける

部品を揃えていく
概念クラス図に落とし込む
1つ目でダメでも2つ目をやってみる
役に立つ部品を見つける
文章ごとに独立して実装できたほうがいい
アウトプット最優先

学び

インプットは付け焼き刃じゃ無理
対象にした予約が難しすぎた
モチベーションや向き不向きの差

難易度低いものからやっていくほうがいい

登り方の工夫

一括全面刷新はやらない
- 品質リスク
  - リリースしたけど効果が出ないリスク
- 工期的なリスク
  - 新旧両方
- 案件Goを通せない
  - 刷新案件は特質上、失敗したら二度とできない

段階的な刷新の流れ

スモールスタートで一部を刷新
並行稼動で検証
品質を満たせば残りを対応開始
実績ができた現行コンポーネントは削除

スモールスタートをどうやったか

トラベルのMyページを対象
カナリアリリースで現行と並行稼動して効果検証
Proxyを立てて10%を新しいほうに流す
- ユーザー固定

検証項目

システム観点
- 機能落ちしてないか
- 障害発生ないか
- メトリクス値
- パフォーマンス
保守性視点
- 開発効率
- 運用フロー
- 障害対応フロー

検証完了したらProxyで100%流す

いらなくなった現行を削除

スモールスタートでハマったこと

暗中模索
- 分からないこと不安が多い
仕様書の消失
- 資料がない、メンテされていない
新しいことをたくさんやりたい欲求
- せっかくなので色々チャレンジしたい

暗中模索対策

中心的に進める人と壁打ち役の選定
中心的…技術力・PM力、サービス理解
- バランス良く総合力高い人がやらないとうまくいかない
壁打ち役
- 中心の人と同等かそれ以上の人
- いない場合はフリーのエンジニア
- 分からないことのアドバイス
- 人材が全然いない

仕様書の消失

DDDで書き起こすチャンスと捉える
ビジネスモデルの理解、共通認識が協力にできる

新しいことをやりたい欲求対策

やるべきことに加えて3個までにする

残りの刷新

きれいを維持
人が増えてぐちゃぐちゃになりがち
WGを作る⇒組織として壁打ちする

ガイドラインと承認フロー

最低限のガイドライン
逸脱する場合の承認フロー

対応コストをなるべくへらす

選択と集中
×全てのコンポーネントを全力で完璧にする
効率化
- 非重点なところは最低限の刷新にする
全社的に求められているところは必ずやる
- 言語やアーキテクチャは現行から変えない
- 全社と違うとサポート受けれない
効率が上がらないなどのリスクはある

KPI貢献度、保守コストが高いものが重要

数年のトレンド分析
斜陽だがKPI貢献
KPI貢献がないものはクローズ
KPIとは
- 売上貢献
- コンバージョン

最終的にシステムに組織をあわせたい

逆コンウェイ
コンポーネントが1人
親和性の高いコンポーネントを複数人でみる
セオリーで困ったら分けない
分けすぎるのは失敗する

登り方はスモールスタートが大事

非エンジニアの同意と承認の工夫

ビジネスメリットで語る
サービスKPIにどう貢献するか

だめなもの

概算値
外部引用
一般論

よいKPI

実績値
開発効率の向上度合い

スモールスタート前の承認のとり方

ビジネスメリットと一般論でゴリ押し
スモールスタートして効果検証してFBすることも約束
工数は全体のうちの一部だけを強調

実績値のとり方

刷新前後のシステム上で全く同じPDCA

フェーズごとに比較

全工程でコスト減
テストが減少
副次効果で工期短縮
- 人員を効果的に配置
Bad
- 詳細設計増加
- UT増加
  - もともと書いてなかったので
合算で28%向上

非エンジニア向けにパッケージング

開発効率⇒サービスの巡航速度
PDCAサイクルの速度128%
チャレンジできる

ビジネスメリットと実績値で語る

ドメイン駆動設計とマイクロサービス

三石広樹さん

ドメイン駆動設計とマイクロサービス from kouki_mitsuishi

はまらないマイクロサービス

対象サービス

コンテンツ表示サービス
- 例）ポイントプレゼント表示、レコメンド表示など
- マイクロサービス化するのは入稿システム

開発のモチベーション

モダンなシステムを目指して開発
エンジニア育成⇒重点
マイクロサービス
Twelve Factors

データモデル

ER図
- ページ情報
- コンテンツ情報
- シナリオ情報

マイクロサービス…？

まるでモノリシックなシステムのパッケージをAPI化しただけのような…
マイクロサービス化してもモノリシックなサービスと変わらない課題

変化に弱い

ビジネス上のルール変更の要求
- 改修範囲が広い
- 改修箇所の特定が困難
- デプロイが複雑
レガシー化

なにかの「考え」が足りていない

ビジネスとサービスの不一致

ドメイン駆動設計で切り込む

モチベーション
- マイクロサービスの切り方がよくない
- マイクロサービス化の指標がほしい
- ドメイン駆動設計の発想・手法に着目
- ソフトウェアはビジネス課題（ドメイン）を解決する
- ひとつのマイクロサービスでひとつのドメインの問題を解決

これまでの設計

データ設計
Web APIに切り分け

データに着目して設計したら巨大なモノリシックができる

これからの設計

モデリング
Web APIに切り分け
コンテキストの境界を探る
集約を見つける
ドメインで分割

データ（技術視点）をベースにシステムを考える
↓
モデル（ビジネス視点）をベースにシステムを考える

現場で実践

企画から新しい案件

コンテンツを一括作成できるツールがほしい
共通と個別をバルクインサート
別のシステムで承認して取り込む

ドメインをモデリングしよう

ユーザーはなににどんな関心があるのか？
関心事をモデリング（設計）しよう

モデリング

モデルを洗い出す
関係を整理する

気付き

表面化していないモデルを定義
まだ曖昧なモデルを見つけた
これから必要になると予想した
ビジネスも常に成長途中
エンジニアがモデル明確化をフォロー

集約をユースケースから考えた

集約とコンテキスト
- APIに分割
ユーザーの操作対象がなにかを追求した
操作する単位をビジネスサイドと議論
ビジネス視点で考えてドメインを操作したい単位を見極める

クリーンアーキテクチャでパッケージ設計

ビジネスルールがつまったドメイン設計のレイヤーを切り離す

実装を終えて

得られたメリット

改修範囲が広い
- ビジネスとサービスの単位一致により局所化
改修箇所の特定が困難
- クリーンアーキテクチャで明確化
デプロイが複雑

ドメイン駆動設計が守る

リファクタ
機能追加
考慮漏れ
仕様変更

気づいた難しさ

チーム
- ドメイン駆動設計の理解を得難い
- 複数チームだと難しい
技術
- 初期実装コストが高い
- ドメインを守ることが大変

これから守りたいポイント

モデリングとサービス分割
- 実装は後でリファクタリングできるけどサービス分離は容易ではない
- 最初のシステム設計が肝心

現場のDDD体験共有

薮内聖也さん

ヤフーダイニングのレガシーはビジネスロジックが整理されていない

戦略的設計

ビジネスロジックの散在（レガシー）

予約者向けWebサービス
飲食店向けWebサービス
社内ツール
- 例）飲食店向け⇒社内ツール対応漏れ

API化を目指す

取り組み

システム全体に存在するシステムのグループ分け
重要度の高い「新規予約：ユースケースの調査
「新規予約」ユースケース関連のシステム構成設計

できたサブドメイン

店舗
予約
ユーザー
特集

戦術的設計

レガシーコード

場当たり的な改修で読解不可能な領域
例）完了クラス
- なんでも完了できる
- 場当たり的なif文
  - 新規予約
  - 予約変更
  - 即予約
副作用を多用
- 多くのメソッドはフィールドを書き換え

場当たり的対策

オニオンアーキテクチャの採用で改善
モデルを以下3つに責務わけして細分化
- ドメインモデル
- ドメインサービス
- ユースケース

ユースケース分離が理解を簡単に

即予約ユースケース
リクエスト予約ユースケース

副作用がたくさん

副作用の制限
普遍なオブジェクトを中心にコーディング

失敗したこと

戦略的設計における分析不足

店舗と予約

店舗名とPR文⇒関係性高い
予約と在庫の有無⇒関係性高い
元々巨大な店舗テーブルの存在
100カラム以上

ぎこちない責務分け

店舗と予約は分けられる気がする

重要なビジネスロジックの所属場所の考察

「在庫があるかないかの判断」をするのはどこ？

店舗と予約

在庫有無の判断を「予約」側に寄せる考察の理由
在庫の有無の判断を分けるほうが良かった
- 店舗掲載情報
- 店舗在庫設定

まとめ

戦略的設計で分離
オニオンアーキテクチャでコードがシンプル
戦略的設計の成功には深い業務知識とDDD経験が必要

ドメイン駆動設計でモブワークしました

辻陽平さん

準備編

ドメインを隔離できるアーキテクチャを採用する

モブする範囲を決める

開発のすべてをモブする必要はない
- 手段（How）の部分はモブしなくていい
- 何がどうあるべきなのか（What/Why）
- 人の解釈を伴う部分はモブしながら共通認識を作っていく
つまりドメインレイヤ（とアプリケーションレイヤ）だけモブ

マルチプロジェクト化する

アーキテクチャで論理的にに分割しただけではレイヤを無視したコードがかけてしまう
モブ中の議論がついつい手段の話しに行きがち
マルチプロジェクト化してレイヤを物理的に分割することでレイヤの制約を強制し、議論の焦点をドメインレイヤに集中させる
Java/KotlinならGradleで、Scalaならsbtでマルチプロジェクト構成

実践編

会話しながらコードを書く

ドメインについての自分の理解・解釈を超えに出して会話することが重要
必要ならラフにモデルズを描いて会話
だいたいのイメージが掴めてきたらコードに落としてみるを繰り返す

ドメインとアプリケーションを行ったり来たりする

ドメインだけで実装していると終わりが見えなくなってくる
アプリケーションサービスがドメインの表現力を映す鏡になる
アプリケーションサービスのコードがその使用をユビキタス言語で自己文書化できているのが理想的

アダプタの実装は後回しする

アダプタレイヤはいったんから実装やダミー実装にしておいて、本実装は後回しにする
アダプタレイヤの実装をやりはじえｍると、ついつい意識が実現手段に向いてしまい、ドメインへの注意力が切れてしまう
アダプタレイヤの実装はモブしなくてもペアやソロで十分

まとめ

DDDのモブワークはいかにドメインに集中するかが鍵
ドメインに集中できるようにアーキテクチャや進め方を工夫する

設計人材を育てるために DDD をどう使うべきか？

萩原利士成さん

新規開発でもレガシーでも設計は大事
良い設計は人が作り、人が育てる
設計できる人がたくさんいれば大きな絵が描けるようになる
自分が設計できる！＝メンバーが設計できるようになる

どうやって人を育てるか？

設計と実装は似ているようで違う
エヴァンス本を読

そもそも設計とは？

design
art or action

技術や工芸みたいなこと
意思決定や選択がある
職人的な要素

利用者の関心事＝システムの外

ソースコード化する
Art or Action

様々な抽象度でモデルが必要になる

実装上の制約がコンセプトレベルで影響を与えたりすることもある

Artを師匠から弟子へと伝える

なぜDDDか？

ドメインモデルがシステムの外（ユーザーの関心）とシステムの中（クラス設計）をつなぐ
実装とも無理なくつながる＆ドメイン層を隔離できる
設計のArtを体験しやすい

「DDDでやって」だけだと難しい

ポイント1：ドメインモデルで議論する

実装圧力に負けずに責務をちゃんと考える
責務の分割と組み合わせ＝設計の基礎となる力
プロパティだけでなくメソッドについて議論を振ると見えてくる

ポイント2：別の視点で

ドメインモデルの中だけで切ろえんしても見えてこないことがある

ポイント3：全体が連動する感覚を体験する

設計は一方通行ではない
師匠の問いかけ力

実践

全体を見渡せるサイズ感
ユーザーや管理者の行動もある
緊急ではない

気付き

ちゃんと時間を確保する
視点を変えられるようにする
ユーザー価値と結びつける
責務について質問して自分の言葉で語ってもらう
ふるまいやユースケースを洗い出す
実装との対応関係や実装ロードマップを議論
コードに落としてみる

良かったこと

ドメインモデル上で議論
別の視点との行き来
継続的なコミュニケーション

やってみての改善点

実装とドメインモデルの距離が遠い
時間変化についての議論が漏れがち⇒どこから作るか？どう変えるか？
ValueObjectがうまく作れない

反省点はあったが、設計のArtを伝えるという意味で一定の成果はありそう

設計力をどう測るか？次の課題

他会場の資料

抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート　大阪 from hogesuzuki

devlove-kansai.doorkeeper.jp

東京のイベントの資料

genbade-ddd.connpass.com

2019-08-30

【勉強会メモ】現場で役立つ1on1の原則

勉強会マネジメント

日時：2019-08-30（金）19:30 - 21:30
場所：Sansan株式会社関西支社

現場で役立つということで実践形式のワークショップが豊富な内容でした。1on1は定期的に実践して試行錯誤しているところですが、感想としては1on1は1対1のふりかえりに近い形式が理想なのかもしれないということです。チェックインで始まるあたりが特にそう感じました。

現場で役立つ1on1の原則

昨年東京で行った、「 DX: Developer Experience （開発体験）が良い環境づくりとは？〜VPoEのリアルなお仕事〜」がベースとなっているとのことです。その時の資料がこちら↓。