無意識のしゅんたっく

2014年7月29日

バックエンドとフロントエンドの開発における考え方の違い

私がメインとして携わっている業務はソーシャルゲームのシステム開発（いわゆるバックエンド）ですが、つい最近、ゲームの演出というか、アニメーション・キャラクターの動き方・スコア表示など、いわゆるフロントエンドをガッツリ作り込む機会がありました。

いろいろ感じたのですが、これは普段の自分がやっている開発内容よりもずっとキツいなあと感じたので報告します。

なお、ここでいうフロントエンドとはゲーム演出に関わるアクションや見せ方をいい、Web製作等でよく言われるCSS・フロントサイドJSとは別です。

ゲームのシステム開発に携わる2つの職種

ゲームとはいえ、これもソフトウェアであり、システムです。ゲームを作るということは、ソフトウェア開発・システム開発をするということでもあります。

このシステム開発に携わる職種は、大きく分けて2つあります。一つは主にロジックやデータの管理・大量アクセス大量更新をどう捌くかといったサーバーサイドを担当するバックエンド開発者、もう一つは主に演出・ユーザーへの見せ方を担当するフロントエンド開発者です。（もちろん製品として完成させるにはデザイナーやプロジェクトマネージャーや営業も関わってきますが、ここでは開発者だけを考えます）

ロジックから演出まで含めて一つのゲームシステムです。なぜ職種が分かれているのでしょうか？それは、システムのロジックと演出で考え方が大きく異なるからだと、私は考えました。その考え方の違いによって、開発者の得手不得手が分かれてくるからです。

サーバーサイドの開発と演出の制作における考え方の違い

バックエンド開発とフロントエンド開発における最も大きな違いは、「終わりがある」か、「終わりにする」かの違いだと思います。あるいは、フロントエンド開発は、開発者が納得したときが終わりなのだと感じました。

普段、仕様を元に仕様を満たすシステムを構成し、仕様を満たすプログラムを実装しているバックエンド開発者は、仕様を満たしていることが確認できれば作業は完了です。もちろん仕様通り作るというのは非常に難しい作業で、それが仕様通りできていることを確認するのも非常に難しい作業です。さらに非機能要件として、秒間最大○アクセスに耐えられる等の仕様もあります。しかし、目指すべき目標はあります。これが「終わりがある」ということです。

一方でフロントエンド開発者の場合はどうでしょうか？

たとえばバイクレーシングゲームを作っているとしましょう。仕様ではAボタン入力でバイクを加速させ、方向ボタンでバイクの重心を変え方向転換やウイリー操作ができるとしましょう。フロントエンドの実装としては、Aボタン入力を受け付けてバイクの動きあるいはタイヤの回転を加速させ、定められたトップスピードに達したら加速を止めるといったことが考えられます。バックエンドの考え方でいけば、加速に関してはこれで仕様を満たしているので実装完了です。

ところが演出を担当するフロントエンド開発者の場合はそうはいきません。車体の重量や道の勾配、風などを考慮して加速を変化させなければなりません。プレイしてみて気持ちよく加速できるか、エンジン音はどうするかなど、突き詰めればどこまでもキリがありません。さらに方向ボタンも実装したら、合わせて加速もチューニングしなければなりません。きりがないけど納期はあります。これが「終わりにする」あるいは納得したときが終わりということです。あるいは監修がいれば、その人が納得するまで終えることはできません。

ゲームのフロントエンド開発をやってみた感想

まず、根性である程度まではやり切りました。根性です。

ただどうしても好きにはなれませんでした。この、終わりが無い感じ、芸術性を突き詰める感じ、短気で大雑把な自分には向いていないようです。

その一方で、見える目標に向かって突き進むバックエンド開発は、すごく自分に向いていると再度実感した良い機会でもありました。前節では仕様さえ満たせばOKのようなことを書きましたが、そんな生易しいものではありません。職人技と言われるような、知識・経験・判断力が中心の世界です。この道を極めて行くのは、非常に難しいです。やればやるほど実感します。尊敬する先輩方の背中は、自分の実力が身に付くほど離れていくような錯覚さえします。それでもどちらを極めたいかと言われれば、迷い無くこちらを選ぶでしょう。

