2014無意識のしゅんたっく2014年7月29日バックエンドとフロントエンドの開発における考え方の違い私がメインとして携わっている業務はソーシャルゲームのシステム開発(いわゆるバックエンド)ですが、つい最近、ゲームの演出というか、アニメーション・キャラクターの動き方・スコア表示など、いわゆるフロントエンドをガッツリ作り込む機会がありました。感じたのですが、これは普段の自分がやっている開発内容よりもずっとキツいなあと感じたので報告します。ここでいうフロントエンドとはゲーム演出に関わるアクションや見せ方をいい、Web製作等でよく言われるCSS・フロントサイドJSとは別です。ゲームのシステム開発に携わる2つの職種ゲームとはいえ、これもソフトウェアであり、システムです。ゲームを作るということは、ソフトウェア開発・システム開発をするということでもあります。このシステム開発に携わる職種は、大きく分けて2つあります。一つは主にロジックやデータの管理・大量アクセス大量更新をどう捌くかといったサーバーサイドを担当するバックエンド開発者、もう一つは主に演出・ユーザーへの見せ方を担当するフロントエンド開発者です。(もちろん製品として完成させるにはデザイナーやプロジェクトマネージャーや営業も関わってきますが、ここでは開発者だけを考えます)ロジックから演出まで含めて一つのゲームシステムです。職種が分かれているのでしょうか?それは、システムのロジックと演出で考え方が大きく異なるからだと、私は考えました。その考え方の違いによって、開発者の得手不得手が分かれてくるからです。サーバーサイドの開発と演出の制作における考え方の違いバックエンド開発とフロントエンド開発における最も大きな違いは、「終わりがある」か、「終わりにする」かの違いだと思います。フロントエンド開発は、開発者が納得したときが終わりなのだと感じました。普段、仕様を元に仕様を満たすシステムを構成し、仕様を満たすプログラムを実装しているバックエンド開発者は、仕様を満たしていることが確認できれば作業は完了です。仕様通り作るというのは非常に難しい作業で、それが仕様通りできていることを確認するのも非常に難しい作業です。非機能要件として、秒間最大○アクセスに耐えられる等の仕様もあります。目指すべき目標はあります。これが「終わりがある」ということです。一方でフロントエンド開発者の場合はどうでしょうか?たとえばバイクレーシングゲームを作っているとしましょう。仕様ではAボタン入力でバイクを加速させ、方向ボタンでバイクの重心を変え方向転換やウイリー操作ができるとしましょう。フロントエンドの実装としては、Aボタン入力を受け付けてバイクの動きあるいはタイヤの回転を加速させ、定められたトップスピードに達したら加速を止めるといったことが考えられます。バックエンドの考え方でいけば、加速に関してはこれで仕様を満たしているので実装完了です。ところが演出を担当するフロントエンド開発者の場合はそうはいきません。車体の重量や道の勾配、風などを考慮して加速を変化させなければなりません。プレイしてみて気持ちよく加速できるか、エンジン音はどうするかなど、突き詰めればどこまでもキリがありません。方向ボタンも実装したら、合わせて加速もチューニングしなければなりません。きりがないけど納期はあります。これが「終わりにする」あるいは納得したときが終わりということです。監修がいれば、その人が納得するまで終えることはできません。ゲームのフロントエンド開発をやってみた感想まず、根性である程度まではやり切りました。しても好きにはなれませんでした。この、終わりが無い感じ、芸術性を突き詰める感じ、短気で大雑把な自分には向いていないようです。その一方で、見える目標に向かって突き進むバックエンド開発は、すごく自分に向いていると再度実感した良い機会でもありました。前節では仕様さえ満たせばOKのようなことを書きましたが、そんな生易しいものではありません。この道を極めて行くのは、非常に難しいです。やればやるほど実感します。尊敬する先輩方の背中は、自分の実力が身に付くほど離れていくような錯覚さえします。それでもどちらを極めたいかと言われれば、迷い無くこちらを選ぶでしょう。雑なまとめ時間をかけてもうまく書けないのでまとめて公開しちゃう。どっちも大変だよね、と。普段ビジネス書ってほとんど読まないんだけど、というかそもそも本をあまり読まないんだけど、書店で気になって読んだ本があったので紹介してみようと思う。ロジカルに分かりやすく書くつもりはないので、すいません...。世の中のビジネス書はほとんど次の二種類に分類できて、平社員がどうやって成果を上げるか、経営者がどのように事業を運営していくかのどちらかになると思う。この本はそのどちらでもなくて、いわゆる中間管理職である、課長がどうやって生きていけば良いかが書かれていた。普段経験しないことが書かれていて、課長たちの仕事を経験できた気がしてとても面白かった。課長とはなにかという話。この話の中で面白かったのは、課長は平社員ではなく経営者・管理職だが、その中では最下位であるという話。上位の管理職と異なり、普段は現場の社員と同じ部屋にいるということ。その分、部長よりも現場に近く、より専門性も高く、担当事業に対する知識・情報量も多い。係長以下とは異なり、担当プロジェクトを持ち、予算管理をするようになること。次のテーマで語られていたのは、課長の仕事で起こる問題とそれをどうやってコントロールするかという話。課長には担当プロジェクトの予算を決め、一度決めたらそれを100%達成しなければならいという話は、学生の頃だったらそんな理不尽なと思っただろうが、今ならそれは達成しなければならないよねと納得できる。達成できないと見込まれた場合、部長にすぐに原因と対策をセットで報告しなkレバならないというのも、まあ当然だよねという感じ。これ本当に厳しい仕事ですよね......。問題社員をどうするかという話。会社の備品を盗んだり、無断欠勤を繰り返すような社員をどうするか。これは法的にNGなので、堂々と法務や人事に報告すればよい。印象に残っているのは、パフォーマンスが極端に低い社員(人事の世界でCクラス社員と呼ばれるらしい)をどうするかという話。結論から言えば、この社員がパフォーマンスを出せないのは課長に責任がある。Cクラス社員でもできる仕事を見繕ってやるべきだ。他の社員が見捨てても、最後まで課長は見捨ててはいけない。パフォーマンスの低い社員は解雇すれば良いのではないかという意見も出るだろうが、それは違う。働き蟻と怠け蟻の割合は、怠け蟻を群れから取り除いても別の蟻が怠け蟻となり、割合は常に一定であるのと似ていて、パフォーマンスの低い社員を組織から取り除いても、いずれ別の社員が怠けるようになる。組織全体のパフォーマンスは最もパフォーマンスの低い社員がボトルネックとなることが多い。そのため、組織を強くするためにも、課長はパフォーマンスの低い社員に向き合わなければならない。簡単に解雇してしまえば、後味の悪いことになるのは明白である。この本の中で何度も語られていたのは、「ほめる」の反対は、「しかる」ではなく「無視する」ことということ。部下が成功・失敗したとしても、ほめたりしかったりせず、無視する・評価しないことは良くない。他のビジネス書やブログなどでも良く言われてることだけど、ほめるときは必ず人前で、ほめる対象の人だけをほめる。逆にしかるときは、二人でこっそり。叱った後はすぐに話題を切り替え、次に期待していることを伝える。社内政治をどうすれば良いかという話。政敵が現れれば、政敵のことを政敵のいないところで褒めて回れば良い。相手はたいがいそれで挫けてしまうし、それでも敵対してくるような相手は、社内でも信頼されないだろう。自分の出世が課長止まりの可能性も考えておくこと。転職やヘッドハントされる場合の失敗しないようにする方法、起業も考えてみること等、面白い話題は他にもたくさんあった。......課長って、大変だね。