ネガティブな気持ちも味方にしてキャリアを築く

「Willがない人はキャリアプランをどうするか」というのは度々登場する話題です。 私自身も強いWillだけでキャリアを築いてきたタイプではないため、個人的な悩みでもあります。

「Willがある人」と聞いてイメージするのは、「やる気に満ち溢れ、自分がどうなりたいか、仕事においてどのような経験を積んでいきたいかを明確に持っている人」ではないでしょうか。

モチベーション理論では「内発的動機」「外発的動機」に分けられるようです。 https://jp.indeed.com/career-advice/career-development/types-of-motivation

私自身は、現状に対する危機感駆動で物事を進めることが多いため、分類で言うところのフィア・モチベーション駆動の割合が強いと思います。 (興味関心の範囲が広いというのも関連していそうです)

モチベーションは「内側から湧き起こる楽しさやワクワク感のようなもの」だけではないと捉えると、自分が感じている気持ちに対して前向きになれそうです。

@ahomuさんのスライドでもWillがない人のためのキャリアとして、MUST駆動でキャリアを築くという考え方が紹介されています。 https://docs.google.com/presentation/d/1zsyAkmAEdcpyLnEDFoxGn16BSm-X3gjxHOSd1IU-tcY/edit#slide=id.g1238ccd7289_0_0

Willのない人にとってはMUST駆動も有効でしょうし、一般的にモチベーションと呼ばれている感情が見当たらなくても、何か行動を駆り立てられるものがあれば、自分の中にそれを見出すことで前に進めるのかも知れませんね。

ポジティブなもの、ネガティブなもの全てを味方につけて、自身を動かすモチベーションを作っていけばいいのかなと最近考えたのでした。

(感想)「子育てコーチングの教科書」から子育てとコーチングで大切な考え方を学ぶ

最近、子育てとコーチングの関係性に興味があり、子育て関連の本を読んでいます。 その中で良かった本がこちら。

amzn.asia

(私が読んだものは旧版、リンク先は新版のもの)

コーチングとテクニックの紹介としては以下のようになっています。

原則

  • 双方向である
  • 個別に・相手に合わせた関わりをする
  • 継続的に関わる

子どもを受け止めるスキル

  • 聞く
  • 見る
  • ペーシング

子どもに働きかけるスキル

  • 質問する
  • 承認(アクノレッジ)する
  • リクエストする

スキルを詳細に伝える本というよりは、これらのトピックについて全体感を示しつつも著者自身や周囲の同僚・上司の子育てエピソードを交えて、コーチとしての心構えを感じさせる内容になってます。

私自身は、むしろそれらのエピソードに自分の子育てとリンクする部分があり、とても共感を覚えました。
誰かから優しさを受け取ったときの暖かな気持ちや、子どもとうまく向き合えずに途方に暮れたこと。それらが自分にとって大事な思い出として心の中に留まっていることを思い出させてくれます。

コーチといえども、コーチングのスキルを駆使して完璧に子どもと向き合っているわけではなく、親として失敗や後悔を経て子どもと一緒に成長している姿に触れて、前向きな気持ちになれました。

私も「不安も含めて、すべての感情を味わうと決める」という姿勢を持てるようになりたいものです。

また「子どもは今ここで何を選ぶのか、何に価値を置くのかを問うてくる。そうやって親としての心が耕される」というくだりも印象的でした。
学習効率だとかコストパフォーマンスだとか、そういったロジックで固められた方法論ではなく、人として「真っ直ぐに心を通わせ合うこと」に向き合う必要がある。
それによって人としての学びを得られることを、改めて気づかせてくれました。

前書きにあるとおり、この本は「子育てとコーチングの架け橋になる本」だと思います。
コーチングの入門としても、子育て書としても学びと発見があるとてもいい本でした。

読書メモ:組織戦略の考え方

組織戦略の考え方

この本は日本の組織の本質的な部分を維持しながら組織設計を行うにはどうすればいいか、について考えられた本です。
「本質的な部分」とは"コア人材を長期雇用すること"と定義されています。
長期雇用を前提とした企業の中で「どのように組織構造を作るのが良いか」または「どのような点を疎かにすると組織が機能しなくなるか」について語られています。

官僚型組織と自己組織化

本書で特に印象的だったのは「官僚型の組織構造が基本である」という部分です。
ここでいう官僚型組織とは「社長をトップとして、中間層として管理職が何層かに配置されたヒエラルキー型の組織」を指しているのですが、官僚型の階層における役割分担として、下記のように説明されています。

  • トップ ... 長期的な戦略を立てる
  • ミドル ... 現在の業務の例外処理を行う、例外処理を定型化して現場に降ろす
  • 現場 ... ルーチンワークを実行、判断できない例外があればミドルに投げる

この構造では現場はルーチンワークに注力し、例外処理を判断して、現場に沿った「革新的なアイデア」を思いつくのはミドル層とされています。

本書を読んだ際の疑問として " 自己組織化されたチームと官僚型組織とは相反する考え方なのか " という点があったのですが、読み進めるうちに、

  • 相反する概念ではなく、自己組織化したチームがある組織でも組織全体として階層構造は必要
  • 自己組織化したチームを取り入れる場合の、組織全体から見た官僚型との差異はミドル ~ 現場の部分にかかってくる

という整理ができました。

官僚型の組織構造で問題となるのは、環境の不確実性が高い状況で例外処理の判断がミドル -> トップまで侵食してしまい、組織全体で長期的な意思決定ができなくなってしまう場合で、対処法として本書では"事業部制(あるいはより小規模で自律的な組織ユニット)"が紹介されていました。

一定の権限を持った組織を事業部として独立させることで、トップの例外処理に対する負荷を軽減するというものですが、不確実性の高い環境では特に例外処理に対する意思決定を現場で行うことが重要なため、現場が扱う領域が「ルーチンワーク」なのか「不確実性が高く、探索が必要なタスク」なのかで自己組織化したチームが必要かどうかを判断するのがよさそうです。

SCRUMMASTER THE BOOKの中でも、"自己組織化したチームはいずれも与えられた境界内でのみ自己組織化する"と書かれており、自己組織化したチームと官僚型の組織は両立できるものであると理解できたのは良かったです。

本書を読んで「権限をできるだけ現場に委譲する」ことの重要さを改めて感じました。
意思決定が経営者に集中するとそこがボトルネックになるため、より現場に近いところで決断ができる人を増やす必要がありますが、自己組織化したチームという文脈でも従来の官僚型の組織構造という文脈でも、意識づけやプロセスの整備によって、体制として委譲できる環境を整えていくことが重要な点だと思いました。

そのほかにも「マトリクスは何も解決しない」という話や「誰かが労力を割くことで全体へ利益が生まれる場合、利益に"フリーライド"してしまう人が発生する問題」、組織が腐敗していくプロセスについての整理など、ある程度規模が大きな組織を運営する上で壁になりそうな事象に対して言及されており、拡大していく組織のなかでどのように組織構造の変化に向き合うかを考える上で良いヒントを提供してくれる本だと思います。

日々の振り返りを便利にするwebサービスを作りました

概要

なお、振り返りの項目と内容については、yuzutas0さんの記事を参考にしています。

続きを読む

Reactで親から子へstate/メソッドをpropsで渡す時の考え方

時々忘れる時があるのでメモ。 propsを子コンポーネントに渡す際の対応関係は下記となります。

render() {
  return(
    <Child
       [子コンポーネントで使用するstate名(A)] = {親コンポーネント内のstate}
       [子コンポーネントで使用するメソッド名(B)] = {親コンポーネント内のメソッド}
    />
  )
}
// 子コンポーネント
import React, { Component } from 'react';

class Modal extends Component {
  
  constructor(props){
    super(props)
  }

  render() {
    return (
        { this.props.[親で指定したstate名(A)] }
         <button onClick={ () => this.props.[親で指定したメソッド名(B)]() }>hoge</button>
    );
  }
}

実際の例に当てはめると、

// 親コンポーネント
import React, { Component } from 'react';
import Modal from'./components/modal.js';

class App extends Component {
  constructor(props){
    super(props);
    this.state = {
      isActiveModal: false,
    }
  }

