うまとま君の技術めも

2015年新卒入社した社畜の勉強内容などなど

エンジニアリング組織論への招待 Chapter1 - 読書メモ

アジャイル開発 読書メモ 組織論

エンジニアリング組織論への招待

目次

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Chapter1：思考のリファクタリング

  • 思考のリファクタリング
    • 頭の中で発生してしまう無駄なプロセスを削除して、考えるときの指針を持ち、問題解決に向かって明確に行動が出来るよう促すもの
    • 「不確実性に向き合う」

不確実性とエンジニアリング

エンジニアリングとは

  • 「曖昧さ」を減らし、「具体性・明確さ」を増やす
    • 曖昧さ
      • 決まっていないこと・将来どうなるかわからないこと ＝「不確実性」

不確実性

  • 組織構造と不確実性
    • f:id:umatomakun:20200209131020p:plain
  • 不確実性の発生源
    • 「わからないこと」から「不確実性」が発生する
    • f:id:umatomakun:20200209131042p:plain

情報を生み出す考え方

仕事の問題解決を行うために必要な3つ思考

  • 論理的思考の盲点
    • どんなときに人が論理的でなくなるかを知った上で問題解決を行う
  • 経験主義と仮説思考
    • 情報を得た上で問題解決を行う
    • 得た情報から全体を想定し問題解決を行う
  • システム思考
    • 全体像を見極め問題解決を行う

仕事の問題を学力テストの問題に変換する

  • f:id:umatomakun:20200209131102p:plain

論理的思考の盲点

論理的思考には2つの前提が必要

  • 2つの前提
    • ルールと自称を正しく認知できること
    • 正しく演繹できること
  • 「人はどのようなときに非論理的になってしまうのかを知る」ことが重要

ベーコンのイドラ

  • 「身体的機能」「自身の環境」「周囲の意見」「伝統や権威」によって錯覚や認識の間違いを起こしてしまう

認知の歪み

  • ゼロイチ思考
    • 白か黒か、敵か味方かのように、2分法で考えてしまう
  • 一般化のしすぎ
    • 1つや2つの事例で決めつけたり、早計な判断をしてしまう
  • すべき思考
    • 他人に対し「○○すべき」と期待し、強制してしまう
  • 選択的注目
    • 人は見たいものだけ見てしまう
  • レッテル貼り
    • ある人の特定の属性に注目して判断してしまう
  • 結論の飛躍
    • 相手の感情を先回りして読み取り、短絡的な判断をしてしまう
  • 感情の理由付け
    • 感情のみを根拠に自分の考えが正しいと判断してしまう

認知的不協和

  • タバコが体に悪いと理解しているがタバコを吸う
    • 知識と行動の整合性が取れていない状態
    • 不整合を避けるため、正当化出来る情報を選択的に取り入れてしまう

扁桃体をコントロールする

  • 「自分」や「自分が大切にしていること」に被害が及びそうだと感じる
    • 恐怖を感じる
      • 怒りに変わる
        • 自分や大切にしていることを守るため、理屈を練り上げてしまう

自分のアイデンティティの範囲を知る

  • アイデンティティ＝「自分を構成すると思っていること」
    • 範囲が広い人
      • 怒りを感じる範囲が広い
    • 範囲が狭い人
      • 怒りを感じる範囲が狭い

「怒り」を「悲しみ」として伝える

  • 他人の大切にしていることを知ることはできない
    • 「怒り」を感じたときは「○○は自分にとって大切で、○○な扱いをされると悲しい」など、「悲しみ」として伝え、相手に自分の大切にしていることを知ってもらう

問題解決より問題認知のほうが難しい

  • 人は自分が間違っているかもしれないことを無意識に避けてしまう
    • 正しい情報を認知できない
    • 自分が間違っているかもしれないと思考のパターンを変える必要がある

経験主義と仮説思考

経験主義：わからないことは調べるしか無い

  • 「理性主義」
    • ある「前提」から演繹的に判断しようという考え（ウォータフォール）
  • 「経験主義」
    • 「経験」を行うことでしか「知識」を得られないという考え（スクラム）
    • 「何がわかればわかるのか」を考え、それを「確かめる」

不確実性と夏休みの宿題

  • 夏休みの宿題
    • 計算ドリル
      • 不確実性が「低い」
      • いつ終わるのか大体わかる
    • 自由研究
      • 不確実性が「高い」
      • いつ終わるのかわからない
  • 自由研究（不確実性の高いもの）から取り組むことで、いつぐらいに終わるのかわかる
    • 不確実性が下がる

