The Dabsong Conshirtoe

技術系の話を主にします。

「ニュータイプの時代」とマネジメント

なんとなく書店で見て気になった「ニュータイプの時代」を読んでみた。時代の変化とともに価値観がどう変わっているか/変わっていくかを改めて整理して知るという意味で、良い本だった。

ニュータイプの時代 新時代を生き抜く24の思考・行動様式

ニュータイプの時代 新時代を生き抜く24の思考・行動様式

せっかくなので、この本で感じたことをマネジメントに絡めて思いつくままにつらつらと書いておこうと思います。(必ずしも「ニュータイプの時代」に記述のあることを書いてるわけではありません。そこから刺激された私の思考です)

気になるメガトレンド

本書では6つのメガトレンドを紹介しているが、特に気にしておきたいと思ったのは以下2つ。

飽和するモノと枯渇する意味

モノ、溢れてますよね。私自身も日々の生活の中で「便利」だとか「効率的」だとかいうものに興味を失いつつあります。もう十分効率的だし生活も便利だよ、と。新しいテクノロジーは好きなんですが、それは便利さの追求よりも面白さを個人的に重視している気がしています。

社会のVUCA化

あらゆるところで言われていることですね。技術の進歩とグローバル化により、メガベンチャーや勢いあるスタートアップにすごい勢いで市場を取られることも多いです。それに伴い、個人のキャリアも計画が難しくなってきていることを感じます。

マネジメントに活かす

淡白な売上目標ではなく、「意味のある」問題設定が必要

  • マネジメントとして行うべきは、売上など淡白なKPIの改善を目指すのではなく、チームが自発的に取り組みたくなるような「意味のある」問題設定をおこなうこと。
  • モノに溢れ便利・裕福になった人々にとって、単純な売上によるKPIや利便性の一層の追求には「取り組む意味」を感じづらい。(もちろんそうでない人もいるとは思う)
  • そこで、「自分はこういう世界であってほしい」「この事業・この仕事をすることで、社会や自分はこう変わる」という利便性や利益を超えた「意味」が感じられる目標が必要。そのための売上であったり効率性であったりする。

計画・ルールは守るべきものではなく、「意味」をベースに見直されるもの

  • 計画やルールは過去の出来事をベースに行われるものですが、VUCAと言われる変化の激しい状態では過去の出来事が参考にならなることもあります。
  • つまり、変化の激しい状態に対して「ルール」「計画」を綿密に行ったり求めたりすることは不可能であると割り切る。
  • 計画については、見直されても素早く動けるように備えておく、見直し自体をプロセスの中に含んでしまう、が必要。
  • ルールについては、ルールが絶対的に信頼できない中で何に依拠して判断すれば良いかというと「倫理観」「美意識」といったものになります。しかし、これは個人によって異なるものであるため、それを組織に昇華する必要があります。それが「組織文化」なのでしょう。
  • 組織文化はこういった変化の激しい環境で正しい意思決定をしていくために必要なものであるため、今重要視されているのかもしれません。
    • 「HIGH OUTPUT MANAGEMENT」にも、「CUA要因」と「文化的価値」に触れた記述がありました

「教育」ではなく場所を変える

  • 同じ職務では、人によってパフォーマンスに差が出る。パフォーマンスの悪い人がいる場合、通常は教育という手段を使う。
  • しかし、人は自分自身が好奇心を持てる場所でもっとも大きなパフォーマンスを出すものである。
  • また、1万時間の法則のように、一定の時間の努力が必要なことがある一方、そうでないことも周りには多いらしい。
    • 若者がおじさんのパフォーマンスを凌駕してしまうなど、むしろ経験値がないほうが有利みたいなこともたまに見る
  • 同じ場所で一生懸命本人の望まない努力をさせるよりは、ミッションや職務を変えるなど、フィットする部分を見つけるほうが教育よりも有益かもしれない。

以上。自分としては以下の価値観をもう少し意識していきたい。

  • 利益よりも意味で表現する
  • 同じ場所にこだわって戦い続けるよりも逃げる、逃がす
  • 先が見えないものに、論理的正しさを求めすぎない。問題に応じて論理と直感のバランスをとる。

経験学習入門を読む(3) 〜経験から学ぶための3つの力〜

この記事について

経験学習入門を数年前に読んだ時の読書メモを掘り出したので読み返したところ、改めて学び直せる点がありそうと感じたので、一挙公開する記事です。

 

「経験学習」入門

「経験学習」入門

 

 本文

  • 経験から学ぶ力の三要素
    • ストレッチ
      • 挑戦的で新規性のある課題に取り組む姿勢
    • リフレクション
      • 行為を振り返り、教訓を引き出す
      • 行為中に振り返ることも大事
    • エンジョイメント
      • 仕事にやりがいや意義を見つける
  • ストレッチのための方略
    • 挑戦するための土台を作る
      • 地味な下積みにより仕事の感覚を身につける
      • 普段から小さなストレッチを繰り返すことで、やがて来る大きなストレッチをこなすことができる
      • 何歳であれ、新しい分野に飛び込む際には土台作りが大事
    • 周囲の信頼を得てストレッチ経験を呼び込む
      • 目の前の仕事の質を高くすることで、より面白い仕事が降ってくる
    • できることをテコにして挑戦を広げる
      • いきなり大きなことをしない
  • リフレクションの方略
    • 行為の中で内省する
      • 仕事の意味や背景を考えること
      • 行為後のリフレクションの質にも影響を与える。自分の頭で考えながら集中して行った仕事を振り返ることで、初めて意味のある教訓を引き出せる。
    • 他者からフィードバックを求める
      • 同僚や部下に積極的なフィードバックを求めることで、適切なリフレクションとアンラーニングを可能にする。
    • 批判にオープンになり未来につなげる
      • 批判を素直に受け取りつつ、取捨選択する。
      • 批判を受けた時に、過去を後悔するのではなく将来の成長に生かすことが大事
  • エンジョイメントの方略
    • 集中し、面白さの兆候を見逃さない
      • つまらない仕事でも集中してこなしていると、必ず面白いと思える何かがでてくるので、それを見逃さない。
    • 仕事の背景を考え、意味を見出す
      • 上からの目標を受動的に受けるだけでなく、積極的に新たな目標を設定する。
      • 無理矢理「自分は面白い仕事をしている」と思い込もうとするのではなく、その仕事を正しく解釈すれば、必ず意義が見えてくる。意味ががないなら意味のあるものに変えていけば良い。
    • 達観して後から来る喜びを待つ
      • 仕事の意味は後からわかることもあるため、あまり目の前の仕事にこだわりすぎない。

経験学習入門を読む(2) 〜経験から学ぶ〜

この記事について

経験学習入門を数年前に読んだ時の読書メモを掘り出したので読み返したところ、改めて学び直せる点がありそうと感じたので、一挙公開する記事です。

「経験学習」入門

「経験学習」入門

本文

  • 70:20:10の法則
    • 70は直接経験から学ぶ
    • 20は間接経験から学ぶ
    • 10は本から学ぶ
  • アンケートによると、新しい仕事や海外勤務、扱いづらい上司・部下と仕事をした場合に成長を感じられることが多い
  • 経験には与えられる側面と自ら作り出す側面があり、後者が大切。
    • 地味な仕事でも工夫して面白い仕事に変えるなどすることで機会を生み出す。与えられるのを待っているのは効率が悪い
    • 小野次郎「次はなにをやらせてもらえるのかな、と上から言いつけられるのをただぼーっと待っていてはダメです。自分からやることを探して、自分で技を磨き、率先して勉強しなければ、絶対に仕事は上達しませんよ」
  • 経験学習のサイクル
    • 具体的な経験をする
    • 内省する
    • 教訓を引き出す
    • 新しい状況に適用する
  • 内省をし、教訓を引き出すステップが重要。経験のしっぱなしでは成長しない
  • 経験学習サイクルは、直接経験と間接経験両方に適用可能
    • つまり、本などで他者の経験を見るときにも内省と教訓の引き出しが重要ということ
  • サイクルを回す際には、対象となる経験が「よく考えられた実践」と呼ばれる考えを満たすと活性化される
    • 課題が適度に難しくて明確
    • 実行した結果についてフィードバックがある
    • 誤りを修正する機会がある

