クリエイティビティがエンジニアの価値を決める
今日の変化と競争の激しい世界において、エンジニアの役割は単に問題を解決することや確立されたプロセスに従うことだけに留まらない。エンジニアの真の役割は、クリエイティビティを活かして考え、価値を生み出す能力にある。とりわけ、トレードオフを打破し、既存の制約を超えることができるかどうかが重要である。バリューエンジニアリングやDevOpsといった実例を通じて、クリエイティビティがいかにしてエンジニアの価値を決めるのか話そうと思う。
バリューエンジニアリングとは
バリューエンジニアリングとは、製品やプロセス、プロジェクトの価値を最大化するために、その機能を分析し、コストを最小限に抑えながらその機能を達成する方法を見つける体系的なアプローチである。バリューエンジニアリングでよく使われるシンプルな方程式が次のものだ。
価値 = メリット / コスト
この方程式において、「メリット」は製品やプロセスが提供する利点、性能、または機能を指し、「コスト」はそのメリットを達成するために必要なリソースを指す。バリューエンジニアリングの目的は、メリットを高めるか、コストを下げることで価値を最大化することである。理想的にはその両方を達成することである。
しかし、このバランスを取ることは簡単ではない。多くのエンジニアは、単にトレードオフのスライダーを調整する安直な考えに陥ることがある。つまり、より高い性能を得るためにコストを増やしたり、コストを抑えるために機能を減らしたりする選択だ。このアプローチは、既存の制約内で製品やプロセスを最適化するかもしれないが、新しい価値を生み出すことにはつながらない。真の価値が生まれるのは、エンジニアがこれらのトレードオフを完全に打破することができたときである。
トレードオフを打破する：クリエイティビティの役割
トレードオフを打破するためには、既存の状況に挑戦し、新たな解決策を見出すという異なる考え方が必要である。ここで重要なのがクリエイティビティである。エンジニアリングにおけるクリエイティビティは、明白な答えを超えて考え、新しい技術を探求し、仮定を疑い、高い性能と低コストを同時に実現する方法を見つけることである。
トレードオフをクリエイティブに打破する例として、材料工学を生かした製品設計が挙げられる。従来、材料の強度と重量にはトレードオフが存在していた。より強度の高い材料は通常、重くなり、コストが増加し、効率が低下する。一方、軽量な材料は同じ強度を提供できないかもしれない。しかし、炭素繊維強化ポリマーのような新しい複合材料を応用することで、軽量でありながら強度を持つ製品を実現できる。このように、トレードオフを打破し、顕著な価値を創出することができるのである。
しかし、エンジニアリングにおけるクリエイティビティは材料科学や製品設計に限られたものではなく、ソフトウェア開発のプロセスにも重要な役割を果たしている。
DevOps：QCDのトレードオフを打破する
ソフトウェア開発（Dev）とIT運用（Ops）を組み合わせた一連の実践であるDevOpsは、クリエイティビティがエンジニアリングにおける価値をいかに再定義できるかを示す強力な例である。従来のソフトウェア開発では、品質（Quality）、コスト（Cost）、納期（Delivery）の間には常にトレードオフが存在していた。ソフトウェアの納期を早めるほど、品質を犠牲にしたり、非効率やエラーによるコスト増加のリスクが高まる。一方、品質に焦点を当てると、納期が遅れ、コストが増加する。
DevOpsは、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを活用し、これらのトレードオフを打破している。テスト、デプロイ、モニタリングといった反復的な作業を自動化することで、DevOpsは品質を損なうことなく、コストの増加を伴わずにソフトウェアを迅速に提供することを可能にしている。自動化ツールやプロセスをクリエイティブに応用することで、エンジニアはもはやスピードと品質のどちらかを選ぶ必要がなく、両方を実現できるようになる。これにより、組織にとって顕著な価値が創造されるのである。
クリエイティビティがエンジニアとしての価値を決める
バリューエンジニアリングやDevOpsの例が示すように、クリエイティビティはエンジニアにとって単なる付加価値ではなく、価値を決める決定的な資質である。トレードオフを打破し、イノベーションを生み出す能力が、今日の競争環境においては大きな競争優位となりうる。クリエイティビティを育むエンジニアは、自らの価値を高め、組織にとっても不可欠な存在となるのである。
新しい製品を開発する際、プロセスを最適化する際、またはソフトウェアプロジェクトに取り組む際には、常に自問してほしい。「どうすればトレードオフを打破できるだろうか？」「他の人が見逃しがちな解決策を見つけるために、どのようにして自分のクリエイティビティを活用できるだろうか？」このような考え方を自問することで、エンジニアが手掛けるプロジェクトの価値を高めるだけでなく、エンジニア自身の価値も向上することができる。
要するに、クリエイティビティはエンジニアリングにおいて単なる付加価値ではなく、あなたの存在を問題を解決する人から価値を創造する人へと変えるのである。
なぜカルチャーインテグレーションが重要なのか
最近、内製化とグローバル化を通じた世界水準のIT組織づくりに関する登壇発表を行った。この発表が予想以上に好評をいただいたので、今回はその内容をさらに掘り下げて、「カルチャーインテグレーションがなぜ重要なのか」について書きたいと思う。
発表の概要は、まさにこのカルチャーインテグレーションに関するものであった。組織文化の強い事業会社において、内製化とグローバル化を推進するにあたっては様々な考え方やカルチャーを上手に統合していくことが大切であった。また深いレベルで互いのカルチャーを理解することによって、お互いの文化を損ねることなく上手に束ねていくことができるというのが基本的な趣旨である。興味がある方は、以下の動画をぜひ御覧いただきたい。
では、なぜそのような難しいカルチャーの統合を苦労して行う必要があるのだろうか。ここには主に以下の理由が存在すると考えている。
- カルチャーインテグレーションは仲間と市場を広げる
- カルチャーインテグレーションは真理を発見する
- カルチャーインテグレーションはイノベーションと利益をもたらす
カルチャーインテグレーションは仲間と市場を広げる
まず初めに、カルチャーインテグレーションは仕事を共にする仲間の幅を広げるものである。これは、特に私がグローバルチームの組成に取り組む中で日々実感していることである。国内の人材にこだわらず、採用の間口を広げることにより、採用の母数は圧倒的に増加する。リモートワークの効率が向上したこともあり、オフショアの活用も以前より格段に容易になっている。
また、国籍以外にも、職種による文化の違いを統合していくことも重要である。特にソフトウェアの内製開発を実施する場合、職人気質が強かったり、多少気難しい面があるとしても、優れた技術を持つ人材を受け入れる器の大きな組織こそ、より大きなチームを構築することができる。
積極的に多国籍の人材を採用することによって、様々な文化圏に対する組織の理解力もあがる。新しい市場でビジネスを開始したりしシステムをリリースしたときに、現地にゆかりのある人材がいると、物事の解像度が大きく異なってくる。特殊なビジネス要件がなぜ必要になるのかわかったり、一部のステークホルダーがプロジェクト方針に納得できないときに効果的な説得ができたりする。
このように、より様々な人材を受け入れていくことによって、より多くの仲間とチームを組むことができるし、より多様な市場に進出することができるようになる。
カルチャーインテグレーションは真理を発見する
また、カルチャーインテグレーションは新しい物事の発見を促す側面がある。なぜなら、異なるカルチャーがぶつかるときには常に反発や矛盾が生じるからである。
哲学者ヘーゲルは、弁証法という、対立する考えや現象から新しい理解や進展を生み出す方法について述べている。まず、ある「正」（テーゼ）となる考え方が提示される。次に、それに対して反対の「反」（アンチテーゼ）が現れる。そして、この対立からより高次の新しい「合」（ジンテーゼ）が生まれる。この過程を繰り返すことで、人間の理解や社会が発展していくと、ヘーゲルは考えたのである。
人類は弁証法によって、さまざまな真理を見出してきた。例えば、アインシュタインの量子力学もその一つである。かつての物理学では、光は波として捉えられていた。しかし、次第に光が粒子のような特性も持っていることが明らかになった。ここでアインシュタインは、光が状況に応じて波と粒子の両方の性質を持つという仮説に至った。これが、現在の量子力学へとつながっている。そして、その量子力学は今、量子コンピュータという新たなイノベーションを生み出そうとしている。
このように、意図的に「異分子」を組織に取り込み、その統合を図る過程で矛盾を生み出し、解決していくことにより、独創的なプロダクトが生まれる可能性が高まると考えることができる。
カルチャーインテグレーションはイノベーションと利益を持たらす
「セレンディピティ」という言葉を聞いたことがあるだろうか。これは、予期せぬ偶然の出来事や発見が幸運な結果をもたらす現象を指し、計画的な努力ではなく、偶然の出会いや出来事が新しい洞察や発明に繋がることを意味する。セレンディピティの典型例は、ペニシリンの発見である。アレクサンダー・フレミングは、実験の失敗から偶然にカビが細菌を抑制することを発見し、これが抗生物質の開発へと繋がった。彼はペニシリンを発見する意図はなかったものの、この偶然の観察から世界初の抗生物質が誕生したのである。
異なる文化を持つ人々が集まって組織を形成する中では、さまざまな知識や物の考え方が自然な出会いを生む。このような環境では、イノベーションが促進されると考えられる。2022年の米移民局の統計によれば、Fortune 500企業のうち43.8%が移民またはその子供によって設立されたものである。異なるカルチャーを持つ経営者が、イノベーションや独創的な視点を活かして経営を行い、高い利益を上げていると考えられる。
カルチャーインテグレーション≠カルチャーリプレースメント
ここで重要なのは、カルチャーを統合していくことである。異なるカルチャーをただ乱暴にぶつければよいわけではなく、従来のカルチャーを否定することでもない。これまでのカルチャーを大切にしながら、新しい考え方を巧みに統合していくことが肝要なのである。
- Kotter と J. Hesket による200社に及ぶ調査によると、強いカルチャーを持つ会社は11年間で約756％の純利益増加をもたらしているという結果が出ている。つまり、これまで会社やチームを形作ってきたカルチャーを大切にすることは、極めて重要である。そのうえで、新しい考え方や文化に触れ、自らを否定することなく新しい考え方を取り込んでいくことが必要なのである。
そのためには、自らの会社やチームの文化を深く理解するとともに、多面的な視点を養うことが重要であると考えている。先の登壇動画でも詳しく述べたが、物事をより深く、多面的に捉えることで、一見矛盾しているように見える事柄が、実は矛盾していないことに気づくことが多々ある。
日々現場でコードを書いているエンジニアの皆さんには、ぜひ積極的にさまざまな国の出身者や異なる職種の人々と交流することをおすすめしたい。また、チームを作るリーダーシップを担っている方々には、カルチャーインテグレーションの重要性に触れ、さまざまな文化を多面的に捉え、統合していくことを日々の業務の中で意識していただけると嬉しい。
English Article:
DevOps カルチャーというコスト -- DevOps は QCD のトレードオフを破壊したのか？
DevOps は QCD を破壊した？
2020年デブサミの登壇発表「質とスピード」が話題に上がってから日本のソフトウェア産業で一つのパラダイムシフトが発生したと考えている。つまり、ソフトウェア産業において、従来のQCDは成り立たなくなったというものだ。その発表の大きな論拠になっているものは2014年に開始され、その後も毎年更新され続ける DORA リサーチだ。この研究が注目された理由は、DevOps カルチャーを高度に推進するエリート企業はそうでない企業に比べて、圧倒的に速いスピードで新機能をリリースするのに、障害発生が少ない点である。つまり、従来のスピードを優先すると品質が下がるという常識を否定しているのである。加えて、DevOpsのプラクティスは自動化を前提としたものがあ多い。つまり、スピードと品質を両立しながら、コストも削減ができることを意味する。これは、つまり伝統的なQCDのトレードオフの破壊である。
筆者も実際、ソフトウェア開発におけるQCDのトレードオフは破壊しうると信じるようになった。その上で、ここ数年はDevOps変革を推進してきた。しかしその過程で分かったことは、これは言う方簡単ではないということである。そして、その理由は、DevOpsカルチャーの醸成こそが最大の難題であるからである。つまり、DevOpsカルチャーの醸成そのものがコストであり、そのコストは意外に大きいということである。
DevOpsカルチャー醸成のコスト
DevOpsカルチャーの醸成が難しい理由は、主に三つある。
一つ目は、その本質を捉えるのが難しいからだ。これを確かめるには、あなたの同僚に「DevOpsとは何か？」と質問してみるといい。ほとんどの同僚は、DevOpsパイプラインやCI/CDといった表面的な仕組みについて語るか、あまり要領を得ない回答をすると思う。実際、普遍的な定義がある訳ではないので、その回答内容をみるとその人の理解度と視点がよく分かる。ちなみに自分は、「毎日のようにリリースを行い、かつ障害や不具合を最小化するために、ソフトウェア開発と運用を統合した様々な方法を組み合わせたもの」と答える。これが正解なのかは未だに分かっていないが、自分はそういう視点で見ている。
二つ目は、DevOpsが戦略としてのキラーパスの性質を持っているからである。戦略のキラーパスは、ストーリーとしての競争戦略において楠木教授が紹介しているものである。キラーパスとは、競合が戦略の一部を真似ただけでは逆効果を発揮する性質のことを言う。端的に言うと、表面だけパクると自爆すると言うことだ。
例えば洗練された CI/CD が整っていないのに、頻繁なリリースのみを真似たとしよう。チームはリリース作業だけでてんてこまいになり、頻繁にバグを引き、本番障害が頻発するだろう。チームが単体テストの重要性を理解せず、第三者によるE2E/UIテストに依存していたとしよう。そのバランスを見直さずテストの自動化のみを推進した場合、少しの仕様変更でもハイメンテナンスなSeleniumテストケースを頻繁に修正することになる。むしろマニュアルテストより効率が下がるかもしれない。
三つ目に、DevOpsは現場からトップまで全員の理解を必要とする。もしIT経営のトップが昔ながらソフトウェア開発パラダイムを持っていたとしよう。「毎日リリースしましょう。そうすれば一回のリリースのリスクを小さくすることができます」とでも言おうものなら異端扱いされることだろう。一度、重大障害が起きればリリースの頻度を下げ、重厚な変更管理プロセスと沢山のチェックリストを用意するように指示がくることだろう。DevOpsのプラクティスと真逆の方向にアクセルを踏んでしまうのである。逆に、トップマネジメントがDevOpsカルチャー推進の音頭をとったとしよう。開発の現場が、ソフトウェアのテストをするのはQA部門の仕事だと思っているとしたら、一向にテストの自動化は進まないだろう。DevOpsの重要な前提である自動化テストが上手くいかなければ、変革は掛け声だけに終わるだろう。
DevOps 変革が難しいエンタープライズ
こうした課題は特に、DXを推進しているような企業では難しい。これらの企業では、デジタルネイティブ企業とは異なり、ITシステムを自分達で作る代わりに、ベンダーから買ってくることに慣れている。そして、ベンダーベースのソフトウェア開発は、DevOpsのプラクティスの真逆を行っている。厳重な変更管理をして、半年に一回にメジャーリリースをまとめ、ソフトウェアの開発が完了してからテストベンダーを大量に雇って手動で試験をこなすことに慣れきっているのである。こうした組織カルチャーの変革をするのは一大事業だ。
こうした理由で、DevOps変革は困難を伴う。品質とスピードを両立すると言うことはとても魅力的であるが、その裏側にはカルチャーを変えるという大きなコストが潜んでいるのである。そして、カルチャーの変革コストは投資承認がおりれば簡単に支払えるものではない。トップから現場までの粘り強く働きかけ、実践を通じて時間をかけて変えていくしかない。
経営科学が示している通り、企業文化というのは移植が最も困難な強みである。それゆえにこの強みを構築した企業は、競合に対して強い優位性を持つだろう。そうした DevOps 変革をトップから現場まで粘り強く働きかけて、変革を推進できる人材は、一騎当千の価値を持つのではないかと筆者は考えている。DevOps推進の鍵は変革のためのコストを認識し、そのコストを粘り強く支払うことなのだと思う。
参考
なぜマニュアルテストは、まずうまく行きそして失敗するのか
本日は、なぜマニュアルテストはまず上手く行きそして失敗するのか、自分の考えていることを書いてみたいと思う。
ソフトウェアテストの自動化は常識である。優れたエンジニアは自ら優れたテストを書き、その結果として優れた品質を担保し続ける。一方で、テスト実装を推進できていないプロジェクトに遭遇することもある。こうしたプロジェクトは、大抵何れかのフェーズで必ず品質問題に直面する。こうしたプロジェクトの軌道を修正するベストな方法は何であろうか。
マニュアルテストのはじまり
テスト自動化を推進できない理由の典型例が「新規案件に忙しすぎてテスト自動化を推進する工数がとれない」というものである。TDD 論者がこの説明を聞いたときに「忙しいからテストができないのではなくて、テストを自動化しないから忙しいのだ」と答える様子は想像に難くない。だがここでは、あえてこの議論には深く触れず、こうしたプロジェクトがどういう道のりをたどるのかを考えてみる。
開発者がテストを実装する時間がないという理由を聞いたマネジメントは、たいてい外部のテストチームにその品質管理を頼る。開発チームから上がってくる品質が信用に足らないから、テストチームは念入りに検査をしてくれと言った具合だ。
マニュアルテストの罠
マニュアルテストの怖いところは、ある一定の規模までは機能してしまうことである。以下の図に示すとおり、ある一定の範囲で障害を最小化できるスイートスポットが存在する。
リリースにあたって障害が多発する場合、おそらくリリースの頻度を下げて品質を担保しようとするだろう。変更をまとめてバッチサイズを大きくすることで、回帰試験の回数を減らして工数を抑える。そして、品証の時間を十分とることでしっかり準備しようという考え方だ。実際この戦略はある一定の規模まではうまくいく。
しかし、あるタイミングで破綻する。なぜなら一回の変更のサイズが増えれば増えるほど、システムの複雑性が指数関数的に増えるからである。2 つのシステムが相互にやり取りするシステムと、3 つのシステムが相互にやり取りするシステムの複雑性は線形比例にならない。リンクの数が指数的に増えるからである。
バッチサイズを大きくすることで確かに回帰テストの回数は減る。だがシステムの複雑さが加速度的に上がるため、より多くのバグが埋め込まれ、より発見が難しくなる。つまり、過去の成功体験にならって人員増強や試験期間の延長をしても対処ができなくなるのである。
罠から抜け出す
テストの自動化や CI/CD の利点は、工数やコスト削減の削減ではない。バッチサイズの最小化である。優れた IT 組織はこれをよく熟知しているため、テストの自動化と CI/CD に十分な投資を行っている。大きなプロダクトであればあるほど、小さく変更して頻繁にリリースする。そうすることでバグの埋め込みを防ぐのである。
ではマニュアルテストの罠にはまってしまったプロジェクトはどうするべきだろうか。残念ながら答えは一つしかないと思う。自動化を推進してバッチサイズを小さくしていくしかない。自動化に反対する人まずいない。問題は自動化が整うまでの暫定的処置を関係者と合意することだ。自動化を推進する間も開発を止めない方法を求められることもあるだろう。だが結局の所銀の弾丸はないのである。
罠から抜け出すには優れたリーダーシップが必要である。チームがあるべきテストの姿を推進するための工数を確保するために開発チームのリーダーは動かなければならない。ステークホルダーとコミュニケーションをし、ときにメンバーを守り、ひたすらに自動化を推進することが結果的に製品の成功への近道となるのである。
英文記事:
チームビルディングの新常識！好きなプログラミング言語を議論せよ
自分が議論を投げかけたのに、チームが静まり返ってしまって気まずい思いをした事はないだろうか。アフターコロナの世界になってチーム・ビルディングの形も大きく変わってきている。特に、リモート・ミーティングで上のような局面に当たる機会が増えたのではないかと思う。
この記事では、エンジニアリング・チームのミーティングや日々のやり取りを盛り上げ、楽しく仕事をするにはどうしたら良いか語ってみたいと思う。
自転車置き場効果 - くだらない事は盛り上がる
自転車置き場効果という心理学の用語がある。正式にはパーキンソンの凡俗法則と呼ばれているものである。簡単に言うと、人間は「くだらない議論ほど盛り上がる」と言うものだ。
例えば、ある会議室で原子力発電所の建設費用の見積もりを議論したとしよう。殆どの参加者は黙ってしまう。だが、職場に自転車置き場を設置するべきかと議題を投げかけると、みんなが活発に発言をする。自分にとって身近な問題であるし、責任も伴わないからだ。
エンジニアには度々盛り上がるトピックというものがある。例えば、あなたの好きなテキスト・エディターは何ですか、あなたの好きな Linux ディストリビューションは何ですかと言った議論だ。これは、ほとんど趣味嗜好としか言えないような議論に陥るがとにかく盛り上がる。それは、トピックが「くだらない」からである。
チーム・ビルディング・イベントでくだらない議論をする
最近、あるチーム・ビルディング・イベントに参加したのだが、これがとても盛り上がった。この組織の四半期目標、経営理念、戦略といったトピックの代わりに全員参加のくだらない議論を行なったのである (無論まじめな話も別セッションで実施した)。
参加者はスライドの QR コードを読み取って投票に参加する。そしてその投票結果がリアルタイムにスライドに表示される。その質問の内容はというと、「もしオフィス移転をするならどこが良いと思いますか」「あなたが働いてみたい他の部署はどこですか」といった他愛もないものであった。エンジニア向けには「あなたの好きなプログラミング言語は何ですか」という質問がなされた。普段業務で使っていない言語がトップにあがり、これは大きく盛り上がった。
くだらない話でチームを盛り上げよう
リモートワークが主体となって以前よりもずっと雑談の機会が減ってしまったのではないかと思う。そんな時は「好きなプログラミング言語」の話をしてみよう。なんなら「嫌いなプログラミング言語」の悪口でも構わない。個人の趣味嗜好によって議論が白熱することだろう。そうした議論は普段の業務と直接関わらないから、意見が割れようと尾を引かない。
くだらない議論によってエンジンのかかったチームは、本題のビジネスにおいても闊達な議論をするようになるだろう。
英文記事: yuichi-murata.medium.com
技術負債は大きな石だと思えばうまくいく
技術負債に対する取り組みは、エンジニアリングにあたって最も活発に議論されるトピックである。この記事では、技術負債に取り組むために如何に工数を確保するかについて、自分の考えを述べたいと思う。
技術負債？とにかく新機能を実装してよ
エンジニアの最も大きな不満の一つは、ビジネスが技術負債への取り組みを理解してくれないことである。ステークホルダーやプロダクトマネージャーは、さらなるビジネスの発展のために次から次へと新しいビジネスや機能のアイディアを持ち込んでくる。あるいは、特定のお客様の不満へ対処するために、緊急の機能改修を要求してくるかもしれない。
「設計の変更が必要なのは分かった。でも、それ今じゃないとだめかな？いまがビジネスにとって大事な時期なんだ。」 理由は様々かもしれない。だが、このようなフレーズでリファクタリングや改善策の実施を押し返されてしまった経験はないだろうか。
もちろん時と場合によって、技術的な負債を増やして前に進むべき時もある。大大的に告知されてしまったリリース日を守るために設計を妥協したり、放っておくとお客様の信頼を大きく損なうような重大なバグ修正を優先することは至極まっとうである。
しかし、意思決定には慎重にならなければいけない。ビジネスにおいて重要でない時は存在しないからだ。最初から自動化テストを実装しておいたほうが、結果的に早くシステムをリリースできる。このように適切な取り組みは、最終的なゴールへの到達を早める。結局は急がば回れということである。エンジニアはこれを理解していているが、ステークホルダーはこれを理解できないことがある。であれば、技術負債への取り組みを推進するのは「エンジニアの責任」である。それが何れ問題になることが分かっているのだとすれば、プロフェッショナルとして、あなたは何としてもそれを推進する責任がある。ピーター・ドラッガーが述べている通り「知りながら害をなすな」ということである。決して「技術負債返済の理解をしてくれない」と嘆いてはいけない。
大きな石ころを先に詰める
とはいえ、一般に理解してもらうことが難しいこの取組をどのように推進すればよいだろうか。スティーブン・コビー博士の著書「最優先事項」からそのヒントを得ることができる。技術的な負債への取り組みは大きな石ころだと思えば良い。
これは彼の講座の講師の話である。その講師は瓶を取り出して、「この中にいくつの石がはいるでしょう」といって瓶の中に石を詰め込み始めた。瓶がいっぱいになったところで、「さてこの瓶はもういっぱいでしょうか」と生徒たちに訪ねた。生徒たちがうなずくと、彼は砂のはいった袋をとりだした。「さてこの瓶はもういっぱいでしょうか」。生徒たちは「いいや」と答えた。
この講師の話は優先事項を以下にスケジュールに組み込むかについて分かりやすい比喩を使って説明している。要するに大事な仕事は先に「瓶」に入れておくことだ。
瓶がいっぱいになってから「すいません、このリファクタリングをしたいので少し砂を避けてください」などと言ってはうまくいくはずがない。まず石を詰めておいて、そこから砂を入れるようにしよう。新規の開発計画を立てるときには、関連するシステムの設計見直しや追加のテストの実装といった技術負債返済のための工数をまず計上しておき、それから新しい機能の実装の工数を積むのである。
大きい石ころについて話すべきか
ここで一つ議論のあるポイントが有る。それは「大きい石ころ」について話すべきか否かである。瓶の中には大きな石ころが詰まっている。だが砂を詰めたあとの瓶の外側からはそうした大きな石ころは見えない。ただの砂のつまった瓶である。我々はこの大きな石ころについて話すべきだろうか。
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!
もしステークホルダーが技術に理解ある人であれば黙る必要はないかもしれない。だが、そうした判断ができないようなのであれば大きな石ころについて「話すべきではない」。話した結果、こうした取り組みを実施できず、結果的にソフトウェアの品質を下げてデリバリーを遅くするのであれば、あなたはプロジェクトの成功にたいして裏切ったことになる。無闇に話さないことも一つのプロフェッショナリズムだと思う。見た目には砂がいっぱいの瓶をみて皆が納得してくれるのならば、それでいいではないか。結果的にはそれがプロジェクトの成功のためになるのであれば、あなたはプロジェクトの成功にたいして誠実なのだから。
そのためにも、大きな石ころの管理には注意を払う必要がある。石ころが瓶に入らなくなるほど大きくなるまで放っておいたり、大きな石ころだけで瓶をいっぱいにしてはいけない。砂がほとんど入らない瓶をみてステークホルダーは怪訝な顔をすることだろう。そうなる前に、継続的に、したたかに大きな石ころを瓶に詰めるのは、プロフェッショナルのエンジニアとしての大事な責任である。
英文記事:
お前はクビだ！優れた技術リードが持つべきひとつの条件
今日は技術が持つべき、ひとつの条件について、自分の考えを話したいと思う。それは「ある特定の人物」をクビにする能力である。
金持ちはますます金持ちになる
資本主義社会に対する一つの批判は、金持ちがますます金持ちになることである。金持ちは自分の資本を用いて割の良い商売を行い、更に儲ける。貧乏人は、誰にでもできる割の悪い商売にありつく。こうした貧富の差は度が過ぎると社会が不安定になり、社会が上手くいかなくなる原因となる。「世界はシステムで動く」の著者ドネラ・メドウズは、これを自己強化ループの典型例として紹介している。つまり、問題は時を経て次第に加速していくのである。
これは金銭的資本に限った話ではない。技術者の経験にも同じ理屈が当てはまる。経験豊富なエンジニアはその知識を活用して難しい問題の解決にあたる。その過程で更に多くの経験と知識をつけていく。その仕事ぶりを聞きつけた人たちが、更に挑戦的な仕事を持ち込んでくる。こうして、優秀なエンジニアはますます優秀になっていく。
一人勝ちはチームをダメにする
個人のキャリア作りという観点でこれは良いことである。一方、チームづくりという観点では少し慎重になる必要がある。一人勝ちはチームをダメにするからだ。
自分には今でも尊敬するシニア・エンジニアがいる。信じられないレベルで広い範囲の経験を持ち、深い知識を持つ。障害が起きれば豊富な経験に基づく直感で素早く被疑箇所にあたりをつけ、常人には考えをつかないような創造的な打ち手で問題を解決してしまう。
チームは高い成果を上げ続けた。だが、チームは彼が離れるタイミングになって、大きな問題を抱えた。次を担う人材が十分に育っていなかったのである。それは、彼がありとあらゆる問題を解決してしまっていたからである。次を担う世代が十分に経験を積んでいなかったのである。
自分は彼から二つの大切なことを学んだ。一つはエンジニアとしての知識と経験で、それはいまの自分の血肉になっている。もう一つは、自分がチームにとってかけがえのない存在にはなってはいけないということだ。
優れた技術リードの条件
自分の考える、優れた技術リードが持つべきたったひとつの条件、それは「自分をクビにする能力」である。自分の手柄を積極的に手放し、後進のために機会を作る。そして、自分をクビにする。この言葉を三年ほど前、エンジニアリング・リーダーシップの勉強会で聞いた。その強烈な言葉が脳裏に焼き付き、常日頃から意識するようになった。
自分はこの言葉を意識して仕事をするようになり、新しいチームを作っては何度も自分をクビにした。それは勇気がいることでもあった。来年には飯の種がなくなってしまうかもしれないからだ。また、「これは失敗するかもしれない」という不確実な状況において、大胆に仕事を任せなければならない局面もあった。仮に失敗したとしても、責任をとり全力で支援をしなければならない。大失態をやらかして、頭を下げて回ったこともある。
だが、不思議なもので、チームが経験を積み自走する状況になると、自然とより大きな機会に恵まれるのである。またそうした大きな機会に見舞われた時、自信を持って今の現場を離れることができるのだ。すでにそこにはチームがいるのだから。
ウォルト・ディズニーの CEO であるロバート・アイガーはこう言っている。
優れたリーダーシップとは代わりのきかない存在になることではない。他の人を助けて、あなたの代わりになるよう支援することだ。彼らを意思決定に参加させ、彼らが身につけるべきスキルを特定し、身につけるのを支援しよう。そして、彼らが何故次のステップに行くことができないのか、時に正直に話す必要がある。
あなたをクビにしよう。それが結果的にあなたの次のキャリアを作るのだ。
英文記事:
