目次
- はじめに
- 結果の出し方に正解は存在せず最適解も人による
- 人生の唯一の正解
- 実は結果を出すことも正解ではない
- マネージング自体も正解ではありません
- 成功体験の記事を読むと寛大になれる可能性がある
- 成功体験の記事を読むときは失敗原因に注目したほうがよい
- 最後に
①はじめに
この記事は、「202501_開発プロジェクトのマネージング資料作成における最適解」のおまけです。
技術的ではないトピックなので、読者の生産性向上には寄与しません。
技術系の記事を読むときに、念頭に置いた方がいいことについて書いています。
②結果の出し方に正解は存在せず最適解も人による
私は元々営業で、トータル40人以上の営業手法を身近で見てきました。結果の出し方に正解はありませんでした。高級ホテルマンのようなスタイル、貪欲に商談を追いかける人、人懐っこく買ってとお願いする人、色々います。
社内の人間関係の構築をどのようにするかや、人間関係のウェットさなども含めて、処世術にも正解はありませんでした。
成功体験は世の中にたくさんあります。
・「人に寄り添う」, 「パワハラは良くない」, 「結果が大事」, 「無理をしない計画」など
これらは成功パターンの一つで、正解ではありません。士気が低くてもパワハラで業務遂行を強制させる人や、きつい計画を実現させて良い評価をもらう人など、さまざまです。
ですが自分の成功体験で自信を持つことができて、それが自分らしさになります。大事なことです。
自分のスタンスを発信することは悪ではありません。自分を肯定的に評価して、優越感に浸れるでしょう。
人懐っこさや技術力などの尖った性質によって、成功につながることも多いです。
他人に指示を出すなら再現性
③人生の唯一の正解
進路の悩みや、コミュニティに属するべきかというすべての問いに対して正解はありません。
唯一の正解があるとすれば、[食事, 睡眠, 運動]によって、心身健康なことです。
これについても実は、肥満や病気さえも武器にする営業マンもたくさんいます。しかし当人は健康でエネルギーに満ちている方が良いと言うでしょうから、正解なのは間違いありません。
よく子供に対して言う「元気に大きく育ってくれればそれでいい」という言葉に近いです。
④実は結果を出すことも正解ではない
前回の記事は、開発現場のマネージングとその成果物を正しく運用して、チーム全員が最小限の労力と精神力で、課題を解決することを目標に書きました。[効率至上主義者]である私なりの最適解です。
仕事で効率を求めようと努力する人は少ないかもしれません。
以下のように、プロジェクトで結果を出すことさえも正解ではない場合もあるのでしょうがないです。
・進捗が遅れ気味のプロジェクトは費用が増大して雇用や残業代を生み出します。システムやコードが分かりづらくて、設計書を共有しない場合は修正工数が増大します。しかし、外注業者にとっては稼げるので正義です。
・効率化にあたって、他部署との摩擦や他人のプライドを考慮して、何もしないのは一般的です。在籍期間が延びれば日本企業は評価します。個人にストレスがかからない状態を望む普通の人の行動です。
・個人が仕事をブラックボックス化してクビにならないようにするのは、よくある話です。効率よく仕事をして副業で稼ぐよりも、効率化せずに残業代で稼ぐ方がシンプルでお金になります。
⑤マネージング自体も正解ではありません。
PMやディレクターにの立場で良いマネージングをする必要があるかというと、そもそもマネージングをしないで結果を出すという選択肢もあります。
・10人規模のプロジェクトを、優秀な人が1人で全て実装する場合があります。そこにマネージングは存在しません。
10人規模のプロジェクトを3人で実装したとしても、攻殻機動隊から引用すると、「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。」というように、マネージングが無いことも少なくありません。
・難しい調査や業務は全て自分が実施して、運用や簡単な仕事だけ他の人に任せるマネージャーもいます。
今後AIやツールなどが進化したり、ハードウェアの演算処理が早くなるほど、大きな仕事を一人でこなすパターンが増えていくでしょう。
昔はブログ記事を書くのにWebエンジニアの知識が必要でしたが、今ではSNSによって子供でもブログを書く時代になったように。
優秀な人でチームを構成するために、マネージャーや人材派遣会社の営業が備えている性質もいろいろあります。
・「寛大さ」や「明るい性格」で離職率を抑える
・「コネクション」や「行動力」で優秀な人と知り合う
・「自分の技術力」でスキルがあることを見抜く人
⑥成功体験の記事を読むと寛大になれる可能性がある
成功体験の記事は属人的な要素が含まれるものが多いです。
成功体験に必要な要素を理解できると、自分には無い性質や、考えもしない行動によって成果を出せることを知ることができるので、少しは寛大な人間になれると思います。
私が今まで出会った中で一番成果を上げた大企業の営業マンは、ライバル他社の営業と仲良くなって、一緒に客先でプレゼンをして成果を上げることを日常的に行っていました。
利益が出て法律を守っていますが、「そういうことをしていいですか？」と上司に聞いたら、ダメという上司が少なくないのは想像できます。前例が無いですし、ライバル企業と仲良くなって資料共有するなど考えられないかもしれません。
彼の成功体験に必要な性質は、[人懐っこさ, バイタリティ, 成果第一主義, 好奇心, プレゼンのうまさ]などでした。彼を部下にするには、マネージャーが彼の性質を見抜いて、彼が行動しやすいように根回しをする寛大さが問われます。
ほとんどの人は、自分の想定内の性質ややり方で、想定内の結果を出す人ではない場合、とりあえず否定するというバイアスを持っています。技術職だとさらに、自分の想定内のやり方を実現できる技術レベルを求めます。
そのバイアスには、嫉妬心や自分の評価を大事にしたいという人間的な欲望も関係するので、否定の仕方は人それぞれです。
成功体験の知見を広げたり、自分の技術力をつけておかないと、結果を出せる能力がある人間と一緒に働くチャンスのとき、そのバイアスによって相手を全面的に否定することになります。
実際の私の経験ですが、バックアップファイル作成バッチファイルについて書き直したことがあります。最初にフルバックアップを取る機能が無いため、全てデータが飛んだら復元できない致命的なバグ同然の設計仕様でした。さらにコードが冗長だったので、PowerShellでリファクタリングしました。
その後上司に変更を提案しましたが、10年間誰からも問題を指摘されたことがないということで、強い拒否反応を示されて採用にいたしませんでした。
上司がPowerShellの経験が無く、コードレビューされた経験や、バッチファイルの設計書の作成経験も無かったことによって、品質管理の技術がなかったので、指摘に対して寛大な対応が取れなかった結果です。
この現場に限らず、毎年そのような人と会う機会があります。
⑦成功体験の記事を読むときは失敗原因に注目したほうがよい
成功体験を真似する場合は、やってみるまで成功するか分かりませんし、成果が出る前に辞めてしまう人も多いでしょう。
その成功体験にどのような資質を想定していて、実際に成功させるために必要な性質を自分が持っていそうかどうかは、最後まで判断できないかもしれません。
例えば、ポートフォリオの作り方を公開している人は「自己管理能力」によって完成させたかもしれません。しかし、「人懐っこさ」によってプロに聞ける状況を作ってさらにいいものを完成させる人もいるでしょう。情熱が足りないのを他の資質で補えずに、完成させられない人もたくさんいるでしょう。
つまり再現性が低いのです。
しかし、失敗原因に対処できそうかどうかは想定できます。
失敗談は事実に基づいたシチュエーションで、判断ミスが明確に分析しやすいので、自分が回避できそうかどうか想像できます。
例えば、「デザインばかりに時間をかけすぎて、コーディングが全然進まなかった。」という失敗談があるとき、自分の資質やテクニックでそれを回避する方法をいくつか考えることができます。
⑧最後に
次は以下のトピックについて書こうかと思っています。今回の記事の反応が良ければ、面接対策について追加で書こうかと思いますが、モダンな技術系記事の方が閲覧数が多いようですね。
✅コーディング初心者がWebアプリ開発現場に入る方法と経歴の作り方の提案
✅モダン環境でフルスクラッチシステムを開発している現場で抑えておくポイント
✅インフラエンジニアにPowerShellの習熟を勧める理由と他スクリプトとの比較