プロフェッショナルの仕事

  • プロフェッショナル
    • 短い時間で一定のクオリティまで上げて、残り時間で作り込む
      • 不確実性の高いものから取り組む
  • アマチュア
    • 残り時間が短くなってから、急速に出来上がってくる
  • f:id:umatomakun:20200209131131p:plain

コントロールできるもの／できないもの

  • 経験主義で重要なこと
    • 「知識」＝「経験」を行動によって手に入れるということ
      • 「行動できることは何か？」
      • 「行動の結果起きたことを観察できるか？」
  • e.g. 「上司が自分の仕事を評価してくれない」
    • コントロールできない
      • 上司の行動
      • 上司の考え
    • コントロールできる
      • 自分の行動
      • 自分の考え

観測できるもの／できないもの

  • 本来コントロールできないはずのものを、自分の行動で変化させようと試みるには
    • 「観測できる」必要がある
    • 「観測できない」ものは、行動しても変化がわからない

あなたができること

  • f:id:umatomakun:20200209131148p:plain

仮説思考：少ない情報で大胆に考える

  • 演繹法
  • 帰納法
  • 「仮説法」
    • 経験主義を更に生産的な（不確実性を下げる）ものにするために、「大胆な跳躍」をもたらす
演繹法 帰納法 仮説法
ルール：人間は死ぬ 事象：このカラスは黒い 事象：2つの大陸は海岸線が似ている
事象：Aさんは人間である 事象：あのカラスも黒い 仮説：大陸は移動してたのではないか
結論：Aさんは死ぬ 結論：全てのカラスは黒い 結論：2つの大陸が1つである証拠を探そう

PDCAサイクル

  • f:id:umatomakun:20200209131204p:plain

データ駆動な意思決定の誤解

  • 「データ駆動な意思決定」
    • 「仮説」を推論するために、持っているデータの可視化をする
    • 「仮説」が正しかったのか、統計的に検証する
    • 「次に取るべき正しい行動」を出すためではない

リアルオプション戦略と遅延した意思決定

  • リアルオプション戦略
    • 仮説を作り、その仮説を早期に少ない予算で検証する
    • 大きな意思決定を遅らせることが出来る
    • f:id:umatomakun:20200209131220p:plain

問題の解決よりも問題の明晰化のほうが難しい

  • 社会で取り組む問題の多くは、情報が不完全な状態から始まる
    • 問題解決よりも先に「どのような問題なのか」をはっきりさせることが重要
  • 「経験主義」＋「仮説思考」→「問題は何なのか」をはっきりさせる
    • 「問題を解く」ことは難しいことではない

全体論とシステム思考

システムとは全体の関係性を捉えること

  • f:id:umatomakun:20200209131240p:plain

部分だけしか見えないことで対立が起こる

  • 3次元のU
    • 様々な対立が、物事を「側面から」見ることができずに発生する
    • f:id:umatomakun:20200209131256p:plain

バランスシートとP/Lの関係性

  • f:id:umatomakun:20200209131314p:plain
  • 企業内部には、まだ資産や利益に還元されていない無形の投資活動が含まれている
    • 全体のフィードバックサイクルで見ると、それらは「コスト」とは限らない
    • P/Lだけ見ると「コストに見えてしまう」

拡張のフィードバックと抑制のフィードバック

  • f:id:umatomakun:20200209131328p:plain
  • どの様なフィードバックサイクルが存在するのか見つけていくことが重要

全体の関係性が見えれば対立は解消する

  • 1つ上の次元から問題を捉えて、システム全体を把握していく
    • 対立から発展的な議論へと視野が拡大する

認知範囲とシステム思考

  • 視野・視座・視点
    • 問題解決のための眼
      • 視野
        • あるポイントからその問題を眺めたときに同時に把握できる領域の広さ
        • 広い／狭いで評価
      • 視座
        • どこから眺めるか
        • 高い／低いで評価
      • 視点
        • どの角度から眺めるか
        • 鋭さ／凡庸さで捉える
  • 個人ではなく関係性に注目する
    • 様々な問題は、本当に個人の問題なのか？
      • 個人同士の関係性が問題なのかもしれない
        • 個人の性質
          • 変えるのは難しい
        • 個人同士の関係性
          • 変えるのは難しくない
          • ここに注目するのがシステム思考

問題解決より問題発見のほうが難しい

  • 世の中は複雑な相互関係を持っている
    • 合理的に見える解決策が別の問題を引き起こしたり、想定していない悪化をもたらす可能性がある
  • システム思考によって問題を変換する
    • 対立に見える問題 → 対立にならない全体像をあぶり出す
    • 個人の問題 → 関係性の問題

人間の不完全さを受け入れる

思考を前にすすめるための3つの考え方

  • 論理的思考の盲点
    • 「人は正しく事実を認知できない」
    • いつ認知が歪むのかを知り、歪んだ認知を正すための行動を促す
  • 経験主義・仮説思考
    • 「いくら理屈で考えても答えが出ない問題に時間を浪費してしまう」
    • 実験によって知識を獲得し、何が問題であるかを削り出すように考えるための行動を促す
  • 全体論とシステム思考
    • 「人は問題を個人の責任にしたり、全体像を見失った局所的な思考をしてしまう」
    • それが全体像ではないかもしれない、問題は関係性にあるのでは、という視点と問題解決のための眼を提供し行動を促す

コミュニケーションの不確実性

  • 人間のコミュニケーションの不確実性は3つの不確実性から来ている
    • 他者理解の不確実性
      • 人は他人や事象を完全には理解できない
    • 伝達の不確実性
      • コミュニケーションが到達するとは限らない
    • 成果の不確実性
      • 仮に理解されたとしても予想されたように行動するとは限らない
  • f:id:umatomakun:20200209131351p:plain

情報の非対称性

  • 同じ目的を持った集団で、何かの情報を片方の人が知っていて、もう片方の人が知らないという状態
    • 人は正確に自分の考えを他人に伝えることは不可能なので、非対称性が生まれる

限定合理性

  • 人間の認知能力には限界があり、ある人にとっての正解が全体にとっての正解になるとは限らない

コミュニケーション能力と透明性

  • 組織の人数が増えるにつれてスケールするはずが、徐々に悪化してしまう
    • 「情報の非対称性」と「限定合理性」が存在するから
  • コミュニケーション能力
    • コミュニケーション能力とは、コミュニケーションの不確実性を減少させる能力
  • 透明性
    • 透明性とは、継続したコミュニケーションや仕組みを通じてコミュニケーションの不確実性を低く維持し、情報の非対称性が削減され限定合理性の働きを弱められている状態

不確実性を削減し秩序を作る

  • 「不確実性を削減し、秩序を作る」ことこそがエンジニアリングで最も重要な出発点・性質である

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Clean Architecture - まとめ

アジャイル開発 読書メモ

読書メモ

umatomakun.hatenablog.com

umatomakun.hatenablog.com

クリーンアーキテクチャ

ソフトウェアアーキテクチャの目的

  • 求められるシステムを構築・保守するために必要な人材を最小限に抑えること
  • 優れた構造（アーキテクチャ）にすることで、ソフトウェアをソフト（変更しやすい状態）にする

優れたアーキテクチャとは

  • 「境界線」と「依存方向」が正しく設計されている
    • 独立した開発・運用・デプロイを可能とする

クリーンアーキテクチャ

  • 優れたソフトウェアアーキテクチャを具体化したもの
    • 「境界線」と「依存方向」を具体化したもの

感想

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture - 読書メモ 2

アジャイル開発 読書メモ

叫ぶアーキテクチャ

優れたアーキテクチャはユースケースを中心にしている

クリーンアーキテクチャ

クリーンアーキテクチャ

  • フレームワーク非依存
  • テスト可能
  • UI非依存
  • データベース非依存
  • 外部エージェント非依存

依存性のルール

  • ソースコードの依存性は、内側だけに向かっていかなければならない

エンティティ

  • 企業全体の最重要ビジネスルール

ユースケース

  • アプリケーション固有のビジネスルール

インターフェイスアダプター

  • フォーマットを変換する
    • ユースケースやエンティティ用のフォーマット
    • データベースやウェブ用のフォーマット

フレームワーク・ドライバー

クリーンアーキテクチャ
f:id:umatomakun:20200203205407p:plain

プレゼンターとHumble Object

Humble Object パターン

  • 「テストしにくい振る舞い」と「テストしやすい振る舞い」に分けるパターン
    • テストしにくい振る舞い
      • View・Database
      • シンプルに保っておく
    • テストしやすい振る舞い
      • Presenter・UseCase

部分的な境界

本格的なアーキテクチャの境界はコストが高い

  • 多くの作業が必要であり保守も必要
  • 優れたアーキテクトは、このような境界はコストが高すぎると判断する
    • 同時に、後で必要になるから境界を残しておきたいとも思う
      • YAGNIに違反する
      • 部分的な境界を実装

部分的な境界

  • 最後のステップを省略
  • 片方だけの境界
    • Strategyパターンを使い、片方だけの境界を作る
  • Facade
    • Facadeパターンを使い、シンプルな境界を作る
片方だけの境界 Facade
f:id:umatomakun:20200203205517p:plain f:id:umatomakun:20200203205533p:plain

サービス：あらゆる存在

サービスアーキテクチャ

  • 「サービス思考アーキテクチャ」・「マイクロサービスアーキテクチャ」
    • サービスが互いに分離されているように見える → 正しくない
      • サービスは共有しているデータと強く結びついていて、間接的ではあるが相互に結びついている
    • サービスが開発・デプロイを独立させていように見える → 正しくない
      • 誤った分離により独立して開発・運用・デプロイできない
      • データや振る舞いが結びついている限り、開発・運用・デプロイには調整が必要となる

横断的関心事

テスト境界

テスト容易性のための設計

  • 脆弱なテストの問題
    • 共通のシステムコンポーネントを変更すると、何千や何百というテストが壊れる可能性がある
  • テスト容易性の設計
    • 変化しやすいものに依存しない
      • GUIは変化しやすい → 脆弱である

テストAPI

  • 変化しやすいものに依存しないようにするために
    • テストから使用できるAPIを作り、全てのビジネスルールを剣侠できるようにする

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture - 読書メモ 1

アジャイル開発 読書メモ

設計とアーキテクチャ

ソフトウェアアーキテクチャ

  • 目的
    • 求められるシステムを構築・保守するために必要な人材を最小限に抑えること

崩壊したコードを書く方がクリーンなコードを書くより常に遅い

  • TDDありとTDDなしで比較
    • TDDを使ったほうが速い

速く進む唯一の方法はうまく進むこと

２つの価値のお話

ソフトウェアシステムの価値

  • 振る舞い
  • 構造 >> こちらの方が重要
    • 簡単に変更できるようにする
      • ソフトであるということ
    • 「形状」ではなく「スコープ」に比例して難易度が変わるべき

アーキテクチャとは？

アーキテクチャ

  • 主な目的
    • システムのライフサイクルをサポートすること
      • 開発
        • 開発しやすくなるようなシステムにする
      • デプロイ
        • 単一のアクションで簡単にデプロイ出来るようにする
        • 速い檀家来からデプロイ戦略を考える
      • 保守

ソフトウェアの価値

  • 振る舞いの価値
  • 構造の価値
    • ソフトウェアをソフトにする価値

独立性

優れたアーキテクチャがサポートすること

  • システムのユースケース
  • システムの運用
  • システムの開発
  • システムのデプロイ

レイヤーの切り離し

  • UI・ビジネスルール・データベース等のレイヤーで切り離す
  • 変更される理由をまとめる

ユースケースの切り離し

レイヤー・ユースケースを切り離すことで

  • 「独立した開発」「独立デプロイ」を可能とする

切り離し方式

  • ソースレベル
    • モジュールを分離する
    • モジュール間で影響しない
  • デプロイレベル
    • デプロイ可能な単位を分離する
    • ソースコードの変更が他のモジュールに影響しない
  • サービスレベル
    • 実行単位を完全に分離する
    • ソースやバイナリの変更が影響しない

バウンダリー：境界線を引く

ソフトウェアアーキテクチャとは、境界線を引く技芸である

  • バウンダリー
    • 「重要なもの」と「重要でないもの」の間に引く
    • 重要なもの
      • ビジネスルール
    • 重要でないもの

f:id:umatomakun:20200131201410p:plain

方針とレベル

コンピュータプログラムは、入力を出力に変換する「方針」を記述したもの

  • レベル
    • 入力と出力からの距離
  • 依存方向はレベルと結びつける

f:id:umatomakun:20200131201425p:plain

ビジネスルール

エンティティ

  • ビジネスデータを操作するビジネスルールを含んだオブジェクト
    • ビジネスルール
      • システムが自動化されていなくても存在するルール
    • ユースケースのことは知らない

ユースケース

  • 自動化されたシステムを使用する方法を記述したもの

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

アジャイル検定 Lv.2 - 試験レポート

アジャイル開発 アジャイル検定Lv2

アジャイル検定 Lv.2 を受験してきたので、結果を含めて簡単なレポートを残しておきたいと思います。

