Yuichi Murata's Engineering Blog

グローバル・エンジニアリング・チームをつくる

努力で人は変わらない?科学が示す「大人の限界」と、最強の生存戦略

「以前に比べて、新しい技術や情報をキャッチアップするのに時間がかかる」 「何度フィードバックしても、メンバーが同じミスを繰り返す」

組織や事業を牽引し、後進の育成に関わる立場にあるならば、一度はこうした「見えない壁」に直面したことがあるはずだ。自身のスキルに対する伸び悩みへの焦りや、他者の育成に対する「人ってそう簡単には変わらない」という徒労感である。

正確に言えば、人が全く変わらないわけではない。変わる方向と速度が人によって違い、その制約を無視した働きかけが巨大な摩擦を生んでいるのである。あなたが感じている自身のキャッチアップの遅れも、メンバーの行動が変わらない苛立ちも、あなたの努力不足やマネジメント手法のせいだけではない。我々に備わっている「ハードウェアの先天的な限界」を、気合や精神論で無理やりオーバーライドしようとしているからこそ苦しいのだ。

現在の心理学や脳科学のコンセンサスにおいて、人間のパフォーマンスは「遺伝と環境の掛け算」である。本記事では、最新の科学的データをもとに、我々が潔く受け入れるべき「才能の残酷な真実」を明らかにする。その上で、圧倒的に伸ばすことができる「大人の武器」と、それを組織全体へスケールさせるための実践的な生存戦略を解説する。


諦めるべき「才能の残酷な真実」ー ハードウェアの限界を受け入れる

まずは、我々が直視すべき「変えられない限界」について整理しよう。

1. 情報処理スピード(流動性知能)の限界

心理学において、新しい情報を瞬時に処理し、暗記や計算を行う能力は「流動性知能」と呼ばれる。これはコンピュータでいうCPUのクロック数やメモリ容量に該当する。

残酷なことに、この流動性知能は10代後半から20代前半をピークに、年齢とともに確実な低下の一途をたどる。新しい概念を丸暗記して素早く処理するようなタスクにおいて、ベテランが若手に勝てなくなるのは生物学的な事実である。

「脳トレをすれば衰えを防げるのではないか」という期待も、科学は否定している。2010年、『Nature』に掲載された1万人規模の調査では、「脳トレゲームのスコア自体は上がるが、それが実生活における記憶力や一般的な認知機能(問題解決能力など)の向上に波及するという証拠は得られなかった」と結論付けられた。米国連邦取引委員会(FTC)も、広告上の主張を裏付ける十分な科学的根拠がないとして、大手脳トレ企業と200万ドルの和解に至っている。我々は、処理速度や丸暗記力で若い世代と真正面から勝負してはならない。

2. タスク処理能力の源泉は「遺伝」

複雑な問題解決能力も、実はかなりの部分が遺伝によって規定されている。

行動遺伝学の双生児研究によれば、IQ(認知能力)のばらつきは、幼少期(約40%)よりも、自ら環境を選べるようになる成人期以降(約60〜80%)のほうが、遺伝的要因によって強く説明されるようになる。(※ただし、これは集団内のばらつきの説明率であり、個人の伸びしろの絶対的な上限を示すものではない)。さらに、職業心理学のデータをまとめたフランク・シュミット博士らのメタ分析(1998年)では、複雑な業務ほど将来のパフォーマンスを予測する指標として「一般認知能力(GMA)」が有効であることが示されている。

つまり、メンバーの理解度が上がらないのは教え方だけの問題とは限らず、元々のハードウェアスペックによる理解の速度に個人差があることを前提に置く必要があるのだ。

3. 性格の「セットポイント」の安定性

知能だけでなく、不確実性への耐性や刺激への敏感さといった「気質」もまた、遺伝的要素が強い。人間の性格には体重や体温のような「セットポイント(基準値)」が存在し、個人間の相対的な順位は生涯を通じて驚くほど安定している。極端な内向型の人材を、無理やり外向的なエヴァンジェリストのように振る舞わせることは短期的には可能だが、根本的な気質を作り変えようとするアプローチは極めて非効率である。

相手を無理な型にはめることを潔く諦め、強みを活かすことにリソースを全振りする。これがマネジメントの鉄則となる。


自分をアップデートする「大人の武器」ー プレーヤーとしての生存戦略

では、我々はどうやって成長し、価値を出し続ければいいのか。ここからは、情報処理の絶対速度が落ちる代わりに手に入る、圧倒的に伸びる「大人の武器」について解説する。

最強の武器「結晶性知能」

我々の最強の武器、それは「結晶性知能」である。これは、過去に蓄積してきた専門知識、成功と失敗のパターン、多様な経験などを組み合わせて、大局的な判断を下す総合的な問題解決能力を指す。20代でピークを迎える流動性知能に対し、結晶性知能は継続的な学習を行う限り生涯伸び続け、Hartshorne & Germine (2015) らの研究によれば、語彙などの指標では60代後半から70代前半にピークが観測されている。

この知能を伸ばす科学的なアプローチは「全く新しい複雑なスキルに挑戦し続けること」である。 ロンドン大学のエレノア・マグワイア博士による「タクシー運転手の脳」の研究がこれを裏付けている。世界で最も過酷とされるロンドンの道路網を記憶した運転手の脳は、空間記憶を司る海馬の後部の体積が対照群より大きく、その差は運転歴の長さと相関していた。

