うまとま君の技術めも

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

Flutter - InheritedWidgetを使ってProviderを実装してみる

Provider

  • ProviderとはInheritedWidgetをラッパーし使いやすくした、状態管理をするためのライブラリである。 github.com

InheritedWidget

InheritedWidgetを使ってProviderを実装してみる

  • InheritedWidgetを使い、Provider.of()Provider.value()を実装してみた

感想

  • provider を使うのであれば、InheritedWidgetの理解を深めておくと良さそう
  • StatefulWidgetvalueをもたせていない場合にうまく動作しなかったが原因はよくわかっていない
  • provider v3 では StatefulWidgetを使った実装だが、v4 から使われなくなっている
    • 軽く実装を見てみたが、どのようにしてChangeNotifierの変更を検知し再ビルドしているのか分からなかった

Flutter Widget of the Week

Flutter Widget of the Week

Flutter Widget of the Week で紹介されたWidgetを実際に使ってみたいと思います。

Flutter Widget of the Week - YouTube

SafeArea

Expanded

Wrap

AnimatedContainer

Opacity

FutureBuilder

FadeTransition

FloatingActionButton

PageView

Table

SliverAppBar

SliverList & SliverGrid

FadeInImage

StreamBuilder

InheritedModel

ClipRRect

Hero

CustomPaint

Tooltip

FittedBox

LayoutBuilder

AbsorbPointer

Transform

BackdropFilter

Align

Positioned

...

Flutter関連情報まとめ

YouTube

ブログ

イベント

プロトタイピング

Dart

開発ツール

まとめ

Flutter入門

Flutterとは

Flutterとは

  • Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase.
    • 単一のコードベースでいい感じのネイティブアプリが作れるもの
    • Google
    • iOS, Android, (Web, Desktop) をサポート

特徴

  • Fast development
    • ホットリロードを始めとした、より高速に開発するための様々なツールが提供されている
  • Expressive, beautiful UIs
    • Material Design 等に沿ったUIパーツを使うことで、いい感じのUIが簡単に作れる
  • Native Performance
    • Dartという言語を使い、各プラットフォームに応じたネイティブコードを生成できる

なぜFlutterを使うのか?

  • より高速に開発するため
  • より魅力的なUI/UXを提供するため

アーキテクチャ・コンセプト

  • 独自エンジンを各プラットフォームで動かせるようにしている
    • エンジン内部にはUI描画処理も含まれている >> Skia
  • ウィジェットのツリーでUIを表現
    • Reactのような宣言的UIを採用している

Androidアプリ作成

Flutter導入

プロジェクト作成

// プロジェクト作成 w/ Integration tests
$ flutter create --org com.umatoma --with-driver-test --no-pub flutter_training_app

// そのままだと依存解決に失敗するので調整
$ vim pubspec.yaml
- test: 1.6.2
+ test: ^1.9.4
$ flutter pub get

アプリ起動

// 利用可能なエミュレータ一覧を確認
$ flutter emulators
3 available emulators:

Pixel_3a_API_28     • Pixel 3a API 28 • Google • android
TEST                • TEST            •        • android
apple_ios_simulator • iOS Simulator   • Apple  • ios
...

$ flutter emulators --launch Pixel_3a_API_28
$ flutter run

テスト実行

// Unit tests 実行
//   ファイル名が *_test.dart となっているものをテストファイルと認識する  
$ flutter test test/
  00:06 +1: All tests passed!

// Integration tests 実行
//   test_driver ディレクトリに target と同期したファイル名のテストが実行される
//   e.g. main.dart >> test_driver/main_test.dart
$ flutter drive --target=./lib/main.dart
Using device AOSP on IA Emulator.
Starting application: ./lib/main.dart
Installing build/app/outputs/apk/app.apk...                         4.3s
Running Gradle task 'assembleDebug'...
Running Gradle task 'assembleDebug'... Done                        13.2s
✓ Built build/app/outputs/apk/debug/app-debug.apk.
...
00:00 +0: end-to-end test (setUpAll)

...
00:01 +0: end-to-end test tap on the floating action button; verify counter

00:01 +1: end-to-end test (tearDownAll)

00:01 +1: All tests passed!

Stopping application instance.

リリース用ビルド作成

