f4エンジニアブログ

f4samuraiの中の人たちが書いています

社内エンジニアのおすすめ書籍6選をまとめました

はじめに

こんにちは、f4samuraiサーバサイドエンジニアの酒井です。今回は社内の第6回技術記事コンテストに投稿された記事の内容を紹介します。

 

技術記事コンテストには毎回テーマがあります。第6回はおすすめしたい技術書(文書)」というテーマで実施しました。

 

新しい知識を吸収したい時や業務で活かしたい技術を習得する場合は、技術書や文書を読む機会が多いかと思います。

今回は、コンテストの中で登場した数ある書籍の中から、いくつかピックアップしてご紹介します。

 

技術記事コンテストの目的

f4samuraiのエンジニア部門では、技術記事コンテストを定期的に開催しています。

個人のインプット促進はもちろんのこと、チームの垣根を越えたコミュニケーションや、エンジニア組織の長期的な成長を目標としています。

 

オフィスのカフェスペースに本棚があるのですが、人に勧められた本を読むのも良い機会に繋がると考え今回のテーマを決めました。

本棚にある本の一部です。歴史を感じますね。

 

f4samuraiエンジニアが選ぶ、おすすめ書籍

アンチパターン―ソフトウェア危篤患者の救出

https://amzn.asia/d/9509Yjw

1冊目はソフトウェア開発の本です。サーバーサイドエンジニアの方がピックアップしました。

 

この本の良いところ

  • 失敗例がたくさん載っている
  • 経験によっては、「ぐさっ」と来るものが多々ある

 

私もお勧めされたので読んでみたのですが、良い意味で非常に読んでいて苦しくなる本でした。思わず「あるある」と頷いてしまうような語りとなっています。

 

開発現場でよく発生する失敗パターンがカタログ化されており、チェックリストとしても活用することができます。

最初の1ページから読み進める必要がなく、興味があるところから読み進めることができるのも嬉しいポイントです。また、各アンチパターンの名称には「溶岩流」「暗室栽培」などユーモラスな名前が付けられています。

 

デッドコードやスパゲティプログラムの話はソフトウェア開発では良くある事例かと思います。ゲーム開発でも同様のことが言えますので、アンチパターンとして心に刻む必要がありますね。

2002年に発売(!)と古い本ではありますが、今でも学びがある本だと感じました。

 

② CGWORLD

https://amzn.asia/d/fSA9tlf

2冊目はゲームグラフィックの雑誌です。ネイティブエンジニアの方がピックアップしました。

 

この本の良いところ

  • 日本で数少ないゲームグラフィック専門で扱っている雑誌
  • 毎月一冊発行

 

コンシューマゲームから、スマートフォン向けのゲームまで最新のゲームグラフィックについて

の解説記事が載っています。

 

毎月発売されるので、最新の技術トレンドを知ることができるのも魅力的です。

 

私自身はグラフィックには疎いのですが、制作技術について知ることができ、楽しみながら読むことができました。

ユーザーや視聴者として体験したゲーム・映像がどのように作られているかを知ることで、技術者としても刺激を受けることができました。

 

年間購読がお得のようです。



③ ノンデザイナーズ・デザインブック

https://amzn.asia/d/bdaIL4U

3冊目は役員がピックアップした本です。

タイトルの通り、デザイナー以外の職種の方がデザインの基本について理解を深めるのにおすすめの本だそうです。

 

この本の良いところ

  • 「近接、整列、反復、コントラスト」など意識することで、資料を見やすく作成できるようになる
  • 位置関係だけではなく、色やフォントについても記載されている

 

非デザイナー向けということで、満遍なく基礎的なデザイン知識を身につけられます。

 

エンジニアとしてある程度キャリアを重ねると、社内勉強会や外部セミナーに登壇する機会も増えてくるかと思います。

私も以前、こちらの古い版を読んだことがあるのですが、発表用スライドの統一感を強く意識するようになりました。何も学ばずに無意識に資料を作っていた時とは、見やすさが各段に改善されました。

 

デザイナーとのコミュニケ―ションをさらに円滑にしたいとお考えの方、プレゼン資料を作る機会が多い方にぜひ読んでいただきたい1冊です。



プログラマー脳 〜優れたプログラマーになるための認知科学に基づくアプローチ〜

https://amzn.asia/d/4sQUJXo

4冊目はプログラマー向けの本となります。ネイティブエンジニアがピックアップした本です。

 

この本の良いところ

  • 書いている/読んでいるコードが疲れやすい理由がわかる
  • 新規参画エンジニアとシニアエンジニアとの認識の違いが明文化されている

 

この本の面白いところは、「認知科学」に基づき技術習得を効率的に行うための方法が解説されているところです。

 

普段書いたり読んだりしているコードで「なんだかここの実装はいつもよりしんどい」、「理解するのにどっと疲れた気がする」といった事象について、なぜそのコードが疲れやすい=認知負荷が高いのかを理解することができます。

 

読み物としても面白いですが、コーディングをする上で他のメンバーがより理解しやすいコードを書く際の参考になります。

また、エンジニアが新規参画した際に負荷がかかりやすい項目について触れられており、既に運用されているプロジェクトに途中参画する方のつまづきポイントを知ることができるので、ベテランエンジニアの方にも参考になる内容となっております。

 

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

https://amzn.asia/d/7gZWiDh

5冊目に紹介するのは、オライリー本です。こちらもネイティブエンジニアの方がピックアップした本となります。

 

この本の良いところ

  • コンピュータの動く仕組みを体系的にわかりやすく説明されている
  • ハードウェアの構成を学び、機械語アセンブリVMを学ぶことができる

 

この本はネイティブエンジニアに限らず、全エンジニアにお勧めしたい本です。

 

「コンピュータがなぜ動くのか」などの基本的な原理原則を学ぶことができるので、確実なスキルアップが望める内容です。また解説だけではなく、実際に手を動かして学ぶ環境が提供されており、ハンズオンをベースに学習することが可能です。

私も以前読んだことがあるのですが、とても読み応えがあった1冊です。手を動かしながら最後まで実施するのに3ヶ月近くかかってしまいましたが、エンジニアの技術的な軸になってくれる1冊ではないでしょうか。

 

⑥ (おまけ)メールはなぜ届くのか

https://amzn.asia/d/icWMMUb

最後に私がピックアップした本を紹介させていただきます。

 

この本の良いところ

  • 非エンジニアの方でもネットワークの概要をざっくりと理解できる
  • IPマスカレードプロトコルなどのネットワーク用語を知ることができる

 

この本は非エンジニアの方にも非常にお勧めの本です。メールを題材として、これでもかというぐらいに、噛み砕いた説明がされています。

 

私は立場上クラウドアーキテクチャに触れる機会が多いのですが、インフラを学んだことがない方の最初の1冊にお勧めです。

 

技術書というよりも、どちらかというと手軽に読むことができるエッセイに近く、早ければ1日で読み切ることができます。この本だけで実務スキルが身につくとは言えませんが、この本をきっかけにネットワーク製品やクラウドの学習によりスムーズに入ることができると思います。



まとめ

今回は5+1冊ご紹介させていただきましたが、コンテストでは他にも沢山の記事投稿がありました。

 

中には、各企業様が公開されている新卒研修資料がお勧め!という内容や、Apple社の 「ヒューマンインターフェイスガイドライン」はとても勉強になる!など書籍以外を紹介する記事も数多くありました。

 

職種やチームの垣根を越えて技術書や資料を共有することで、他メンバーがどのような技術領域に関心があるのか、どんな知識を持った仲間がいるのか、などを知るきっかけになりました。

 

エンジニアの多い職場でも、周囲の人と技術書の意見交換をする機会は多くない……というケースもあるのではないかと思います。

そんな方は、ぜひ一度おすすめ書籍をシェアしてみてください。きっと想像以上の効果があると思います。



この記事をお読みいただきありがとうございました。

少しでもインプットや会話のきっかけになれば幸いです。

 

また別の記事でお会いしましょう!

24卒エンジニアが入社後の2カ月間を振り返ってみた

 

自己紹介

皆さん、はじめまして。ネイティブエンジニアとして、4月1日よりf4samuraiに入社した新卒の舘(たち)と申します。

 

先輩方から「ブログ書いてみなよ」とお声がけいただいたので、今回はご挨拶も兼ね、入社の経緯や4月からの研修期間について書いてみようと思います。

エンジニアとして就活中の方や、f4samuraiに興味がある方にとって参考になれば幸いです。

 

ちなみに、学生の方だと「そもそもネイティブエンジニアって何するの?」と思われる方も多いかと思います。f4samuraiでは、ネイティブエンジニアは主にUnityを使ってインゲーム部分を中心とした実装を行う、つまりユーザーの皆様が直に触れるゲームそのものを作っているエンジニアのことを指します。

 

学生時代にやってきたこと

僕が学生時代にやってきたことは、ゲーム制作です。

長期間かけて高クオリティの物を作ると言うよりは、短期間で多くの物を作るスタイルで取り組んできました。

 

短期間といっても、数日で制作するゲームジャムから、4〜5ヶ月程かけて行う制作などさまざまでした。1人で制作することもあれば、友人たちと集まって制作したり、授業の一貫でチームを組んで制作することもありました。

制作したゲームは展示会などで、沢山の人に遊んでもらいました。その際にいただいた意見を元にブラッシュアップしたり、次の制作に活かしたりしてもっと面白いゲームを作れるように一生懸命取り組んできました。

 

ゲーム開発者を志した理由

僕の場合、もともと「ゲームクリエイターになりたい!」という強い意志があったわけではないのですが、昔からパソコンに触れていた影響からか、プログラミング未経験のころから「なんとなくエンジニアになれたらいいな」程度の考えはありました。

 

そして大学選びの時、自分が本当に興味を持てるものは何なのかと振り返ってみて、幼少期から大好きだった「ゲーム」があると気づき、その時に初めて「ゲームクリエイター」を自分のキャリアの選択肢として考え始めました。

 

いざ大学に入学してみると、ちょうど新型コロナウイルスが流行し出したタイミングと重なり、授業が全部オンラインになってしまいました。

結果として自分の時間がたくさんできたので、興味のあったゲーム制作を始めてみることにしました。

 

実際に制作をしてみるとすごく楽しく、また自分の作ったゲームを人に遊んでもらって楽しんでもらえたときに大きな喜びを感じました。

次第に、「自分はこれを仕事にしたい」と思うようになりました。

 

f4samuraiを受けたきっかけ

『マギアレコード 魔法少女まどか☆マギカ外伝(以下:マギレコ)』をプレイしたことをきっかけにf4samuraiを知りました。もともと、アニメ『魔法少女まどか☆マギカ』が大好きだったのでゲームが出たと聞いてプレイし始めて、世界観やストーリーなどのクオリティの高さから開発会社に興味を持ちました。

 

就活時はf4samurai以外の会社も受けていましたが、ゲーム業界に就職したいということだけは決めていました。その中で、「成長できる環境がある」「自分の信念に近い企業理念である」など自分の中で会社選びの軸に当てはまる会社を探していました。

その点でいうと、f4は選考全体を通して「合っているな」と感じることが多かったです。

 

入社の決め手

最終的にf4samuraiに入社を決めた理由を聞かれると、正直「なんとなく」という言葉が一番しっくりくるんです。

もちろん、なにも考えていないという意味での「なんとなく」ではなく、話を聞いていく中で感じた雰囲気が他の会社さんよりも自分に合ってそうだったり、自分が働いているイメージが湧いたというのが具体的な理由として挙げられると思います。

あと、『マギレコ』を開発した人達と一緒に働けるという点も個人的に嬉しいポイントでした。(笑)

 

実際に入社してからは約2カ月しか経っていませんが、今のところいい意味で学生時代の自分がいた環境の延長戦でいられると感じています。

先輩方が優しくて親しみやすいので、雑談をしやすいのはもちろん、研修期間のうちから次に実装するキャラなどプロジェクトについていろいろ見せていただいたりしていました。

 

入社後の新卒研修

f4samuraiの新卒社員は例年、入社後2カ月間研修を受け、6月から現場配属される流れになっています。

研修スケジュールは、ざっくり分けると4月が座学中心の講義期間、5月は新卒の同期メンバーでゲーム制作を行う演習型の研修期間という二部構成になっていました。

(研修中には、役員陣とお話する機会もありました。写真は金さんとの座談会)

 

4月:講義期間

4月の講義では、さまざまな職種・チームのリーダークラスの方に登壇いただき「そのチームはどういう仕事をしているのか」「他職種と実務でどのように関わっているのか」などについて教わりました。

ゲーム制作の知識がない新卒社員もいるため、技術面は基本的なことが中心でした。自分の場合は学生時代に学んだことと重複する部分もありましたが、あまり触れてこなかったシナリオライターの業務内容や制作工程についての講義や、この会社ならではの職種の関わり方についての話など、新たに得る知識も少なからずあり興味深かったです。

 

5月:同期とのゲーム制作

5月のゲーム制作演習では、新卒だけで「社員旅行の宴会を盛り上げるゲーム」を作ることになりました。

f4samuraiでは毎年6月に社員旅行を開催しており、夜の宴会ではクイズ大会やゲームなどを実施しています。昨年までもゲーム制作の研修は行っていたのですが、今年初めて「研修で作ったゲームを社員旅行でみんなに遊んでもらう」ことになりました。

今年の新卒は、3名のプランナーとエンジニア(僕)の合計4名。プランナーの3人は全員ゲーム制作未経験ということもあり、僕はエンジニアとしてのシステム開発はもちろんのこと、学生時の制作経験を活かしてみんなのサポートもするという少々ハードな1ヶ月間を過ごしました。

 

制作スケジュールは、

  • 【企画編】最初の1~2週間ほど各自で企画書を制作しコンペを実施
  • 【設計編】選ばれた企画を次の1週間程度で仕様に起こす
  • 【実装編】最後の2週間で実装する

という流れでした。

 

「社員旅行で遊ぶ」という明確なゴールがあったので、面白いゲームならなんでもいいという訳ではなく、プレイする様子を見ている側も楽しめること、みんなの視線を一画面に集めて盛り上がれること……などを考慮する必要があり、企画のアイデア出しから全員で苦戦しました。

 

実装期間にも余裕がない中、エンジニアが一人ということでプレッシャーもあったのですが、同期のプランナー陣がノーコードで実装できる部分を自分たちで実装できるようUnityの使い方を勉強してくれたり、デザイナーがいない中デザイン素材制作をすべて担当してくれる人がいたり……最終的には4人が一つのチームとして協力しながら作りきることができました。

また、講師やメンターの方など、色んな先輩方が技術面でも仕様面でもたくさんアドバイスをくださって、かなりサポートしていただきました。

 

結果として、ゲームは無事完成し、役員陣や一部先輩社員にテストプレイしていただいた時には大いに盛り上がり、皆さんからご好評いただきました。

社員旅行でのお披露目はこれからですが、手ごたえを得られる結果でよかったです!

(テストプレイにご協力いただいた先輩方。楽しそうに遊んでいただけて嬉しいです!)

 

今後の抱負

先述の通り、6月から正式に現場配属となり、僕は運用中のプロジェクトに参画しました。

今はトレーニング期間として一つひとつタスクや課題を与えていただいている状態ですが、将来的にはただ言われた通りに作るだけではなく、ゲームがより面白くなるような提案まで行えるエンジニアになっていきたいです。

そのためにも、プログラム以外のことにもアンテナを張り、チームから信頼される人間になりたいと思います。

 

まずは今のチームのメンバーとして、1日も早く一人前になれるよう頑張ります!

また成長した姿をお見せできるタイミングで、ブログのほうにも顔を出せたらと思います。

 

今後ともよろしくお願いします!舘でした。

「長期運用」に基づく資産の形成

はじめに

みなさんこんにちは。ネイティブエンジニアの宮﨑です。

今回は社内の第2回技術記事コンテストに投稿した記事を紹介します。

技術記事コンテストには毎回テーマがあり、第2回のテーマは「今のプロジェクトで変えたいところ」でした。

私がテーマに掲げたのは「長期運用」に基づく資産の形成です。

どうも資産運用っぽいタイトルになりましたが、プロジェクト運用の話です。

 

バトルスキル開発コストの悩みと中長期的な設計の重要性

さて、今日のゲーム開発において一つ悩んでいることがあります。それは「ゲームキャラクターが持つバトルスキル」の開発コストが下がらないことです。

私は現在、運営タイトルを担当しています。このタイトルには新規開発時から所属していました。

今振り返ると、リリース前の開発期間では分析や設計に十分な時間を割けませんでした。目の前の要望に応えることに注力し、中長期的な展望を見据えることが出来ていなかったのです。

また、リリース当初のスキル実装には多くの「バリエーション」が不要であったため、将来的なニーズを見落としていました。

今必要でない機能の優先度が下がり、「必要になったタイミングで改修する」という判断が下されましたが、いざ運用が始まると「動作保証」が重要になり、既存スキル全てに影響するような大規模な改修は容易にできなくなりました。

具体的には、「開発コスト削減のためのプログラム修正」という売り上げに直接反映されない業務を行いたかったのですが、それをすると「QAによる既存スキル全チェック」という工数が発生することになり、運用が進むほどコスト削減のためのプログラム修正が困難になりました。

「運用が落ち着いたら改修しよう」ではなく、「運用が始まる前に」「先を見据えて」設計しておく必要があったのです。

 

開発コストが下がらない2つの理由:バリエーションの増加と複雑なスキル管理

開発コストが下がらない原因の一つ目は、常に「バリエーション」が増加することです。

スキルの「効果」や「条件」など、毎月新要素を開発しています。新たな機能追加であり、遊びの幅を広げることに工数が発生するのは仕方のないことです。

原因の二つ目は、「効果」と「条件」の組み合わせを1スキルとして実装してしまったことです。2つを組み合わせるために、常に追加で実装が必要になる設計にしてしまったのです。

この原因が曲者で、新たなスキルを開発するには、常にエンジニアがコードを書く必要があります。

毎月新スキルが5個追加される場合、5つのクラス・PRが発生し、これらの開発コストは常に発生します。

 

開発コスト削減のための3つの対策

対策としては以下3つが考えられます。