  onClickModal(){
    this.setState({
      isActiveModal: !this.state.isActiveModal
    });
  }

  render() {
    return (
    <div className="section">
      <Modal 
       isActiveModal={ this.state.isActiveModal }
       onClickModal={ () => this.onClickModal() }
      />
    </div>
    );
  }
}

この場合、

  • (親)this.state.isActiveModalを、(子)isActiveModalという名前で子コンポーネントに渡す
  • (親){() => this.onClickModal}を、(子)onClickModal()という名前で子コンポーネントに渡す

となります。

// 子コンポーネント
import React, { Component } from 'react';

class Modal extends Component {
  
  constructor(props){
    super(props)
  }

  render() {
    return (
      <div>
        <div className="content has-text-centered">
          <button className="button is-text" onClick={() => this.props.onClickModal()}>Click!</button>
        </div>

        <div className={'modal ' + (this.props.isActiveModal ? 'is-active' : '')}>
          <div className="modal-background" onClick={() => this.props.onClickModal()}></div>
          <p>This is Modal.</p>
        </div>
      </div>
    );
  }
}

コンポーネント側は、this.props.[親で指定した名前]で、親から受け取ったstateやメソッドを使用できます。

Vue.jsも同じ考え方で対応できますが、子コンポーネント側でpropsプロパティを追加しなくても使える分、Reactの方が楽にかけますね。

「速習ASP.NET Core Part4.入力値の検証」IValidatableObjectでエラーがでる場合の対処

public class Book: IValidatableObject
{
   ...
}

Part4.入力値の検証「検証ルールの追加」でModels/Book.csにIValidatableObjectを実装した際、 下記のようなエラーが出ます

'Book' does not implement interface member 'IValidatableObject.Validate(ValidationContext)'

Validate(ValidationContext)を実装しないといけないのですが、 これは次項目の「独自の検証ルールを実装する」で、新しく自分で設定した検証ルールを実装する時点で必要になるため、いまの段階は不要です。

public class Book
{
   ...
}

このように、サンプルコードから: IValidatableObjectを削除しても、正常に検証エラーが表示されます。

「速習ASP.NET Core」のDBをSQLiteにする手順

会社では普段フロントエンドの構築を行っていますが、サーバサイドの言語としてC# / ASP.netが使われているため、業務の役に立つのではということで、ASP.NET Core を触っています。

山田祥寛さんの「速習ASP.NET Core」が分かりやすかったので、少しずつ読み進めているのですが、 「Part2.モデルの基本」のEntity Frameworkの説明で、MSSQLを使用している箇所をSQLiteで実装したかったので、 SQLiteの追加〜マイグレーションまでの手順をまとめてみました。

環境は下記のとおりです。

基本的には、下記の公式チュートリアルを、書籍の内容に置き換えて適用する形となります。

.ASP.NET Core MVC アプリへのモデルの追加 | Microsoft Docs

※namespaceは個人用のプロジェクト名に合わせているので、ご自身の環境に応じて変更してください。

/ModelsにMyContext.csを追加

using Microsoft.EntityFrameworkCore;

namespace tutorial_dotnet_core_mvc.Models
{
  public class MyContext: DbContext
  {
    public MyContext(DbContextOptions<MyContext> options):base(options) {}
    public DbSet<Book> Book {get; set;}
  }
}

SQLiteの追加

startup.csを編集

// usingを追加
using Microsoft.EntityFrameworkCore;
using tutorial_dotnet_core_mvc.Models;

public void ConfigureServices(IServiceCollection services)
{
  services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
  // 追加
  services.AddDbContext<MyContext>(options => options.UseSqlite("Data Source=MyDb.db"));
  ...
}

EntityFrameworkCore.Sqliteをターミナルから追加

dotnet add package Microsoft.EntityFrameworkCore.Sqlite --version 2.1.1

マイグレーションを実行

// migrationファイルの作成
dotnet ef migrations add InitialCreate
// データベースの作成
dotnet ef database update

注意点

SQLiteにはboolean型が無いため、DBに値を入力するときは、'0','1'に置き換える必要があります