// keystore 作成
$ keytool -genkey -v -keystore ./key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias key
// 署名用の設定を追加
$ vim android/app/build.gradle
// apk 作成
$ flutter build apk
You are building a fat APK that includes binaries for android-arm, android-arm64, android-x64.
...
Removed unused resources: Binary resource data reduced from 37KB to 32KB: Removed 14%
Running Gradle task 'assembleRelease'...
Running Gradle task 'assembleRelease'... Done                      14.9s
✓ Built build/app/outputs/apk/release/app-release.apk (15.6MB).

Webアプリ作成

Webアプリ機能有効化

// 現時点ではbeta版らしい
$ flutter channel beta
$ flutter config --enable-web

// 作成済みのプロジェクトにWebアプリのコードを追加する場合
$ flutter create .

Recreating project ....
  web/index.html (created)
  web/manifest.json (created)
  web/icons/Icon-192.png (created)
  web/icons/Icon-512.png (created)
Wrote 7 files.
...

アプリ起動

$ flutter run -d chrome

リリース用ビルド作成

$ flutter build web

状態管理

State

  • Widgetは常にImmutableである
  • 状態管理はStateで管理し、変更に応じてWidgetを再生成する
    • setState() をCallすることで、状態が変更されたことを通知する
class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return Container(
      child: RaisedButton(
        onPressed: () {
          setState(() {
            _count++;
          });
        },
        child: Text('Increment: $_count'),
      ),
    );
  }
}

Provider

  • provider パッケージを使うことで、複数Widgetを跨いだ状態の管理が簡単に行える
    • Provider/Consumer が Pub/Sub の関係
    • 任意のWidgetに状態を共有できる
void main() {
  runApp(ChangeNotifierProvider(
    create: (context) => CountModel(),
    child: MaterialApp(
      home: Column(
        children: <Widget>[
          CounterText(),
          CounterButton(),
        ],
      ),
    ),
  ));
}

class CountModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;

  void increment() {
    _count++;
    notifyListeners();
  }
}

class CounterText extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Consumer を通して Provider に渡したモデルにアクセスできる
    return Consumer<CountModel>(
      builder: (context, countModel, child) => Text('Count: ${countModel.count}'),
    );
  }
}

class CounterButton extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // データを参照する必要がない場合は Provider.of で listen:false でもOK
    final countModel = Provider.of<CountModel>(context, listen: false);
    return RaisedButton(
      onPressed: () => countModel.increment(),
      child: Text('Increment'),
    );
  }
}

Widget

感想

  • 軽く使ってみた感じ、非常に簡単に環境構築〜アプリ作成まで行えるのが良い
  • エディタを含め開発環境周りもそれなりに整っており、全体としての完成度が非常に高い印象
  • Reactに影響されてそうな部分が多く、Reactユーザーにとっては参入障壁が低いはず
  • テスト周りもデフォルトで Unit・Widget・Integration テストを行える環境が整備されていて良い
  • バックエンドにDartを採用できれば、アプリ〜バックエンドまで少人数かつ1チームで全てを網羅することで出来る可能性も
    • これができれば、規模が拡大してもFeatureチーム単位で組織を分割しやすくなる?
  • ただし、各プラットフォームに関する知識をもっていないと、ハマった時に大変そう...

参考情報

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

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

目次

書籍

Chapter4:学習する組織と不確実性マネジメント

いかにして不確実性を管理するか

  • 不確実性をマネジメントするには、不確実な要素をリストアップして、それらを比較する

スケジュール予測と不確実性

スケジュールマネジメントの基礎

  • スケジュールマネジメントとは次の3つに注目して改善を行うマネジメント
    • 制約スラックを削減する
    • 見積もりの予測可能性を上げる
    • プロジェクトバッファの消費を可視化し改善する
  • 出来る限り早く「いつリリースされるのか」という時間の精度を上げる

制約スラックとクリティカルパス

  • 制約スラック
    • 依存関係を考慮した上で、発生してしまう無駄
  • クリティカルパス
    • 依存関係から導かれるスケジュール遅延の原因となる作業の流れ
  • 成約スラックを削減するには?
    • 「リソース制約」を取り外す
      • 「この作業はXさんにしかできない」といった属人化した作業
    • 「依存制約」を取り外す
      • 「2つの作業を同時に行えない」といった作業の依存関係

悲観的見積りと楽観的見積り

  • プリンシパル・エージェント理論
    • 経済における人間関係を「依頼者」と「代理人」との契約の束として捉える考え方
    • 「依頼者」と「代理人」における情報の非対称性により、「悲観的見積り」や「楽観的見積り」が生じてしまう

