勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

情報システムの障害状況ウォッチ(2018年後半)

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。

元ネタはこちら。みんな見たほうが良いよ!

2018年後半(7~12月)の傾向

  • 2018年前半はかなりハイペースで障害が推移(月平均5.8件)していたが、後半は若干スピードダウンして月平均5.2件のペースにダウン。通年では月平均5.5件の水準となったそうだ。とはいえ2017年の月平均が4件なのでトラブルの多い年だったことにはかわりない。
  • 気づかなかったが前回集計からローカルニュース中心に報道された自治体などのトラブルを別カウントするようになったようだ(この障害は主要分析のカウントには含まない)。

主要なトラブルなど

というわけで、いまさらだけれど2018年後半のトラブルのおさらい。こんなことありましたね。

ファーストサーバ Zenlogic全停止事故

ソフトバンク 大規模通信障害

病院の電子カルテシステムがランサムウェアに感染

雑感

Effective DevOps 第Ⅰ章~第Ⅳ章を読んだ #デッドライン読書会

技術書の積読が一向に減らない。世の中的には積読合宿で消化したり、ABDという読書手法で団体戦で消化する方法もあるようだが自分はあくまで自分自身で消化したい派である。というわけで知人と一緒にデッドライン(締切り)を設定して積読に立ち向かうことにした。第一弾としてEffective DevOpsを読んでいる。ボリュームがあるので前半と後半に分けていて、今回は2週間で前半部まで読んだ。というわけで本記事は前半の感想です。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps関連書籍と、Effective DevOps

流行りのキーワードということもあり、DevOps本はいろいろと発売されている。これまでに自分でチェックした本は以下の通りである。

The DevOps 逆転だ!究極の継続的デリバリー

2014年に翻訳された本。ゴールドラットのThe Goalのような小説仕立てでDevOpsを紹介している。非常に面白いのだけれども、DevOpsをまったく知らない人向けな印象。なお米国流のシステム開発の文脈で語られているので日本的ソフトウェア開発との文化的違いも気になる。ある意味、経営層やマネージャ向けの本と言えるだろうか。残念ながら日本では刺さりにくそう。

DevOps教科書

2016年に翻訳された本。割とアーキテクチャ的な視点でDevOpsが語られているのが特徴。今あらためて読んでみると、DevOpsの文化的側面はほとんど触れていないのでびっくりする。一方でDevOpsを実現するアーキテクチャという観点での深掘りは非常に参考になる。

The DevOps ハンドブック 理論・原則・実践のすべて

2017年に翻訳された本であり、 The DevOps 逆転だ!究極の継続的デリバリーの続編でもある。前作とは一転してガイドブック/テクニック集な位置づけとなっており、現時点で最も教科書的に扱える書籍である。割とよく読み返している。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

2018年の翻訳本。タイトルどおりDevOpsを扱った本ではなく、SREについての本だが同書内でも「SREはDevOpsに拡張を加えたものと考えられる」と書かれている通り、DevOps的な文脈で読むこともできる。ただ本書はあくまでGoogleのSREに関する論文集であるため、DevOpsの参考書としては相当ハードルが高いと思う。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

2018年の翻訳本。DevOpsの解説書というより、毎年発表される「DevOps Status Report」の過程で得られたデータを下に、何をすれば開発スピードが改善されるかについて書かれている。DevOpsをさらに突き進むために、もしくは評価するために読むと良い書籍。

そして「Effective DevOps ―4本柱による持続可能な組織文化の育て方

で、やっと本題。本書はどのような位置づけにあたるのだろうか。
前半しか読んでいないけれども、現時点の印象は

  • DevOpsを進めながら突き当たる課題について考えるきっかけを与えてくれるエッセイ集
  • プロセスとしてのDevOps導入時(輸入時)に抜け落ちてしまうカルチャー的な部分を補完する本

である。
というわけで、本書はDevOpsを学ぶ本ではなく、実践している人が読むべき本というのが前半を読んだ感想だ。

Effective DevOps 前半の感想

さて、Effective DevOps 第Ⅰ章~第Ⅳ章の感想である。なお実は私は翻訳本ではなく原著をベースに読んでいるので引用部部は訳書とは異なるかもしれない(そして誤訳しているかもしれない)点には注意いただきたい。

ロッククライミングの例え(2章 DevOpsとは何か)

DevOpsの説明でロッククライミングとの類似性が示されているところでオッと思った。確かにわかりやすい。この話は以下のブログ記事が元ネタっぽい。