さらに興味深いのは、彼らが新しい視空間情報の学習では対照群に劣っていたことだ。つまり脳の変化は「汎用的な頭の良さ」ではなく、投じたドメインにのみ現れる。脳トレが転移しないのと同じ理由で、特定ドメインへの長期の深い関与は他に転移しない代わりに、その領域では確実に効く。だからこそ、大人はリソースを分散させず、自分が価値を出せる「複雑な知識のネットワーク構築(システム全体の俯瞰)」にこそ全ベットすべきである。

「論理的・システム思考」という仕組みのインストール

結晶性知能と並んで重要なのが、「論理的思考(メタ認知)」と、物事の全体像を俯瞰する「システム思考」である。 行動経済学者のダニエル・カーネマンは人間の思考を、直感的で速い「システム1」と、意識的で遅い「システム2」に分けた。

ただしカーネマン自身は、直感(システム1)そのものを意志の力で鍛え直すことには悲観的だった。私たちが身につけるべき現実的な打ち手は、意志の力ではなく「仕組み」である。重要な意思決定にチェックリストを挟む、事前に失敗の理由を書き出す(プレモーテム)、判断を一晩置く。バイアスは消せないが、発動しにくい手続きを設計することはできる

目の前の単発の事象にとらわれず、複雑な因果関係や組織の構造全体を捉える「システム思考」。課題を構造化し、全体最適を見極めるこの力は、正しいフレームワークの反復と仕組み化によって確実に強化できる。過去の経験の蓄積である「結晶性知能」と掛け合わせることで、その真価は最大限に発揮される。

【注意】大人の性格変化について

性格の根本的な気質は変わらないが、社会的な振る舞いとしての「パーソナリティの表出」は後天的に変化し得る。ビッグファイブ性格特性の研究では、加齢とともに責任感(誠実性)や協調性が上昇し、不安(神経症傾向)が低下する「成熟の原則」が確認されている。

また、イリノイ大学の研究(2015年)では、「こうなりたい」という意志と小さな行動の継続で、性格特性のスコアを後天的に変化させられることが示唆されている。ただし、注意点として、この「意図的な性格変化」に関する研究は比較的新しい分野であり、介入効果の長期的な持続性については検証が続いている段階である。 この理論を過信し「意志があれば性格は変えられる」と過度なプレッシャーをかけることは避けるべきだ。あくまで「社会的なスキルとしての振る舞い」と捉えるのが実用的である。


個人の武器をチームへ展開する「掛け算の組織づくり」

マネジメントの役割は、ここまで述べた個人の限界と武器を前提に、チーム全体のパフォーマンスを最大化することである。

1. 適材適所と「環境のデザイン」

実務の世界で広く共有されている強力な経験則として、「弱みを克服させるより、強みを活かせる場所に配置した方が生産性は圧倒的に高まる」というアプローチがある(Gallup社のストレングス理論など)。新規事業のカオスに強いメンバーと、緻密な運用に強いメンバーを見極めることが第一歩だ。

ここで比喩として借りたいのが「エピジェネティクス(後成的遺伝学)」という概念である。遺伝子の配列自体は変わらなくても、環境によって「どのスイッチがオン/オフになるか」は変化する。ビジネスにおいても同様に、能力の発揮量は環境(睡眠、負荷のかけ方、心理的状態、任される裁量)に大きく左右される。リーダーの仕事は、メンバーの才能のスイッチをオンにするための「環境」をデザインすることだ。

2. チームの最大値を決める「心理的安全性」

その環境の最たるものが「心理的安全性」である。Googleのプロジェクト・アリストテレス(2015年)が証明した通り、チームの成果は個人のIQやスキルの合計値ではなく、「対人関係のリスクをとっても安全であるという共有された信念」に依存する。

ハーバード・ビジネス・スクールのエイミー・エドモンドソン教授が指摘するように、心理的安全性は単なる「ぬるま湯」ではない。それは「失敗を隠さず報告する」「分からないことを率直に質問する」といった、組織の成長に不可欠な「学習行動」を生み出すための土台である。

3. 実務で活きる4つの発達段階

ティモシー・R・クラーク博士は、心理的安全性には実務向けの強力なフレームワークとして、以下の4つの発達段階があると提唱している。

段階 名称 状態・アクション マネジメントの障壁
第1段階 帰属の安全性 「自分はこのチームにいていい」と思える メンバーの疎外感、情報の不透明性
第2段階 学習の安全性 「分からない」と言ってもバカにされない 質問に対する冷笑や「そんなことも知らないの?」という態度
第3段階 貢献の安全性 自分のスキルやアイデアでチームに貢献できる マイクロマネジメント、権限移譲の欠如
第4段階 挑戦の安全性 現状を否定し、新しいイノベーションを提案できる 失敗に対する非難、減点主義

特に第2段階の「学習の安全性」が欠如していると、若手は質問をためらい、ミスは隠蔽される。現代のビジネスが直面する複雑な課題は、一人の天才のひらめきではなく、チーム全員のエラーと教訓から構築される「組織全体の結晶性知能」によってのみ解決できる。


結び:2000年前の「制御の二分法」という知的な生存戦略

最後に、古代ギリシャ・ローマ時代に隆盛を誇ったストア派哲学の、後世に「制御の二分法」と呼ばれる考え方を紹介しよう。 哲学者エピクテトスはこう説いた。

「君の力ではどうにもならない事柄については、『これは私には何の関係もないことだ』と即座に言えるように備えておきなさい」

マネジメントにおける焦りや徒労感の多くは、コントロールできないもの(自身の加齢による処理速度の低下、メンバーの先天的な理解速度、気質の安定性、過去のミス)を無理にコントロールしようとすることから生まれる。

変えられない限界をありのままに受け入れた上で、自分がコントロールできる領域に全リソースを集中させること。

  • 特定のドメインに深く関与し、「結晶性知能」を蓄積し続けること。
  • バイアスを回避する「仕組み」を作り、全体を俯瞰する「システム思考」を回すこと。
  • メンバーの才能のスイッチを入れるため、「心理的安全性の高い環境」を根気強く組織にデザインすること。

この2000年前の知恵こそが、科学が示す「人間の限界」を理解した我々が取るべき、最も知的で合理的なアプローチである。明日からの組織運営やキャリア構築の指針として、ぜひ活用していただきたい。

English Post:

https://yuichi-murata.medium.com/can-effort-really-change-people-e3a9745ff57e


【参考・引用文献】

  • Hartshorne, J. K., & Germine, L. T. (2015). When does cognitive functioning peak? The asynchronous rise and fall of different cognitive abilities across the life span. Psychological science.
  • Owen, A. M., et al. (2010). Putting brain training to the test. Nature, 465(7299), 775-778.
  • 米国連邦取引委員会(FTC)プレスリリース (2016). "Lumosity to Pay $2 Million to Settle FTC Deceptive Advertising Charges for Its “Brain Training” Program".
  • Plomin, R., & Deary, I. J. (2015). Genetics and intelligence differences: five special findings. Molecular psychiatry, 20(1), 98-108.
  • Schmidt, F. L., & Hunter, J. E. (1998). The validity and utility of selection methods in personnel psychology: Practical and theoretical implications of 85 years of research findings. Psychological bulletin, 124(2), 262. (※Sackett et al., 2022によるメタ分析の更新議論も参照)
  • Maguire, E. A., et al. (2000). Navigation-related structural change in the hippocampi of taxi drivers. Proceedings of the National Academy of Sciences, 97(8), 4398-4403.
  • Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.
  • Hudson, N. W., & Fraley, R. C. (2015). Volitional personality trait change. Journal of personality and social psychology, 109(3), 490.
  • Roberts, B. W., Wood, D., & Caspi, A. (2008). The development of personality traits in adulthood. Handbook of personality: Theory and research, 3, 375-398.
  • Gallup社 クリフトン・ストレングスに関する実証研究。
  • Google re:Work (2015). "The five keys to a successful Google team".
  • Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350-383.
  • Clark, T. R. (2020). The 4 stages of psychological safety. Berrett-Koehler Publishers.
  • エピクテトス『提要(エンケイリディオン)』

クリエイティビティがエンジニアの価値を決める

今日の変化と競争の激しい世界において、エンジニアの役割は単に問題を解決することや確立されたプロセスに従うことだけに留まらない。エンジニアの真の役割は、クリエイティビティを活かして考え、価値を生み出す能力にある。とりわけ、トレードオフを打破し、既存の制約を超えることができるかどうかが重要である。バリューエンジニアリングやDevOpsといった実例を通じて、クリエイティビティがいかにしてエンジニアの価値を決めるのか話そうと思う。

バリューエンジニアリングとは

バリューエンジニアリングとは、製品やプロセス、プロジェクトの価値を最大化するために、その機能を分析し、コストを最小限に抑えながらその機能を達成する方法を見つける体系的なアプローチである。バリューエンジニアリングでよく使われるシンプルな方程式が次のものだ。

価値 = メリット / コスト

この方程式において、「メリット」は製品やプロセスが提供する利点、性能、または機能を指し、「コスト」はそのメリットを達成するために必要なリソースを指す。バリューエンジニアリングの目的は、メリットを高めるか、コストを下げることで価値を最大化することである。理想的にはその両方を達成することである。

しかし、このバランスを取ることは簡単ではない。多くのエンジニアは、単にトレードオフのスライダーを調整する安直な考えに陥ることがある。つまり、より高い性能を得るためにコストを増やしたり、コストを抑えるために機能を減らしたりする選択だ。このアプローチは、既存の制約内で製品やプロセスを最適化するかもしれないが、新しい価値を生み出すことにはつながらない。真の価値が生まれるのは、エンジニアがこれらのトレードオフを完全に打破することができたときである。

トレードオフを打破する:クリエイティビティの役割

トレードオフを打破するためには、既存の状況に挑戦し、新たな解決策を見出すという異なる考え方が必要である。ここで重要なのがクリエイティビティである。エンジニアリングにおけるクリエイティビティは、明白な答えを超えて考え、新しい技術を探求し、仮定を疑い、高い性能と低コストを同時に実現する方法を見つけることである。

トレードオフをクリエイティブに打破する例として、材料工学を生かした製品設計が挙げられる。従来、材料の強度と重量にはトレードオフが存在していた。より強度の高い材料は通常、重くなり、コストが増加し、効率が低下する。一方、軽量な材料は同じ強度を提供できないかもしれない。しかし、炭素繊維強化ポリマーのような新しい複合材料を応用することで、軽量でありながら強度を持つ製品を実現できる。このように、トレードオフを打破し、顕著な価値を創出することができるのである。

しかし、エンジニアリングにおけるクリエイティビティは材料科学や製品設計に限られたものではなく、ソフトウェア開発のプロセスにも重要な役割を果たしている。

DevOps:QCDのトレードオフを打破する

ソフトウェア開発(Dev)とIT運用(Ops)を組み合わせた一連の実践であるDevOpsは、クリエイティビティがエンジニアリングにおける価値をいかに再定義できるかを示す強力な例である。従来のソフトウェア開発では、品質(Quality)、コスト(Cost)、納期(Delivery)の間には常にトレードオフが存在していた。ソフトウェアの納期を早めるほど、品質を犠牲にしたり、非効率やエラーによるコスト増加のリスクが高まる。一方、品質に焦点を当てると、納期が遅れ、コストが増加する。

DevOpsは、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインを活用し、これらのトレードオフを打破している。テスト、デプロイ、モニタリングといった反復的な作業を自動化することで、DevOpsは品質を損なうことなく、コストの増加を伴わずにソフトウェアを迅速に提供することを可能にしている。自動化ツールやプロセスをクリエイティブに応用することで、エンジニアはもはやスピードと品質のどちらかを選ぶ必要がなく、両方を実現できるようになる。これにより、組織にとって顕著な価値が創造されるのである。

クリエイティビティがエンジニアとしての価値を決める

バリューエンジニアリングやDevOpsの例が示すように、クリエイティビティはエンジニアにとって単なる付加価値ではなく、価値を決める決定的な資質である。トレードオフを打破し、イノベーションを生み出す能力が、今日の競争環境においては大きな競争優位となりうる。クリエイティビティを育むエンジニアは、自らの価値を高め、組織にとっても不可欠な存在となるのである。

新しい製品を開発する際、プロセスを最適化する際、またはソフトウェアプロジェクトに取り組む際には、常に自問してほしい。「どうすればトレードオフを打破できるだろうか?」「他の人が見逃しがちな解決策を見つけるために、どのようにして自分のクリエイティビティを活用できるだろうか?」このような考え方を自問することで、エンジニアが手掛けるプロジェクトの価値を高めるだけでなく、エンジニア自身の価値も向上することができる。

要するに、クリエイティビティはエンジニアリングにおいて単なる付加価値ではなく、あなたの存在を問題を解決する人から価値を創造する人へと変えるのである。

yuichi-murata.medium.com

なぜカルチャーインテグレーションが重要なのか

最近、内製化とグローバル化を通じた世界水準のIT組織づくりに関する登壇発表を行った。この発表が予想以上に好評をいただいたので、今回はその内容をさらに掘り下げて、「カルチャーインテグレーションがなぜ重要なのか」について書きたいと思う。

発表の概要は、まさにこのカルチャーインテグレーションに関するものであった。組織文化の強い事業会社において、内製化とグローバル化を推進するにあたっては様々な考え方やカルチャーを上手に統合していくことが大切であった。また深いレベルで互いのカルチャーを理解することによって、お互いの文化を損ねることなく上手に束ねていくことができるというのが基本的な趣旨である。興味がある方は、以下の動画をぜひ御覧いただきたい。

www.youtube.com

では、なぜそのような難しいカルチャーの統合を苦労して行う必要があるのだろうか。ここには主に以下の理由が存在すると考えている。

  1. カルチャーインテグレーションは仲間と市場を広げる
  2. カルチャーインテグレーションは真理を発見する
  3. カルチャーインテグレーションはイノベーションと利益をもたらす

カルチャーインテグレーションは仲間と市場を広げる

まず初めに、カルチャーインテグレーションは仕事を共にする仲間の幅を広げるものである。これは、特に私がグローバルチームの組成に取り組む中で日々実感していることである。国内の人材にこだわらず、採用の間口を広げることにより、採用の母数は圧倒的に増加する。リモートワークの効率が向上したこともあり、オフショアの活用も以前より格段に容易になっている。

また、国籍以外にも、職種による文化の違いを統合していくことも重要である。特にソフトウェアの内製開発を実施する場合、職人気質が強かったり、多少気難しい面があるとしても、優れた技術を持つ人材を受け入れる器の大きな組織こそ、より大きなチームを構築することができる。

積極的に多国籍の人材を採用することによって、様々な文化圏に対する組織の理解力もあがる。新しい市場でビジネスを開始したりしシステムをリリースしたときに、現地にゆかりのある人材がいると、物事の解像度が大きく異なってくる。特殊なビジネス要件がなぜ必要になるのかわかったり、一部のステークホルダーがプロジェクト方針に納得できないときに効果的な説得ができたりする。

このように、より様々な人材を受け入れていくことによって、より多くの仲間とチームを組むことができるし、より多様な市場に進出することができるようになる。

