会社員の立場と実力は運が7割、選択が1割、残りは努力

悪い意味での典型的なSIエンジニアの口癖は、
「なんで○○なの?」
だ。
なんでそうなるのかを興味があるのではなく、否定するためになぜなぜ聞いてくるのだ。
説明できなければ、「×」。

こういう人とは建設的な議論にならない。
そういう人と話していても、話は広がらない。
雰囲気が悪くなるし、とりあえず否定しようと構えている人とやる仕事に良いアイデアは降ってこない。そのうち案も出なくなる。
それが続くと、無難なことしか言わない非イノベーティブなSIエンジニアの出来上がりだ。

一方で、(悪い意味での)典型的SIエンジニアには、
「これはこうだから、こうした方がいいんじゃない?」
という人は少ない。
対案を出すだけの技術的な素養はないからだ。
技術的な裏付けはなくても否定はできる。
プロ野球の観戦者や国の政策を否定するオバサンと同じで、
否定するのは実はすごく簡単なのだ。

そもそもどのような場合も完璧な案というのはなく、メリット・デメリットを考えて取捨選択しなければならない。
否定するだけなら簡単なのだ。
だから相手を否定するなら、自分も覚悟しなければならない。
それ以上と自信を持てる対案を出す覚悟。相手が絶対に間違っているという自信と、その自信の裏付けとなる確固たる知識だ。

研修で久しぶりに同期と会って少し驚いた。
話し方が部署で見た40代の社員と似てきていたことにだ。

とりあえず自信満々に詰める。
詰めるけど、対案は言わない。なぜなぜ聞いて、完璧な説明を求める。ググレと言いたくなる。
もちろん、説明することは大切だ。

でも質問の基本は、
「自分は○○と思うけれど、これはどうでしょう?」
だと思う。
自分の意見も持たずになぜなぜ詰めるのは、外野スタンドからペットボトルを投げ入れるようなものだと思うからだ。

最近、「外注管理」しかしない若手社員の記事が話題になった。
同期もCOBOLやらアセンブラ(?)で書かれたコードを、自分では一切見ることなく協力会社の人に任せきりで、一日中マネジメントという名の調整メールばかりしているようだ。

一日中メールを打って、何が積み重なるのだろう。
自分のリソースの9割を社内調整に費やし、何かを生み出す時間はほぼ全て他の人間に任せきり。会社がなくなったらその人に何が残るのだろう。タイピングしかできないじゃないか。

以前研修で、

boolean isError = false;

というようなコードを書いた。
この型を「ブーリアン」と読めない同期がいた。変数の宣言の意味がわからなかった。
Javaでも他の言語でも基本だと思うんだけど、全くソースに触れない人から見るとただの呪文だ。ちなみに新人のときは自分もわからなかった。

(コードは)意味がわからない、読む気がしないと一蹴された。

日本語でboolean。
「チェック条件がOKであるかを判定するための変数をクラス変数として宣言する」
と書けばいいのかな。

可視性とかもどうやって日本語で説明するんだろう。
public
private
protectedと書けば済むことを、いちいち「クラス内でしか見れないレベルで宣言する」などと日本語に書けというのだろうか?

ソースを見たほうがずっとわかりやすくて早いはずなのに、「内部設計書」に書かれた日本語しか見ないから、コードの話ができなくなる。

そもそも内部設計書、詳細設計書なんてものは下手くそな翻訳書に似ている。
英語が読める人は英語をそのまま読んだ方がずっとわかりやすいように、内部設計書、詳細設計書を読むならコードを見たほうがずっとわかりやすいし、早い。

気になるところはJavaDocを見れば済む話だ。それをなぜ内部設計書とか詳細設計書を作るかと言えば、「外注管理」しているSIエンジニアがコードを理解できないからである。

詳細設計書レビューや内部設計書レビューなるものができても、コードレビューはしない。

コードレビューの方が256倍くらい大事だと思うんだけど。
中がわからないと不安じゃないですか。
そもそもオブジェクト指向で書かれた中〜大規模のコードを詳細設計書みたいな「フロー図」にどうやって書けばいいんだろう。UMLじゃダメなんだろうか。

コードに触れないエンジニアは、素振りをしないプロ野球選手と一緒だ。

なぜそんなことにも気付かずに、外注管理の名の下の「マネジメント」に慢心し、

「おれ仕事回しちゃってるよ」

みたいな顔で、文句を言うのだろうか。

「あの人早くやってくれねぇんだよ」
と言うくらいなら、自分で手を動かして問題を解決してしまえばいいのに。

なんでメールしか打たないのだろう。なんで詰めるだけなんだろう。

「まだですか?」
「なんでできないんですか?」

と。

「苦戦してるんですか?じゃあ手伝いますよ!俺がここやっときますね!」
と言えないんだろうか。。

「テストケースを切ってる俺カッコイイ」→「テストは協力会社任せ」
とか言う前に、さっさとテストコードを書いてJUnitを走らせた方がみんなが助かるんじゃないかな。そっちのほうがカッコイイエンジニアだと思うんだ。

大手SIerに入社する新人は本当に皆優秀な人が多い。
勉強ができて、物覚えが良く、人も良い。
素晴らしい人達だと思った。まるで敵わないと思った。
こういう人達と切磋琢磨していける環境は最高だと思った。
自分がダメで情けなかったけど。まだまだみんなの方が優秀だけど。

でも、そんな優秀な人達がいつの間にかに丸投げを覚え、技術は身に付かず、管理者という名の糸電話になってしまう。

協力会社がやったことを「管理」して、プロジェクトマネージャーに報告する。
プロジェクトマネージャーからのフィードバックを協力会社に伝える。

詰める文化を学び、「下」から上がってきた成果物にイチャモンを付ける。
イチャモンを付けることが自分の存在価値だと思い始める。自分で手を動かすのはマネージャーの仕事じゃないと言って、技術的な要素は協力会社任せになる。
それはきっと、正しい努力ではない気がしている。

どうしてあんな人柄もいい(本当に良い人ばかり)優秀な新人たちが「詰める管理者」なるかというと、そういう文化を見て育っていくからだ。
赤ん坊が身の周りの言葉を吸収して覚えていくように、新人は身の周りの文化から仕事を吸収する。それがどんな仕事であろうと。周りに見えるものから精一杯吸収する。
何もわからない、「はじめての会社生活」だから。はじめに目に見えるものがすべてに思える。
生まれたばかりのアヒルの子のように。

言ってみれば、「運次第」である。
“何も知らない”新人がSIerに入って技術が身に付くかどうかは7割が「運」
1割がチャンスが回ってきたときの「選択」。あとの2割は「努力」だ。

新人は環境にものすごく左右される。
身に付く技術は、努力ではどうしようもないくらい環境に依存する。
努力する意志の強い人でも、努力の方向性は日々の職場の環境に影響を受けてしまうからだ。
まじめに仕事ができるようになろうとする真摯な人ほど、職場の環境の影響を受けやすい。

コードを書かない、成果物がエクセル方眼紙で書かれた資料だけという環境だから、
「仕事が出来る人」の定義が曖昧になる。
「コードを書いた人」ではなく、仕事とは別に「難しい資格を取った人」が尊敬されることになる。
資格を取ったからといって、金は生み出せないのに。
エンジニアはコードで金を稼ぐべきなのに。
高度情報処理試験に受かった人がすごいと言われる。コードの話はしない。
資格試験に受かったあの人すげーという話は出てきても、あのプロダクト作ったあいつすげーという会話は全く出てこない。それってエンジニアの会社なのかなぁ。

自分のロールモデルがカッコイイプログラマーで良かった。
カッコイイと思う目上の人が「レビューで詰めている先輩」じゃなくて良かった。
周りにいる人が、自分で問題を解決し、難しいところは”自分で取り組もう”とするエンジニアでよかった。
自分はまだまだまだまだヘッポコだけど、先輩がすごすぎて自分が情けなくなることもたくさんあるけれど、カッコイイ先輩のようになりたいと思えるから、頑張れる。