DevOpsとITIL(4章 基本的な用語と概念)

4章では関連する方法論とDevOpsの関係について書かれているが、ITILについての触れ方は興味深い。

(ITアナリスト兼コンサルタントのStephen) Mann氏はITILプロアクティブではなく反応的であることが多いと述べています。そのため、ITILを使用している組織は、より積極的な計画と顧客重視を実践に追加する方法を検討すべきです

DevOpsとITILの関係についてはDevOps教科書SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームでも軽く触れられているが、上記のような見方までは提示されていない。

アンチパターンとしての根本原因分析(RCA)(5章 devopsに対する誤解とアンチパターン)

DevOps本によくある項目が「DevOpsに対する誤解」である。例えばSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームEffective DevOps ―4本柱による持続可能な組織文化の育て方で比較してみるとこんな感じ。

  • Effective DevOps ―4本柱による持続可能な組織文化の育て方 (5章)
    • devopsに関係があるのは開発者とシステム管理者だけだ
    • devopsはチームである
    • devopsは肩書だ
    • devopsはウェブ系のスタートアップだけの問題だ
    • devopsには認定資格が必要だ
    • devopsとは、半分の人員ですべての仕事をすることだ
    • devopsには「正しい方法」(または「間違った方法」)がある
    • devopsを取り入れるためには X週間 /Xか月かかる
    • devopsはツールの問題だ
    • devopsとは自動化のことだ
    • devopsは一時的な流行だ

ラインナップの重複と差異が両書の違いを表しているようで面白い。

一方でEffective DevOpsにはアンチパターンに関する章もある。その中で根本原因分析(RCA)を取り上げているのが面白い。

根本原因分析には、システムが線形的に失敗する(または成功する)という暗黙の前提があります。これは、十分に複雑なシステムには当てはまりません

これはDevOpsに固有な話題ではなく、近年の複雑化するソフトウェアにおける重要なポイントを指摘していると思う。一方で、特に国内ソフトウエア開発のプラクティスでは類似の「なぜなに分析」が障害分析手法/品質改善手法として定着しているわけで、この使い方は今後見直すべきポイントの一つだろう。

6章 効果的なdevopsのための4本柱

おそらく本書の肝となるのがこの4本柱の概念である。すなわち

  • Collaboration:開発チームと運用チームの協力
  • Affinity:チーム間の関係を構築し、お互いに学び、目標を達成する
  • Tools:アクセサレーター
  • Scaling:成長・成熟および縮小の考慮

である。特にAffinityはこれまでのDevOps本ではあまり取り扱われていない(はずの)テーマだ。

9章 アフィニティ:個人からチームへ

で、アフィニティの話である。本章では個人間、個人とチーム、そしてコミュニティとの親和性(アフィニティ)について語られていて、個人的には本書の前半部で最も学びの多かった章だ。本書ではDevOpsから始まる信頼関係を組織レベルから業界レベルに広げ、革新するためにどうするかまで大きなスコープについて語られている。
なお、組織レベルの信頼性の問題は医療分野における安全確保のために色々と研究されてきているらしい。→Pathways for Patient Safety: Working as a Team(PDF) (この記事はちゃんと読めていないので、あとで改めて取り上げたい)

  • チーム間の対立や利益相反をどうするか
  • コミュニティとの情報共有と企業間の競争をどう考えるか(共有しすぎると競争力が弱まるのでは?)
  • 特定の個人の言動がアフィニティを破壊する(いわゆるBrilliant Jerks問題)
  • 妨害的なチームの存在の対処

などなど興味が尽きない。
本書では割とさらっと触れられている程度である。個人的に、もう少し深掘りしてみたい。

腐ったリンゴ理論/ヒューマンエラーを理解する

DevOps関連の書籍(DevOps HandbookやEffective DevOpsなど)やPostmortem関連の記事でよく引用されている書籍「ヒューマンエラーを理解する―実務者のためのフィールドガイド」について調べたメモ。

ヒューマンエラーを理解する―実務者のためのフィールドガイド

ヒューマンエラーを理解する―実務者のためのフィールドガイド

The Field Guide to Understanding 'Human Error' (English Edition)

The Field Guide to Understanding 'Human Error' (English Edition)

Bad apples

安全尊重の文化

DevOps推進の文脈でよく出る話が、安全尊重の文化である。そしてこの安全を議論する上で避けて通れないのが「ヒューマンエラー」の誤用である。
例えば「The DevOps ハンドブック 理論・原則・実践のすべて」では次のように記載されている。

4.1 組織的な学習と安全尊重の文化を生み出す
複雑なシステムのなかで働くときには、定義上、自分の行動の結果をすべて完全に予測することは不可能である。そのため、たとえ事前に準備し、注意して仕事を進めても、日常業務のなかで予想外の結果が起きたりすることがある。
こういった事故が顧客に影響を起こしたときには、なぜそのようなことが起きたかを知ろうとする。根本原因はヒューマンエラーだと見なされることが多く、そうすると、管理者たちは問題の原因を作った者を特定し、非難し、恥辱を与えるという反応をとりがちだ。そして公然とそうでなくても、管理者たちはミスを犯した人物を処罰することをほのめかす。そして、ミスの再発を防ぐために、プロセスや承認を増やす。

「ヒューマンエラーを理解する―実務者のためのフィールドガイド」はまさにこの問題について書かれた良書のようだ。「The DevOps ハンドブック 理論・原則・実践のすべて」だけでなく、目につく範囲では

など、繰り返し紹介されている。

冒頭で紹介した通り翻訳書もあるのだが、調べてみるとlearning.oreilly.comで原著にアクセスできるようなのでちょっと読んでみた。

腐ったリンゴ理論

「ヒューマンエラーを理解する―実務者のためのフィールドガイド」では、ヒューマンエラーについて「以前の考え方(Old View)あるいは腐ったリンゴ理論」と「新しい考え方(New View)」を提示している。具体的には次のような対比になっている。

以前の考え方(腐ったリンゴ理論) 新しい考え方
「ヒューマンエラー」はトラブルの原因です 私たちが「ヒューマンエラー」と呼んでいるのは、より深いトラブルの兆候です
「ヒューマンエラー」は恐れられ、戦われるべき独立した行動のカテゴリーです。 「ヒューマンエラー」は帰属、事実の後に我々が下す判断です
「ヒューマンエラー」がターゲットです。人々の行動は私たちがコントロールする必要がある問題です 行動は、人々のツール、タスク、および動作環境の機能に体系的に関連しています
「ヒューマンエラー」は戦争を宣言するためのものです。人々は完璧を練習する必要があります 「ヒューマンエラー」とは、複雑さや実際の仕事の矛盾に人々がどのように対処したか(成功したかどうか)についての情報です
「ヒューマンエラー」は単純な問題です。すべてのシステムが整ったら、人々に注意を向けさせ、順守させます 「ヒューマンエラー」問題は、それを作成するのを助ける組織と少なくとも同じくらい複雑です
より厳格な手順、コンプライアンス、技術、監督により、私たちは「ヒューマンエラー」の問題を減らすことができます 人々の日々の仕事の厄介な詳細をよりよく理解することで、我々は彼らにとってそれをより良くする方法を見つけることができます
私たちは、ゼロエラー、ゼロ傷害、ゼロ事故を達成することができ、そして達成しなければなりません 私たちは人や組織の回復力を高めることができますし、しなければなりません

つまり、腐ったリンゴ理論とは「システムが正しく動いているのならば、腐ったリンゴおよびそこから生じる過ちを全て除去すれば良い」という考え方である。そしてこの考え方は現代の複雑な仕事やシステムには通用しない、というのはエンジニアのみなさんであればご存知の通り(そして常に「古い見方」をする敵に悩まされる)

なお、同書では(改めてみればあたりまえの)以下のような指摘などがされている

  • 腐ったリンゴ理論は有用性に限界があるだけでなく、逆効果になる可能性がある
  • 腐ったリンゴ理論から生み出される拙速な対策(関係者の懲戒、再訓練、手続きの追加など)は組織の学習を阻害し、生産性を悪化させ、かつ対策としても不十分となる

また、同書では航空業界などの様々なトラブル事例分析も添えて、具体的なヒューマンエラーの分析などについて記されているようだ。いつかちゃんと読みたいが、とりあえず今回はこんなところで。

EAの死あるいは再生、複雑適応系

昨年読んだ「――システム構築の大前提―― ITアーキテクチャのセオリー」は現代版のEA(Enterprise Architecture)の教科書として非常に素晴らしい本であった。というわけで久しぶりにEAに興味が湧いていろいろと調べていたところ、2019年に入って「Complex Enterprise Architecture: A New Adaptive Systems Approach」という書籍が出版されていたので読んでみた、という記事。

なおKindle化はされていないが、APressでPDF版が購入できるようだ(プレビューもできる)。

また米オライリーSafariに加入していれば追加費用無しにWebで読むことができる(加入方法はこちらの記事を参照)。

くわしくは後述するが、なかなか難しい本である。一方でEAを取り巻く最新の状況や歴史も紹介されているので、キャッチアップには非常に役立った。

EAの死

Complex Enterprise Architecture: A New Adaptive Systems Approach」は、従来のEAは現在は機能不全となっており見直しが必要であることを主張している本である。既存EAの機能不全については同書以前に次のような批判があることを紹介している。

では、改めてEAは何が問題なのだろうか。同書では次のような指摘がされているようだ。

  • 従来のEAはトップダウンアプローチのフレームワークである。これは、企業が単一の大規模な情報システムを構築している時代にはうまく機能していた。
  • しかし時代は変わり、企業が多数の情報システムを保持し、開発プロセスの多くははアジャイル/DevOpsに変化。
  • 巨大な情報システムをスクラッチで構築する時代は終わった。システム開発の多くは新技術を用いた既存システムの更改や、既存システムをベースとした機能追加となっている。
  • この環境下で従来のEAはその価値を正しく発揮できていない。
  • 現代の企業は非常に動的に変化している。静的なEAでコントロールすることは難しい。企業情報システムのすべてを少数のエンタープライズアーキテクトが掌握、管理することは現実的ではない。

まあ、ですよねー。実際のところEAを活用できている企業は存在するのだろうけれど、一般論としてはうまくいっていない印象はある。

Complex Enterprise Architecture

というわけで、本書ではこの状況を打破するために以下のような提言を実施している、と思う……(ここでちょっと自信が無いのは私の英語力の問題もあるのだけれども、本書はほとんど例示がないのだ。念のため著者のWebサイトも確認してみたけれども見当たらない様子。ということで私が正しく理解している自信はちょっと無い。興味のある方は原著をあたっていただきたい)。

というわけで本書ではこれを実現する場合に整理すべき事項(オブジェクト類)などについても整理している(がほとんど文章なのでイメージしにくいのだ)。

うーん、これはどうなんだ……

現実的ではあるが、これでいいのか?

自分の見聞きした範囲が狭いのだが、実態として多数の情報システムを抱える企業が統制を効かせる方法としては、本書に書かれたような方向性になってしまうような気がする。

  • 企業単位の全体俯瞰モデル(EAにおけるBAやDA、SA)は作成できたとしても維持困難で、実態としては割とカオス。
  • 一方で統制を効かせる必要はあるので、ルールやガイドラインを整備してエントロピーの増大を抑制。
    • しかし、ユーザ部門などによるシャドーITの導入増加などで混乱は拡大。

ただ、この状況を「複雑適応系としてコントロールする」なんて、本当にできるのだろうか? というのはちょっと疑問である。
もうちょっと、調べてみようかな……

――システム構築の大前提―― ITアーキテクチャのセオリー

――システム構築の大前提―― ITアーキテクチャのセオリー

PagerDutyのPostmortem(トラブル事後分析)ガイドが公開。かなり良さそう。

Monitoring Weekly - Improve your application monitoringのニュースレター経由で知ったのだけど、PagerDutyからPostmortemのガイドが公開されていたようだ。

ざっと読んでみたところ、かなり有用そう。

Postmortemとは

訳書だとSRE本やEffective DevOpsなどが詳しかったと記憶しているが、定義はこんな感じ。

ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因(群)、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
SRE 15 章 ポストモーテムの文化:失敗からの学び

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

未訳だけれどもSRE本の続編、SRE Workbookに書かれたPostmortemの話は以下の記事で触れているので興味があればご一読いただきたい。
agnozingdays.hatenablog.com

PagerDutyのPostmortemガイド

PagerDuty Postmortem Documentation
というわけで、ざっと読んでみた感想。

  • ChromeGoogle翻訳機能でもけっこう読める(ただし、Postmortemが「死後」と翻訳されるため、かなりスピリチュアルな翻訳になるので注意)
  • 「学習する文化」といった背景の話から初めて、ステップバイステップの執筆ガイド、共有方法までカバーされていて、たぶんいきなりトライすることができそう
  • テンプレートだけでなく、チェックリストなども含まれていて至れり尽くせり
  • Apache Licenceなので使い易そう
  • 参考資料集が充実していて興味深い。紹介されていた以下の本はぜひ読んでみたいが・・・(どちらもSafariBooksOnlineに収録はされているようだ)

