話題になっていた「世界一流エンジニアの思考法」。
非常に読みやすく、すらすらとテンポよく読めるのに、色々と深く考えさせられた。
本サイトは通常はアフィリエイトを狙うのだが、この本には最大限のリスペクトを示すため、アフィは付けない。
読み終わって思ったこと
全エンジニアに読んでほしいと思いつつも、まずは管理職のトップの方から順番に読んでほしいと思った。
生産性とは合理性だ、ということを具体例をもって示し、そして合理的に仕事を進めるアイディアがたくさん盛り込まれていた。
本書は自社開発をするソフトウェアエンジニアがメインとなっており、私の主な仕事である「顧客へシステムを納品する請負インフラエンジニア」には今すぐに取り入れるのは難しいものも多い。
だが本質は同じと感じた。
本書のことをそのまま書くのも芸がないし、私が長年経験した請負インフラエンジニアとして本書をどう捉えどう感じたかを書いていきたい。
念のため
全て私の経験・観測範囲を基にした私の感想・妄想です。また、記載してあることは世界の一部の話であり、全てがそうであったとは思っていません。
責任のアウトソースとベンダコントロール
本書を読んで確信したことがある。(知っていたけど再確認)
2000 年頃から日本で行われてきた IT の請負の本質は「スキル者のアウトソース」ではなく「責任のアウトソース」であったこと、そして「責任」というのが長年にわたって IT 業界の生産性を下げていく根源でもあったこと。
責任のアウトソースとは何か。具体的には発注者が「僕たちよく分からないからプロである業者がうまく仕上げてね。問題起こさないようにね。」というスタンスであること。
需要と供給がマッチしている限り、これは問題ないようにも思える。
たしかに最初の頃はこれでもうまくいくところが多かった気がする。
だがその後、発注者側にも詳しい人が出てきて「ベンダコントロール」という言葉が出てきた。このあたりが一つ転換点だったようにも思う。
例えば、とある人が IT ベンダから IT 外のところに転職したとすると、今まで IT ベンダに「全部おねがーい」ってやっていた部署で、彼は大活躍ができる。ベンダの積算に過大な見積りが無いか、その見積の根拠は何か、といった精査をし、削減していった。これは適度な範囲であれば当然の権利だ。ベンダの責任範囲をコントロールし、その分の価格を減らしてもらう。これなら合理的だ。
ただ、実際はどうだったかというと、問題が起きたとしたら不合理な理由でベンダも連帯責任になるのだ。
私の観測範囲では、「ベンダコントロール」という言葉を自分の武器だと言う人に、技術が好きな人はいない。だからかもしれないが私はこの言葉はあまり好きではない。この言葉の正確な定義はよく分からないが、とりあえず「ベンダの技術者をうまく使って仕上げる」ということだろう。発想がそれなので自分自体は技術の詳細は把握していない。
そしてうまくいけば自分の手柄にしてしまい、うまくいかない場合はベンダに責任を問うのである。グレーなものは追加要件ではなく仕様の範囲内にされてしまうこともある。
このスタンスは当然ベンダから見れば面白くない。それでもベンダの会社内で一時的にでも評価されればそれが支えにもなろう。だが、この構図自体がサステナビリティがない。持続可能ではないのだ。Win-Winではないのだから。
結果、SE の反乱が起きる。大転職時代の幕開けである。押さえつけられていた SE の賃金が高騰し始めたのだ。
話を戻そう。
最初に「責任のアウトソース」という言葉を使ったが、責任とは例えば以下のものだ。
ひとつ、品質は損なってはならない (ここでいう品質というのは、仕様書の内容ではなく顧客が「イイね！」と感じるかどうか)
ひとつ、納期は遅らせてはならない
ひとつ、追加費用は出さない
「世界一流エンジニアの思考法」で紹介されている方法は、基本的に QCD をどうバランスを取り、顧客への最大限の価値を創造するか、という話であり、3 つとも固定化される「責任のアウトソース」パターンには適用が難しい。
本書でも「責任の所在や完璧を過剰に求めることが足を引っ張っている」と表現されている。
また、責任の内容を定義するのは契約だが、契約するまでにも生産性低下の要因がある。例えば要件のすり合わせと見積りである。
ベンダは責任を全うするために必要な情報を念入りに確認するだろう。何度か折衝する。それが実を結ぶなら問題ないが、結果失注となれば生産性は大きく低下する。その間の進捗・成果は０なのだから。
これは会社単位での話でもあるが、これがそこら中で行われているなら、日本全体での生産性低下である。もし「見積もりするだけなら無料だから」と安易な気持ちで見積もりを取る人がいたら、「日本の生産性を下げてますよー」と心の中で呟いても良い。
また、責任のアウトソースの枠で行動をする際、実験が許されない。実験は技術者としての幅を広げる機会だが、責任のアウトソースの範囲内ではどうしても堅く行くしかない。この話は次の心理的安全性に繋がる。
心理的安全性
責任を押し付けられるリスクを抱えたベンダはどのような行動をとるか。
いや、これは別に IT 業界、仕事に限った話ではない。要は、自分では結論を出さず、相手に結論を出させ、答え合わせをして正解だったら自分の手柄、間違ってたら結論を出させた相手の責任、ということをしてくる人間に対してどう対応するか、という話だ。
まあ、なるべく堅いプランを考えるようになるし、なるべく余計なことを言わなくなる。
この２点はそれぞれ生産性を下げる要素がある。
１つは堅いプラン。いやいや、そこまでしなくても、っていうプランを考える。ひどいと 1 % の確率で 100 万円くらいの損害が出る話でも、100 万円の保険を考えることになる。(補足すると、技術が分かる人は発生確率や発生時の被害額もある程度予測できるが、分からない人はできないし、そんな人が上にいると、説明が面倒だから対策をする、ということがある。)
そしてもう１つは余計なことを言わない。これが心理的安全性の話になる。
心理的安全性、というのは最近よく聞く言葉だと思うが、私の解釈ではこれは「チーム内で間違ったことを言ったとしても気にせずにいられる状態であるが故に意見がよく集まり、かつ、常に正しい意見、合理的な方法が採用される状態」と考えている。
例えば妻が機嫌悪いときに余計なことを言わないようにしよう、と思い、商業施設の近いほうのトイレを教えない、というのは心理的安全性が無い状態である。
発注元が出した答えが明らかに間違っていても、ベンダはそれを止めないことがある。もし指摘すれば問題は発生しないかもしれないがそれがきっかけで別の問題が起きるかもしれない。そうしたときに責任を押し付けられる。ならば黙ってたほうがお得である。
アジャイル開発・内製化
私はもともと請負インフラエンジニアだったが、最近は自社開発のソフトウェアエンジニアもやっている。なので本書には本当に打ちのめされた。請負インフラエンジニアで染みついた仕事の仕方をしていた部分があり、その矯正を本書に隅々まで指導してもらったからだ。
QCD の配分は自分たちの裁量であるし、技術的な実験はできるし、自分たちの責任で過剰なリスクヘッジはしないで済む。ベンダとの要件すり合わせ、見積というプロセスは無い。アイディアがあればすぐ検討なり検証なり開始できる。業務委託で教えを請いながらやってはいるが準委任であり、主導は自分たちだ。学びも多い。
請負インフラエンジニアでは適用し難い本書のアイディアがほぼほぼ適用できる。なので私はどうしても請負インフラエンジニアのときの仕事のやり方と今のやり方を対比して見てしまう。
アジャイル開発・内製化は責任をアウトソースしないので生産的・合理的に進められる。前提としてメンバーに相応の技術力が必要だが、今後日本の IT 業界もこのやり方が主流になっていくと思う。そうなったとき、今の SI 請負はどういう形に変貌するのだろうか。このあたりは予測がつかない。
でも未来は明るいんじゃまいか
正直、請負インフラエンジニア業は会社の仕事上不可欠だし会社としてやっていかなければならないだろう。これをどのように自社開発のように生産性を高めていけばよいか、具体的な答えは見つからない。
だが、未来は明るいんじゃないか、という気もしている。
コロナ禍以降、少なくとも私の観測範囲ではすごく状態が変わったと思う。具体的に言うと、社内で感情論はだいぶ無効化され、建設的な議論が目立つ。会社の仕事の仕方が変わり、生産性・合理性が求められるようになった。踏み絵の類の仕事はだいぶ減ってきた。
また、最近、安芸高田市の石丸市長の動画にはまった。彼は年齢は私の 1 つ下。合理的な思考、それを感情をこめて響かせて伝える力、実現力・実行力、全てがすごいなーと思った。
少し前までは「日本の既得権益にしがみつく無能はなかなか駆除できないんだろうなぁ」と諦めているところがあったが、彼を見て、我々の世代が社会に合理性をもたらすのだ、という使命感すら湧いてきた。
なので、SI 請負も合理的な形を模索し、フィットしていくものと思っている。
冒頭、「本書を管理職のトップの方から読んでほしい」と書いたが、それは『我々の世代が仕事の仕方を変えるから、それを少しでも理解してほしい』という気持ちからだ。社内の風向きが変わった今だから、素直にそう思える。昔だったらそんなことすら思わなかった。
日本は徐々に、だが確実に変わっている。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント