つくりかた兼人録

中身がどうなってるのか分からないと使えないでしょ

「どうしてこうなったのか？」

「詳細は分かりません」

「中はどうなってるの？」

「いや、僕らが中身を作ったわけじゃないので」

「は？　中がどうなってるのか分からないのに使いようがないでしょ」

　少し前のネット記事で、今時の新人はこんなんだ、というのを取り上げていました。

　まあプログラムの現場で、不具合があった時に原因を調べるわけですが、中々進まない所へ熟練の先達が状況を確認しに来た時の話のようです。

　プログラムの現場である事くらいしか説明されていませんでしたが、「信じられないような次世代の感覚」として取り上げられていました。

　まあ仕事が終わっていないのに定時で帰る、とかの記事が話題になっていたのでその系列で取り上げられたのでしょうね。

　しかし記事見た人の印象ってどうだったんでしょうね。

　プログラムが分からないと、上記会話のどこが問題で、何を指摘されているのかサッパリ分からないのだと思います。

　実際問題かと問われれば、僕はこの新人に問題は無いのだと思います。

　僕の主観には違いないですが、この問題を提示している人はかなり古い人なのではないかと思いますね。

　年代ではなく、未だに90年代の一人でシステムを作っていた頃の体勢のまま現在に至った人なのではないかと思います。

　実際昔はその風潮ありました。

　ライブラリの中身も理解した上でプログラムを組まなければならない。

　それに間違いはありません。

　というより当たり前。

　しかし今のプロジェクト規模は当時のシステムとは比べ物にならないのですね。

　ゲームとはいえ、

　システム班、プレイヤー班、エネミー班、ＵＩ班、パラメーター班、サーバー班と部署だけでも結構な数で、

　それぞれの方針によってプログラムされ、個別にコンプリートするのかと言えばそんな事はなく、他部署が作ったプログラムを使用する場面も多い。

　特にＵＩ(メニューとかHP表示とか)なんてのはプレイヤーのパラメータも扱えば、敵のパラメータも扱う。

　全部の部署に片足突っ込んでいると言っていい。

　それにプログラムと言うのは「数か月前作った」なんてものではなく、何年もその会社が使っているのが常です。

　そんな中に突然入って、中身を全部理解して使えなんてのは無茶もいいとこ。

　ベテランが会社や部署を変わる事もありますが、一年かかってもそんな事はできません。

　でもそれは昔から言われている事で、だから「構造化」とか「オブジェクト指向」とか言う効率化を図る概念も多く研究されているんですね。

　要するにプログラムというのはインアウト、

　つまり「何を入力すれば」「どんな結果が返るのか」さえ知っていれば中身がどうなっているのかなど知る必要はない。

　もちろん知れるなら知ればいい。その方が安心です。

　それをしない事はルール違反ではないし、想定外の使用で問題が起きてもそれはマニュアルの不備です。

　実際にはインターフェイスマニュアルが完備されている現場などなく、古い、抜けてる、存在しない。よくある事です。

　そんな中でどう立ち回って、仕事を回していくかが難しいのであって、未だ多くの人間が頭を悩ませています。

　それを新人が中を把握しなかったからダメだで済ませられるんならそんな楽な事はない。

　しかし中にはその会社に10年いるとか、そもそも元のシステムを作った本人だとかで、内部構造を全て知ってる者もいたりする。

　自分で作ったなら当たり前だし、マニュアルが用意されてないならその人間の落ち度でしかない。

　冒頭の人がそうかは分からないですが、ネット記事だけだと詳細が分からないのですから。

　結局冒頭の記事が何を伝えたいのかは全く分からなかったですね。