経験学習入門を読む(1) 〜成長とは〜

この記事について

経験学習入門を数年前に読んだ時の読書メモを掘り出したので読み返したところ、改めて学び直せる点がありそうと感じたので、一挙公開する記事です。

 「経験学習」入門

 

「経験学習」入門

 

 

本文

  • 成長には2種類ある
    • 能力的成長
      • テクニカルスキル
        • 業務知識、業務遂行能力
      • ヒューマンスキル
        • コミュニケーション能力、管理能力、調整力
      • コンセプチュアルスキル
        • 論理的思考能力、戦略的に物事を考える力
    • 精神的成長
      • 仕事に対し適切な「思い」を持つこと
      • 自分対する思いだけでなく、他人に対する思いが大きくなることを成長と言う。
        • 「成長したい」だけじゃなくて、「相手のためになりたい」とか。
  • 成長のハシゴ
    • 初心者
    • 見習い
    • とりあえずの一人前
    • === ===
    • 中堅
      • 組織の3割くらい
      • 中核的な人物
    • === ===
    • 熟達者
      • 組織の1割くらい
      • 社内外に認めらるエース
  • プレイヤーとしての成長と、マネージャーとしての成長がある
    • プレイヤーは、専門領域を縦横に伸ばし、マスターを目指す
    • マネージャーでも、現場リーダーと部長クラスでは求められる能力が異なるので、別の成長のハシゴを登ると認識すべき
  • アンラーニング(学びほぐし)
    • ベテランになっても成長し続けるには、時代遅れになった知識を捨て、改めて学びなおすことが必要
    • ドルマネージャー -> シニアマネージャーと役職が変わった時にも意識する。

管理職のためのエラスティックリーダーシップ

エラスティックリーダーシップという本を最近読んだのですが、ここ最近読んだマネジメント系の書籍の中では最もしっくりきました。

目標が自己組織化されたチームである点は自分の職場の目指すところですし、3つのモードとそれごとのリーダーシップ、という図式も単純明快でわかりやすく、実践で活かしやすいと思いました。 

 

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

 

 

 ただ、この本は基本的には現場のマネージャー向けのプラクティスとして書かれていると思いますが、私が担当しているVPoEのような、複数のチームや組織全体を見るいわゆる管理職的な人にとってはどのように活かせるのだろうかと考えをめぐらしながら読んでいました。

 

本書ではその辺りについて、第10章「管理職のためのマニフェスト」で軽く触れられており、モードごとのプロジェクト、チーム、個人に分けて説明されています。ここでは、それを参考にしつつ、評価育成や組織編成といった管理職の行う仕事の観点(と私個人の経験)からまとめてみました。

 

ここでの管理職の定義

  • チームリーダーの上長にあたり、開発チームに直接的な影響力がない
  • 複数のチームを管理する立場にあり、その規模は10名〜50名程度
  • ミッションとして、ラインの管理や、評価、育成、採用の制度設計といった組織づくりがある

 

活かせるであろうポイント

  • チームリーダーの支援、育成、評価の指針として
  • 採用、育成、評価制度設計の指針として
  • リーダー、メンバーの成長を支援する組織編成の指針として

 

チームリーダーの支援、育成、評価

管理職かそのチームやリーダーの状態確認のフレームワークとして、もしくはチームリーダーに、自身のチームの現在地の確認と将来的なプランを計画する手助けとして、エラスティックリーダーシップにおける3つのモードの概念が利用できるでしょう。

 

例えば、チームが日々のタスクをこなすのが精一杯で、中長期のプロダクトロードマップを見越した技術プランが練れていなかったり、なかなかメンバーのキャッチアップが進まずチームの力が上がってこないようなケースがある場合、

  1. チームがサバイバルモードにいるという共通認識をリーダーと合わせる
  2. 指揮統制型のリーダーシップを発揮して、チームを学習モードへ移行させるように指導する