カルチャーインテグレーションは真理を発見する

また、カルチャーインテグレーションは新しい物事の発見を促す側面がある。なぜなら、異なるカルチャーがぶつかるときには常に反発や矛盾が生じるからである。

哲学者ヘーゲルは、弁証法という、対立する考えや現象から新しい理解や進展を生み出す方法について述べている。まず、ある「正」(テーゼ)となる考え方が提示される。次に、それに対して反対の「反」(アンチテーゼ)が現れる。そして、この対立からより高次の新しい「合」(ジンテーゼ)が生まれる。この過程を繰り返すことで、人間の理解や社会が発展していくと、ヘーゲルは考えたのである。

人類は弁証法によって、さまざまな真理を見出してきた。例えば、アインシュタイン量子力学もその一つである。かつての物理学では、光は波として捉えられていた。しかし、次第に光が粒子のような特性も持っていることが明らかになった。ここでアインシュタインは、光が状況に応じて波と粒子の両方の性質を持つという仮説に至った。これが、現在の量子力学へとつながっている。そして、その量子力学は今、量子コンピュータという新たなイノベーションを生み出そうとしている。

このように、意図的に「異分子」を組織に取り込み、その統合を図る過程で矛盾を生み出し、解決していくことにより、独創的なプロダクトが生まれる可能性が高まると考えることができる。

カルチャーインテグレーションはイノベーションと利益を持たらす

セレンディピティ」という言葉を聞いたことがあるだろうか。これは、予期せぬ偶然の出来事や発見が幸運な結果をもたらす現象を指し、計画的な努力ではなく、偶然の出会いや出来事が新しい洞察や発明に繋がることを意味する。セレンディピティの典型例は、ペニシリンの発見である。アレクサンダー・フレミングは、実験の失敗から偶然にカビが細菌を抑制することを発見し、これが抗生物質の開発へと繋がった。彼はペニシリンを発見する意図はなかったものの、この偶然の観察から世界初の抗生物質が誕生したのである。

異なる文化を持つ人々が集まって組織を形成する中では、さまざまな知識や物の考え方が自然な出会いを生む。このような環境では、イノベーションが促進されると考えられる。2022年の米移民局の統計によれば、Fortune 500企業のうち43.8%が移民またはその子供によって設立されたものである。異なるカルチャーを持つ経営者が、イノベーションや独創的な視点を活かして経営を行い、高い利益を上げていると考えられる。

カルチャーインテグレーション≠カルチャーリプレースメント

ここで重要なのは、カルチャーを統合していくことである。異なるカルチャーをただ乱暴にぶつければよいわけではなく、従来のカルチャーを否定することでもない。これまでのカルチャーを大切にしながら、新しい考え方を巧みに統合していくことが肝要なのである。

  1. Kotter と J. Hesket による200社に及ぶ調査によると、強いカルチャーを持つ会社は11年間で約756%の純利益増加をもたらしているという結果が出ている。つまり、これまで会社やチームを形作ってきたカルチャーを大切にすることは、極めて重要である。そのうえで、新しい考え方や文化に触れ、自らを否定することなく新しい考え方を取り込んでいくことが必要なのである。

そのためには、自らの会社やチームの文化を深く理解するとともに、多面的な視点を養うことが重要であると考えている。先の登壇動画でも詳しく述べたが、物事をより深く、多面的に捉えることで、一見矛盾しているように見える事柄が、実は矛盾していないことに気づくことが多々ある。

日々現場でコードを書いているエンジニアの皆さんには、ぜひ積極的にさまざまな国の出身者や異なる職種の人々と交流することをおすすめしたい。また、チームを作るリーダーシップを担っている方々には、カルチャーインテグレーションの重要性に触れ、さまざまな文化を多面的に捉え、統合していくことを日々の業務の中で意識していただけると嬉しい。

English Article:

yuichi-murata.medium.com

DevOps カルチャーというコスト -- DevOps は QCD のトレードオフを破壊したのか?

DevOps は QCD を破壊した?

2020年デブサミの登壇発表「質とスピード」が話題に上がってから日本のソフトウェア産業で一つのパラダイムシフトが発生したと考えている。つまり、ソフトウェア産業において、従来のQCDは成り立たなくなったというものだ。その発表の大きな論拠になっているものは2014年に開始され、その後も毎年更新され続ける DORA リサーチだ。この研究が注目された理由は、DevOps カルチャーを高度に推進するエリート企業はそうでない企業に比べて、圧倒的に速いスピードで新機能をリリースするのに、障害発生が少ない点である。つまり、従来のスピードを優先すると品質が下がるという常識を否定しているのである。加えて、DevOpsのプラクティスは自動化を前提としたものがあ多い。つまり、スピードと品質を両立しながら、コストも削減ができることを意味する。これは、つまり伝統的なQCDのトレードオフの破壊である。

State of DevOps より: エリートと低グループのパフォーマンス差分

筆者も実際、ソフトウェア開発におけるQCDのトレードオフは破壊しうると信じるようになった。その上で、ここ数年はDevOps変革を推進してきた。しかしその過程で分かったことは、これは言う方簡単ではないということである。そして、その理由は、DevOpsカルチャーの醸成こそが最大の難題であるからである。つまり、DevOpsカルチャーの醸成そのものがコストであり、そのコストは意外に大きいということである。