①マスタ上で柔軟なスキル表現を可能にする
②Unity機能を利用する (ScriptableObject)
③Unityコード内での「バリエーション」開発を容易にする

 

マスタ上で柔軟なスキル表現を可能にする

現在の設計を見直すなら、スキル効果とスキルの発動条件を分けてクラス実装し、マスタにて自由に組み合わせて使えるようにするべきでした。、このようにしておけば、スキルの効果やスキルの条件それぞれが、開発資産として蓄積されます。そして、効果・条件をマスタの設定で組み合わせることで、エンジニア作業無しで新スキルを無数に生み出せることになります。

現状ではエンジニアが最終的な出力に関わることで、毎月のスキル作成数が制限され、工数が増えるという問題が生じます。しかし、これらの資産をプランナーが自由に組み合わせられることで、初めて資産の有効活用ができていると言えるのではないでしょうか。

 

②Unity機能を利用する (ScriptableObject)

プランナーがUnityでバランス調整を行うのであれば、ScriptableObjectでスキルの効果種別、発動条件、効果範囲などを組み合わせる案もあります。しかし、運用が既に始まっているケースでは一部パラメータのみをScriptableObjectで定義すると見通しが悪くなるため、採用を見送りました。

 

③Unityコード内での「バリエーション」開発を容易にする

そのため、今のプロジェクトでは既存の設計やスキル挙動に影響を与えず、エンジニア作業の効率化を目指しました。

既存スキルには手を加えず、新たなスキル構成クラスを利用することで、「効果」と「条件」の組み合わせを容易にしました。

改修効果はアプリ開発に留まり、スキル関連クラスの見通しが若干低下するなどのデメリットもありますが、エンジニアの開発工数削減やエラー率低下に寄与しています。

 

マスタでの定義による効率化と次期プロジェクトへの展望

今回は、現在運用しているプロジェクトの「スキル開発」についてより良い設計・運営方法を検討してみました。

スキル開発における「効果」「条件」をマスタで定義可能にしておけば、エンジニアの作業なくプランナーのみで新たにスキルを生み出せます。

現在のプロジェクトではマスタ変更は難しいですが、次の新規開発ではこの経験を活かして開発を行いたいと思います。

私が所属するf4samuraiについてはこちらをご覧ください▼

speakerdeck.com

調査のコツは「思考を全部書き殴ること!」 

 

はじめに

ネイティブエンジニアの桑田です。スマホゲームのプロジェクトでUnityを使った実装を担当しています。

今回は社内向けに書いた記事を紹介します。

記事のテーマは「今までで解決するのが一番難しかった技術的問題」だったのですが、ここではUnityのバージョンを2018から2021に更新した際のビルドエラーとの格闘を思い返しつつ、「仕事をうまく進める上でのちょっとしたコツ」と絡めて書きたいと思います。

 

本題

Unity2018からUnity2021へのアップデートは三世代アップということもあり、かなり大規模な変更を含んでいたので、修正内容はソースコードからビルド設定の変更まで多岐に渡りました。表面的なソースコードのエラー修正が終わり、エディタ上では動作に問題がないことを確認した後の、アプリのビルドやストアアップロード関連のエラーは特に原因が分かりにくく、苦労させられました。

 

エラーの原因を要約すると

 

  • UnityのFrameworkを生成する処理(2021で追加)よりも先にFrameworkを必要とする処理が存在した
  • 不要なFrameworkを削除する既存処理のせいで、本来必要なUnityのFramework(2021で追加)もまとめて消されていた
  • 普通に誤字があった

 

となるのですが、これらが複合していたため、どれか1つを正しても別の要因のせいでエラーになり、問題の特定が難しくなっていました。

これらの問題を修正して、アプリビルドとストアアップロードが無事に終了して安堵していたら、その後に「iOS12.2未満の端末でアプリが起動しない」という不具合に直面しました。

 

調査の結果、原因は「Swiftライブラリの追加を削除した」ことでした。

iOS12.2未満だと標準でSwiftライブラリが導入されていないため、アプリ側で追加する必要があります。

もともとは追加する設定になっていたのですが、色々な検証をしている最中に設定を外してしまっており、それによって問題が起きていました。

 

どれもこれも後から振り返ってみればシンプルな原因でしたが、これらの原因を特定するために行った調査、検証、修正はものすごく疲れました。

不具合を直すために処理を変えると別の不具合が起きたり、組み合わせ次第によって新たなエラーが起きたり……

実装意図のわからない古い処理や、普段わざわざ確認しない設定項目を洗う必要があり、さらにアプリの運用業務と並列して調査を行っているため、何日間も成果が出ないと焦りも募り、一歩も前に進められていないとどんどん苦しくなっていきます。

 

それでもなんとか調査を乗り越えて修正まで漕ぎつけられました。

そのコツは、検証作業ログを雑に書き殴っていたことだと思います。

弊社エンジニアの基本方針として、「なるべく調査・検証ログは資料として残して会社全体で共有しよう」というものがあり、自分も不具合の原因の詳細や調査内容についてはNotionページに書き残しながら作業をしていました。

「資料に残す」というと、どうしても綺麗に書かないといけないとか、理路整然としてなければいけないとか、ハードルが高く感じると思います。最終的な資料としてはそのほうが良いのですが、調査段階においては「思ったことを全部書き殴る」くらいの雑さのほうが良いです。

自分が書いていた実際のログを引用してみると、

 

「よくわからないが多分ここが怪しい」

「いや待て、ここの処理ってなんだ?」

ipaファイルが出力されてねえ!」

「この仮説通りならうまくいくはず」

「失敗。なんでだよ!!!」

「設定をOFFにしたら通ったっぽい!!!!!!!!! うおおおおおおおおおお!!!!」

 

と、主観や感想や感情がめちゃくちゃ入っており、とても全文を載せられないほど文章が荒れ狂っています。

答えを知ってから読み返すと道中の仮説は半分くらい間違っているし、めちゃくちゃ遠回りをしているし、文体もおかしいので資料としては失格です。

しかし感情を乗せまくったことで、自分がどこでつまずいていて、どこを怪しんでいて、何を勘違いしていて、どういう道程で答えに辿り着いたのかという流れは鮮明に理解できます。

 

真っ当な資料としては当然NGですが、未知のエラーを調査するときはこれくらい雑に思考を書き散らすほうが良いと思います。

これには以下のメリットがあります。

思考を書き出すメリット

 

1.仮説を言語化して可能性を一つ一つ潰していくのを視覚化できる

頭の中で考えてばかりだと結局どのような可能性が残っていて何を検証したのかがこんがらがってしまうので、文章化は大事です。

 

2.これまでの思考の流れを思い返せるので、以前の仮説を再現させやすい

検証には何日間もかかるので、どんどん最初に検証した内容を忘れていきます。

いろいろ考えたけどやっぱり最初の方法が正しかったなとなった際に、思考と検証のログを残しておけば当時の状況を再現させやすいです。

 

3.テンション感も記録できるので自分がどこで詰まっているのかわかりやすい

「どこで一番つまずいたのか」「何が一番わからなかったのか」というのは、綺麗な資料からは読み取れません。

生の感情を直接資料にぶつけて残すことで印象に残りやすくなり、今後類似する不具合と相対したときに気を付けるべきポイントがイメージしやすくなると思います。

 

4.思考の流れやテンションが視覚化されるので他者からアドバイスをもらいやすい

検証に他者の手を借りる場合、前提や仮説や感想など筆者の思考の流れが全部書かれた資料であれば

「ここの前提の認識に誤りがある」「この仮説であればこっちのアプローチのほうが良い」などの指摘を受けやすくなるでしょう。

結論だけ書いてしまうと、自分の調査内容に問題があったとしてもそれに気づいてもらいにくくなります。

また上述した通り、どこで一番つまずいているかも一目瞭然なので、調査を引き継ぐ際も便利です。

赤裸々な文章を人に見られるのは恥ずかしいですが、背に腹は代えられません。

 

5.成果が出なくても文章量が増えるので仕事してる感を得られて焦りが緩和される

これが割とバカにならなくて、検証して失敗して別の検証してを繰り返していると、目に見える成果が出ず無駄に工数を使っている感がしてどうにも気分が落ちていきます。

なかなか成果を出せない時間が続くと、短期間で成果の出る別の作業をやりたくなってしまいます。テスト勉強中に部屋の掃除を始めてしまうアレです。

しかし思考ログを全部書き殴ってると、その文章全てが作業の成果として蓄積されていくので、仕事した感が出て自分を満足させられ、ストレスが緩和されます。また、上司に対して「私はちゃんと仕事やってますよ」というアピールにもなります。

 

6.文章を書くハードルが下がる

ちゃんとした文章を書こうと思うとなかなか筆が進みません。

「ちゃんとしてなくていいからとにかく思ったことを全部書け!」の心持ちでいきましょう。

まとめ

この辺りのコツは、学生の座学とも通じるなあと思います。

黒板の板書をただノートに綺麗に書き写したり教科書の文章に蛍光ペンを引くだけでは頭に入ってきません。

ノートとは自分の思考を書き出して理解を深めるためにあり、綺麗に書くことそのものは目的ではありません。

そこに自分の感情を入れ込みまくって「これなんで?」「こうじゃない?」「こうなのか!」「じゃあこっちは?」「これだ!!!」と落書きをしまくることで自分だけのノートが出来上がり、自分に最適化されたノートが完成します。そうしたノートを読み返したほうが復習も捗るでしょう。

「授業中のノートはメモ書きとして扱い、授業が終わった後に復習がてら綺麗にまとめる」

というのは勉強法としては王道です。「東大生のノートは汚い」という風説もあります。(本当か?)

というわけで、私が思う仕事をうまく進めるコツは「調べ物をするときは、自分の思考の流れをだらだらと書き殴ろう」でした!

ゲーム業界でこれから働く新入社員に教えたいこと

はじめに

ネイティブエンジニアの松村です!

もうすぐ4月、新入社員が入社する時期ですね!

 

ゲーム業界は

「あのアニメや漫画のゲームを作りたい」

「こういうゲームシステムで世界中の人を楽しませたい」

といった夢を叶えられる素晴らしい業界です。

 

自分も、幸運にも何度か好きな作品に携われたこともあります。

新入社員の方々には、ぜひそのような夢を叶えてほしい、そういう思いを込めて、今回は「新入社員に教えたいこと」を記事にいたしました。

教えたいこと

自分が新入社員に教えたい事は

  1. 文章力
  2. コミュニケーション力
  3. ゲームをより好きになる事

です。

教えたい理由

この3つを教えたい理由は、自分が個人的にゲーム会社で働く上での基礎的な能力だと感じているからです。

そして、この3つを身につけると、業務を行う上で様々な部分が円滑になり、加えて学習というスキル自体にバフをかけたようなメリットがあると思っています。

どのような方法で教えるか

文章力を上げるには

まず、文章力を上げるには、日記を書くことをおすすめします。内容は人に見せなくて構いません。

仕事のことでも、趣味のことでも、書くテーマは自由です。日記を書くことで、日々の思考を言語化しアウトプットができるようになります。

例えば、

「今日は良い日だった。」

という粗い解像度で日々暮らしているのと

「今日は朝、限定販売のパンを購入することができた。前日早めに目覚ましをかけた努力が成果を上げた。昨日の自分に感謝したい気分だ。」

という細かい解像度を持っており、それを伝えることができるのとでは雲泥の差です。

どこが違うかというと

・出来事の原因を説明できている

・複数の出来事を関連付けられている

という点が違います。

前者の文は、なぜ良い日だったか原因がわかりません。
また、どうしたらその良い日を再現できるかもわかりません。

後者の文は、

・出来事をリストアップする

・出来事の関係性を考える

ことができており、この結果よい日を再現するための方法がわかり、他人にも伝えられるノウハウとなっているとも言えます。

実際に仕事を行っていると、スケジュール作成、工程管理、工数見積もり、デバッグ、そして実装に至るまで、あらゆる業務は文章化、言語化能力を必要とします。

このスキルは、日記を書く習慣から養うことができます。日記から発展して、日々の業務、学習したこと、遭遇した問題とその解決策を文章にすることで、思考を整理し、明確に表現する能力が向上するのです。

最初は思ったように文章を書けないかもしれませんが、上手く書けなくて悔しい、あの人のように素晴らしい文章を書きたい、と思うことこそが成長のきっかけとなると思っています。

コミュニケーション能力を身につけるには


コミュニケーション能力は、自分が好きなゲーム、アニメ、映画、食べ物など何でも構わないので、好きなものを語ることが能力を高めるきっかけとなると思います。

「昔のゲームって、ちまちまレベル上げするのが楽しかったよね〜」

「自由にマップを移動できるものが多く、好き勝手移動すると、突然強い敵がでたりして、そういうところも面白かったよね」

「考えてみると、この2つは関連しているよね、レベル上げすると、いろんなところに行けるようになる。これってまさに、作業と報酬になってる。昔のストーリーに縛られないゲームならではの魅力って、こういうことだったんだね」

このように、どこが面白いかを会話しているうちに、内容の深堀りをしたり、相手に伝わらないことを更に解像度を上げて説明をしたりと、思考力やコミュニケーション能力が鍛えられます。

聞き手側が「どこが好きなの?」とか「それは違うんじゃない?」とか話を深堀りしてくれる人だと、より成長が早くなるのではないかと思います。

この能力を若くして身につければ、仕事を円滑に進めたり、自分の環境を自分でコントロールしたりすることができるようになります。

自分の中で悩みや問題を溜め込まずに、個人、そしてプロジェクトの成長や進行を促進するコミュニケーション能力は早くに身に着けてほしい能力です。

ゲームをより好きになって、いろんなゲームを知る

就職活動の時によく業界研究と言われるように、ゲームを作るならゲームについて知ることが、仕事をするために重要です。

このために必要なことはゲームを好きになり、ゲームをたくさん遊ぶことです。

この能力は、業界で働いていくうえで大事な能力である以上に、楽しくゲームを作るうえでの重要な能力です。

例えば、

「デッキ構築型のローグライクなカードゲームに、強化や進化、限界突破を入れてマネタイズしたいんだよね」

とプランナーから言われた時に、各々のゲームの要素を知らなければ、非常に苦労します。

逆にゲームをやっているだけで

「ああ、あれとあれを組み合わさればいいのか!」

と理解でき、コミュニケーションが円滑になり、仕事の着手が早まります。

もちろん、すべてのゲームをプランナーレベルで知る必要はありませんし、わからない時は質問することができれば問題ありません。

そして質問に答えてもらった時に、「それは面白そうだね!」とポジティブに業務に取り組むことができれば、自分もチームも楽しくゲームが作れるかと思います。

ここで一つ例を出すと、実際のゲーム開発では

「キャンプの楽しさをゲームに落とし込みたい!」

といった意見が出ることもあるかもしれません。この時重要になるのは、今までのゲーム経験とどうすればゲームになるかを考えられることです。

そのために、ゲームをより好きになり、色んなゲームを知っておいてほしいです。

まとめ

今回は「新入社員に教えたいこと」というテーマで、自分の考えをまとめさせていただきました。

文章力、コミュニケーション力の向上は時間がかかるものなので、日記を書いたり、好きなものを語るなどを習慣として、あせらず続けていくことをオススメします。

そして、エンジニアとしては技術力も非常に重要ではありますが、この業界で充実した毎日を過ごすために、ゲームをより好きになって、知識も夢も目標も大きく広げていってほしいと思っています。

Apple Privacy Manifest対応でやるべきことについて

はじめに

みなさんこんにちは。ネイティブエンジニアです。
今回は『Privacy Manifests』対応についてやるべきこと、実際に取り組んでいることを説明いたします。

 

『Privacy Manifests』とは、Appleにより提供されるプライバシー対策のアップデートです。2024年春より実施されることが通達されており、対応しないとアプリの審査が通らず、リジェクトされると言われています。

 

2024年春の実施開始となると、早ければあと1ヶ月となります。具体的な対応期限や、どれほど厳しく運用されるかは通達されていませんが、Unityのアップデートが必要な可能性もあり、早期に準備をはじめ、理解をしておくことが望ましいです。

対応が必要なこと

まず、対応が必要な項目についてリストアップしました。

  • Xcode15を使いPrivacy Manifestsを出力できるようにする
    • Privacy Manifestsを作成し、以下の内容を記載する
  • Privacy Manifests対応がされたSDKを使用する
    • コード署名のあるSDKを使用
  • Unityを使用している場合、Privacy Manifests、署名対応がされたバージョンに更新する


Xcode15の使用

Privacy Manifests を作れるのはXcode15からです。
また、4/29 からXcode15の利用が必須となるため、早めのアップデートを行いましょう。

 

この時、MacOS Sonomaにアップデートすると基本的にXcode14以前が使えなくなります。
Xcode14も必要な場合は、Ventureをインストールするなどで対応しましょう。

Privacy Manifestsの作成

最初にPrivacy Manifestsの作成方法を説明します。

Xcode15を開き
File > New > File …から、ResourceのカテゴリにあるApp Privacyを選んでください。


PrivacyInfoと初期の名前が設定されています。こちらは変更しないでください。
ビルド対象を指定するTargetも選択してください。


作成すると以下のように空のPrivacy Manifestsが作成されます。



Privacy Manifestsの記載

Privacy Manifestsには以下の内容を記載することが必要です。

  • ATTの使用状況と、トラッキングドメインの記載
  • 使用しているデータとタイプの記載
  • 使用しているRequiredReasonAPIの記載

一つ一つ確認していきます。

 

ATTの使用状況と、トラッキングドメインの記載

ATT(App Tracking Transparency)とはアプリ起動時に

「(アプリ名)が他社のAppやWebサイトを横断してあなたのアクティビティの追跡をすることを許可しますか?」

を表示し、パーソナライズした広告提供のため利用されるIDFAの使用時にユーザーの同意を求めるものです。
ATTを使用している場合は、Privacy Tracking Enabled (NSPrivacyTracking)を選択し、YESにしてください。

 

そして、ATTで使用するトラッキングの通信先のドメインを、Privacy Tracking Domains (NSPrivacyTrackingDomains)により設定してください。
Privacy Tracking Domains を選択し、(+)ボタンを押すか、右クリックからのAdd Rowのメニューから行を追加し、ドメインを記載してください。

使用しているデータとタイプの記載

アプリが収集する、ユーザーのデータのカテゴリと、データを収集する理由を記載します。

 

記載すべき内容は、App Store Connectのアプリのプライバシーの内容と同じであるため、その内容を確認し、Privacy Manifestsに記載していきます。


元となる情報源はこちらです。
新規アプリではこの内容を確認し設定していきましょう。

developer.apple.com

 

データの用途は、Privacy Nutrition Label Types(NSPrivacyCollectedDataTypes)に記載します。
データごとに記載が必要な項目とその意味は次の通りです。

 

Collected Data Type 収集するデータの種類

Collection Purposes 使用の目的

Used for Tracking        トラッキングに目的に使用しているか

Linked to User        ユーザーのアイデンティティに結びつくデータか



「トラッキング」や「ユーザーに関連付けられたデータ」という言葉は、以下のように理解をしています。

 

ユーザーのトラッキングに使用されるデータ(Data Used to Track You)
アプリを通じて収集された後に、第三者と共有されるデータ

ユーザーに関連付けられたデータ(Data Linked to You)
アプリが収集した後、誰のものであるか認識されるデータ

ユーザーに関連付けられないデータ(Data Not Linked to You)
アプリが収集した後、ユーザーには紐づけられず匿名なデータ

 

正確な情報については以下のAppleのサイトをご確認ください。 

developer.apple.com

 

Required Reason APIの使用の記載

Privacy Accessed API Types(NSPrivacyAccessedAPITypes)

 

以下にリストアップされる、使用理由の登録が必要となるAPIに関しては、アプリの実装状況を調べてPrivacy Manifestsへの記載が必要です。

developer.apple.com

 

Unityでアプリを開発している場合こちらのサイトにある
「Unity の C# .Net Framework API」を参考にしてください

docs.unity3d.com

 



例えば、UserDefaultsの場合、Privacy Accessed API Typesを追加し、
Privacy Accessed API TypeにUser Defalutsを選択、
Privacy Accessed API Reasonsは以下の、User defaults API項目より、該当する利用の選択肢を全て選んでください。

developer.apple.com

 

Required Reason APIの使用状況の検索

実際に、APIを洗い出す方法を説明します。
iOSのネイティブコードはこちらを検索

developer.apple.com

 

Unityの場合、以下記載のAPIソースコードから検索します

docs.unity3d.com

 

grepでも検索できますが、ripgrepのほうがより高速に検索できるため

brew install ripgrep

でインストールし、以下のコマンドで検索します
(※ripgrepはテキストのみ対応でバイナリ検索は行わないことは注意してください)

 

UnityのAPI検索のため csファイルの検索を実行する場合

rg --type cs \

   -e 'fileInfo.CreationTime' \

   -e 'directoryInfo.CreationTime' \

   -e 'fileInfo.LastAccessTime' \

   -e 'directoryInfo.LastAccessTime' \

   -e 'fileInfo.LastWriteTime' \

   -e 'directoryInfo.LastWriteTime' \

   -e 'fileInfo.CreationTimeUtc' \

   -e 'directoryInfo.CreationTimeUtc' \

   -e 'fileInfo.LastAccessTimeUtc' \

   -e 'directoryInfo.LastAccessTimeUtc' \

   -e 'fileInfo.LastWriteTimeUtc' \

   -e 'directoryInfo.LastWriteTimeUtc' \

   -e 'File.GetCreationTime' \

   -e 'Directory.GetCreationTime' \

   -e 'File.GetLastAccessTime' \

   -e 'Directory.GetLastAccessTime' \

   -e 'File.GetLastWriteTime' \

   -e 'Directory.GetLastWriteTime' \

   -e 'File.GetCreationTimeUtc' \

   -e 'Directory.GetCreationTimeUtc' \

   -e 'File.GetLastAccessTimeUtc' \

   -e 'Directory.GetLastAccessTimeUtc' \

   -e 'File.GetLastWriteTimeUtc' \

   -e 'Directory.GetLastWriteTimeUtc' \

   '/path/to/unityproject'

 

iOSのネイティブコードを検索する場合

rg -i  \

   -e 'creationDate' \

   -e '\.modificationDate' \

   -e '\.fileModificationDate' \

   -e '\.contentModificationDateKey' \

   -e 'getattrlist\(' \

   -e 'getattrlistbulk\(' \

   -e 'fgetattrlist\(' \

   -e 'stat\.st_' \

   -e 'fstat\(' \

   -e 'fstatat\(' \

   -e 'lstat\(' \

   -e 'getattrlistat\(' \

   -e 'systemUptime' \

   -e 'mach_absolute_time\(' \

   -e 'volumeAvailableCapacityKey' \

   -e 'volumeAvailableCapacityForImportantUsageKey' \

   -e 'volumeAvailableCapacityForOpportunisticUsageKey' \

   -e 'volumeTotalCapacityKey' \

   -e 'systemFreeSize' \

   -e 'systemSize' \

   -e 'statfs\(' \

   -e 'statvfs\(' \

   -e 'fstatfs\(' \

   -e 'activeInputModes' \

   '/path/to/unityproject'

 

バイナリファイルから見つける場合はこちらのサイトで紹介されていた
nmというコマンドを使うようです。

buildersbox.corp-sansan.com

 

このコマンドは、アプリのAPIを調べるときには必要なさそうですがSDKで使われているかをチェックする時に使えそうです。

 

Privacy Manifests対応のSDKを使用する

Privacy Manifests対応は、アプリで使用しているSDKに対しても求められます。

 

アプリの箇所で説明した

  • 使用しているデータとタイプの記載
  • 使用しているRequiredReasonAPIの記載

が必要となります。
加えて、以下のSDKについては署名対応も必要となります。

 

developer.apple.com

 

SDKの対応状況については、詳細にまとめてくださった方の情報を紹介させていただきます。

dev.classmethod.jp

 

Unityを利用している場合は

C#のコードで提供されるSDK
自分でデータタイプ、RequiredReasonAPIを確認しPrivacy Manifests対応を行う

 

iOSのバイナリがある場合
SDKの提供元のPrivacy Manifests対応SDKを使用する

 

といった対応になります。
プロジェクト、会社ごとに使用しているSDKは違うため、社内で使用しているSDKリストを作成し、確認していくことをおすすめします。

 

SDKの対応状況確認

SDKのPrivacy Manifests対応は、提供元が対応しないと完了しません。
以下のような手順で、会社のプロジェクト全体で整理したうえで、SDK対応を進めていくのがいいかと思います。

  1. SDK Privacy Manifests対応リストの作成
  2. 公式サイトの確認
  3. GitHubリポジトリのRelease状況、Issueの確認
  4. SDK提供元への問い合わせ


SDKへの署名

SDKに対してのコード署名は、Appleが名指ししている以下のSDKは対応が必須です。

developer.apple.com

 

この中にはUnityFrameworkも含まれているため、Unityのアップデートも必要になります。
こちらは後述いたします。

 

Xcode15で、XCFrameworkを確認すれば、以下のような表示でSDKに対する署名の状況がわかります。



詳細についてはこちらのドキュメントや

developer.apple.com

 

こちらの動画で説明されていますのでご確認ください。

developer.apple.com

 

Privacy Manifests対応のUnityを使用する

UnityはAppleから名指しされているSDKであるため、Privacy Manifests対応・署名対応が行われたバージョンを使用する必要があります。
Privacy Manifestsに対応されているUnityは以下のバージョンからとなります。


Unity2021.3.35f1
Unity2022.3.18f1
Unity2023.2.7f1

 

署名については、上記バージョンでは対応されていないようなので、対応後のバージョンアップが必要です。

 

Unityで作ったアプリのPrivacy Manifests対応

Unityで作ったアプリのPrivacy Manifests対応は、この資料の前半で説明した手順でXcode15でPrivacyInfo.xcprivacyを作成し Assets/Plugins(またはAssets/Plugins/iOS)フォルダにいれることで、Unity側のPrivacy ManifestsとアプリのPrivacy Manifestsが統合されます。
詳細は以下をご確認ください。

 

docs.unity3d.com

 

まとめ

今回は『Privacy Manifests』についてやるべきことを書きました。

執筆時点での情報に基づいているため、情報が古くなっていたら申し訳ありません。


Unityについてはこちらのフォーラムでも、Unity社内の人も含めた情報交換が行われているので参考になります。このフォーラムによると署名処理はまだ実装されていないようです。

forum.unity.com

 

今回調査した結果、アプリ自体のPrivacy Manifests対応は、そこまで時間がかかるものではないようです。しかし、Unityやその他SDKのアップデートは、SDK提供元の対応が必要ですし、最新版へのアップデートは互換性を保つための修正や動作確認に時間がかかることが予想されます。そのため、早期に準備しておくべきだと感じました。

 

今回の記事が参考になりましたら幸いです。

新卒のインストラクターだったらコードリーディングを教えたい

前置き

CTO/CHROの松野です。
最近は暖かい日も増えてきて、春を感じるようになりました。f4samuraiにも、4月には4名の新入社員が入社する予定です(この文章「4」が多いですね)。

そこで今回は、僕が新卒時代に教わって今も役に立っていることを書きたいと思います。

新卒で教わったこと

新卒で入社した会社はSIerでした。そこで最初に配属されたプロジェクトがオープンソースソフトウェア(OSS)を調査研究するプロジェクト」でした。

僕は2003年入社なのですが、当時はいろんなOSSが誕生していました。中にはエンタープライズ用途を想定したOSSもありましたが、金融業界や流通業界などミッションクリティカルなシステムにも使えるのか?を調査をするプロジェクトです。

調査したOSSを例にあげますと、

などがありました。会社で一番使われていたプログラミング言語Javaなので、Javaで書かれたソフトが多いです。

ちゃんと使えるかどうかを判断するために、OSSなのでソースコードを読んでみよう、ということで、先輩と一緒にコードリーディングをしていきました。

コードリーディングの進め方

コードリーディングについては、以前このブログで掲載した他メンバーの記事も参考になりますので、ご覧下さい。

f4samurai.hateblo.jp

この記事と違うのは、対象がプロジェクトのコードではなく、世の中で広く流通しているオープンソースだ、というところでしょうか。

最初に読んだソースコードJUnit

JUnitは、ソフトウェア開発において自動テストという概念を持ち込んだ画期的なソフトウェアです。 JavaのプログラムをテストするコードをJavaで書くためのライブラリで、ご存じの方も多いと思います。

JUnitソースコードは、GitHubで公開されています(僕が見たのはJUnit4なのでリンクもJUnit4に貼りますが、最新バージョンはJUnit5ですね)。

github.com

コードを見ると分かるのですが、めちゃくちゃきれいなんですよね。 本当に見本みたいな書き方がされていて、心が震えたことを覚えています。

もう一つすごいのは、JUnitのテストコード自体も、JUnitで書かれていることです。自分自身で思想を体現しているし、テストコードのサンプルにもなっているし、このソフトウェアの中ですべてが完結していて美しいです。

対象のソースコードが多い場合は

OSSによっては、ソースコードの量がめちゃくちゃ多いこともあります。その場合は、

  • ディレクトリ単位で、どんな機能を持っているの考える(仮説を立てる)
  • 重要そうなソースファイルをいくつか開いて、仮説を検証する
  • それぞれの機能がどのように結びついているのかを確認する
  • HTTPリクエストの処理や、サーバの起動処理など、一つのシーケンスに沿って処理を追う

などがポイントかなと思います。

やって良かったこと

コードリーディングの対象がオープンソースだったので、一流のエンジニアが書いたソフトウェアを読むこと自体がとても勉強になりました。

 

例えば、デザインパターンを勉強したときに「概念は分かるけどどうやって使うの?」と疑問に思っていたのですが、実際にオープンソースとして実装されているのを見ることで理解を深めることができました。また、コメントはこの粒度で、こういった内容を書くといいのか、みたいなことも参考になりました。

 

僕は最近CHROの業務割合が多くなり、プログラミングからは離れているのですが、たまに人手の足りない新規事業チームから「アプリの改修したいんだけど、やってもらえませんか?」とお願いされることがあります。
全然知らない人が書いたコードを渡されても、あまり抵抗感なく読み始められたのは、新卒のときにコードリーディングをやっていたおかげかな、と感じて、新卒時代の僕に感謝しています。