アジャイル検定

アジャイル検定とは

アジャイル開発のスキルを客観的な尺度で分析・判定するのが、アジャイルソフトウエア開発技術者検定試験です。

試験システムとして、CBT(Computer Based Testing)を採用しています。
いつでも、どこでも受験することができます。4肢択一スタイルの問題、平均で70%の正解率を得られるよう、難易度を調整しています。
合格基準は80％以上の正解率です。

agilecert.org

アジャイル検定の構成

  • Lv.1試験
    • アジャイル開発に参加するのに必須となる知識が出題される
  • Lv.2試験
    • アジャイル開発のチームメンバーとして必須となる知識が出題される

アジャイル検定 Lv2.試験

試験範囲

試験時間および出題形式

  • 試験時間：60分
  • 出題形式：多肢選択式 (四肢択一) 40問
  • 評価方法：65％以上合格

Lv2.試験結果

f:id:umatomakun:20200130201555p:plain

試験勉強

umatomakun.hatenablog.com

感想

  • Lv2ではLv1に比べ圧倒的に複数選択可能な形式の問題が多かったので、より正確に理解していることが求められる
  • 各要素の目的を意識して勉強すると良さそう
  • 合格したものの、合格ラインギリギリだったので引き続き理解を深めるよう努めていきたいと思う

石井食品の攻守両輪：デザインスプリントとカイゼン - イベントメモ

アジャイル開発 イベントメモ

DevLOVE

devlove.doorkeeper.jp

石井食品

  • 会社
  • 石井さん
    • 代表
    • 元エンジニア、CSM
  • 池田さん

守：見える化/ふりかえり/バックログ化/期待マネジメントでカイゼンした話

  • 部署
    • 課題解決チーム
      • 直販チーム
      • 通販チーム
  • 現場の悩み
    • １．周りのメンバーは自分のことをどう思っている？
    • ２．仕事量が多いプレイングマネージャーはどうする？
    • ３．会議が多いのはどうすれば？
  • 対策
  • 実践（最初の一歩）
  • 不安を共有する

攻：ISHII SPRINT

  • 新商品開発をデザインスプリントする
    • デザインスプリント
      • Googleが提唱
      • ５日で課題解決
      • 理解→発散→決定→施策→検証
      • 課題解決に集中させるのが目的
      • ５日という制約があることで、無駄を省きつつ、アウトプットの質向上を狙う
  • なぜここにいるのか
    • 食品の新商品を作りたい
    • 新商品開発の型を作りたい
  • デジタルと食品の差
    • 問題解決という目的はどちらも同じ
    • 食品ならではの前提はある
  • ISHII SPRINT
    • ３日で行った
    • 総勢２０人弱の規模で３チーム形成
    • Day1
      • ニーズを満たす（LeanCanvas）→どうやって検証するか？
    • Day2
      • 施策→フィードバック
    • Day3
      • 検証→お店で試食会
  • 学び
    • 短期集中で結果かが出ることの強さ
    • 部署間の壁を越えられる
      • 「良いものを作る」という１点のみに集中できる
    • クリティカルメイキング
  • ともに考え・ともに作る
    • 役割・部署を越えた協働

パネルディスカッション

  • 社風
    • 社長が子供を連れて会議にも参加
  • デザインスプリント
    • 池田さん→乾燥野菜のチーム
      • １分で料亭の味
      • 部署の壁が心配だった
  • 年末催事大作成
    • 半分が新メンバー
    • 工場の方にもヘルプで入ってもらう
      • 目的を前もって共有しておけばよかった...
    • 人の取り合いになっていた...
  • きっかけ
    • 社長がOSTを開催→新商品開発の案が出た

ISHII SHOKUHIN 365

365.ishiifood.co.jp

感想

  • ソフトウェア開発に限らず、チームでゴールを目指して協力し合うことが大切だと改めて実感
    • 部署・役割の壁を取っ払うことで、より良いアイデアが生まれる
  • 企業のビジョンやミッションも重要になってくる印象
    • ビジョンやミッションに基づいた課題解決をするためにその会社で仕事するんだよね？
    • 会社・部署・チームそれぞれの単位で同じ目的を持つことで高みを目指したい
  • ただただ作業のようなプロダクト開発を行う組織は絶対に作りたくないなと思う
    • チームで同じ目的を持って課題解決目指す仕事のほうが楽しいよね

アジャイル検定Lv.2 勉強メモ - リファクタリング