人は上を見て育つのだ。
カッコイイと思った人に近づきたくて頑張るのだ。

基本的には先輩に対しては「尊敬バイアス」がかかる。
なのに、周りにいる先輩達が自分で手を動かさないで詰める人ばかりだったら、自分もそうなってしまうに違いない。

「進捗は?」
「なぜ遅れてるんですか?」
「なぜできないんですか?」
「これ、ちゃんとわかってますか?」
「これ、やっといてくださいね。以上、よろしくお願いいたします。」

「とりあえず詰める」ことは、楽をすることなんだよ。
仕事をしているように見えるし、レビューしてやったという満足感を得られる。
でも、その人は何も問題を解決していない。
何かを生み出してはいない。相手の不快感を除いて。

自分で手を動かすことが求められる今の環境に本当に本当に感謝したい。
自分でコードを書いて、コードを読んで、自分で障害に対応できる環境に感謝したい。
滅びゆく技術を守るのではなく、未来を見て前向きに技術を学んでいける環境に感謝したい。
技術に関心があることが、「こいつ何やってんの?」と言われない環境がすごく嬉しい。

こんなことを想像してみた。
高校の部活でその競技をやったことがない先生がいきなりやってきて、監督になる。
ある試合で、
「なんでそのシュート外したんだよ。ビュッと打ってシャッとよければ決めれただろうが?わかってんの?」
「なんで敵に負けてるんだよ。負けてる理由はなんだよ。説明しろよ」
と言われても、きっとそのチームは強くなれないんじゃないだろうか。

「お前たちが強くなるには、こうしたらいいんじゃないか」
「いまお前はシュートが入らなくて悩んでいるみたいだけど、そういうときはこうしたらいいと思うぞ」
「チームが強くなるために俺も頑張る。一緒に頑張ろう」
と、自分の経験を元にして言える監督の方が、やっぱり立派だと思う。

管理者はもちろん必要だし、大変な調整をしてくれる上司がいるのもよくよくわかっている。
マネジメントを否定するつもりは全然ないし、感謝もしてる。
でも20代のいま、「手を動かす仕事」を全部協力会社さんにやってもらうのは、まだ早いと思っている。コートに立って、プレイヤーとして経験を積んでいきたいと思っているから。
コートの中で、汗をかきたいと思っていたから。

だから自分は本当に運が良かった。
プレイヤーとして経験を積める素晴らしい機会をいただくことができた。
選ぶことができた。
本当にありがとうございます。
幸運に報いるために、できる限りの努力を惜しまないでいきたい。
そしてもっとチームに貢献して、恩返ししたい。

20 Comments

愚痴太郎

そんな愚痴ばっか言ってないで
管理や調整役がいなくても自分で案件取ってマネジメントして
客を満足させられる仕組みやら会社やら作ったら?

本来、技術的素養だけでお客さん満足させられるんなら
なんで管理や調整やってる人が市場から淘汰されないの?

shige

愚痴太郎さん
そんなこと書いてありましたっけ?

完全に

愚痴太郎さんの言うとおりだな。
典型的な現場の仕事しか出来ないタイプの物言い。
自分がやってみろよ、その仕事をよりよい形で。その後文句を言え。

hoge

だからまぁ。調整しかできない屑はじきに淘汰されるよね。定年まで逃げ切りはきつかろう。

pizza

でできないことを他人にやらせるだけの管理者はダメだけど、
できるからって自分でやっちゃう管理者はもっとダメだ。

あまいね

完全に理想論。お客さんと調整して、仲良くなって自分の名前で仕事とってきて、自分の配下に協力会社引き連れて管理して、完成責任を負う立場を一通りやってからだね。

ish104

コード読めないSEは論外だとは思いますが、調整ってのも実は結構重要で、黙って一週間遅れるのと、一ヶ月遅れると通知するのでは後者の方が相手も助かったりします。それは心情的なものではなくて、仕事では「先の見通し」ってのが結構重要でそれが分かってればそれなりに他の対策がうてたりするから。
だから詰めるのはそれなりの根拠を持って相手方に説明したり、見積もりを改善するために必要だったりすると思うんですけどね。
自分が開発してる時も記事のように感じてましたが、少し管理側になった時は「コードばっかり書いてないで少しはお客さん見ろよバカ」とか思ってしまったり。

hm

コメント欄でプログラムが書けない自称エンジニアが吠えてますね。
筆者は調整という業務自体は否定していないと思う。
そして、同じ調整するにしても、中身が理解できる上でやってるのとそうでないのでは最終的な成果物が大違いですよ。

taise

全ての人がコードをかける必要はないかもしれません。
プロジェクトの着地点を作ったり、他社との調整であったり、スケジュール管理であったり、そうした役割もシステム開発には欠かせません。
それぞれ得意・不得意があるのでいろんな役割の人がいていいと思います。
ただし、おっしゃる通りコードの読めない人、システムの仕組みが理解できていないSEが、私の周りでも見受けられます。
そういった人に、技術的な判断であったり、お客様の望む機能であったりを提供することは、難しいと思います。
理想かもしれませんが、コードも書けるべきというのは、その通りだと思います。
なんだか私と境遇が似ている気がして長々とコメントしてしまいました。
周りに流されずに、技術を学んで、楽しんで仕事をしていきたいですね。

hmさんへ

> 自分のリソースの9割を社内調整に費やし、何かを生み出す時間はほぼ全て他の人間に任せきり。
> 会社がなくなったらその人に何が残るのだろう。タイピングしかできないじゃないか。
> 管理者という名の糸電話になってしまう。

ここまで書いてあって「筆者は調整という業務自体は否定していない」と読めるとは。
しかもどのコメントの人もコード書けないと断定できる人はいないのにプログラムが書けないとエンジニアと断定w
コードは読めても日本語を読むのは苦手なんですね^^

通りすがりのエンジニア

プログラミングとかマネジメントどっちが大事というよりも、企業で働く人として、各工程の基礎はある程度知っておくことが大切だと思います。IT企業は変に切り分けがはっきりしすぎているために、企業としての成熟度が低いと思います。
さらに最近はコードさえかければどんなことをしてもよいという悪しきエンジニア像が流行っていて恥ずかしいです。そんな人は、本当に一握りのはずです。変に対立するのではなく、歩み寄ることがIT企業目指すことのはずなのに

anonymousSE

ここで書かれている対象となってる人物は、コードの受入れ検査をする立場のエンジニア(そしてその人には肩書きがついてて管理する立場にある)ですよね。
書き手の焦燥感から対象が拡大解釈して受け取れる文面になってるもんで「スティーブ・ジョブズもコード書けないとダメなのかよ!」まで発展するような感じでとられちゃうのはちょっと残念。

それでも、受入するエンジニアが納品物のコードがわかんないのは最悪ですよ。それの何が悪いんだ?って本気で思ってる人は理解しがたいです。
純日本文学の原稿取りに行く編集者がイラン人で日本語がまったく読めない。面白いかどうかをテスト仕様書で報告しろって言ってるようなもんだと思います。

まぁ、コード読めない受入エンジニアは顔真っ赤にしてここにコメントしてくると思うよ。
「ステップ数(笑)」で納品検査してるような人ね。

gomo

多分君に自分の頭で考えて欲しくて、「これはこうだから、こうした方がいいんじゃない?」と答えを出さずに、「どうしてこういう選択をしたのか?」をしつこく聞いてきてるんじゃないかな。

この方がいいよって教えるのは簡単だけど、そういうのは応用が効かない。自分で考えて、考えて出した答えは次応用が効くんだよね。

robinson

何が目的なのかわかってないやつ多い。
否定するだけで対案出さないやつ多い。
何をどうすればお客さんに満足してもらい納期を守れるかを考え、提案できる人少ない。
「なんでできないんだよ」楽
「これはこうすればできるんじゃないか?」能力必要
「それはできません」楽
「それは時間がかかりますが、この方法なら同じようなことができますよ」能力必要