雑なまとめ

時間をかけてもうまく書けないのでまとめて公開しちゃう。

まあどっちも大変だよね、と。

2014年7月15日

課長の教科書

普段ビジネス書ってほとんど読まないんだけど、というかそもそも本をあまり読まないんだけど、書店で気になって読んだ本があったので紹介してみようと思う。ロジカルに分かりやすく書くつもりはないので、すいません…。

タイトルは、新版はじめての課長の教科書

世の中のビジネス書はほとんど次の二種類に分類できて、平社員がどうやって成果を上げるか、経営者がどのように事業を運営していくかのどちらかになると思う。

この本はそのどちらでもなくて、いわゆる中間管理職である、課長がどうやって生きていけば良いかが書かれていた。

普段経験しないことが書かれていて、課長たちの仕事を経験できた気がしてとても面白かった。

まず、課長とはなにかという話。

この話の中で面白かったのは、課長は平社員ではなく経営者・管理職だが、その中では最下位であるという話。
また、より上位の管理職と異なり、普段は現場の社員と同じ部屋にいるということ。
その分、部長よりも現場に近く、より専門性も高く、担当事業に対する知識・情報量も多い。
係長以下とは異なり、担当プロジェクトを持ち、予算管理をするようになること。

次のテーマで語られていたのは、課長の仕事で起こる問題とそれをどうやってコントロールするかという話。

課長には担当プロジェクトの予算を決め、一度決めたらそれを100%達成しなければならいという話は、学生の頃だったらそんな理不尽なと思っただろうが、今ならそれは達成しなければならないよねと納得できる。
また、達成できないと見込まれた場合、部長にすぐに原因と対策をセットで報告しなkレバならないというのも、まあ当然だよねという感じ。
ただ、これ本当に厳しい仕事ですよね……。

また、問題社員をどうするかという話。
会社の備品を盗んだり、無断欠勤を繰り返すような社員をどうするか。これは法的にNGなので、堂々と法務や人事に報告すればよい。そうだね。

最も印象に残っているのは、パフォーマンスが極端に低い社員（人事の世界でCクラス社員と呼ばれるらしい）をどうするかという話。
結論から言えば、この社員がパフォーマンスを出せないのは課長に責任がある。Cクラス社員でもできる仕事を見繕ってやるべきだ。また他の社員が見捨てても、最後まで課長は見捨ててはいけない。
パフォーマンスの低い社員は解雇すれば良いのではないかという意見も出るだろうが、それは違う。働き蟻と怠け蟻の割合は、怠け蟻を群れから取り除いても別の蟻が怠け蟻となり、割合は常に一定であるのと似ていて、パフォーマンスの低い社員を組織から取り除いても、いずれ別の社員が怠けるようになる。
また、組織全体のパフォーマンスは最もパフォーマンスの低い社員がボトルネックとなることが多い。そのため、組織を強くするためにも、課長はパフォーマンスの低い社員に向き合わなければならない。
また、簡単に解雇してしまえば、後味の悪いことになるのは明白である。

この本の中で何度も語られていたのは、「ほめる」の反対は、「しかる」ではなく「無視する」ことということ。
部下が成功・失敗したとしても、ほめたりしかったりせず、無視する・評価しないことは良くない。

他のビジネス書やブログなどでも良く言われてることだけど、ほめるときは必ず人前で、ほめる対象の人だけをほめる。
逆にしかるときは、二人でこっそり。叱った後はすぐに話題を切り替え、次に期待していることを伝える。

社内政治をどうすれば良いかという話。

政敵が現れれば、政敵のことを政敵のいないところで褒めて回れば良い。
相手はたいがいそれで挫けてしまうし、それでも敵対してくるような相手は、社内でも信頼されないだろう。

また、自分の出世が課長止まりの可能性も考えておくこと。
転職やヘッドハントされる場合の失敗しないようにする方法、起業も考えてみること等、面白い話題は他にもたくさんあった。

……課長って、大変だね。

2014年6月28日

今年でWebエンジニア8年目

今までの自分を振り返ってみる。ダメだった自分、少しだけ変われた自分を見つめ直してみる休日。

Webエンジニアとして初めの2年間くらいは、本当に何も出来なかった。

PHPのforeachが意味不明ってレベル。
RDBの正規化なんて、単語すら知らなかった。

分からないからって、何かを自発的に勉強したこともなかった。
そもそも、自分から勉強しようという発想がなかった。

その状態が2年くらい続いて、諦めた。

たまたま出会った経済産業省の課長補佐の方がとてもかっこ良くて、国家公務員に憧れて勉強を始めた。試験は落ちた。
バイトしなきゃお金がなくなるから、またインターネット関連のアルバイトを始めた。

また、Webエンジニアに戻った。

旅行代理店でECサイトを開発したり、個人事業で受託案件をやって騙されてみたり、でも技術者としては少し成長してみたり…
大学でも計算機科学の勉強をして、前よりもいろんなことが分かるようになったし、できるようになった。

でも、インターネットの仕事が楽しいと感じたことはなかった。

インターネットとは全く別の業界でフルタイムの仕事を探そうとしてみたけど、やりたいことなんて見つからなかった。

Webエンジニアになって5年目、大学院に進学した。

初めてインターネットの仕事が楽しいと思えることがあった。

たまたま参加したインターンシップで、とあるサービスの1つの機能を実装してリリースした。
リリースするとユーザがすぐにその機能を利用し始め、すぐにユーザーのフィードバックを得られた。
反応の早さに驚いた。これを自分が作ったんだなと、感動した。

また別の会社でWebエンジニアになった。そこでは複数のサービスを自分がエンジニアリーダーとなって開発した。楽しかったし、月給も今より多くて、すごく自信もついた。
ただ、自分の技術力にも限界を感じたし、自分が技術的に伸び悩んでるのも実感した。

その後また別の会社に入り、運用中のシステムのリプレイスやセキュリティ向上などをやるようになった。
ここでテスト駆動開発者の和田卓人氏をはじめ、尊敬するエンジニアという存在に出会った。10年後の自分はこの人たちのレベルまで到達できるのだろうか…。

7年目の途中で、自分が初めてインターネットの仕事が楽しいと思えた会社に、フルタイムのエンジニアとして正式に入社した。

システム開発は、今でもやっぱり難しいけど、7年もやれば出来ることがかなり増えてきた。
最近はすごく余裕もある。大量参照・大量更新が発生するようなサービスをどうさばくか、自分なりにノウハウもたまってきた。
新しい技術を勉強したり、ユーザーのための開発・リリースをするのがすごく充実した毎日。

今後のキャリアがどうなるかは分からないけど、また明日にでもゆっくり考えてみようかな。そんな休日。

2014年3月15日

技術者は誠実でなきゃいけない

最近、会社の技術者の一人として、
会社の人事から学生に紹介されることが増えてきました。

ある学生に会ったときに、ついキツめに注意をしてしまったので、
自戒の意味も込めて記録しておきます。

こんな感じで質問されました。

学生「あなたの所属するチームでは、何か新しい技術を使った開発に挑戦していますか？」
学生「例えば、アジャイルとかどうですか？いろいろ便利なツールとかあると思うんですけど、使ってますか？」

ん？ツール？

よく分かんなかったので、質問に質問で返してみました。

自分「アジャイルのツールって、どういう意味ですか？例えば何がありますか？」

学生「まあよく分からないんですけど、いろいろあるって聞いたことあります。ごにょごにょ」

自分「（話なげーな。）あ、すいません。アジャイルって何か分かってますか？」

：
：

以下やりとり（からの説教）が続くんですが、まあ、よく分からないことを知ったかぶりして話してるようなんですよね、どうやら。

知らないことがあるのは問題じゃないと思うんですよ。

知らないことを知らないと言う誠実さ、
分からないことを分からないと言う勇気、
そういうのがだいじなんじゃないかなって思います。

うちの会社には親切で面倒見がよく、技術力の高い技術者がたくさんいます。
教えるの、大好きです。

だから、知らないことは先輩がどんどん教えてくれます。
きっと他の会社もそうだと思います。

ただ、「できます！」「知ってます！」って言われちゃうと、
教えようがない。

そこまでは、百歩譲りましょう。

でも、それでは仕事も遅くなるし、
そもそも終わらないかもしれないですよね。

結局、「言ってること」よりも「成果」で評価されるので、
「できるって言うけど、その割に仕事遅いし、タスク振りにくいなあ」
ってなります。

結果的に、こいつには大きな仕事は任せられないわってなります。

なので、知ったかぶりしたり、ごまかしたり、嘘をついたりすることは、
技術者は絶対にやってはいけないことだと思います。
（自分はこれを科学者（大学院生）だった頃にやって、大きな失敗をしました）

技術者は、誠実でなきゃいけないんです。

誠実じゃなきゃ、信用されないんです。
（もちろん技術力も必要）

信用されなきゃ、面白い仕事が失われていきます。

ここまでは開発者の中での話でしたが、
ビジネスの人と話すときも同じことが言えると思います。

納期を守らなかったり、バグが残ってたり、
成果物（リリース）に必要なファイルが足りないまま出荷（リリース）されたり…

こんなことが続いたら、仕事も頼めなくなるし、
「できます」って言っても信用してもらえないと思うんですよね。

信用してもらった方がいい仕事がしやすいですよね。

ってことで俺も、誠実に、正直に生きていこうと思います。

2014年3月12日

納得して仕事したい

俺はサービス業の技術者です。

作ってるのはWebサービス（ソーシャルゲーム）なんだけど、
開発の内容を、納得してやるのとそうでないのとで生産性が全然違うなーと。

どんなものを開発するかを考えるのは、技術者の仕事じゃないです。

だけどやっぱ、作ったものが売れなかったらすげーガッカリする（´・ω・｀）
だから価値のある、売れるものをつくりたい。

売れないって思って作ってたら、そりゃモチベーションも下がりますわ。

これなら面白くなると信じて開発してたら自然と楽しくなるし、
少しでも早く企画してくれた人に動くところを見せたくなる。
少しでも早くお客さんに製品を届けたいと思う。

どんな企画でも、やろうと思えば何だって実現できるんです。
でも、何でもやればいいってもんじゃない。コストもかかる。

それがお客様のためにならない、または利益につながらないと思えば、
俺はそれをやりたいとは思えないんです。

だから、なんでそれをやるのか訊いてます。必ず。

ビジネス専門職の人たちだって、全力で次のアクションを考えてくれてる。
それはきっと、なんらかの仮説・理由・根拠の上に導きだされたアクションだと信じてます。

だから、何かをはじめようという時には、その理由を教えてほしいんです。
背景から説明してほしいんです。

納得したいんです。

次のアクションはこれをやります！じゃなく。

納得して進みたいんです。

なんでそれをやるか納得して、
これなら絶対に面白い！これなら売れるって信じられるようになって初めて、
プランを全力で実現したいって思えるようになるんです。自分の場合。

オレは「納得」したいだけだ！
「納得」は全てに優先するぜッ！！
でないとオレは「前」へ進めねぇッ！
「どこへ」も！「未来」への道も！探す事は出来ねえッ！！

- ジャイロ・ツェペリ『スティール・ボール・ラン』より

納得できなかったら口出しもするけど、
納得したら、あとはやるだけです。
実現するのは任せてください。全力でやります。

STEEL BALL RUN vol.8―ジョジョの奇妙な冒険Part7 (8) (ジャンプコミックス) より

2014年1月23日

毎日こつこつ勉強してるよ

少しでもいいから、毎日何か必ず勉強することを継続してます。
去年の12月半ばから毎日継続してて、今日で連続33日目です。

大晦日も正月も、量は少なかったけど、休まず続けてます。
その代わり、たとえ短時間だったとしても、学習の質は下げないように気を使ってます。

自分は技術者で、科学者ではないので、新しい技術を切り拓くことは求められてないし、できないです。
でも自分は技術者なので、既存の技術や新しい技術をビジネスで利用できるレベルにまで高め、実際に利用できるよう準備しておくことは大切だと考えてます。

それに、実際に現場で使われなかったとしても、身につけた技術の本質から得られる学びは、他の技術を学習するときにも役に立ちます。

これからも、毎日少しずつでもいいから、自分の技術を高める努力を継続していこうと思います。