がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

どうしたものやら…

先に。「答えの出ていない問い」なので、そんなに歯切れのよい結論とかありませんので念のため。


元ネタはこちら。
突如発表された『拡散性ミリオンアーサー』 サービス終了の真相を訊く
http://app.famitsu.com/20141226_479007/


色々と「難しいなぁ」と、いろんな角度から思ったので。
まだ考察中のネタなんで悩みながら、一端、文章化してみようかなぁ、っと。
とりあえず、重要な箇所はこの辺。

もともと『拡散性』を配信する前後で、とあるどうしようもない事情からコアスタッフが抜けたんです。

コアスタッフが抜けてしまったがゆえに、核となるプログラム部分がブラックボックスのようなものになってしまい、それを手探り状態で更新していたんです。それをなんとか打破しようと考え、運営1年後のタイミングでいまの運営会社に移管をしました。そのタイミングでプログラムを1から作り直そうという話もあったんですが、通常の運営をしながら並行して新規でプログラムを作るのは思った以上の難易度で、想定していた作りにはなりませんでした。結果、運営のしやすさはさほど変わらない状態で、新しい仕組みを取り入れることも難しくなっていました。


割とあちこちで見受けられる状況な上に、あんまりにも「色々な可能性」があって、その色々毎に考察ポイントがあったりするもんで、この文章を書くに至ってみたり。
とりあえず雑に要約すると
・コアプログラマが抜けた
・その人以外では「核の部分」に手を出せない
・リメイクしんどい
・故にサービス終了
ってな感じかなぁ、っと。


ん…多分「よくある論調」で持ってくると「属人性ヨクナイ!」って話になるんだろうと思うんだけど、正直、そんなに簡単な問題じゃない可能性が想起されてみたり。
簡単な可能性としては
・作りが超キタナくて
・作った本人以外手が出ない*1ようなとっちらかりっぷり
のブツなのがあって。
…それにしてもなお
・ンな汚いコード書くな
以外に
・「とっちらかってること」を、発注側とかディレクターとかプロデューサとかがどうやって把握捕捉するか?
って問題が横たわってみたり。


少し先に横道にそれると「コアプログラマは、他の人に技術継承をしなかったんだろうか?」って疑問はまぁ出てきて。
・当人にその気がない
・周囲にその気がない
・工数的に無理ぽだった
あたりの可能性があって、それぞれにそれぞれの突っ込み所が。
「当人にその気がない」場合、当人に意識改革をってのもあるんだけど同じくらいに「ちゃんと周囲で仕切ってる人間が継承を促す」ってのも重要だし。
「周囲にその気が無い」については場合によっては「首を切ってでも、その気のある人間をある程度揃える」重要性。
「工数的に無理」については、マネジメント失敗してる、としか。


で…多分一番憂慮すべき可能性って「難易度が高くて他の人に手が出ない」場合。
何を以て難易度を高いとするかってのは勿論あるんだけど。


恐らく、ビジネスにある程度さとい人なら、こう考えると思う。
「結局の所"お仕事"でコードを組んでいる以上、周囲が付いてこれないレベルのものを自己満足で組んでいるのは、結果的にビジネスに悪影響を与えるのだから、ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを納品すべきである」。
これについては正直「程度問題」としか思えないし、どちらかというと(今の)おいちゃんはこの見解には基本、否定的。


わかりやすく、極端な一例を。
・わからない人がいるからオートマトンは使わないでくれ
・わからない人がいるからオブジェクト指向プログラミング(クラス)を使わないでくれ
・わからない人がいるから共通関数は作らないでくれ
・わからない人がいるから配列は使わないでくれ
困った事に「全部実話」です。
有難い事に、幾つかは伝聞ですが。


結局の所。
技術は「それがないと困っているところで編み出された技法」なので。無論「乱用は厳に慎み、忌むべき」ではあるにしても、最低限を「適切に使う」場合において、技術ってのは「非常に重要なもの」ではあるわけです。
つまり「技術を使うな」って事は「出来ない事が発生する」や「非常に非効率なやり方になる」事を意味する訳なのでございます。


勿論「とはいえ、他の人が扱えなくなるのは困る」ってのが天秤の片側に乗ってるんで、そう軽々に「学べ」で片付くもんじゃねぇだろうなぁ、ってのは、重々承知ではあるんですがね。
ただ「ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを」って発言は、割と簡単に「水が低きに流れるが如く」駄目な方に行きやすく、結果的に「よりしゃれにならんブツが仕上がってくる可能性」が十分に想起される上に「それを抑止する方法が今ひとつ、明確になってない」んですね。


無論それで「学習させているうちにビジネスが潰れたら意味あんめ?」ってのはあるのですが。


まぁそこから考えると。
・可能な限り優秀なメンターを若干名
・適度に熟練度があり、且つ十分な向上心がある一般職人をある程度
・溢れんばかりの学習意欲に満ちあふれた見習いを、一般職人が扱える程度の数
ってな取りそろえを「如何に全力で取りそろえるか」って話になるのですが…まぁ「熟練職人ってどこにいるんですか? http://www.mars.dti.ne.jp/~hirok/sekai/bou/bou387.html 」って話になるんですけどねぇ…えぇ…でも、それ以外に良い方法思い浮かばねぇのよ正直。


ただ。
その辺前提で考えると。どうにも「ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを」って発言って。
勿論、真摯に捕らえるのであれば十分に「一考以上の価値がある」はずなんだけど、現実的には「現状維持と怠惰となまけの言い訳にしかならない可能性が高い」と考えられる状況が多すぎる訳で。


そうすると。
無論、書く側に「ちゃんと教育する胆力を要求する」前提ではあるにしても&加減ってのはあるにしても、基本「上にあわせる」方が、最終的に獲られるモノが多いんじゃねぇかなぁ? とか思う訳なんですよ。
その辺まで全部考察した後で改めて読むと、色々と、考えてしまう訳なんですねぇ。

コアスタッフが抜けてしまったがゆえに、核となるプログラム部分がブラックボックスのようなものになってしまい、それを手探り状態で更新していたんです。それをなんとか打破しようと考え、運営1年後のタイミングでいまの運営会社に移管をしました。そのタイミングでプログラムを1から作り直そうという話もあったんですが、通常の運営をしながら並行して新規でプログラムを作るのは思った以上の難易度で、想定していた作りにはなりませんでした。結果、運営のしやすさはさほど変わらない状態で、新しい仕組みを取り入れることも難しくなっていました。

何故にそこが「ブラックボックスになってしまったのかなぁ?」と。


現場の下っ端も中堅所も現場の技術仕切ってる人もプロジェクトをディレクションしている人もマネジメントしている人もプロデュースしている人も発注している人も。
割と真剣に考えておかないと、結構「激痛が走る」所なんじゃないかなぁ? とか思うわけなんですね。


などという雑文を、つれづれと。

*1:下手したら、作った本人「でさえ」手が出ない