スケジュール不安の見える化

  • 「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくかどうか」を管理する
  • CCPM
    • スケジュール不確実性の削減をプロジェクトバッファの消費という形で「見える化」する
  • 多点見積り
    • 個別のタスクに対して複数パターンの見積りを行い、タスクごとの不安を洗い出す
  • 個別の不安量がわかったら
    • 「不安なタスクの順に問題解決をする」ことで、スケジュールマネジメントを有利に進める
    • 「不安の大きいタスク」と「不安の小さいタスク」にタスク自体を分割する
      • 「不安部分のみを切り出して」実施することが出来る
  • 不安の原因を取り除く相対見積り

計画でなく実績から予測する

  • 小さくスプリントを繰り返す
    • 同じ様なタイムボックスを繰り返すことで、実績から将来の予測を行いやすくする
  • ヴェロシティと生産性
    • ヴェロシティが多い ≠ 生産性が高い
  • ヴェロシティを用いたスケジュールマネジメント
    • ヴェロシティの平均値・偏差 → 最悪値・最高値 → 完了予定を推定

要求粒度と不確実性

  • 作る工程よりも「何を作るか」が決まっていく過程の方が不確実性をもっていてブレ幅が大きい
    • スケジュールマネジメントには要求が詳細化されていく過程もマネジメントする必要がある
  • ボトルネックを探してスループットを上げる
    • 「プロダクト」には完了がない
    • 機能が要求されてから価値が生まれるまでの「川の流れ」を見る必要がある
    • バリューストリーム

スケジュール不安はコントロールできる

  • 不確実性をリリース予測の幅として表現する
    • スケジュール不安が可視化できる

要求の作り方とマーケット不安

スケジュール不安とマーケット不安の対称性

  • スコープバッファの成立条件
    • 優先順位の高い機能ごとに完了する
  • プロダクトに最初に触る顧客
    • プロダクトオーナー
    • プロダクトに触れることで「目的不確実性」を減少させる
  • ユーザーストーリー
    • 各機能を顧客にとっての物語となるよう分解したもの
    • 「XXXは、XXXすることができる、これによってXXXできるからだ。」

マーケット不安はいつ削減できるか

  • 安いコストで仮説を検証していき、不確実性が十分に下がったら大きな予算をかける
    • 「仮説」
      • 直感的に少ない断片情報だけから「このようにしたらビジネスが成立する」というビジネスモデル全体
    • 「検証」
      • 「仮説として成立しているか」を精査し、その後に行うアクションの全て
  • 価値と不確実性
    • 機能の優先順位を考えるときは、価値とリスクのマトリクスに分類する
  • リーンキャンバス
    • 仮説が仮説として成立するためには、ビジネスが成立してできた後のイメージが重要
    • 仮説を明らかにするためのフォーマット
      • 1:顧客の課題「どんな痛み・ニーズを感じているか」
      • 2:顧客セグメント「誰がどの位それを感じているか」
      • 3:独自の価値「他にはない独自の価値はなにか」
      • 4:解決策「どのようにその痛みを解決するか」
      • 5:チャネル「どこから顧客をどのくらいの値段でつれてくるか」
      • 6:収益の流れ「お金はいつどのようにいくら支払ってもらうか」
      • 7:コスト構造「売上に対してどんなコストがどれだけかかるか」
      • 8:測定項目「何がどれくらいなら上手くいっているか」
      • 9:競合優位性「なぜ自分たちがそれをやると上手くいくのか」

スクラムと不安に向き合う振り返り

  • スクラム
    • 「役割の整理」と「いつどんな会議を開くか」をまとめたもの
    • いつどのようにチームが課題と不安に向き合うのかを測定し、改善を行うためのタイミングを矯正するためのフレームワーク
    • 「不安への向き合い方」をチームが学習するための方法論
  • スクラムにおける役割
    • プロダクトオーナー
      • チームのROIを最大化させるため、ビジネス上の要件からプロダクトバックログを作成する
      • プロダクトバックログ
        • ストーリーを優先順位に並べたもの
    • 開発チーム
      • プロダクトバックログに従ってどのように作るべきかの意思決定を行う
    • スクラムマスター
      • プロダクトオーナーと開発チームの間に存在する「ボトルネック」を解消する
  • スクラムにおけるイベント
    • スプリント計画
    • デイリースクラム
      • 前日まで課題やその日やることを簡潔に共有する
    • スプリントレビュー
      • プロダクトオーナーがインクリメントをレビューする
    • レトロスペクティブ
      • 次に向けての改善アクションを決める
