「3人でゲーム作ろうまんが」に対する僕自身の意見
元ツイート
こちらのツイートが話題になっていた。
3人でゲーム作ろうまんが(1/6 pic.twitter.com/Vzz6wU1lk6
— てつなつ (@TTetsunatsu) October 14, 2020
僕自身にも若干似たような体験があるがそれは一旦横において、共感できる部分、共感できない部分があったので僕の意見を書いておく。
少人数のチームで期待されることはそれぞれがなし得ないことを補い合う関係
共感できるポイントは以下の部分
わたしたちが個人ではなくチームでゲームを作ろうと日々努力するのは 個人のスキル不足というのももちろんありますが 一番の理由は個人で到達できることには限界があると考えているからです
なので当然あなたにもわたしは「わたしたちではできないこと」を求めます
大人数のチームの場合は指示系統がしっかりしてたり指示内容が明確でないと場が混乱しますが、 これから試行錯誤してものづくりをする少人数のチームにおいては良い考えだと思う。
それぞれが得意な分野や苦手な分野をもつことを意識でき補いあえる関係が築ければ、それぞれを尊敬できプロダクトの期待値も上がるはず。 逆に指示待ちの人がいると誰かの足を引っ張ることになってしまう。 そういった意味で高いポテンシャルやモチベーションを持つ少数精鋭のメンバーでチームを構成したいと考えるのは妥当なことだと思う。
リーダーからの期待の表明が遅すぎる
問題となるのは新人（というかチームにすら入っていないだろう美大生）に対してこの期待の表明が参入当初の時点でなされていないことである。 「現役の美大生」ということに対するステレオタイプで一方的で期待は大変良くない。
美大生の仕上げてきた一校目にいきなり「ふつうすぎます」「これじゃわざわざお金を払って他人にお願いした意味がありません」とダメ出しをするシーンがあるが、このダメ出しの仕方は良くないと思う。 却下された（＝作り直しを命じられた）理由が相手の立場だと理解できない。
結局美大生は二度のダメ出しを食らって、「具体的な（OKがもらえる）指示をしてください」と憤ってから、上記の期待の表明を受け何をするべきか考えるようになって良いものが作れたという話になっている。
「反骨心で這い上がってくる」「自分で気づいてほしい」は甘え
この漫画のような例がないと言うわけではないと思うし、こういう経営者に頑張ってついていくことで成長できたというパターンも少なからずあると思う。 あなたのチームに入ってくる期待の新人は何度もやり直ししてくる反骨心のある人かもしれないし、他のメンバーの期待値に対して気づいてくれてよしなにパフォーマンスを発揮してくれる最高の人かもしれない。その可能性はゼロではない。
しかしながら、僕自身はこのパターンだけがエピソードとして残るのはあまり良く思っていない。
理由の一つは、このやり方は依頼を受ける側の立場から見ると高い期待をベースにしてダメ出しされているのか感情でダメ出しを食らっているのかが判断できないこと。 もう一つの理由はこのエビソードで語られない部分でリーダーが人となりを見て「この人ならやってくれると思う」という確信を抱く理由が読者には全く伝わらないことだ。
これは成功したというパターンではなくこういう考え方もあるのかもしれないと読んだ上で、それぞれ現実の立場におけるコミュニケーションは大事に行っていくべきである。
蛇足
なぜかこのツイート漫画が「例の漫画」というキーワードでTwitterトレンド入りしているようだ。 Twitterは公開されている場所なのでツイートする前に文脈が明らかであるか（誤解を招かないか）確認して投稿したいところではある。
「こういうのは勢いが大事なんだよ」という意見もごもっとものように聞こえるが、 トラブルを避ける第一歩は「アクションを起こす前に立ち止まって冷静になること」だと思うので今一度自分が何をしようとしているのかツイートボタンを押す前に考えてもらえるとありがたい。
学習コスト論
JVM上のJavaでない言語を使いたい、と主張したところ、こんな返答が返ってきた。
「学習コストが高く、メンテナンスできる開発者が少なくなるようでは困る。これまで使っているJavaでやってくれ。」
これに対して、賛成・反対の立場から意見を書いてみたいと思う。
賛成の意見
「みんなが共通で使っている言語を使うべき」というのは、開発を進める上で理想的であるように思える。
また、Javaなら様々なリソース（本、Web、人的ノウハウ）に頼れるため、開発が進めやすいだろうと予測できる。
僕の主張に関しても、まだ発展中の言語であってリファレンスもそれほど多くなく、Javaの扱う概念より抽象度が上がり人によっては学習すること自体に時間がかかってしまうという可能性が否めないため、導入は難しいと考えるのは妥当であると思える。
反対の意見
学習コストに関していうと、「支払うべき学習コストを払わなかったから、維持管理コスト、運用コストが長期的に絶えない」のだと僕は思っている。
同じJavaでもバグの少ないプログラムというのは当然あるわけで、そうなるための一人ひとりの能力向上はどんな会社でもどんなエキスパートでも常に必要になる。
そうでなければ結局間に合わせで作ったバグの発見しにくいコードを長い間改修するはめになり、「後から機能追加したら自作ライブラリにバグがあったので迂回するコードを書いた」「それぞれがコードを書いて、混ざるのが嫌だから全部別のクラスにした」なんていう自分勝手なコードが生まれることになるんだろう。
メンテナンスできる開発者について、指摘の通り当初は僕一人とか居ても高々数人だと思う。
でも、必要に迫られたらやるでしょう。かつて僕がそうしてきたように。
その際に学習コストが〜なんてことを考えてたのかは甚だ疑問です。
また、言語レベルでプログラムの考え方が抽象化されてるため、
- コードの量が少なくなる
- 下手な一時変数などでバグを埋め込む確率が減る
- クラスや関数に関する考え方がより柔軟になる
- 処理の並列化が容易
などの大きなメリットがあります。
「いつも使っている」という落とし穴
「探せばすぐに同じようなサンプルコードが見つかる」というのも、実は良くないことだと思うのです。そのままコピーしたり、変数だけちょこっと増やしたりするばかりで、コードを書いた本人も本質的な解決はできていないことに気づかないままかも知れません。
やり方を真似るというのは人間の学習の基本であり、一番わかり易い教育手段です。
しかし、それは特別な問題に関して対処方法を知るだけであり応用が利かないため、解決すべき問題を自分の頭で解釈し分解し具体的な解決に導くまでの道程は自分自身で作って行かなければなりません。
人手ではなく人材として求められるのは、そのような単調な学習で得られるものを超えた柔軟性や困難を乗り越える発想力や新しいサービスに漕ぎ出せるような発展性であり、「やっていれば皆いつかはできる」というものではないはずです。
サンプルコードの読み方として「写経」と称されるものがあります。
同じコードを自分で書いてみて、動かしてみるのです。
その際重要なのはただ丸写しして動いたことに感動するのではなく、「解決しようとしている問題は何か」「何故このコードは動くのか」などを読み解くことや、「自分が書くときの発想も同じコードになっていくのか」「他のやり方はあるのか」「部分的に変更する場合、何が要点なのか」を書きながら試すことだと思います。
写経のように、一字一句自分の中に染み込ませていくのです。
個人的すぎる趣向として
正直なところ、僕はJava言語が余り好きではないし、元々RubyとかCとかFORTRANとかから入ってきた人間なので、オブジェクト指向にもなりきれていないような言語は中途半端すぎると思います。
もちろん、言語として学ぶことは大きく、利用頻度も認知度も世界的に高いことは認めた上で、「JavaはJavaだけに頼る開発者を潰していく言語」なんじゃないかと思ったりするんです。
また、新しい言語の抽象度の高さ故、その概念理解に苦労するかもわかりませんが、それこそが「プログラム」に関する考え方を揺さぶり新しい発想を生み出すことになるため、逆にJavaなどの言語でも活かせる理解が得られると思います。
あと、Haskellとか傍目には制限が強く特殊な言語と思われがちですが、やってみると問題解決のロジックが引き締まったり、無駄な処理がわかるようになってきて良いと思います。オススメです。
プロフェッショナルとは？
先日「あなたにとってプロフェッショナルとは？」と聞かれて、こんなふうに答えてみました。
「責任感」と「可能性の追求」
自分らしいといえば自分らしいかもしれないけど、なんかこれだけでもないような…と言った後に考えていました。
とはいえアレもコレもと追加したところで支離滅裂だし、誤解をまねくことを承知で割り切ることは必要だと思います。
- 責任感
行った仕事に対して対価となるものをいただく以上、中途半端に終わらせたり勝手に見切りをつけて逃げることは出来ません。
また、「指示があったからやりました」という逃げ口上は自分の仕事が何であるか考えていないということに他なりません。
もちろん初めからすべて納得ずくで始めることは不可能かと思いますが、それでもやると決める意志は自ら示すものです。
その代わり、「なにかがおかしい」「この仕事は必要なのか？」という疑問は、個人的にはきちんと発言するべきだと思います。
以前からのやり方に従うだけになっていたり、ただのルーチンワークに1日取られてしまうようなら、はっきり言って無駄だと認識しています。
「なぜこのやり方なのか」「この仕事は『なぜ必要なのか』『誰が行うべきか』『もっと簡単な代替案はないのか』」という言葉を反芻するようにしています。
- 可能性の追求
ベンチャーという精神が個人的には好きなのですが、そもそもベンチャーとは何か。
新しい分野の開拓、ある事柄の見方を変えた新しい解決法を模索する、などなどいろいろあると思います。
では、ベンチャー企業と銘打ったあと、「ベンチャーでなくなる」とはどんなことなんでしょう。
僕の提案としては「積み上げたものを捨てる覚悟ができなくなったとき」かなと感じています。
いずれどんなものも時代の変化と共に消えて行き、その速度が分野によって加速している以上、全く同じ物や全く同じやり方では合わなくなるのは必然であり、常に変化と改善に向けた努力を強いられます。
ベンチャーであるということはその変化に一石を投じる挑戦を行うということであり、周りを巻き込んで変化を促すからこそベンチャーだろうと感じています。
しかし、社会が変化した後にその会社はどうなるのかというと、さらに変化を追求するのか、変化してゆく社会に適応していこうとするか、様々だとは思いますが、一時代の観念に根を張ることは正直難しいと思います。
私個人としての考えを述べると、変化を恐れてはいけないし、自ら変化し、周囲の考え方を変化させることを忘れてはいけないと思っています。
もちろん、手当たり次第に変化するのではなく、その意図や意味を理解する努力が必要になると思います。
これからも多くの方々と仕事を共にする以上変化することは必然ですが、その変化を意識的に受け止められるか、また、より良い変化に促すことができるかということは必ずもっと先のステップに繋がることだと思っています。
まだまだ若輩者ですが、こんな考えでプロフェッショナル足りえる仕事をしていきたいと思います。