アジャイル開発 アジャイル検定Lv2

アジャイル検定Lv.2 出題範囲

リファクタリング

リファクタリング

コードの不吉な臭い

  • 奇妙な名前
    • メソッドやクラスの名前が奇妙な場合
      • 不適切な命名は理解するのが難しい
      • 適切な名前が思いつかない場合は、設計が良くない兆候
  • 重複したコード
    • 同じコードが複数箇所にある場合
      • 重複コードがあると、複数箇所に同じ修正を行う必要がある
      • 重複コードを1箇所にまとめる
  • 長すぎるメソッド
    • メソッド名が長い場合
      • 短いメソッド名の方が理解しやすい
      • 短く役割が明確なメソッドを書く
  • 長すぎるパラメータリスト
    • メソッドの引数が多い場合
      • パラメータが多いと、1つ1つが何を意味しているのか理解しづらくなる
      • 新たなデータが必要になった時にパラメータリストの変更が必要となる
  • グローバルデータ
  • 変更可能なデータ
    • クラス内部のデータを変更している場合
      • データを変更すると予期しないバグを生み出す
      • データを書き換えるのではなく、変更後の新しいデータを持ったオブジェクトを返す
  • 変更の偏り
    • 1つのクラスが異なる理由で何度も変更されるような場合
      • 異なる役割にも変更の影響が出てしまう
      • クラスの役割が多すぎるので、役割を明確にし変更理由が1つになるようにする
  • 変更の分散
    • 1つの理由で複数のクラスが変更されるような場合
      • 変更すべき箇所が分散すると、重要な変更を実装し忘れる場合が出てしまう
  • 機能の横恋慕
    • クラスのメソッドが、別クラスのデータやメソッドとばかり処理を行っている場合
      • 役割の所在が異なっているため、メソッドを別クラスに移動させる
  • データの群れ
    • 同じ様なデータのグループが、複数箇所で使われている場合
      • 同じ役割であるため、1つのクラスにデータをまとめる
  • 基本データ型への執着
    • 基本データ型ばかりを使っている場合
      • 基本データ型をクラスに置き換えることで保守性を上げる
  • 繰り返されるSwitch文
    • 同じ様なSwitch文が何度も出てくる場合
      • 分岐を追加した場合に、すべてのSwitch文を変更する必要がある
      • Switch文の代わりにポリモーフィズムを使う
  • ループ
  • 怠け者
    • 十分な仕事をせず、理解したり保守するコストに見合わない場合
      • 不要なクラスは削除する
  • 疑わしき一般化
    • 将来必要になるという理由で書いたが、実際には使われず無駄になっている場合
      • 無駄に複雑になっているため、よりシンプルな方に変更する
  • 一時的属性
    • 特定の状況でしか使われないインスタンス変数がある場合
      • コードを理解しづらくなる
      • 別のクラスに切り出す
  • メッセージの連鎖
    • 複数のクラスを経由するメソッドチェーンがある場合
      • チェーンの途中で呼び出されるクラスに強く依存してしまう
      • 委譲を利用してチェーンを隠蔽する
  • 仲介人
    • クラス内のメソッドのほとんどが委譲を行っている場合
      • 仲介人を除去して、委譲先のオブジェクトと直接処理を行う
  • インサイダー取引
    • クラス間で過度にデータの交換を行っている場合
      • クラス間の結合が強くなってしまう
      • クラス間で共通して使用するデータを持つクラスを用意する
  • 巨大なクラス
    • 1つのクラスで多くの処理を行っている場合
      • クラスに役割が多すぎる
      • インスタンス変数を整理したり、親クラスに処理をまとめたりする
  • クラスのインターフェース不一致
    • 置き換えたいクラスのインターフェースが異なっている場合
      • 他のクラスへ置き換え可能にするには、インターフェースが同じである必要がある
      • インターフェースが同じになるようにする
  • データクラス
    • 属性・getter・setterしか持たないクラスがある場合
      • 必要な処理が誤った場所に書かれている可能性が高い
      • データクラスを使用しているコードを、データクラス自身に持たせられないか検討する
  • 相続拒否
    • 子クラスが親クラスの一部しか利用していない場合
      • 継承階層が間違っている
      • メソッド・変数の階層を変更したり、継承を移譲に変えたりする
  • コメント
    • 詳細なコメントが書かれている場合
      • コードの分かりづらさを補うためにコメントが記述されている
      • コメントを書かなくても内容が分かるようにする

参考資料