Whatの検査 Howの検査 日々の検査
Plan スプリント計画 スプリント計画 デイリースクラム
Do スプリント スプリント その日の作業
See スプリントレビュー レトロスペクティブ デイリースクラム
対象 インクリメント プロセス 前日までの作業

どこに向かって、どのように振り返るか

  • プロダクトチームにとって振り返るべきゴールとは
  • 振り返りの流れ
    • 0:ゴール再認識
    • 1:テーマ設定
    • 2:現状整理
    • 3:よかった探し
    • 4:問題の洗い出し
    • 5:問題の深堀り
    • 6:対策の決定

不安を知りチームマスタリーを得る

  • チームマスタリーを得ている状態
    • チームが自分たち自身の手によって広い視野での問題解決を進めることができる状態
    • 自己組織化された状態

書籍

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

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

目次

書籍

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

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

Chapter3:アジャイルなチームの原則

アジャイルなチームをメンタリングする技術

アジャイル開発

  • チーム全体に対してメンタリングを行い開発出力を向上させる手法
  • 開発手順・開発フロー

アジャイル開発が必要とされた2つの理由

  • ソフトウェアの大規模化・複雑化
  • マーケットの不確実性に対応

アジャイル開発は3倍の成功率、1/3の失敗率

  • 大規模開発こそ、アジャイル開発はより効果的であるという結果が出ている

プロジェクトマネジメントとプロダクトマネジメント

  • ソフトウェア開発の前提が変化した
    • プロジェクト型開発 → プロダクト型開発
プロジェクト型開発(計画駆動) プロダクト型開発(マーケット駆動)
予算が開始時点に決まっている 予算は各ステージごとに徐々に調達される
成功はコスト・スケジュール・スコープが満たされるかどうかで計測される 成功はその製品が最終的に得たマーケットや収益に基づき計測される
プロジェクトマネージャーによって指揮される プロダクトマネージャーとテクニカルリードのペアで指揮される
  • 2つの不確実性に対するアプローチ
計画駆動 アジャイル型開発
前提とする不安 スケジュール不安 スケジュール不安とマーケット不安
戦略 初期計画の精度を高める 実験的に徐々に精度を高める
変化 変化に弱い 変化に強い
アプローチ 理性主義 経験主義的

ウォータフォールかアジャイル

  • スコープとする範囲

アジャイルの歴史

アジャイル開発は経営学

  • アジャイルというコンセプには、ソフトウェア開発というよりむしろ、経営学あるいは、組織学習という文脈の中で生まれてきたもの

デミング博士とPDCA

  • デミングの4つの「深遠なる知識」が日本の製造業に浸透し、ソフトウェア開発にも取り入れられた
    • システムの理解
      • システムの個別要素ではなく、関係性に着目し生産性を向上させる
    • ばらつきに関する知識
      • 測定によって知識を得るという態度
    • 知識の理論
      • 知識がどのようにして得られ、展開していけば良いのかという知識
    • 心理学に関する知識

トヨタ生産方式とリーン生産方式

  • トヨタ生産方式
    • 「在庫は悪」として捉え、実現手段として「従業員」のマインドに徹底的にこだわった
  • リーン生産方式
    • トヨタ生産方式の徹底した無駄の排除と現場主義による改善を高く評価
    • それらを整理し、マニュアル化、パッケージ化したもの

生産方式から知識経営へ

  • 新しい新製品開発ゲーム
    • NASAと日本企業における新製品の開発フローを比較した論文が発表された
NASA 各プロセスがばらばらの専門家によって分割されている
日本企業 異なる分野の専門家が一丸となって開発を進める
  • SECIモデル
    • 4つの段階を繰り返すうちに、組織内に知識が獲得されていく
  • シングル・ループ学習
    • 過去の学習を通じて獲得した「ものの見方・考え方」に基づいて、改善を繰り返す学習
  • ダブル・ループ学習
    • シングル・ループ学習のサイクルに、環境の不確実性を取り込んで、今まで前提としていた前提自体を変えていくような学習