The Field Guide to Understanding Human Error (English Edition)

The Field Guide to Understanding Human Error (English Edition)


SREやDevOpsを採用(?)していなかったとしても、品質改善活動の一環として「トラブル報告」「原因分析」「再発防止」などの活動をしているのであれば、いろいろと改善のためのアイデアが見つかりそうだ。

Scratch3.0でAtCorderに参加できるようになったのでいろいろやってみた

AtCorderという競技プログラミングサービスがある。設問に対して各種の言語で回答を書くと合否判定されるものなのだけれども、最近Scratchで書いたロジックをC++に変換してAtCorderの解答欄に入力できるという面白ツールがリリースされていたので、これを利用していろいろ遊んでみた。

やってみて気づいたこと

はじめのはじめ

基本的には次のページの通りだけれども

Scratchの全てのブロックのうち何が利用できるかがわからず、途中で対応していないイベントブロックを使おうとしたりして、少し回り道をしてしまった。
利用できるブロックは以下にあるので、軽く目を通しておくとよさそう。

入力処理について

こちらのページの説明では

Scratch では標準入出力は使えないので、標準入力の代わりに「〜と聞いて待つ」ブロック(一行の文字列入力欄が現れます)、標準出力の代わりに「〜と言う」ブロック(指定された文字列をネコがしゃべります2)を使っています。
Scratcher's AtCoder の紹介 - Qiita

とあったのだけど、この標準入力は改行までを受け付けるのではないという事に最初は気づかず少しハマってしまった。
例えば練習問題のPracticeAだと

入力は以下の形式で与えられる。

a
b c
s

とあったので「a」「b c」「s」が入力されると思ったら違った。普通に4回に分けて入力されるようだ(つまり2行目のb cは別々に入力される)。
よく見たら以下の記事で細かく説明されてた。

入力は調べるの「a と聞いて待つ」のように使う (改行とスペースで分けて読まれる)
Scratch3.0を使ってAtCoderで競技プログラミングを楽しむ - Qiita

なるほど〜

テストをやりやすくする工夫

AtCorderに提出するためには上記の通り入力を受け取るようにする必要があるのだけど、コードをテスト、デバッグする際にいちいちキーボードから入力するのは面倒。
というわけで試行錯誤した結果、次のような形にすると良さそうということがわかった。

  • 初期化、主処理はブロック化する
  • 提出用のスタートイベント(緑の旗)とは別にテスト用のイベントを作って、テスト時はコードでデータを入力する
  • テストパターン(問題で示される入力例)を最初にコメント文にしておく

具体的にはこんなイメージ。
f:id:kent4989:20190124233818p:plain
https://scratch.mit.edu/projects/281501288/editor/

便利関数が使えない

たとえばSortなどもScratchでは手組みする必要があるのでなかなか手強い

その他の感想など

頭の体操になって面白い。ブラウザだけで完結するのも手軽で良い。

小学生からはじめるわくわくプログラミング

小学生からはじめるわくわくプログラミング

小学生からはじめるわくわくプログラミング2

小学生からはじめるわくわくプログラミング2

Scratchで学ぶ プログラミングとアルゴリズムの基本

Scratchで学ぶ プログラミングとアルゴリズムの基本

ゲリラでない採用面接ガイド(自分用)

ほぼ自分用メモ。人材の採用面接はいつも悩ましくて、いろいろ調べたり考えたりしている。いっぽうですぐに調べたことを忘れてしまう(だって人間だもの)のでストアしておく記事。定期的に更新していきたい。

現時点の採用面接の基本方針

所属組織のガイドラインはあるのだけれども、個人的にはいろいろと改善していきたいと思っている。というわけで現時点の方針は次のような感じ。

  • イントロダクションで面接の流れを説明する
  • 面接官(自分)の自己紹介をしっかりする
    • その後の質疑応答をスムーズに進めるために、面接官のレベルを(出来れば)把握してもらう
  • 予め決めた評価軸に沿って評価する(思いつきで質問しない)
    • アドリブを否定するものではないが、あくまで点数をつけるために必要な質問をする
    • このあたりの詳細はGoogleのワーク・ルールズ本が詳しい
    • 評価軸は秘密
  • 妥協しない
    • 短期的な視点(例えば今すぐ、どうしても人が欲しいとかで)で決定しない

