いろいろな会社の募集を見て気付いたことがある。ソフトの設計までしかしない技術系社員の募集に、実装経験(例えば「C言語での開発経験」)が入っていることが多いのだ(ほぼ100%)※。
※実際に、「設計」の職種に特定言語での開発経験を条件として出していた大きなメーカーに聞いたら、本当に設計までしかせず、実装は外注するという答えだった。もしかして、特定言語での開発経験と言っても、その言語を使ったプロジェクトに携わったことがあるだけで良くて、自分で実装していなくてもOKなのだろうか??
以前書いた、設計までなのに「開発」と呼ぶことと合わせてどうしてかと思っていたのだが、 どうも、「プログラマーの上位はSE(= 設計までの人)」という、日本で一般的な階層構造(→ 参照: 中央辺りに多重下請け構造)を想定しているからのような気がして来た。
その他に、大企業だと、系列に実装を行う子会社(実際には、更に孫請けが居るかも知れない・・・)があって、そこに発注することも多い。これは、経済的な理由なのかそこに子会社があるから(全く本末転倒だが、お偉いさんの命令とか管理職の忖度があるのかもね・・・)なのか分からないが、そういう現実はある。上に書いたメーカーもそういう回答だった。
日本では、大手IT企業は設計までしかせず、実装や試験などの本当に手を動かす仕事は下請けに外注する(良く言えば「ソフト版ファブレスメーカー」みたいなものか)。これが「上位は設計まで」という意識になっている。あるいは、(中位・下位の)実装も行うIT企業でも、経験の少ない社員は下積み的に実装をし、経験を積むと出世してSEのような設計までの人になる。ここでも「上位は設計まで」になっている。
それから、下請け会社も何段階にも階層化されていて、中抜きするだけのところも多い。一番最後(底辺)は、安い(ここに来るまでに安くなってしまった)お金と短い(ここに来るまでに短くなってしまった)期間で(→ 参照: 中間マージンについての例)実装させられる「どこかの」プログラマーとかコーダー(自分たちで「IT土方」と卑称してしまっている)なのだが、ここまで来ると伝言ゲームのようになっていて、本来の仕様(特に意図)はまともに伝わらないだろうし、実装上の疑問や確認事項があっても、まともに回答されない(できない)のではないか。そもそも、最底辺の人は、指示された機能の実装(コーディング)だけをし、仕様や設計の意図なんて全く気にしないだろう(そんなお金も時間ももらっていないし、気にして意見しても無駄だから・・・)。
募集条件の話に戻ると、設計(までの)技術者に求められるのは「いい物(製品・システム)を考える(設計する)」ことだから、その業務なりプロジェクトで使うと想定される言語の実装経験など不要なはずだ。まあ、実装経験があるということは「プログラミングの勘」がある(だろう)から、設計に役立つことは多いが、なまじっか詳しいために、外注に余計な指示をして(、それが必須条件のようになって)逆効果になる場合も多い。そうでなく、一番最初の考え(アイデア・構想)や仕様検討や設計のセンスなり経験を求めればいいはずなのだが、証明も確認もなかなかできない※。例えば、条件に「画期的なアイデアを出せる方」などと書いても難しいだろう(たまに、ちょっと危ない会社が書いているがｗ)。結局、求人側にIT業界の階層構造が染み付いていて、「ある程度の実装経験があれば(その「上位」の)設計もちゃんとできるだろう」といった考えで、そういう条件しか出せないのかも知れない(というか、単に前例に倣っただけかもｗ)。
※日本にはいろいろなIT関連の資格試験はあるが、条件に指定する会社は少なく、余り重視されていないようだ。それは、そういう資格に実効性がないのがバレているからかも知れないｗ そうであれば、代わりに今までの経験や実績を見ればいいと思うが、特に非IT系企業では、経歴とか作例を見ても理解・評価できないのかも知れない。
それに、以前も書いたが、設計の後を外注して いい/まともなものができる可能性は低い。いくら良く考えて仕様・設計を作っても漏れ(「想定外」ってやつ)や誤りはあるし、逆に、それを防ごうとして過剰になることもある。基本的な仕様や設計が誤っていたらやり直しになるから、時間とお金の無駄だ(予算超過を心配して、さまざまな無理を通す場合もある)。過剰な設計も無駄だ。そもそも、外注のプログラマーがそれを読んで適切に実装できるほど詳細な「設計書」を書くのなら、自分で実装した方が速いだろう。USなどの有名企業が日本のようなやり方をしていないのが、証拠だ(実際に見た訳ではないが、何かの記事で読んだ(→ 先日、Amazonの例を紹介した))。
脱線: 大好きな音楽に例えれば、「天才的な作曲家は自分で譜面を書かないし、弾くこともない」みたいなものだろうか? 音符を書くなんて下等・面倒なことは弟子に任せて、ひたすら曲想を語って書かせる? 曲作りの途中でも完成しても、試奏もせず(というのは、脳内に生まれた段階で完璧なので)、専属のピアニストに弾かせて記譜誤りを確認する程度? なんか、これはこれで成り立つ気もするぞｗ (映画「アマデウス」の「レクイエム」のシーンより想像) でもまあ、すべてのソフト技術者(設計までの人)が天才ではないし、すべてのプログラマーが天才設計者の意図を正確に汲んで的確に実装できる訳でもないから、やっぱり無理なのだ。
こうして、技術者なのに、なぜか日々ワープロやスプレッドシートなどで(それが本当に必要なのかすら良く分からない)何かの書類を書き続け、顧客(上司・部下も?)対応や外注管理でひたすらイライラ・消耗するだけのつまらない仕事に就くことになり、更に、大金を投じても動かない・使えないシステム(例: どこかのペイ: 書いたあとで、9月で終わるというニュースが・・・ 合掌)が増えてしまうのだ。いろいろもったいない。。。 この良くない構造は今まで何十年も続いて来て、いい加減得策でないのは明らかだと思うのだが、いったいいつまで続くのだろうか??
まあ、何もかもうまく行かなかった訳ではなかったから、前例(成功体験)を踏襲して続いているのだろうが、きっと、無駄な費用や顧客の減少(移動)や多くの人間破壊・崩壊などが隠れているはずだ。それがGAFAの台頭とか、近頃問題とされている日本の低い生産性にも関係しているかも知れないね(ここはテキトーｗ)。
それではどうしたらいいかを考えると、以前も書いたように、全部自社で作る(実装する)べきだとは言わないが、日本的階層構造でフェーズごとに組織や担当を(あるいは、組織ごとにフェーズや担当を)きっちり区切るのを止めるといいのではないか。例えば試作(コンセプトを実証するもの)は内製して充分に練り、仕上げ(本物(製品)にする)を外注するとか、社員と外注の実装する人たちが渾然一体となって作る(今もSESであるだろうが、単に同じ場所に居るだけで、やっぱり線引きされていてうまくなさそうな感じだ)とかがいいように思う。オープンソースプロジェクトのように、社員も外注の人もみんなで分担してプログラムを書く・使う・問題を報告して修正・改良するってのがいいかも知れない(余りにも牧歌的だと言われそうだが・・・)。まあ、少なくとも僕は、そういうふうに仕事がしたい。
naoki: 2019-08-01 18:46
9月で
終わ
る
www
れんと: 2019-08-01 18:48
●(期待通り、)見付けて下さいましたかっ!ｗ