軽量ソフトウェア開発プロセス

  • スクラム
    • ダブル・ループ学習を短い期間で繰り返していく
  • エクストリーム・プログラミング
    • うまくいくソフトウェア開発における、現場の暗黙知形式知とし、カタログ化したもの
  • 適応型ソフトウェア開発
    • 不確実なビジネス環境では、官僚機構的なワークフローではなく、創発的な仕組みが必要という考え
  • リーンソフトウェア開発
    • ムダ・ムラ・ムリという3つの贅肉を減らし、引き締まったソフトウェア開発を実現する
    • 贅肉を減らすための7つの原則
      • 1:全体を最適化する
      • 2:ムダをなくす
      • 3:チームに権限移譲する
      • 4:学習を強化する
      • 5:早く提供する
      • 6:品質を作り込む
      • 7:決定を遅らせる

アジャイルソフトウェア開発宣言

従来重視されてきたもの これから重視していくべきもの
プロセスやツール 個人と対談
包括的なドキュメント 動くソフトウェア
契約交渉 顧客との協調
計画に従うこと 変化への適応

アジャイルの歴史に見る3つのポイント

  • アジャイルは失われた日本的思考を取り戻し、新たな合理性を取り入れることでもある
  • ソフトウェア開発プロセスに組織学習を組み込み進化していった
  • アジャイル開発とは複数の軽量プロセスの総称である

アジャイルをめぐる誤解

アジャイルに関する5つの誤解

  • 誤解1:アジャイル開発は決まったプロセスである
  • 誤解2:アジャイル開発では設計しない
    • 必要であればドキュメント作成も行う
    • 情報伝達はドキュメントよりもコミュニケーションの方が伝達効率が良いという考え
  • 誤解3:アジャイル開発は優秀なメンバーでないとできない
    • 自立性が求められ、課題に直面し成長した結果、優秀なメンバーがいるように見える
  • 誤解4:アジャイル開発では中長期計画がない
    • 不確実性が大きい場合は中長期計画の意味があまりないと判断することもある
  • 誤解5:アジャイル開発は開発者に決定権がある方法だ
    • アジャイルなチームは仮説検証を繰り返し、顧客ニーズやビジネス価値を深く理解する
    • より抽象的な要求を定義できるようになり、意思決定の権限が徐々に移譲されていく

アジャイルはなぜ誤解されたのか

  • 経験主義の意味が理解されないまま、プロセスだけ導入してしまう場合があるため
  • システム思考、自己組織化、禅といった要素を知らない人には伝わりづらい
  • ウォータフォールvsアジャイルとして対立した形で広まってしまった
  • 開発・ビジネスそれぞれの立場における限定合理性としてアジャイル開発を理解してしまった
  • 従来手法を重視する人たちにとって、生業となっていた知識が否定されるような体験になってしまった
  • 誰かの思想信条を無条件に受け入れてしまう場合があった

アジャイルの格率

アジャイル」は理想状態

  • 「チームが環境に適応して不確実性を最も効率よく削減できている状態」
    • この状態に向かうため「どうしたら、さらに不確実性を減らせるのか?」という問に答えていく

アジャイルな方法論

  • 不安に向き合うこと
    • 不安の正体は不確実性である
    • 1人で不安に向き合うのは難しいので、チームの力を借りる
  • 少人数の対話を重視する
    • 少人数かつ対面でのコミュニケーションで情報共有を行う
    • 「情報の非対称性」を減らし、「通信不確実性」を削減する
  • 役割を分けない
    • 役割を分けると「役割を遂行するにはどうすればいいか」という「限定合理性」が発生してしまう
    • チームの目的について「今、自分は何をすべきか」という問いをメンバーが常に持つようにする
  • 経験のみを知識に変える
    • 「うまくいく」ことだけを目的にしてしまうと、「うまくいかない」ときに不安が増大してしまう
    • 実験によって得られた結果だけがチームにとって重要な知識となる
  • 意思決定を遅延する
    • 「仮説思考」と「リアルオプション戦略」により、経営上の意思決定を遅延させる
  • 価値の流れを最適化する
    • プロジェクト型チームは、ある要求に対してどれだけ早く応えられるかを最適化する
    • プロダクト型チームは、ある時間にどれだけの要求に応えられるかを最適化する

アジャイル開発は「脱構築」される

  • アジャイル開発においては、チームが自分たち自身のやり方や役割を変えていくような「脱構築帰納を内蔵させるように振る舞うことを要求する
  • 別のチームが実行している「ある瞬間の特定の開発手法」を真似たからといって、チームがアジャイルになるとは限らないことに注意する

書籍

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

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

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

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

目次

書籍

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

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

Chapter2:メンタリングの技術

メンタリングで相手の思考をリファクタリング

メンタリング

  • 相手の歪んだ知識を補正し、次の行動を促し成長させていく手法

メンタリングとエンジニアリングの関係

  • エンジニアリング
    • 不確実性を削減する工程
      • 組織として力を発揮するには?
        • 「人間の不完全さ」の影響を削減することが重要
  • コードレビュー
    • 問題に対するより良い考え方に気づいて成長を促す
      • コードを書いた人自身が、指摘のポイントに気づくよう促せるとベスト
  • ペアプログラミング
    • 相互に対話的に問題解決を行うピアメンタリング技法
      • ナビゲーター・ドライバーを経験することで問題解決に対する考え方のレベルが向上し、成長を促す
  • 障害時ハンドリング
    • 障害のときは目の前の課題に目が向いてしまいがち
    • 障害時のハンドリングを行うには司令塔が必要
      • 情報を整理し、不確実な状況から順番に原因を特定し、障害を収束させるためにチームを支援していく
  • チームマネジメント

「自ら考える人材を作る」ためのテクニック

  • メンタリング
    • 「自ら考える人材を作る」テクニック
      • 「自立した人材」
  • 人材タイプ
    • 依存型人材
      • 問題を与えられてから考える
      • 問題と解決策を渡されてから考える
    • 自律型人材
      • 自ら問題を発見し解決することができる
      • 問題について、自分事として捉えている
  • 依存型人材と自律型人材を分ける要素は?
    • 上司と部下という関係における期待値の問題
      • 期待値が調整されていない
        • 提案しても却下され続けてしまう
        • 負のフィードバックサイクル
        • 「学習性無気力」が生まれてしまう
      • 期待値が調整されている
        • 提案して動いた結果評価される
        • 正のフィードバックサイクル
        • 「自己効力感」が生まれる

効果的なメンター/メンティの関係性

  • メンターとメンティの関係性を効率的なものにするための条件
    • 謙虚(Humility)
      • お互いに弱さを見せられている
    • 敬意(Respect)
      • お互いに敬意をもっている
    • 信頼(Trust)
      • お互いにメンティ(自身)の成長期待をもっている
  • メンターとピアメンター
    • メンター
      • メンティにとってのロールモデルとなるような、能力と経験をもった人物
    • ピアメンター
      • ロールモデルとなるほど尊敬される訳ではないという状況から始まるメンター関係
  • 階段を上る手助けをする
    • メンティを階段を上らせるために必要なこと
      • 階段を認識させる
        • 見えていない課題に自分で気づかせる
      • 壁に梯子をかける
        • 成長を実感させ、正のフィードバックを促す
      • 階段を上りたくさせる
        • 自ら考え行動するよう促す

「他者説得」から「自己説得」に

  • 応用力
    • 自ら獲得した知識だと感じることによって生まれる
      • 自己説得
  • 他者説得
    • 自分以外の他者から、たとえや理屈、学習などを通じて、その事を説得すること
    • 特徴
      • 他人が答えを伝える
      • 体感を伴わない
      • 理解を確認できない
    • 納得が伴わないためメンティの行動を変容させることができない
  • 自己説得
    • 周りの状況などから、自ら今までわからなかったことを理解した状況
    • 特徴
      • 他人が質問で促す
      • 体感を伴う
      • 行動の変化が発生しやすい
    • 質問を通じてメンティにとっての盲点となっている部分を外していき、自ら解決策に導く

「悩む」と「考える」の違い

  • 悩む
    • 「次に取るべき行動」がわからずにいる状態
  • 考える
    • 「次に取るべき行動」を行うこと
  • メンターは「悩み」を聞き出し、気づきを促して、「考える」に変えていく

傾聴・可視化・リフレーミング

メンタリング

  • その問題が解けない理由を1つずつなくしていき、「ひとりでも」解けるパズルに変換すること
    • 感情に固執していて解けないので「傾聴」をする
    • 客観視できずに解けないので「可視化」をする
    • そもそも解けない問題なので前提を変える「リフレーミング」をする

空っぽのコップにしか水は入らない

  • f:id:umatomakun:20200214225820p:plain

「傾聴」と「ただ話を聞くこと」の違い

ただ話を聞くこと 傾聴
「自分の」意見を言う 「相手の」感情への共感を言動で表す
「自分の」興味のあることを質問する 「相手の」話の内容を「可視化」する
「自分に」興味のないことには興味がなさそうな素振りをする 「相手の」思考の「盲点」を探索しながら質問をする