参考文献(順次追加予定)

デマルコ / デッドライン

古典その1。

デッドライン

デッドライン

正しい管理の四つの本質

  • 適切な人材を雇用する
  • その人材を適所にあてはめる
  • 人びとの士気を保つ
  • チームの結束を強め、維持する

(それ以外のことは全部管理ごっこ

常にこの言葉に戻るようにしている

Joel on Software / 採用面接ゲリラガイド

古典その2。

Joel on Software

Joel on Software

面接の前に、私は候補者の履歴書を読み返し、面接のプランを紙切れに書き出すようにしている。プランと言っても、要は私が聞きたいと思っている質問のリストだ。次に挙げるのはプログラマの面接で使う典型的なプランだ。

  1. イントロダクション
  2. 候補者がやった最近のプロジェクトについての質問
  3. 簡単なプログラミングの質問
  4. ポインタ/再帰の質問
  5. 答えに満足しているか?
  6. 質問は?

面接の終わりに、その人が頭が良く物事を成し遂げる人だと納得させてくれ、4人か5人の他の面接者も同じ意見なら、あなたはその人を雇ってもたぶんまずいことにはならないだろう。しかしもし何であれ疑念があるなら、誰かもっといい人の現れるのを待った方がいい。

ほんこれ。

ワーク・ルールズ!―君の生き方とリーダーシップを変える

要するに、ほとんどの面接が時間の無駄なのは、面接者が最初の10秒で得た印象を確証するために99.4%の時間が費やされているからなのだ。「あなた自身について聞かせてください」「あなたの最大の弱みは何ですか?」「あなたの最大の強みは何ですか?」。こんな質問には何の価値もない。
多くの企業で採用されているケース面接や難問奇問にも、同じく価値はない。(中略)
こうした類の質問でわかるのは、せいぜいのところ、訓練すれば改善できる個別のスキルにすぎず、受験者を評価する役には立たない。最悪の場合、こうした問題は相手の知らない取るに足らない情報や知見を土台にしているため、面接者を賢くなった気にさせたり自己満足を感じさせたりするだけに終わってしまう。

おっしゃるとおり・・・

Joy, Inc. 役職も部署もない全員主役のマネジメント

メンロ ーでは密接に協力しあいながら仕事をする 。ゆえに 、最初のインタビュ ーでの必須事項は 、 「幼稚園レベルのスキルを持っているか 」だ 。礼儀正しくしているか 、周りとうまく遊べるか 、人と分けあえるか ?

最近のプロジェクトでは本当にこの要素の重要性が高まっていると思う。

NETFLIXの最強人事戦略~自由と責任の文化を築く

NETFLIXの最強人事戦略?自由と責任の文化を築く?

NETFLIXの最強人事戦略?自由と責任の文化を築く?

最適な人材を探すうえで大切なのは、「カルチャーフィット(文化の適合性)」ではない。カルチャーフィットがよい人とは 、一緒にビ ールを飲みたい相手だというくらいの意味しかない 。この方法で人材を探すのは 、往々にして激しくまちがっている。会社が必要とする仕事に合致したスキルをもつ人材には 、じつにさまざまな個性をもった人がいる 。

これは興味深い指摘だと思う。というわけで個人的には「所属組織に向いているか」という観点での評価はしないように心がけている(むしろ、自組織の特徴をしっかりと相手に伝えて、相手側で判断してもらうようにしたいと思っている)。

アジャイルエンタープライズ

アジャイルエンタープライズ

アジャイルエンタープライズ

第21章 アジャイルで使える人事制度を考案する

従業員を大切にする文化を築きたいなら 、内発的に動機付けされた従業員がいれば実現できるでしょう 。ここで疑問となるのが 、内発的に動機付けされた従業員を採用するときに 、 HRは何を求めるべきかです 。これについては 、自律性 、熟達 、目的についての考えを聞きましょう 。たとえば 、以下のような質問をするといいでしょう 。

  • 何を学んでいますか ?
  • 最後に読んだ記事は何ですか ?
  • 何について興味がありますか ?
  • 習得したいと思っているスキルはありますか ?
  • 仕事の自律性についてどう思いますか ?
  • プロダクトを作るときに 、顧客はどのような役割を果たしますか ?
  • コラボレ ーションを促進する方法は何ですか?

Joy,Inc.本と同じだが、最近このあたりの重要性が高まっていると思う。