moon

確かに、手法として口先で「詰める」マネジメントを実践している方はいらっしゃいます。
そういう人をはたから見ていると、問題の把握と解決をプレイヤーに依存しているので、
結局のところプロジェクトの生命線を外部に依存してしまっている状態です。
常にプロジェクトには安定感ないし、可哀想といえば可哀想だと思います。

マネジメントに特化した人間であっても、常に余裕のある納期交渉ができるとか、
優秀なメンバーが集まるといったスキルがあれば、何の問題もないと思います。
ただ、これができる人間は皆無なので、常にプロジェクトは火の車でエンジニアに皺寄せがくる、
という風景が日常化しているのだと思います。

世のマネージャの方々は、こういった不満が鬱積しているのを認識して、エンジニアとうまくやれるよう工夫して欲しいです。

まぁ、一番悪いのは土方システムを持ち込んだ経営の連中だと思いますが。
まともなエンジニアリングができる仕組みが整っているとは、到底思えない。

st

うちの場合は、
所謂プログラミングを全く知らない社長が営業をやっていて、
同様の「詰める」マネジメントを押し付けられています。
プロマネはそんな社長に嫌気がさして昨年退職…
組織運営としては酷い有様ですが、零細企業にはこんな具合で
開発しているところも少なくないのでは。

↑のmoonさんの仰っている通り、現在は工程も手法も全てプログラマ任せ。
確かに、チームというよりは外注的な扱いに近いですね。
そして、開発環境はいくら自分で改善できても、経営者までは変えようが無いという…
来月、もう少し自分を伸ばせそうなところに転職する予定です。

ちゃお。

申し訳ないですが、愚痴にしか聞こえません。
私はコーダーもマネージャーも経験した事がありますが、
管理する人間がその方が速いからとテストコードを書くなんて事をしだしたら役割もへったくれもなくなりますよね。
あなたがそのマネージャーを無視して直接取引先に納品物を届けるようなもんです。
なぜ遅れてるのか、と詰めるだけの人間は要らない、ととれますが、まず遅れてる事実があるのなら、何を言おうが言い訳です。
マネージャーは何も仕事を遅らせていませんが、貴方が遅れていることを相手に説明して謝って、時には契約金を減らしたりして赤字を生みながら対応する事になります。

名選手と名監督は似て非なるものです。Junitを使ってテストしているのならば、そのままレポートツールと連携させてグラフ化するだけなのに、相手にコードを読ませる理由がわかりません。

通りすがり

同じ仕事をしても同じ価値観を得られる訳ではないので、否定する人が居るのは当たり前ですが、それを匿名で上から目線で言ってると人の家でトイレ借りて、マジックで落書きしてるくらい失礼ですよね……。あ、僕もか。

コードレビュー、大事ですよね……「動けばいいんだよ」なんて言ってる人の意味が判りません。
昔、24時間に一度、ログを評価するためのソースを書いている人が、ログを評価するために24時間要するソースを自信満々で発表して、どうして怒られてるのか判らない顔をしていた事を思い出してしまいます。
それは、僕の5年先輩で、僕より学歴も良く、仕事が出来ると周囲に言われている人でした。

動けばいいんだよ、という人は、きっと良い環境で簡単な処理を動かしているか、自分で考えてコード書かない、いわゆるコーダーなのだろうなぁ、と思います。

ただ、目的(仕事を終える)を達成するためにはコードの良し悪しなんて無意味、いや、いっそ悪い方が修正案件をいただけるから良い、なんて嫌な話も聞こえてきますが。目的(お客様の満足と自社の利益)を達成するためにはレビューも必要だと思います。他のも、ないがしろにしてはいけませんが

yhm96625

コードの読めないマネージャーとか都市伝説だろと言ってみるテスト

Dekosuke

コンテキスト分からないので的はずれかもしれませんが、
「なんで○○なの?」って質問すること自体が悪いことには思えませんね・・・

現在コメントは受け付けておりません。