共感をして話を聞き出す「信号」

  • しぐさ・うなずき・座り方
    • スマホを見たり、手で机をタップするといったしぐさはNG
    • ポジティブな話→早く細かくうなずく、ネガティブな話→ゆっくり深くうなずく
    • 横に座り、自分の全身が見えるようにして話をする
  • 表情
    • 「相手の目を見て話す」のは威圧的に感じつ場合もあるので注意する
    • 相手と同じ様な感情を表現する→「ミラーリング
  • あいづち
    • 「Aさんが、〜したんですね」「〜が許せないんですね」といった、要約や共感という形であいづちを打つ
  • 気がつかない信号を指摘してもらう
    • メンティに気になる所があったら、教えてほしいと伝える
  • 共感と同感
    • 共感
      • 相手がそのような気持ちになった理由を理解する
      • e.g. 「そういう理由であの人が許せないんですね」
    • 同感
      • 自分が相手と同じ気持ちになる
      • e.g. 「確かにあの人は許せない!」

問題の「可視化」と「明晰化」

  • 「可視化」と「明晰化」
    • f:id:umatomakun:20200214225848p:plain
  • 事実と意見を分ける
    • 「可視化」するのは事実関係
      • 感情と癒着した問題には事実がはっきりしない表現が出てきやすい
        • 質問を通じて事実関係を切り出していく
  • フォーカスポイントを作る
    • 色々な悩みをまとめて全部解消することはできない
      • 問題を分解し、1つ1つにフォーカスして解いていく
  • 衝突から比較可能への変換
    • 「悩んでいる」状態
      • 「選択肢」が不明確
      • 「比較軸」が不明確
      • 「評価方法」が不明確
    • これらを明らかにして解けるパズルに変換する

認知フレームとリフレーミング

  • 人はありのままに物事を見られない
    • 物事を認知できる枠組みが存在する
      • 「認知フレーム」
    • 認知フレームは「焦り」「優先順位」やちょっとした発言で変えることができる
      • 「リフレーミング
      • 「解けない問題」から「解ける問題に」変換する
  • 認知フレームを発見する「キーワード」
    • f:id:umatomakun:20200214225915p:plain
  • 前提の「確認」と「取り外し」
    • 前提
      • 「常識」や「普通はこうする」といった認知フレーム
    • 質問を通して前提を「確認」し、不要な前提は「取り外す」
      • 「そもそも、何で〜なんですか?」
      • 「これは必ず必要なんですか?」
  • 情報の非対称性の解消
    • 情報の非対称性
      • 自分は「わかっている」けど、相手はわかっていない
      • 相手は「わかっている」けど、自分はわかっていない
    • 解消するには
      • 自分の情報を相手に伝える
      • 相手の情報を自分が聞く
    • 「相手は〜と思っているに違いない」「自分の考えは相手に伝わっている」といった認知フレームがあると、当たり前のことができなくなってしまう
      • 相手に情報が伝わっているか確認する
  • 課題の分離
    • 不安や悩みを抱えると問題が大きくなってしまう
      • 課題を分離する
    • 思考の範囲をクリアに限定する
      • 「あなたにとって具体的に何が問題か」
      • 「あなたがコントロールできるものは何か」
      • 「どうなればその具体的な問題は解消されたと言えるのか」

心理的安全性の作り方

心理的安全性

  • 対人リスクを取っても問題ないという信念がチームで共有されている状態

「アットホームな会社」は心理的安全性が高いか

  • 影響から考える心理的安全性
    • 心理的安全性」を高めることによるチームへの影響
影響 解説
率直に話すようになる 課題について他の人がどう思うかをそれほど気にしないでも発言できる
考えが明晰になる 不安が少ないため認知の歪みが少なく、考えを明晰に表現できる
意義ある対立が後押しされる 関係性の悪化に伴った対立ではなく、より本質的な対立を健全に議論できる
失敗が緩和される 失敗を報告しやすくなり、ミスについて話し合う機会が増え、学習を行える
イノベーションが促される 今までの前提を取り払って、思考することが出来るようになり、創造的な意見が出る
組織内の障害で履く目標に集中できるようになる 目標に対してストレートに向き合えている。組織内の理不尽を取り除くことに力をかけないでも済む状態にある
責任感が向上する 対人リスクを取っても、目標に対して自律的に行動出来るようになる
  • 心理的安全性と責任
    • f:id:umatomakun:20200214225943p:plain
  • 自己主張と同調圧力
    • 同調圧力
      • 周囲と出来る限り同調してコミュニケーションするような環境・集団心理
      • 対人リスクを避けている
        • 自己主張しづらい
  • メンタリングにおける心理的安全性
    • メンタリングを効果的にするためには
      • 「対人リスク」が取れる状態を構築する
    • 「対人リスク」が取れる状態にするには
      • 自分の弱さ・自分の失敗を開示する
        • 「〜で失敗したけど、〜したら上手くいって成長した」といった物語で自分の弱さを開示する

