最高のプログラマーになるための必要な15の要素-あのゲーム解釈版

こちらマティアス・エンドラー氏のブログにあったこれまで出会った良き開発者に共通するものはなにか？をまとめたものになります。非常に納得の行くものが多かったのでぜひ皆さんにも共有できればと思います。一部自分の解釈に合わせたものにアレンジしてますので、本文が気になる方は下記リンクを参考にしてください。
https://endler.dev/2025/best-programmers

ドキュメント読め！

Read the Reference(リファレンスを読む)

若いプログラマーのやるべきことがあるとすれば、自分の使っているもののリファレンスを読むことです。これは言語のことが書かれてあるものや、職場特有のフレームワークがあるならそれに関するものに目を通すことが最優先です。

先輩に迷惑をかけないテクニックの一つ

よく新人さんあるあるで取り上げられる

先輩さん「新人くん、わからなかったら聞いてね」
新人くん「うっす」
・・・
新人くん「先輩、ここわかんないっす！」
先輩さん「そんなもん自分で調べろ！！」
新人くん「えぇ・・・・」

というエピソード。実は自分も新人の頃に何度かやらかしてました。が、こういった場合もこの「ドキュメント読め！」の教訓があれば回避することが容易です。

渡された仕事に関するドキュメントを探して、問題解決につながるものを探してから質問すればほとんどの場合は叱られることはないでしょう。これはなにも単独で解決策にたどり着くという話ではなく

• Aのドキュメントを読んだが、今回の問題に関する項目が見つからなかった
  • どこらへんにあるか聞く
  • 違うドキュメントの場所を教えてもらう
• Aのドキュメントを読んで、問題解決に繋がりそうな場所は見つかったが用語がわからなかった。
  • 用語について調べる
  • 用語についての文献などの場所がわからない場合はそちらを案内してもらう

ツールの使い方を理解しよう！

Know Your Tools Really Well(ツールを本当によく知る)

エンドラー氏的には使用するテクノロジーを根本的なレベルで理解することを求めています。ゲーム制作だとしたら、利用しているエンジンのことをどのぐらい理解しているかなのかもしれないですが、もう少しグレード落とした内容で理解してもいいかと思います。

Unity自体のツールとしての理解

個人的な意見が多い部分ですが、Unityを使ったゲーム開発者におけるツールの使い方の理解には幾つかの側面があると思います。

Unityの各設定やカスタマイズについて

Unityエディタには様々な設定があります。起動を早くしたり、特定の動作を簡単にするためのショートカット機能などがあります。画面のレイアウトなども作っているゲームによっては変更してから作業することでぐっと楽になることも少なくありません。

Unityの動き・ライフサイクルなど

開発をするうえではUnity独特のインスペクターの扱いや、MonoBehaviorを用いたライフサイクルを理解しながら制作を進められるかどうかなどがつながってきます。C#は理解していても、Unity独特の仕様をしらずにハマるなんてこともしばしばあります。

OnEnableやOnDisableなどのメソッドもC#的にはどこから呼ばれてるか分からないような書き方になっていることに注意が必要。あとはインスペクターでボタンなどのイベントを登録している点や、当たり判定などはRaycast TargetやCollision Matrixなどプログラム的にはあっていても動作しないなんてところもハマりポイントになったりします。

Unityを取り巻くパッケージやアセットについて

Unityでのゲーム開発では避けて通れない、パッケージとアセット。これらを活用出来てこそ開発スピードをぐっとお仕上げます！

パッケージについて

Window/Package Managerから必要に応じてインポートすることが出来るゲーム開発を進めるためのツール。開発を進める以外にもなぞのトラブルを調査するときに便利なプロファイラや、ゲームの様子を撮影するレコーダーなど様々なパッケージが用意されています。

中にはPreview版でインターフェースが変わる可能性はありますが、すぐに試したい機能にアクセスすることも出来ます。このあたり一通り有用なパッケージなどに目を通しておくと思わぬ解決策が見つかるかも？！

アセットやオープンソース

ゲーム開発を潤滑に進めることが出来るアセットやオープンソース。ところが他の人から便利！と勧められたとしても、使いこなすようになるために多くの時間が必要です。その大きな要因としては、日本語のドキュメントが少ないということが挙げられます。

最近はChatGptなどで得られる情報も少なくないですが、それでもオリジナルのドキュメントなどがネイティブ言語でないのは思いのほかに大きいです。なんせそのアセットやオープンソースを使った情報自体も少なくなっちゃいますからね。

なにかのアセットを使う場合、ちゃんと使いこなせるようになるまでの時間もゲーム開発の工数に組み込む必要があるので注意です！！

エラーメッセージは大事

Read The Error Message(エラーメッセージを読む)

プログラムを書くと、誰しもがエラーを生みます。これはもう仕方ないものです。今までエラーを出したことありません！というプログラマーがいたとしたら、ビルドもテストプレイもしたことがないのでしょう。この項目ではエラーメッセージを読むということですが、皆さんはちゃんとプログラムを読んでいますでしょうか？

ゲーム開発に慣れてくると当たり前のことですが、プログラムを始めて間もない人は案外このエラーを読むということが苦手な人が多いです。

エラーに理由あり！何が悪いかを調べる！

プログラムは勝手にエラーになりません。書いた内容に不具合があるからエラーになります。これは人間の言語だと「今日、うまい食べたごはん！」とか構文とか適当でもなんとなくで伝わりますが、プログラムには誰のことなのか、うまいが食べたにかかっているのはおかしい、とか言って理解を拒まれます。しかしエラーメッセージにはこんなものが表示されるでしょう

• 主語がありませんよ！
• うまいという形容詞はごはんなどの名詞にかけてくださいね！

という感じだと思います。プログラムでもいろんなエラーが発生します。

• プログラムを動かす前の静的エラー
  • 構文の不具合
  • 変数の形などの不一致など
• 動かしてアクセスして初めて起こる動的エラー
  • 配列のオーバー
  • ぬるりふぁれんすいくせぷしょんえらー
    • Unity使ってる人は飽きるほど見るエラー

大抵のエラーは、エラー内容を見ることで、ある程度パターンを絞り込めるようになるので、エラー内容をしっかりと把握し、直したことがある問題！として扱えるようになりましょう！

よくあるエラーチートシート

必ずこう！というものではないですが、これらのエラー内容を見たらおおよその検討がつけられるようにちょっとだけみなさんにも共有。

静的エラー

初心者の場合はこっちのエラーに苦戦することが多いですね。パターン覚えて対処出来るようになりましょう！

エラーメッセージ	どういうエラー	対処法など
CS1002: ; expected	セミコロンがない！	行末に「;」のつけ忘れがないかチェック
CS0116: A namespace cannot directly contain members such as fields or methods	クラス外などにメソッドを定義している・・・つもりがなくてもそう判断される	どこかの｛｝が対になっていない
CS0103: The name ‘X’ does not exist in the current context	変数や関数が未定義	スペルミスやクラスなどを間違えている
CS0246: The type or namespace name ‘X’ could not be found	型や名前空間が見つからない	using などの追加忘れ

動的エラー

ゲームを動かしてお目見えする

エラーメッセージ	どういうエラー	対処法など
NullReferenceException	オブジェクトやインスタンスが未割り当てのものにアクセスしてしまう	インスペクターの設定や、インスタンス生成処理を見直す
IndexOutOfRangeException	配列やリストのサイズ以外へのアクセス	配列やリストなどのインデックスが配列のサイズをオーバーしていないかチェック。 ループの中などもハマりポイント！
InvalidOperationException: The object is used after being destroyed	Destroy後のアクセス	対象のオブジェクトがなくなった後にアクセスしているスクリプトがないかチェック

問題を細かく分ける

Break Down Problems(問題を分解する)

プログラマーに限らず、何をするときでも物事を細かく分けるのは大事ですね。Unityのゲーム制作においてもブレイクダウンが必要なシチュエーションは多く存在します。

エンドラー氏によると、プロの開発者として給料をもらう仕事の大部分は、この問題分解だそうで、適切に行うことで単純な問題を次々に解決していくだけでお仕事が完了するようです。

問題を細かく分けるとは？

Unityで実際に問題を細かく分ける例を上げてみましょう。

あなたはプロジェクトを進めるうえで、当たり判定が効かない！という報告を受けました。この時どのぐらいの不具合原因を想像出来ますでしょうか？

• 当たり判定で取っているメソッド名の名前が違う
  • OnCollisionEnterとかのつづりが間違っているとそれだけで反応しない
• OnCollision系とOnTrigger系の使い方を間違えている
• OnCollision系とOnTrigger系の引数を間違えている
• 当たり判定を取りたいオブジェクトにCollision系のコンポーネントがついていない
• 当たり判定を取りたいオブジェクトのいずれかにRigidBody系がついていない
• 2D系と3D系の各コンポーネントを間違えている
• Layerの設定が間違っている
  • CollisionMatrixなどの関係なども

とか軽く想像出来る範囲だけでもこれだけの問題点が挙げられます。実際のエラーはもっと根本的に違うこともありますが、Unityでの開発に慣れてくるとこのあたりがパッとひらめくようになり、結果的に問題解決に近づくことが容易になります。

このようになにかの問題にあたった時、その問題を分解する力というのは物事をしっかり理解しているかや、過去にトラブル対応したときの経験がどのように積み重なっているかが大きく反映されます。

「最後までやりきるのが大事！」という言葉はこういった問題解決のための経験値をしっかり得ることが大事！ということにもつながったりするんですね。

分からなくても、やってみる

Don’t Be Afraid To Get Your Hands Dirty(手を汚すことを恐れないで)とありましたが、内容的にはチャレンジ精神を忘れるな！という感じのこと。

こちらに関しては元の英語内容と少し異なる訳を当てはめています。原文では「最高のプログラマーはたくさんのコードを読み、それに触れることを恐れない」というふうに書かれています。このコードに触れる、コードを変更するというのはプログラムなんかでは差分が発生したことを確認する作業をDirty Checkと言ったりします。そのあたりから手を汚すことと言っていると私なりの解釈をしました。またコードに限らず、自分の担当外だからと言ったり、それじゃあ助けられないよとは言わないことも合わせて記載されています。

こういうシチュエーションで渦中に飛び込めるようになりたい

実際に手を汚すことを恐れないシチュエーションとは何なのか。個人的にいくつか挙げてみました

• 初めて見るソースコード
• 使ったことがないライブラリ・フレームワーク
• 自分の担当以外の箇所
• 他の人のヘルプ（内容はまだ確認してない）
• 誰か手が空いてる人いるー？というざっくりした呼びかけ

という感じじゃないでしょうか？初めて見るソースコードは、なにか新しいことに着手すると避けようがないのでみんな経験はあると思います。ライブラリやフレームワークも導入したりすることはあるでしょう。

では、残りの３つはどうですか？みなさん、なにか相談やヘルプを求められた時、他の人が答えてくれないかなぁ・・・と思ってやり過ごすことはありませんか？まぁ私も100%応えられてないような気はしますが、配信中の質問は逃げられないですからねｗ

実際困っている人に対して、100%解決出来る場合は返答することもあるかもしれません。しかし自信がなかったり厄介事はごめんだ、という感じで逃げていることはないでしょうか？こういう時、勇気を出して自分なりの返答や意見を言うことは本当に大事です。

というのも、こういうものは自分が質問者側に回った時にすぐわかると思います。分からないなりにほんのちょっぴりでも返答がもらえたらめちゃくちゃうれしくないでしょうか？もうこれに尽きると思います。そしてこの行動自体は結構いろんな人が見てます。評価のためというわけではないですが、自分の成長のチャンスにもなりますので、ぜひ分からない領域にも飛び込んで行ってみてください。

情けは人の為ならずの精神

Always Help Others(常に他の人を助ける)。エンドラー氏によると、優れたプログラマーは大人気でくっそ忙しいはずなのに、なんか人助けをいつもしています。これは好奇心が強く、支援的な考えを持った人が優れたプログラマーになるための要因の一つだと言えます。

チームが成功するという意思をもつ事が大事

ゲーム制作に限らないですが、基本的にものを作るときはチームで取り組むことが多いです。もちろん大成功を収めている人の中には独力だけでなんとかしている人もいると思いますが、それはとても稀なケースであり、見えない部分では有機的に誰かと関わっていることが多いです。

要は何をするにしても、なんらかのコミュニティでうまくやっていくためのスキルが必要ということです。ただ、このうまくやっていくという部分ですが、分からない場合は次のことを念頭において取り組むとよいかと思います。

• プロジェクトが成功することに繋がるか
• 誰か困っている人はいないか

まずはこの2点で大丈夫です。最近の風潮で、自分の担当じゃないので！とか断って余計な仕事をしないのが良し！みたいなのオススメされてることあると思いますが、ちゃんと仕事や制作をしたいのであれば困ってる人を見かけたらできる限り「何か手伝いましょうか？」と声を出してみてください。

上長の方やリーダーの判断でヘルプを任されるかどうかが分かれると思います。

• ヘルプをする場合
  • 現在のタスクとの優先順位を考える必要がある
  • 知らない部分を把握する必要がある
  • 仕事（作業）が終わる時間が遅くなるかも
• ヘルプが出来ない場合
  • 今のタスクはプロジェクト進行上手放せない
  • 担当するには難しすぎる

まぁだいたいこんな理由でしょうか。当然自分にヘルプが出来ない場合もあると思いますが、それでも大丈夫。このアクションから何が得られるかわかりますでしょうか？

ヘルプをしたときはヘルプ箇所への理解が深まりますし、ヘルプが出来なかったとしてもあなたが困っているとき、チーム員はきっとあなたを助けることに積極的になることでしょう。（いつも手伝ってくれる人のことは気にかけたくなるでしょう？）

ちなみにスーパープログラマー先輩達は、困っているときに助けてもらえる！とかの次元ではなく、「後々問題を起こすよりさっさと解決しとこ！」ぐらいののりでサクサクヘルプしてきます。なので積極的にヘルプを名乗り出ないとどんどん問題解決能力の差が開いてしまうので注意！

書いて伝える！

Write(書け)の一言。四の五の言わず、とりあえず手を動かす。某桜井さんも言ってる。お題の原文はWriteの一言だったので、黙々と作業に取り組めという感じかと思ったのですが、「優秀なエンジニアのほとんどは、言葉遣いが上手で、喜んで知識共有をします」とありました。

これは作業をしろ、ということではなくドキュメント制作をしようという意味の書けですね。ライティングスキルとプログラミングスキルには強い相関性が見られるそうです。

優れたプログラマーは文章を書いたり構成を考えるのがうまい

優れたプログラマは複数の言語を使いこなし、また文章の書き方をマスターしています。これはプログラムを書くときのコーディングスタイルにも影響します。文章というのはその人の思考方法を多く物語ります。実際に優秀なプログラマーさんはいろんな場での講演を行ったりLT(ライトニングトーク)なども積極的に参加していることが多いです。しかもちょっと面白い話が多い気がします。

このように話をしたり、良い文章を書いたりすることは、良きプログラマーに共通することだと言えます。

情報のアウトプットが最大のインプット

さて、私の解釈として「書け」からどのように優れたプログラマーに近づくか、平凡なプログラマーがするべきことは「情報のアウトプット」だと考えます。

プログラムに限らないですが、自分にとって貴重な情報を入手したときに「他の人には教えたくないなぁ・・・」と思うことはないでしょうか。これ自体は分からなくはないのですが、これは他の人に差をつけたいということだと思います。もちろん個人や会社の特許に関わる内容であれば秘匿にするべきです。

しかしそのほとんどの場合は公になっている情報だと思います。もしそうであれば自分の得たの情報を共有することをしてみてください。ブログなりツイート（ポスト）なりなんでも良いので自分の言葉で発信することで一見ほかの人に同じ情報レベルを与えているように感じるかもしれませんがほとんどの場合に次の効果が得られます。

• 情報を求めた人にとっての感謝。有益な情報！
• 情報が間違っていた場合、訂正のためのアドバイス
• 他にも別の情報がないかフォローされる
• 他の人から関連する情報を教えてもらえる

など、結果的に自分の得られるものが上回ります。多分優れたプログラマーの方々は得た情報がさして貴重だと感じないから発信も気軽で、結果的に得られるものが多いのではないかなと思います。

いろんな発信方法、オススメはブログ！なんとなく、でプログラムやってる人こそ！

情報発信をする場合、次のような方法がメジャーでしょうか

• X(旧ツイッター)による発信
• ブログなどによるまとめ < オススメ
• Youtubeなどの動画投稿
• GithubなどにOSSとして公開

個人的にはブログなどによるいつでもアクセス出来るドキュメントとしてまとめるのがオススメです。書き直しが出来るのと、自分の考えを誰かに伝えるための文章構成などを考えるにはとても良い練習になります。うまくいくと収益化なんかも出来ますし、趣味でお小遣い稼げるのもいいですね。

他の人に説明するとき「なんとなく・・・」と言語化出来ていない人こそこういった文章に書き起こして説明出来るようになる練習は本当に勉強になります。慣れないうちはどこまで書いたらとかどう表現したらとか迷う部分が多いかもしれません。自分で書いた文章はヘンテコに見えてこんなもん公開してもいいのか？と思うこともあるかもしれませんが、まぁそこは慣れよう！最近だとChatGPTなどに文章校正お願いしてもいいですしね。

常に学ぶ！

Never Stop Learning(学びを止めるな！)

優秀な開発者には60歳を超える人もいます。彼らがすごい理由の一つは常に学び続けているということです。リードしている人が同じスピードで走ってたらそりゃ追いつけねーわの理論。それを地でやるのがすごい人たる所以ですね。

成長しているとはどういうことか？

これは自分が新人のころのマネージャーに言われたことなんですが、今でも意識してる一言です。

「先月書いたコードを、良くする方法はあるかい？あるんだとしたらそれが成長。もし無くなっているなら成長が止まってるから焦りなさい」

自分の書いたコードが完璧！なんてことはあまりなく、動かせば不具合、気づいたら別の書き方の方が全然良いものなんてことはザラにあります。いつまでも油断しないように有りたいものです。

しかもこの先月書いたコードとの比較はプロジェクトを進めながらのものになります。はじめから完璧なものを要求しているわけではなく、今考えつく最善のコードを書き、物を作りながら成長を繰り返すことが大事というわけです。

実際に一人でプログラムの勉強をするのと、プロジェクトの中で他の人のコードに揉まれながらの勉強では圧倒的に学習効率が違います。ぜひ、戦いの中で成長していってください。

プログラマーに貴賎なし

Status Doesn’t Matter(地位は関係ない)。良き開発者は若手もベテランも関係なく積極的に話し合いをします。これは誰からも学ぼうとする姿勢を持っているからです。新人の人は社内構造にまだよく分かっていない状態で、新鮮な考え方を持っているからです。

誰からも学ぶ姿勢を持つには、誰かに教えるのが一番！

新人の場合は当然誰からも学びを得ることが大事ですが、そうではない人はどうすればよいか。もっとも実行しやすい方法は「誰かに何かを教える」のがとてもオススメです。

自分が理解できていることを、まだ知らない相手に教えるというのはとてもいい復習になります。例えばインターフェースの使い方など、使うときは不自由なくても、その概念を知らない人に説明する時に思った以上に苦労します。ときにはインターフェースを使う上で別に必要な知識の説明も必要になるでしょう。説明をする相手の素朴な疑問に応えるのもいい勉強に繋がります。

思った以上に伝わらなかったり、言語化するのが思ったり大変だったり、やってみると本当に色んなところに学びがあります。相手に伝わらないということが、慣れないうちはかなり大きなストレスになることもあると思いますが、ぜひ寄り添って教えてあげてください。

評価される下ごしらえ

Build a Reputation(地位を築く)。さぁ優れたプログラマーになれば、優れたプログラマーになれると思いますか？これはトンチとかではなく他社からの評価の話です。自分自身のプロデュースと言ってもいいでしょう。評判を上げる方法は以下のようなものが挙げられていました。

• 組織向けに重要なサービスを構築
• 有名なツールを作成した
• 人気のオープンソースに貢献する
• 注目されるような本を出版

社内や世間から、定量的に評価出来るものが必要という感じですね。まぁ本を出せ！とかはみんなに要求するのは大変だと思うのでもっとしやすいことをやってきましょう！

なぜ評価が必要なのか

まず前提として評価される必要があるのはなぜか。もちろん「真面目に仕事や作業に取り組むことで自然と評価はついてくる！誰かに評価されようなど邪道！！」と思う方もいるかも知れません。まぁ私もアピールするのとか苦手な方ではあるのですが、これは自分のためだけではなく、参加するコミュニティのためでもあります。

自分の評価が足りない場合、それを指摘してもらったり、なにかに困っているとき、頼るべき相手を正しく見定めるということに繋がります。プロジェクトを進めるうえでこれは大きな財産になります。

どこかバグや疑問点が出た時に、コミュニティの中に「とりあえず声をかけられる人」なんかがいると思います。そういった存在に近づくためには人からの評価が必要になります。

ちなみにこういった存在には明日からすぐになることはほぼ出来ませんので、時間をかけて信頼を得られるように下地を作りましょう。

評価を得る前に失点をしない環境を作る、下地編

まず第一に評価を得るために大事なものがあります。それは「短期間で評価を得るのは無理！でも失うのは一瞬！！」と言うことです。つまり、この文章を読んでも明日から誰かに評価されるなんてことはほぼないと思ってください！いいですか？明日から誰かに評価されることはほぼありません！

ということを頭に入れた上で、どういうアクションを取っていけばいいかお話します。

• 遅刻をしない
• 報告をする
• 分からないことを調べる
• 他の人の話を聞く
• 面白いことを見つけたら共有する
• 何かしてもらったらお礼を言う
• 挨拶をする
• 他のメンバーへの気づかい
• 何かやらかしたら謝る

からですね。内容的には小学生で習うような内容がほとんどです。これは評価を得る下準備みたいなものですが、そもそも失点をしないというのが大事になってきます。すべての悪評を覆すほどの技量を持っているなら気にする必要はありませんが、我々凡人はまずは無害認定を受ける必要があります。これらは１日ではなし得ないものになりますので日々の積み重ねを頑張ってください。

ネクストステップ！ようやく得点を稼ぐ

ポイントを稼ぐには下地が必要。正確には下地があったほうが得点に倍率がかかりやすいという感じのイメージですね。

• 自分のパートに責任を持つ
  • ほかセクションからの質問に応える
  • 不具合時に積極的にメンテナンスを行う
• コミュニティの役に立つ
  • 相談に乗る
  • 話題を提供する

何も難しいことをする必要はありません。やったことに責任を持つことが重要です。そしてコミュニティにとって有益な存在となることが大事です。

自分のパートに責任を持つことに関しては、何らかの制作を行った場合、その箇所に関わる質問や不具合が発生した時にいち早く回答・修正ができるようになることです。作ってそれで終わり！ということは基本的にはほぼなく、関わった箇所は自分の手足のように理解し、メンテナンスを行います。これを繰り返すことでどんどんプロジェクト全体で必要となる存在となれます。

コミュニティの役に立つアクションをすることで、何かあった時に声をいち早くかけられやすくなります。これ自体はコミュニティの他の人への提供する一方的なものに見えるかもしれませんが、問題があったときや、他の人の情報共有などが行われるときにも自分へのフィードバックがスムーズになることが少なくありません。ついでに声をかけられる存在になっていくというのはホント大事。

自分の知ってることを相手が知っているとは限りません

Have Patience(忍耐強く)。何をするにも必要なスキル。何かを学ぶのに当然時間は必要です。これは自分にも他人にも言えること。

この忍耐、私は２種類あると私は考えます。

自分が理解するための忍耐(そんなに大事じゃない)

まずは最も理解しやすい方の忍耐。これは新しいものや知らないものを学習する際、勉強に時間を費やしたりする必要がある忍耐です。これまでに何かものを作ったりしたことがあるのであれば、これらの努力や忍耐を知らないという人はいないでしょう。

なのでこっちの忍耐に関しては特に言及しません！頑張って勉強しよう！

他者が理解するための忍耐(こっちが大事)

ところが相手側が理解（学習）することに関しての忍耐になった途端に我慢出来ない方が多く見受けられます。よく言うセリフとして「なんでこんなことも理解できないの？」というやつですね。自分が分かっていることを相手が分かっていないという状況で寛容になれるかどうかは良きプログラマーというよりそもそも人として必要な要素です。

もちろん何かを作ったりする上で、急いでいたりするときはあるかもしれませんが、相手の立場に立って理解をしっかりと示す必要があります。

こういったシチュエーションで相手と足並みを揃えてものづくりやコミュニティを形成出来ることこそ、良きプロｇ、というより良き仲間ですね。

ちなみに大体の場合はドキュメントが不十分であったり、そもそも教えてあげる自分の説明が悪い！と思ってあの手この手で寄り添いましょう。

バグを憎んで人を憎まず

Never Blame the Computer(コンピューターを責めない)。「なんか知らんけどバグった！」すべてのプログラマーが口にした言葉の一つです。これ言うの自体はもう仕方ないと思いますが、それでも原因がついて回るのがプログラム。怖いね。

プログラムは勝手にバグらない

突然起こったと思いたいバグは、時としてソフトウェア、他の人、自分の犬、天候のせいで起った・・・と思いがちですが、優れたプログラマはそうはしません。もちろん皆さんも本当は何か自分のした行動が悪いとどこかでは理解しているはず。こういった事態でよくあるのは以下でしょうか

• なんらかのライブラリ・フレームワークをうまく使いこなしていない
• 過去の自分が作ったものへの影響、エンバグの発生
• 開発環境の変化
  • エディタやツール、OSのバージョン変更
  • Gitやファイルのバージョン管理システムの不具合
  • サーバーサイドの変更対応

いずれも自分が直接変更しなかった内容があるかもしれませんが、それでもある日プログラムは誤作動を起こします。しかし確実に原因があってバグります。なぜなら、バージョン互換性を持ったプログラムを書いてない自分が悪いし、然るべきエラーを出力しなかった自分が悪いからです。

ただ、ちゃんと調査を行い原因と向き合うプログラマを責める人はそこまで多くはいないでしょう。勝手知ったるプログラマーであれば「明日は我が身」ということを身に染みて理解しているからです。

分からないことは分からない！

Don’t Be Afraid to Say “I Don’t Know”(「分からない」と言うことを恐れないで)。わりと当たり前なことなのですが、なぜか嫌がる人が一定数いるというのが謎。

就職面接で分からないと言わせたい

さて、こちらのタイトルはただの意地悪ではありません。エンドラー氏は、就職面接などで相手が「分かりません」と少なくとも一度は言うように強く迫るそうです。これは面接する側が優位に立ちたいからではなく、面接を受けに来た人の知識の限界を知りたいからです。

これは面接を受ける人の限界点を知り、一緒に課題に立ち向かいたいからです。こういった時の質問ですが、実際には回答の内容にそこまでの興味はありません。回答の際、分からないことに対して嘘をついていないかを見極めています。分からないことに直面したとき、傲慢さや防衛本能から自分が分かっていないことを隠そうとするような人とは仕事をしているとき、本当に困った時に頼りにすることが難しいでしょう。

ちなみに優れた候補者の返答はこんな感じだそうです「んー、分からないですが、興味深い質問ですね！推測するなら・・・」ですって。強者感半端ないっすね・・・

実際に分からないと言う準備

で、ここまでの話を聞いて素直に「分かりません！」を唱えればよいかと言うとそうではありません。言ってること違うやん！と思うかもしれませんが、何事にも準備というものがあります。私達下っ端が分からないを言う時、本当に分からないことを証明する必要があります。

• 質問自体が分からない
  • 何を回答したら良いのか分からないなど
  • そもそも自分の専門分野外のことなど
• 質問の中の単語が分からない
  • 内容はなんとなくわかるけど、一部知らない単語が入っているため確認が必要
• 質問の回答を言葉にするのが難しい、説明が難しい
  • 回答自体はできそうだけれど、どう伝えたらいいかが分からない
• 調べてみたが分からない
  • 調べ方が悪かったのかな、関連記事が見つけられなかった
  • ニッチな内容だとWebに解決策がなかった

分からないとなると、だいたいこんなところじゃないでしょうか。この中だと調べてみたけど分からないが一番望ましいですが、即興で返答しないといけない場合はどこがなぜ分からないかを添えて回答するようにしてください。

思い込みで行動しない！

Don’t Guess(推測しないで)。原文では「曖昧なことに直面したら、推測する誘惑を拒否する」とありました。これは次の要因を引き起こすからです

• 自分の推測が間違っており、さらなる不具合を引き起こす
• 間違った前提に基づいて頭が固まってしまい、長い間にわたって自分を苦しめる

とのことです。ということで、これは推測自体を言っているのではなく、考えたことを確かめもせずに実行に移すと大変なことになっちゃうよ？！ということですね。

思い込まないにはどうすればよいか

個人制作をしていると、どうしても相談する相手がいないということがあると思います。そういった場合はどのようにするのが良いでしょうか？

• 確信を得るまで調べる
• 動作確認を行う
• 誰かに相談する
  • 最近だとChatGPTやAI系のもの
  • SNSやゲーム制作のコミュニティなど

個人でやるなら、ちゃんと調べて動作確認を行うという感じでしょうか。相談する相手がいればもちろんそれがいいのですが、SNSやChatGPTなどはどこまで正確なレスポンスがもらえるかなかなか難しいと思います。教えてもらったことも、ちゃんと動作確認を行って問題ないことを確認してください。

シンプルイズベスト

Keep It Simple(シンプルに！)。優れたプログラマーはシンプルなコードを書きます。これは物事を簡単に捉えることが出来る出来るからです。実際にシンプルにコードを書くことで他の人にも伝わりやすく、メンテナンスも行いやすいコードになります。

シンプルにわかりやすい表現を行おう

物事をシンプルに捉えたり、表現するのは難しいことです。これは相手の理解度を把握した上で言葉を選んだり、シンプルな構成で表現出来ているかに繋がります。たとえば次の例文を皆さんは御存知でしょうか？

パルスのファルシのルシがコクーンでパージ

FF13でネタのように擦られているゲーム内の状況を言い表した説明文です。ちなみにゲームをやってない人が聞いても分からないのは当然です。これは上の方でも話していた「単語が分からない」状態の説明になっているからです。実際にゲーム遊んでると別に自然な内容です。

治安の良いところと悪いところがあります。ルシというのは治安が悪いところの偉い人に使命を与えられた人たち。ルシさん達を治安のいいところから隔離します！

ちなみにルシの方々は使命が果たせないと化け物になるわ、果たせても体がクリスタルになるわと詰んでる

という感じでなんとなく伝わりやすくなったでしょうか？もっと一言で伝えると「奴隷みたいな人たちがなんか住む場所ごと見捨てられそう」とかそんな感じですかね（昔すぎて覚えてないのでちょっと間違ってたらすまんません）。

これ、プログラムや仕事場で同じようなことを自然としている人は結構います。相手が理解してない単語や風習を気にせずに会話に盛り込んで話しを進めたり、必要以上に難しい言葉選びをする人はいないでしょうか。

おわりに

今回自分なりの言葉を使って言葉を解釈させていただきました。お題としては「私の知る最高のプログラマーとは」となっており、職場やコミュニティでも一握りの人に対する共通点について語られた内容でした。

ところが、実際の自分のような半端者が同じようなことを真似しても栄養になりにくいと思い、誰にでも実践可能な言葉やアクションとして落とし込んだつもりです。

これからゲーム制作や、何らかのコミュニティに関わる人にとって少しでも役に立つことを心より願います。

普段やYoutubeで配信をしたり、ゲーム開発に役立つ情報を発信してます。お時間合えば遊びに来てください！