DevOpsカルチャー醸成のコスト

DevOpsカルチャーの醸成が難しい理由は、主に三つある。

一つ目は、その本質を捉えるのが難しいからだ。これを確かめるには、あなたの同僚に「DevOpsとは何か?」と質問してみるといい。ほとんどの同僚は、DevOpsパイプラインやCI/CDといった表面的な仕組みについて語るか、あまり要領を得ない回答をすると思う。実際、普遍的な定義がある訳ではないので、その回答内容をみるとその人の理解度と視点がよく分かる。ちなみに自分は、「毎日のようにリリースを行い、かつ障害や不具合を最小化するために、ソフトウェア開発と運用を統合した様々な方法を組み合わせたもの」と答える。これが正解なのかは未だに分かっていないが、自分はそういう視点で見ている。

DevOps のプラクティスとカルチャーの関連

二つ目は、DevOpsが戦略としてのキラーパスの性質を持っているからである。戦略のキラーパスは、ストーリーとしての競争戦略において楠木教授が紹介しているものである。キラーパスとは、競合が戦略の一部を真似ただけでは逆効果を発揮する性質のことを言う。端的に言うと、表面だけパクると自爆すると言うことだ。

例えば洗練された CI/CD が整っていないのに、頻繁なリリースのみを真似たとしよう。チームはリリース作業だけでてんてこまいになり、頻繁にバグを引き、本番障害が頻発するだろう。チームが単体テストの重要性を理解せず、第三者によるE2E/UIテストに依存していたとしよう。そのバランスを見直さずテストの自動化のみを推進した場合、少しの仕様変更でもハイメンテナンスなSeleniumテストケースを頻繁に修正することになる。むしろマニュアルテストより効率が下がるかもしれない。

三つ目に、DevOpsは現場からトップまで全員の理解を必要とする。もしIT経営のトップが昔ながらソフトウェア開発パラダイムを持っていたとしよう。「毎日リリースしましょう。そうすれば一回のリリースのリスクを小さくすることができます」とでも言おうものなら異端扱いされることだろう。一度、重大障害が起きればリリースの頻度を下げ、重厚な変更管理プロセスと沢山のチェックリストを用意するように指示がくることだろう。DevOpsのプラクティスと真逆の方向にアクセルを踏んでしまうのである。逆に、トップマネジメントがDevOpsカルチャー推進の音頭をとったとしよう。開発の現場が、ソフトウェアのテストをするのはQA部門の仕事だと思っているとしたら、一向にテストの自動化は進まないだろう。DevOpsの重要な前提である自動化テストが上手くいかなければ、変革は掛け声だけに終わるだろう。

DevOps 変革が難しいエンタープライズ

こうした課題は特に、DXを推進しているような企業では難しい。これらの企業では、デジタルネイティブ企業とは異なり、ITシステムを自分達で作る代わりに、ベンダーから買ってくることに慣れている。そして、ベンダーベースのソフトウェア開発は、DevOpsのプラクティスの真逆を行っている。厳重な変更管理をして、半年に一回にメジャーリリースをまとめ、ソフトウェアの開発が完了してからテストベンダーを大量に雇って手動で試験をこなすことに慣れきっているのである。こうした組織カルチャーの変革をするのは一大事業だ。

こうした理由で、DevOps変革は困難を伴う。品質とスピードを両立すると言うことはとても魅力的であるが、その裏側にはカルチャーを変えるという大きなコストが潜んでいるのである。そして、カルチャーの変革コストは投資承認がおりれば簡単に支払えるものではない。トップから現場までの粘り強く働きかけ、実践を通じて時間をかけて変えていくしかない。

経営科学が示している通り、企業文化というのは移植が最も困難な強みである。それゆえにこの強みを構築した企業は、競合に対して強い優位性を持つだろう。そうした DevOps 変革をトップから現場まで粘り強く働きかけて、変革を推進できる人材は、一騎当千の価値を持つのではないかと筆者は考えている。DevOps推進の鍵は変革のためのコストを認識し、そのコストを粘り強く支払うことなのだと思う。

参考

www.devops-research.com

なぜマニュアルテストは、まずうまく行きそして失敗するのか

f:id:yuichi1004:20210425170627p:plain

本日は、なぜマニュアルテストはまず上手く行きそして失敗するのか、自分の考えていることを書いてみたいと思う。 

ソフトウェアテストの自動化は常識である。優れたエンジニアは自ら優れたテストを書き、その結果として優れた品質を担保し続ける。一方で、テスト実装を推進できていないプロジェクトに遭遇することもある。こうしたプロジェクトは、大抵何れかのフェーズで必ず品質問題に直面する。こうしたプロジェクトの軌道を修正するベストな方法は何であろうか。

マニュアルテストのはじまり

テスト自動化を推進できない理由の典型例が「新規案件に忙しすぎてテスト自動化を推進する工数がとれない」というものである。TDD 論者がこの説明を聞いたときに「忙しいからテストができないのではなくて、テストを自動化しないから忙しいのだ」と答える様子は想像に難くない。だがここでは、あえてこの議論には深く触れず、こうしたプロジェクトがどういう道のりをたどるのかを考えてみる。