アクノレッジメントとストーリーテリング

  • アクノレッジメント
    • 「承認」
      • メンティの存在・行動を理解し、受け入れ、感謝を伝えること
    • アクノレッジメントには3つの段階がある
  • YouメッセージとIメッセージ
    • Youメッセージ
      • 「あなたは〜だね」
    • Iメッセージ
      • 「わたしは〜と感じた」
    • ニュアンスを変えることで、よりアクノレッジメントを伝えやすくなる
  • フィードバックを求める
    • メンターがメンティに相談して意見を求める
      • 求められているという体験は、自己承認と自己効力感を生み出す
    • 当たり前のことを意識してやる
      • アクノレッジメントは当たり前なことばかりだが、忘れてしまいがち
        • ちゃんと挨拶する
        • 無視しないで話を聞く
        • 相手に感謝を伝える
        • 気にかけて話しかける
        • 自分本位ではなく相手本位で話をする

ストーリーテリングの重要性

  • 自己開示
    • 包み隠さず苦労や思いを伝えることが重要
      • 問題を乗り越えられるという感覚を得てもらう
  • 感情の共有
    • 「辛い」や「憎い」など、感情を説明する
      • 自分事として理解し、話を深く聞いてもらう
  • 価値観の共有
    • 「伝えたい価値観」をはっきりさせておく
      • 同じ様な価値観を持つことの重要性を理解してもらう
  • 半報性の原理
    • 人から施しをもらうと、自分もお返しが必要と感じる心理
      • メンティ自身の「自己開示」を引き出す

ジョハリの窓心理的安全性

内心ではなく行動に注目する

内心は見ることができないが、行動は見ることが出来る

  • メンタリングの最終工程
    • 「これからどうするか」を話し合い、合意し、次回に振り返ることを約束すること
  • SMARTな行動
    • 「SMART」
      • 「言葉は決して正しく伝わらない」という前提のもと、少しでも解釈の差を減らしていくための原則
        • Specific(具体的な)
          • 何をするのか解釈にブレの少ない言葉にする
        • Measurable(測定可能な)
          • 行動が行われたことを、どのようにして計測するのかを合意する
        • Achievable(到達可能な)
          • メンティに十分コントロール可能である行動を合意する
        • Related(関連した)
          • 課題と行動の関連性をメンティ自身が「説明できる」ような行動にする
        • Time-Based(時間制限のある)
          • いつまでに行われ測定されるのかが決まっている
  • 「わかった?」は意味のない言葉
    • 「わかった?」と聞く
      • 「わかりました」「わかりませんでした」
        • わかったかどうかの情報が、メンティの頭の中にしかない
    • 「わかる」の定義を「具体的な行動を行うことができる」とすると
      • 「〜をやってみて」「〜をせつめいしてみて」
        • 観測可能な行動を通じて、理解を確認する

能力は習慣の積分、習慣は行動の積分

  • 人の成長のサイクルは、行動・習慣・能力・成果の4つの事柄のループ

なぜ行動を起こせないのか?

  • 「行動変化」を起こすことができないとき
    • 行動を「阻害する力」と「促進する力」が働いている
      • バランスによって行動が行われたり、行われなかったりする
  • 「行動を促進する要因」
    • フィードバック機会を増やし、適切に承認していくことで強化
  • 「行動を抑制する要因」
    • 環境や構造を変えるための行動に変換して、その行動を促していく

ゴールへのタイムマシンに乗る

  • メンタリング
    • 自律的な人材を育むために行う
      • 自分が気づかなかった問題に気づくようになる
      • 認知の歪みによる感情と問題の癒着を切り離せる
      • 答えではなく、次の一手を生み出す行動が取れるようになる
    • 「ゴール認識」が重要
      • ゴールによって「認知フレーム」が変わる
        • 高いゴール設定と「ゴール認識」のレベルが伴う必要がある
    • ゴール認識のレベル
      • レベル4になると、習慣が変化し始める
        • 「ゴールへのタイムマシンに乗った」状態

書籍

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

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