という方向へ導くことが必要です。

 

学習モードに導くには時間の捻出が必要ですが、プロダクトスケジュールの見直しやチーム構成の変更などリーダーの範疇を超える対応が必要な場合は、管理職が手を打つ必要があります。(本で援護射撃と表現されているのはこのようなことかなと思いました)。

また、チームが良くない方向に進んでおり、品質やスケジュール面でのリスクがある場合、本書10.2.1「サバイバルモードのプロジェクト」に記載の通り、リーダーやチームにそのリスクを説明して対策すべきです。

リーダー自身がサバイバルモードにいる自覚がない場合には気づかせる責任も管理職にはあります。

同じように、学習モードから自己組織化モードへチームを持っていけるようなコーチングなりフィードバックなりが、管理職の仕事となってきます。

 

採用、育成、評価制度設計の指針

上記の直接的なコーチングと並行して、メンバーを含めた育成や評価の制度面にエラスティックリーダーシップのエッセンスを含めることで、組織全体の改善につなげられるでしょう。各チームへの間接的な支援です。

メンバーの評価指針はさまざまな観点があると思いますが、チームビルディングにどれだけ良い影響を与えられているか、という点が一つあると思います(チームビルディングはリーダーだけの責任ではないと考えています)。

チームを自己組織化モードに持っていけるような取り組みを率先して行えているメンバーや、サバイバルモードを抜け出そうとする行動をするメンバーを高く評価することで、組織全体を自己組織化チームを目標として動いてもらえるようにします。

バス因子を除こうとする行動や、プロジェクトの進行管理や仕様調整などをリーダーに頼らずともできる or できるようになる、という行動もそうです。

 

リーダー、メンバーの成長を支援する組織編成

管理職としては、ある特定のチームだけでなく、すべてのチームが自己組織化モードへと移行できるようにもっていくのが望ましいはずです。

ただ、特定のチームは現状のメンバー構成ではその状態に持ってくのが困難な場合もあります。

管理職が組織人事の権限を持つならば、チーム編成を変更することでその問題に対処します。

例えば、人材流出やプロジェクト状況の大きな変化によりサバイバルモードへと移行してしまったチームには、経験豊富なリーダーを異動や採用により投入し、指揮統制型のリーダーシップでサバイバルモードを脱出してもらう。

また、それとは逆に、チームが自己組織化モードに移行し、リーダーの仕事量が減っている場合、思い切ってリーダーを剥がし、別プロジェクトに挑戦してもらう。うまくいっているチームの体制変更は迷いますが、リーダーが安全地帯から出られるようにする事でリーダーにとってもチームにとっても今以上の成長環境を提供できるはずです。

 

自己組織化チームにおけるチーム体制変更の体験談

私個人の経験ですが、以前に自己組織化されたチームのリーダー務めていたことがあります。もちろん最初からそうではなかったのですが、2年くらいチームの運営をしたころにはメンバーは自立し、私の役割は大枠でのファシリテートとレビュー、技術的な改善を率先して行う、くらいでした。次期のリーダー候補もしっかり成長しており、正直自分がいなくても回るだろうなという感覚が強くありました。

 

そんななか、次期リーダー候補メンバーに更なる刺激を与えたいという思いと、自分自身も新たなプロジェクトに挑戦したいという思いからチームリーダーをメンバーに譲り、私は新規プロジェクトのリーダーとなりました。

 結果、もとのチームはチーム編成やビジネス環境の変遷はありながらも新リーダーのもと安定してプロダクト開発を続けられており、私自身も新製品の立ち上げや組織作りなどに挑戦できるようになり、お互い、ひいては組織全体にとって良い人事になったなと思います。

 

まとめ

管理職におけるエラスティックリーダーシップとは、リーダーに対するコーチングを基礎とした個々のリーダー/チームのモードに応じた支援と、育成評価の制度設計や採用計画などのシステム作りにより、組織全体のモードを管理することにあるのかなと考えました。

PyConJP 2016で「Pythonで入門するApache Spark」を話した

1ヶ月近く過ぎてしまいましたが、今年のPyConJPで、「Pythonで入門するApache Spark」というタイトルでスピーカーを務めさせていただきました。

資料

Jupyterコード

動画

PyConJPには参加者として2012年くらいから参加していましたが、スピーカーとして参加するのははじめてでした。大きなカンファレンスで一度話してみたいという願望があったので、叶ってよかったです。立ち見の方もいらっしゃるなど、思った以上に人が集まりとても緊張しましたが、良い経験をさせていただきました。

発表資料の準備をすることで、Sparkの基礎をもう一度振り返ることができたのが良かったかな。時には人前にさらされることも大事ですね。

運営の皆様、発表準備を手伝っていただいた皆様、どうもありがとうございました。

会社ブログでも紹介していただきました。ありがとうございます!

SparkのShuffleについて調べてみる (4:Shuffle Readの実装探検)

前回の記事では、SparkのShuffle Writeの実装を追ってみました。

今回は、Shuffle Readの実装について調べていきたいと思います。(前回と同じく今回も個人的な理解の促進のためにこの日記を書いています。)

Shuffle Read

Shuffle Readは、Shuffle Writeにより書き出されたデータを読み出す処理です。処理するタスクの前段のステージがShuffleステージである場合に行われます。

Shuffle Readは、Sort ShuffleでもHash Shuffleでも同じクラス(BlockStoreShuffleReader)が使用されます。

データのフェッチ

BlockStoreShuffleReaderは、ShuffleBlockFetcherIteratorを使用して対象のデータ(ブロックIDとデータストリーム)を逐次取得します。この時、リモートにあるデータを一度にフェッチするデータの最大はspark.reducer.maxSizeInFlightにより制御されます。この値が大きいほどフェッチの効率はよくなりますが、メモリへのプレッシャーが増します。実際には、最大で5ノードへ同時にリクエストを送るためにこの値を5で割った数を上限としているようですが、どこでその「最大5ノード」という制限をしているかは不明でした。

どのBlockManagerからどのBlockIDを抜けばいいかは、MapOutputTrackerというmapタスクの出力を管理するオブジェクトが教えてくれます。

また、Shuffle Writeの方式によってデータの書き出され方は異なりますが、ここの違いはBlockManagerの中でShuffleBlockResolverにより吸収されています。例えば、Sort Shuffleの場合は前回紹介したIndexShuffleBlockResolverが使用されます。

フェッチされた各データは解凍とdesrializeがされ、キーに応じた集約が行われます。Map Side Combineが行なわれている場合はマージされた結果同士のマージ、そうでない場合は個々の値のマージが行われます。

データのマージ

マージにはExternalAppendOnlyMapというオブジェクトが使用されます。このオブジェクトは値のマージ方法を知っており、データを外部から受け入れてマージされた結果を返します。データが一定の水準に達するとディスクに退避するところが特徴的です。Shuffle Writeで登場したExternalSorterもデータがメモリに収まらない場合はディスクに退避する機能を持っていますが、どちらも同じSpillableというtraitで実現しています。

また、ExternalSorterでもデータの保持にはPartitionedAppendOnlyMapとうオブジェクトを使用しており、先のExternalAppendOnlyMapと同じ親(AppendOnlyMap)を持ちます。AppendOnlyMapではKey-ValueのデータがシンプルなArrayとして記録されるオープンアドレスのハッシュテーブルです。基本的にはキーが入っているインデックスの一つ後ろに値が入っているようです。

キーのポジションは、キーのハッシュ値とQuadratic Probingというキーの衝突回避の手法により決定されているようです。

こうしてマージされたデータがBlockStoreShuffleReaderから返却されます。sortByKeyのようなソート順序の指定がある場合、ExternalSorterによりソートが行われた上で返却されます。

以上です。ExternalAppendOnlyMapでspillしたデータとオンメモリのデータをマージするところなど、まだまだ深く潜り込めるポイントはたくさんありそうですが、ひとまずこの辺で。