開発者がテストを実装する時間がないという理由を聞いたマネジメントは、たいてい外部のテストチームにその品質管理を頼る。開発チームから上がってくる品質が信用に足らないから、テストチームは念入りに検査をしてくれと言った具合だ。

マニュアルテストの罠

マニュアルテストの怖いところは、ある一定の規模までは機能してしまうことである。以下の図に示すとおり、ある一定の範囲で障害を最小化できるスイートスポットが存在する。

f:id:yuichi1004:20210425170556p:plain

リリースにあたって障害が多発する場合、おそらくリリースの頻度を下げて品質を担保しようとするだろう。変更をまとめてバッチサイズを大きくすることで、回帰試験の回数を減らして工数を抑える。そして、品証の時間を十分とることでしっかり準備しようという考え方だ。実際この戦略はある一定の規模まではうまくいく。

しかし、あるタイミングで破綻する。なぜなら一回の変更のサイズが増えれば増えるほど、システムの複雑性が指数関数的に増えるからである。2 つのシステムが相互にやり取りするシステムと、3 つのシステムが相互にやり取りするシステムの複雑性は線形比例にならない。リンクの数が指数的に増えるからである。

バッチサイズを大きくすることで確かに回帰テストの回数は減る。だがシステムの複雑さが加速度的に上がるため、より多くのバグが埋め込まれ、より発見が難しくなる。つまり、過去の成功体験にならって人員増強や試験期間の延長をしても対処ができなくなるのである。

罠から抜け出す

テストの自動化や CI/CD の利点は、工数やコスト削減の削減ではない。バッチサイズの最小化である。優れた IT 組織はこれをよく熟知しているため、テストの自動化と CI/CD に十分な投資を行っている。大きなプロダクトであればあるほど、小さく変更して頻繁にリリースする。そうすることでバグの埋め込みを防ぐのである。

ではマニュアルテストの罠にはまってしまったプロジェクトはどうするべきだろうか。残念ながら答えは一つしかないと思う。自動化を推進してバッチサイズを小さくしていくしかない。自動化に反対する人まずいない。問題は自動化が整うまでの暫定的処置を関係者と合意することだ。自動化を推進する間も開発を止めない方法を求められることもあるだろう。だが結局の所銀の弾丸はないのである。

罠から抜け出すには優れたリーダーシップが必要である。チームがあるべきテストの姿を推進するための工数を確保するために開発チームのリーダーは動かなければならない。ステークホルダーとコミュニケーションをし、ときにメンバーを守り、ひたすらに自動化を推進することが結果的に製品の成功への近道となるのである。

英文記事:

yuichi-murata.medium.com

チームビルディングの新常識!好きなプログラミング言語を議論せよ

f:id:yuichi1004:20210417141145p:plain

自分が議論を投げかけたのに、チームが静まり返ってしまって気まずい思いをした事はないだろうか。アフターコロナの世界になってチーム・ビルディングの形も大きく変わってきている。特に、リモート・ミーティングで上のような局面に当たる機会が増えたのではないかと思う。

この記事では、エンジニアリング・チームのミーティングや日々のやり取りを盛り上げ、楽しく仕事をするにはどうしたら良いか語ってみたいと思う。

自転車置き場効果 - くだらない事は盛り上がる

自転車置き場効果という心理学の用語がある。正式にはパーキンソンの凡俗法則と呼ばれているものである。簡単に言うと、人間は「くだらない議論ほど盛り上がる」と言うものだ。

例えば、ある会議室で原子力発電所の建設費用の見積もりを議論したとしよう。殆どの参加者は黙ってしまう。だが、職場に自転車置き場を設置するべきかと議題を投げかけると、みんなが活発に発言をする。自分にとって身近な問題であるし、責任も伴わないからだ。

エンジニアには度々盛り上がるトピックというものがある。例えば、あなたの好きなテキスト・エディターは何ですか、あなたの好きな Linux ディストリビューションは何ですかと言った議論だ。これは、ほとんど趣味嗜好としか言えないような議論に陥るがとにかく盛り上がる。それは、トピックが「くだらない」からである。

チーム・ビルディング・イベントでくだらない議論をする

最近、あるチーム・ビルディング・イベントに参加したのだが、これがとても盛り上がった。この組織の四半期目標、経営理念、戦略といったトピックの代わりに全員参加のくだらない議論を行なったのである (無論まじめな話も別セッションで実施した)。

参加者はスライドの QR コードを読み取って投票に参加する。そしてその投票結果がリアルタイムにスライドに表示される。その質問の内容はというと、「もしオフィス移転をするならどこが良いと思いますか」「あなたが働いてみたい他の部署はどこですか」といった他愛もないものであった。エンジニア向けには「あなたの好きなプログラミング言語は何ですか」という質問がなされた。普段業務で使っていない言語がトップにあがり、これは大きく盛り上がった。

くだらない話でチームを盛り上げよう

リモートワークが主体となって以前よりもずっと雑談の機会が減ってしまったのではないかと思う。そんな時は「好きなプログラミング言語」の話をしてみよう。なんなら「嫌いなプログラミング言語」の悪口でも構わない。個人の趣味嗜好によって議論が白熱することだろう。そうした議論は普段の業務と直接関わらないから、意見が割れようと尾を引かない。

くだらない議論によってエンジンのかかったチームは、本題のビジネスにおいても闊達な議論をするようになるだろう。

英文記事: yuichi-murata.medium.com

技術負債は大きな石だと思えばうまくいく

f:id:yuichi1004:20210411115812p:plain

技術負債に対する取り組みは、エンジニアリングにあたって最も活発に議論されるトピックである。この記事では、技術負債に取り組むために如何に工数を確保するかについて、自分の考えを述べたいと思う。

技術負債?とにかく新機能を実装してよ

エンジニアの最も大きな不満の一つは、ビジネスが技術負債への取り組みを理解してくれないことである。ステークホルダーやプロダクトマネージャーは、さらなるビジネスの発展のために次から次へと新しいビジネスや機能のアイディアを持ち込んでくる。あるいは、特定のお客様の不満へ対処するために、緊急の機能改修を要求してくるかもしれない。

「設計の変更が必要なのは分かった。でも、それ今じゃないとだめかな?いまがビジネスにとって大事な時期なんだ。」 理由は様々かもしれない。だが、このようなフレーズでリファクタリングや改善策の実施を押し返されてしまった経験はないだろうか。

もちろん時と場合によって、技術的な負債を増やして前に進むべき時もある。大大的に告知されてしまったリリース日を守るために設計を妥協したり、放っておくとお客様の信頼を大きく損なうような重大なバグ修正を優先することは至極まっとうである。

しかし、意思決定には慎重にならなければいけない。ビジネスにおいて重要でない時は存在しないからだ。最初から自動化テストを実装しておいたほうが、結果的に早くシステムをリリースできる。このように適切な取り組みは、最終的なゴールへの到達を早める。結局は急がば回れということである。エンジニアはこれを理解していているが、ステークホルダーはこれを理解できないことがある。であれば、技術負債への取り組みを推進するのは「エンジニアの責任」である。それが何れ問題になることが分かっているのだとすれば、プロフェッショナルとして、あなたは何としてもそれを推進する責任がある。ピーター・ドラッガーが述べている通り「知りながら害をなすな」ということである。決して「技術負債返済の理解をしてくれない」と嘆いてはいけない。

大きな石ころを先に詰める

とはいえ、一般に理解してもらうことが難しいこの取組をどのように推進すればよいだろうか。スティーブン・コビー博士の著書「最優先事項」からそのヒントを得ることができる。技術的な負債への取り組みは大きな石ころだと思えば良い。

これは彼の講座の講師の話である。その講師は瓶を取り出して、「この中にいくつの石がはいるでしょう」といって瓶の中に石を詰め込み始めた。瓶がいっぱいになったところで、「さてこの瓶はもういっぱいでしょうか」と生徒たちに訪ねた。生徒たちがうなずくと、彼は砂のはいった袋をとりだした。「さてこの瓶はもういっぱいでしょうか」。生徒たちは「いいや」と答えた。

この講師の話は優先事項を以下にスケジュールに組み込むかについて分かりやすい比喩を使って説明している。要するに大事な仕事は先に「瓶」に入れておくことだ。

瓶がいっぱいになってから「すいません、このリファクタリングをしたいので少し砂を避けてください」などと言ってはうまくいくはずがない。まず石を詰めておいて、そこから砂を入れるようにしよう。新規の開発計画を立てるときには、関連するシステムの設計見直しや追加のテストの実装といった技術負債返済のための工数をまず計上しておき、それから新しい機能の実装の工数を積むのである。

大きい石ころについて話すべきか

ここで一つ議論のあるポイントが有る。それは「大きい石ころ」について話すべきか否かである。瓶の中には大きな石ころが詰まっている。だが砂を詰めたあとの瓶の外側からはそうした大きな石ころは見えない。ただの砂のつまった瓶である。我々はこの大きな石ころについて話すべきだろうか。

Martin Fowler の著書 Refactoring からこの言葉を引用したい。

Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!

もしステークホルダーが技術に理解ある人であれば黙る必要はないかもしれない。だが、そうした判断ができないようなのであれば大きな石ころについて「話すべきではない」。話した結果、こうした取り組みを実施できず、結果的にソフトウェアの品質を下げてデリバリーを遅くするのであれば、あなたはプロジェクトの成功にたいして裏切ったことになる。無闇に話さないことも一つのプロフェッショナリズムだと思う。見た目には砂がいっぱいの瓶をみて皆が納得してくれるのならば、それでいいではないか。結果的にはそれがプロジェクトの成功のためになるのであれば、あなたはプロジェクトの成功にたいして誠実なのだから。

そのためにも、大きな石ころの管理には注意を払う必要がある。石ころが瓶に入らなくなるほど大きくなるまで放っておいたり、大きな石ころだけで瓶をいっぱいにしてはいけない。砂がほとんど入らない瓶をみてステークホルダーは怪訝な顔をすることだろう。そうなる前に、継続的に、したたかに大きな石ころを瓶に詰めるのは、プロフェッショナルのエンジニアとしての大事な責任である。

英文記事:

yuichi-murata.medium.com