スーパーエンジニアへの道 (T1:Pt1:Ch03-1)①紹介編
プログラマー、SE、テスト担当者などソフトウェア分野の技術者で、チーム/グループでの仕事のレベルを高めたい人にはとても刺激になる本だと思います。
季節柄、これからソフトウェア技術者/ソフトウェアテスト技術者を目指す人にもお勧めの本です。
訳書表題は『スーパーエンジニアへの道 技術リーダーシップの人間学』。書誌情報は本文末にあります。
タイトルで敬遠するとしたら損。
表題に「スーパーエンジニア」という言葉を考案した経緯は訳者まえがきにありますが、1990年代初頭ならではの“事情”という感じがします。2020年代半ばの今なら、訳書副題、そして原著表題にあるTechnical Leader(技術リーダー)で十分通じるのでは？ と、久々に読み返して思いました。
著者の出自からしてコンピューター/ソフトウェアの分野を想定していますが、職種を問わず、技術領域でチームやプロジェクトを“率いる、導く”、そんな役割を引き受ける存在になるための心構えとヒントを説いています。
技術自体（コンピュータ、ソフトウェア、プログラミング、テスト）の話は殆ど出てきません。その代わりに、「人としての在り方」が解かれています。
ソフトウェアのデザインや実装であれ、検証(テスト)やQAであれ、チームプレーが欠かせません。今は個人の力量が重要に思えても、いつか遠からず「チームでのパフォーマンス」を考える時が来ます。
といって、「リーダーになろう。なりなさい」と押しつけることはもちろんなく、「あなたは（本当に）リーダーになりたいか？ ここまで読んでもなりたいと思うか？」という問いも投げかけながら話を進めていきます。「自分は向いていないな」「興味ないな」と思ったらそこで本を閉じればよいし、知識だけ仕入れておくのもありでしょう（「人々が力を付与されるような環境を作り出すプロセス」は、頭に入れておいて損はありません）。
時間をかけるつもりで
A5判二段組みで300ページ弱という大部なので、気長に読みましょう。
（ワインバーグ師の著作ですから）「原理や考え方は措いておいて、How-Toだけ述べる」ようなものにはなっていません。その点でも気長に読みましょう。
第一部の60ページは1～2週間かかっても読み切りましょう。本書でいう「技術リーダー」とはどんな存在、役割を想定しているのか、どんな技能が求められるのか、そんなのなりたくない人もいる、ということが描かれます。
その先は、第一部での定義に沿って、技術リーダーシップに求められる技能とその身につけ方の詳しい解説です。興味のある章を気が向いた時に読んでいくのでよいでしょう。
本書には電子書籍版があります。電子版なら「いつでも持ち歩いて、空いた時間に読む」がしやすいですね。
で、技術リーダーって何。
ワインバーグが想定している「技術リーダー」像を、まえがきから引用してみます。
成功したシステムと不成功に終わったシステムを比べてみて、じきわれわれは成功のほとんどすべてが少数の傑出した技術労働者の働きに依存している、ということに気づいた。(略)
それらのリーダーたちは、工学部や理学部で育てられた純粋の技術者でもなければ、経営学科で訓練されたありきたりのリーダーでもなかった。彼らはそれとは違った、合いの子であった。彼らはアイディアの質に対するこだわりを共有していた。(略)自分の身の回りのものはすべて最高であることを望む人々であった。われわれは彼らを「技術リーダー」と呼んだ。
本文を読んでいくと、リーダーシップという概念を（組織やプロジェクトの）マネジメントから（いったん）切り離して扱い、論じている点が目を引きます。組織上のポジションはあまり関係ないし、任命されれば本書でいうリーダーになれるわけではない。
そうではなく、リーダーシップは「人々が力を付与されるような環境を作り出すプロセス」といい、そういうプロセスをリードするのがリーダーの仕事としています([1] p.12)。
このようなリーダーを問題解決型リーダーとも、またリーダーシップの発揮の仕方を問題解決型リーダーシップとも名づけています([1] iii, p.21)。
問題解決型リーダーシップの在り方
三つのポイント
このようなリーダーは次の三つの点に注意を向けます([1] p.21)。
取り組むべき問題の定義に当たり、 問題を理解する。ソフトウェアのデザインやテストならば、要求や要件、仕様の細部まで、不明点をなくすまで読み込み、共通理解を築く。
アイデアの流れを調整する。（本書中では「アイディア」）。問題をやっつけるためのアイデアを自分から出したり、メンバーが出すように刺激を与えたりする。また、出てきたアイデアを比較検討・取捨選択する。
品質を保持する。プロセスとプロダクトの品質を随時測定し、コントロールを図る。
ひとつの信念
そして、どんなやり方をするのであれ、このようなリーダーに共通に具わっているのは「(今よりも)もっとよいやり方は必ずある」という信念だと言います([1] p.22, 本文では「信仰」という語を使っている)。
ソフトウェアを書く側なら、アーキテクチャやキーメカニズムのデザインで、いくつか案は思いついたけどどれも一長一短、という状況。
テスト側なら、ちまちまやっていたら到底期限までにこなせないテストを効率よく実行する手段が必要な状況。
そんな状況で（時にはぎりぎりのタイミングで）「冴えたやり方」を思いつき、うまく行った、といった経験があれば、「事を成すに当たっては、よいアイデアを求めよう」という姿勢が培われるでしょう。
そしてこの姿勢は、後天的に身につけることができるものだと言います（これは、ワインバーグの信念）。
余談
筆者が本書を読んだのは「技術リーダー」として何年か過ごした後でした（本書を参考にしてリーダー修行を積めたわけではなかった）。振り返ってこれらのことをできている/いたか考えると、(-ω-;)ｳｰﾝ となってしまうのが偽らざるところです。
「問題の理解」はやっていた自覚はあるしできていた自信もある。
「アイデアの流れを～」は、しているつもりはあったけれど傍から見て効果的だったかどうか。
「品質を保持」は、気にかけているほどできていたかな。……
という風に、読みながら「いま現在の自分」のかんたんなチェックリストとして使ってみるのもよいと思います。
他の著作と関連するサブテーマ, トピックが多い
訳者まえがきでも触れられていますが、本書はワインバーグの思考・経験・思想の集大成、ないしは一連の著作の結節点（ハブ）といった趣があります。（すべての著作には一般システム思考という底流があることは別にして）
「問題解決」という点では、『ライト、ついてますか』に（から）通じているところがあります。
主にソフトウェア分野のプロジェクトが例として取り上げられる点、そしてシステム思考が前面に出ている点では、『システムづくりの人間学』に（から）通じているところがあります（システム思考、本書でも遺憾なく炸裂しています）。
本書と同時期に書かれた『コンサルタントの秘密』は、問題解決型リーダーシップ（人々に力を付与する環境を作り出す）の一側面として通じるものがあります。
そして、品質という観点が出てくる点では、のちの『ソフトウェア文化を創る(Quality Software Management)』シリーズに通じるものがあります。同シリーズでは、バージニア・サティアの交流モデルが（少々装いを変えて）大活躍しています([2])。（筆者はこちらを先に読んだのでこちらのモデルの印象が強い）
他の著作に（から）つながるものをたくさん含んでいるという点で、「ワインバーグの最初の一冊」としてもよい本と言えると思います。「技術者として成長する」ことに興味があるならなおさら。
文献・書誌情報
[1] G.M.ワインバーグ・著, 木村泉・訳 『スーパーエンジニアへの道 ――技術リーダーシップの人間学』 共立出版 1991
原著 (日本語訳の扉記載の情報に基づく)
Becoming a Technical Leader -- An Organic Problem-Solving Approach
Gerald M. Weinberg
1986, Dorset House Publishing Co., Inc.
[2] G.M.ワインバーグ・著, 大野侚郎・監訳, 栁川志津子・訳 『ソフトウェア文化を創る2 ワインバーグのシステム洞察法』 共立出版 1996
原著 (日本語訳の扉記載の情報に基づく)
Quality Software Management: Volume 2 First-Order Measurement
Gerald M. Weinberg
1993, Dorset House Publishing Co., Inc.
(2024-03-27 R001)
（②回想・感想編は後日に別記事として公開します(見込み)）
この記事が気に入ったらサポートをしてみませんか？