f4エンジニアブログ

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

2023年サマーインターンシップ振り返り~企画編~

はじめに

エンジニアの松村です!
今回は夏に行われたサマーインターンを(今更ですが……)振り返ってみようと思います!
記事が長くなったので、「企画編」と「運営編」の2回に分けたいと思います。今回の振り返りは企画編です。社内でインターンの企画を作る際にどのような事を考えていたかを説明します。みなさんが企画を考えるときの参考になれば幸いです。

2023サマーインターンの内容

今年行われたサマーインターンは、2023年9月6日(水)〜 9月8日(金)の3日間で開催しました。1チームがプランナー3名、エンジニア2名、UIデザイナー2名の7人で構成され、合計4チームで行いました。

このサマーインターンは、UIデザインリーダー、COO兼ディレクター、エンジニアリーダー、採用担当の人事メンバーが企画段階から集まって相談しながら作り上げたものです。

自分は、まだ入社2年未満ですが、会社の大事にしているものや、魅力の伝え方を整理してサマーインターンの内容を決めていくのはとても楽しい仕事でした!

話し合って完成した、サマーインターンの内容は、

「f4samuraiで運営していたタイトルの素材を使い、オリジナルのカードゲームを作る」

というものです。

今回カードゲームをテーマにしたのは、今後スマホゲーム業界で働く時にはかなりの確率で作ることがあるだろうと考え、少しでも将来に役立てばと思いこのテーマとしました。

 

サマーインターンを通して伝えたかったこと

スケジュールを立て、期間内に要望を実現する

サマーインターンで伝えたかったことは、実際のゲーム開発で重要なポイントを肌で感じとってもらうことです。

特に、ゲームを開発するエンジニアとして意識してもらいたいのは、スケジュールを意識し、期間内に要望を実現することです。

そのため、今回のサマーインターンでは、最初のオリエンテーションで以下のようなスケジュールを説明し、作業を進めてもらいました。

自発的に振り返りを行いPDCAを回すチームや、分業をして作業をするチームもあり、素晴らしい理解力と実践力をもった学生さんに出会うことができ自分も刺激を受けました。

 

 

ゲームの基盤・ライブラリを作成し、品質と開発速度を向上させる

次にゲーム開発のエンジニアとして意識してほしいのは、基盤やライブラリを作り、品質や開発速度を向上させるということです。

毎回、何を作ればいいか悩んでいたり、フルスクラッチでゼロからゲームを作っていると、非常に工数がかかってしまいます。

このため、各ゲームで必ず作るものを基盤やライブラリとしてまとめていくことが重要です。

そのためには、ゲームがどうやって作られているかを理解することが最初のステップです。ゲームを完成させるには何が必要かが言語化できていれば、クラスや関数化を行いゲーム基盤のライブラリを作り始めることができます。

今回一例として、以下のようなゲーム基盤のまとめ方を提示しました。

 

「データ構造」は、プレイヤーやエネミーのHP、カードの攻撃力、スキルなどゲームのベースになるものです。まずは構造化されたシンプルなデータを用意することで、思考の整理ができ、作るものが明確になってきます。

 

次の「確率処理」は、繰り返し遊べるゲームには必須の重要な要素です。

すぐに最適解がわかり、プレイヤーが操作する必要がなくなってしまうと、ゲームとしての面白みがありません。面白いゲームにはこの確率的要素が必ずといっていいほど存在します。 

 

「演出基盤」は、パーティクルを出したり、エフェクトを入れたり、UIをアニメーションさせたりと、ゲームを快適に、理解しやすく、没入感を高めるために必須の機能です。短い時間の開発なら、何が必要かをしっかり意識してすり合わせ作ることが重要です。

 

最後に「カードゲームのシステム」、手札、山札、捨て札、ドロー、使用など、カードゲームには優れたゲームメカニズムがたくさん既に提案されています。

予めこのようなものが必要であると理解し、クラスなど構造化して実装することができれば、変更や拡張もしやすい質の高いゲーム基盤へと繋がります。

面白さの具体化を行う方法

加えて、エンジニアが企画を実装していく上で必要になる、面白さを形にしていく方法についても説明を行いました。

企画が提案された直後は、ゲームの面白さが仕様として詳細にまとまってない時があります。

そのようなとき、例えば下記の「ハリウッド映画のようにかっこよくしたい」といった漠然とした提案に対して、要素を分解して言語化し、作業にまで落とし込んでいくことができれば、開発が前に進むといった話をしました。

 

 

インターンを実施した感想

インターンを実施した感想として、まずは、参加してくれた学生のみなさんがゲーム作りを楽しんでくれたのが一番うれしかったです!

短い時間で作りきるには、楽しいだけではなくプレッシャーもあったかと思います。

その中で、積極的に質問したり、チームの中で助け合いアイデアを形にしている参加者の姿を見ると、ゲームをチームで作る上で重要なことを改めて振り返る事ができました!


インターンの振り返りはこちらにもまとめてありますので、興味ある方は是非ご覧いただければと思います!

note.com

 

そして、f4samuraiの文化に触れられたのも良かったです!

企画時には、数々のヒット作を生み出したディレクターやリーダーと議論し、参加する人の気持ち、得られるもの、サマーインターンまでに必要な準備など、様々な視点から議論ができました。結果、昨年度のサマーインターンからより進化できたと思います!

日頃から朝会の中で雑談時間を設けているなど、コミュニケーションを重視している事は感じていたのですが、サマーインターンの企画を進める中で、一人ひとりの意見を尊重した上でよりよいものを作っていくというf4samuraiのスタイルを改めて感じられたのは貴重な体験でした。

来年はよりf4samuraiらしく、そして学生の皆さんが成長できるサマーインターンにできればと思っております!

今年も1年ありがとうございました。来年もよろしくお願いいたします!

 

 

 

ChatGPTなどの大規模言語モデル (LLM)の能力と、ゲームへの活かし方の考察

はじめに

エンジニアの松村です!

 

12月、街はイルミネーションが華やかで美しい季節ですね!

自分の場合、職業柄、イルミネーションの歴史を調べたり、見せ方を分析してゲームに活かせないか考えて楽しんでいたりします(笑)

 

さて、今回は、以前ゲームのPR施策で活用した、ChatGPTを代表とする大規模言語モデル(LLM)を題材といたします。

今年は、AIについての大きな発表が多く、日々新たな進化が見られてほんと楽しい年でした!

改めてどのようなものかを振り返り、ゲームでの応用案をご紹介したいと思います!


ChatGPTとはなにか

OpenAIが開発した大規模言語モデル(LLM)を活用した人工知能チャットボットです。

非常に強大なデータセットディープラーニングを用いて構築された言語モデルであり

人間のトレーナーを使用してモデルのパフォーマンスを改善しています。

 

ChatGPTの仕組み

ChatGPTの理解にはこちらの記事が参考になります。

ChatGPTのTop PやTemperatureについて少し知ってみよう - Ateam Tech Blog

簡単にまとめると、ChatGPTは大量のデータに基づき、一番生成される確率の高い文章を出力するように動作します。

過去のAIに対して、近年のChatGPTをはじめとしたLLMが大きく発展したのはTransformerというアルゴリズムによるものです。

ChatGPTを動かす機械学習モデルTransformerをゼロから理解する。|es

この中のAttentionという仕組みによって、単語の関連性を計算できるようになり、入力された文章に対して関連度が高い重要な情報を出力できるようになった、と私は解釈しています。

自然言語処理モデルを直感的に理解したい(1) Transformer

これらの仕組みによって、当初想定されていたよりも様々な能力が、LLMを用いたシステムで実現出来ています。小規模のモデルでは見られない能力が、大規模なモデルでは突然生まれる、創発と呼ばれる現象が起こっているようで、まさにSFのような世の中になってきていると感じました。

LLMでできること

では実際に、LLMができることにどのようなものがあるか、整理してみます。

 

検索

まずは検索です。

 

入力

日本の都道府県で一番大きいのは北海道では一番小さいものは?

 

出力

日本の都道府県で一番面積が大きいのは北海道です。一方、一番面積が小さいのは香川県です。

 

 

翻訳

続いては日本語から英語への翻訳。

入力

ゲーム会社は最先端技術を学び新たな遊びを常に生み出さないといけません

 

出力

Game companies must constantly learn cutting-edge technologies and create new ways to play.

 

 

創作

入力

ソーシャルゲームを題材に575の俳句を作ってください。

 

出力

夏の夜 熱く闘うは レイドボス

 

 

 

このように、一番確率の高い文章を出力するというというベースはあるものの、文章を細かく解釈し、様々なアウトプットを実現できます。

ゲームでの使い方

LLMが持つ、文章を解釈し、多様な表現を実現する機能は、新たなプログラミングとも捉えられる面白いものです。これをゲームではどのように使えるか、自分なりに整理してみました!

以下のような機能がゲームに活かせると感じています。

  • 世にあるルールや現象をベースとした判断を出力できる
  • 指定した設定の人間のように振る舞える
  • ルールに基づきゲームを運用できる

この機能を使えば、例えば脱出ゲームのゲームマスターや、サバイバルゲームのルール・演出作成などを行えそうです。

実例を説明していきます。

ChatGPT活用例1  脱出ゲームの作成

まずは、脱出ゲームをチャット上で実現する例を説明します。

この例では、ルール作成、ルールに応じたゲームの運用、プレイヤーキャラクターの詳細な行動の生成が実現できています。

 

人間の入力

ホテルの一室に捉えられた天才エンジニアが主役の脱出ゲームを作ってください。 エンジニアの行動はチャットで指示します。

 

 

ChatGPTの出力

了解しました!脱出ゲームのシナリオを以下に作成します。

 

シナリオ: 場所: 未知のホテルの一室 登場人物: 天才エンジニア (プレイヤー)

背景:

ある日、天才エンジニアが目を覚ますと、自分が知らないホテルの一室に閉じ込められていました。部屋には窓がなく、扉もしっかりとロックされている。彼の技術を試すために、ある人物によってこの部屋に閉じ込められたのだとすぐに気づきました。彼は脱出するためのヒントやアイテムを見つけるために部屋中を探し始めます。

部屋の構造:

  1. ベッド(枕元にテーブルランプ)
  2. 机(引き出しが3つ)
  3. 本棚(様々な本が並んでいる)
  4. ドア(電子ロックがかかっている)
  5. 壁掛け時計
  6. コンピューター(パスワードロックがかかっている)

スタート: エンジニアが目を覚ますところから始まります。プレイヤーには部屋の状況を伝え、どこを調べるか選択してもらいます。

エンジニアのアクション例:

  1. ベッドの下を調べる。
  2. 引き出しを開けて中を調べる。
  3. 本棚の本を一つ選んで中身を確認する。
  4. コンピューターの前に座る。

脱出の手がかり:

  1. 引き出しには小さなドライバーセットが入っている。
  2. 本棚のある本の間に紙が挟まっていて、それがコンピューターのパスワードのヒントとなっている。
  3. コンピューターにはドアの電子ロックを解除するためのプログラムが入っているが、実行するにはパスワードが必要。

ここから、プレイヤーは指示を出し、脱出に必要な手がかりやアイテムを見つけるためのアクションを選択します。

さあ、どこから調査を始めますか?

 


人間の入力

本棚を調べる

 


ChatGPTの出力

本棚の状況

本棚にはさまざまな本が並んでいます。技術書、小説、アートブックなど、多岐にわたるジャンルの本が置かれています。ただし、一冊の本が他の本よりも少し前に突き出していることに気づきます。

エンジニアはその突き出している本を手に取ります。タイトルは「電子の世界」。中身をパラパラとめくると、ページの間に薄い紙が挟まれていることを発見します。

紙には次のように書かれています。

「最も素晴らしい技術はシンプルな中に存在する。」

このメッセージは一体何を意味しているのでしょうか?他の本も調べるか、このヒントを元に次のアクションを選択するか、選んでください。

 

 

このような感じで、今までは複雑なif文などでしか作れなかった世界やルールの構築を今までと違った方法で作成することができそうです。

ChatGPT活用例2 ルール、構成のコントロール

更にゲームをコントロールする方法を検討してみます。

方法は、より詳細な依頼を投げることで実現出来ます。


人間の入力

20人で行うサバイバルゲームのルールを作成してください。

プレイヤー層が一番多い世代を選び説明してください。 

マップは1時間の番組に適したサイズになるようにロケ地を選び説明 。

第1STAGEの内容を説明 。

キャラクターの設定も説明 。

勝敗判定の決め方、盛り上がりどころ カメラワークを考慮し、必要な台本 をアウトプットしてください。

 

 

ChatGPTの出力

  1. 客層: 20代から30代の若者。この世代はSNSの普及やリアリティーショーへの関心が高く、参加者や視聴者としての関与が期待されます。
  2. マップ: 海辺の無人島。森、浜辺、小高い丘などのバラエティ豊かな地形があり、1時間番組内で多彩なシチュエーションを生み出せる。
  3. 第1STAGE: 「資源争奪戦」。マップ上の特定の地点にサバイバルに必要なアイテム(食料、工具、武器など)が隠されている。参加者はそれらのアイテムを探し、他の参加者と争奪戦を繰り広げる。
  4. キャラクターの設定:
    • リーダータイプ: 戦略的で人々を引っ張っていくカリスマ性を持つ。
    • 知恵袋: サバイバル技術や知識に詳しい参加者。
    • 肉体派: 体力やアクションを活かすタイプ。
    • 策略家: 他の参加者との同盟や裏切りを駆使してゲームを進める。
    • お人好し: 素直で人間関係を重視するタイプ。
  5. 勝敗判定:
    • 最後の5人になるまでのサバイバルを目指す。
    • アイテムの取得数や他の参加者との協力・裏切りの結果、各ステージの終わりにポイントが付与される。
    • 最終的に最もポイントを獲得した者が勝者となる。
  6. 盛り上がりどころ:
    • アイテムの争奪戦
    • 参加者同士の協力・裏切りの瞬間
    • サバイバルの難関や意外な展開
  7. カメラワーク:
    • ドローンカメラで全体の様子を捉える。
    • アクションカメラで参加者の視点を取り入れる。
    • 隠しカメラやリアクションカメラで各参加者の感情やリアクションを捉える。
  8. 必要な台本:
    • オープニング: 司会者がルール説明。
    • 参加者自己紹介: 各参加者が自分の戦略や意気込みを話す。
    • サバイバルの各局面でのナレーションや解説。
    • クライマックスや結末を迎えるシーンでの背景音楽やナレーション。

この設定により、視聴者は参加者の心理戦やサバイバルの緊張感を楽しみながら、各参加者の成長や変化を見守ることができます。

 

ChatGPTはその特性上、より詳細なルールを記載するとそれにそって返答を作成してくれます。

文章のコンテキストをかなり詳細に把握して返答を作ってくれるため、キャラクターや世界観の設定をしっかり行えば、インタラクティブに生成される物語も作れるようになりそうです。

まとめ

ChatGPTを代表とする大規模言語モデル(LLM)を使うと、今まで実現が大変だった

  • 世にあるルールや現象をベースとした判断の出力
  • 指定した設定の人間のような振るまい
  • ルールに基づきゲームマスターを行う

といった設計、設定作成をAIが実行し、少ない工数で実現することができそうです。

今回は、文字のみでのアウトプットでしたが、ChatGPTはAPIも存在しており、画像が表示・配置できるゲームエンジンから実行する方法も研究されています。

マップエディタに組み込みデータ生成の助けとしたり、文字入力をして会話に反応してくれるキャラクターを作ったりと、ゲームエンジンと連動できると更に面白いことができそうですね!

スマートフォンが出た時のような可能性が広がる技術、今後も研究を続けて情報発信していこうと思います!

スマホゲームでのChatGPTの活用 アンジュ・リリンクのエイプリルフール施策

はじめに

今回は業務においてChatGPT を活用した件についてお話しします。
作ったものは、2023年4月1日(土)の24時間のみ公開された、エイプリルフール限定施策のWebサイトです。

 

 

▼本施策に関するプレスリリース

https://prtimes.jp/main/html/rd/p/000000081.000068754.html

エイプリルフールストーリーの概要

『アンジュ・リリンク』の公式HPにチャットAIが登場。青蘭学園の情報が搭載されたAIに対して自由にメッセージを送ることで、ストーリーが展開していきます。

 

<ストーリーあらすじ>

Dr.ミハイルが開発した最新鋭AIが突然、記憶を喪失してしまった!

あなたと日向美海はDr.ミハイルから依頼を受け、記憶を喪失し、ポンコツAIとなってしまったAIから聞き取り調査を行うことに。

最新鋭AIに何があったのか?

事件の真相を聞き出そう!

 

施策の仕様とポイント

・特設Webサイト上で、プレイヤーはチャット形式で自由に会話ができる。

・会話が10往復するまでの間に記憶喪失の原因を特定し、フォームに正解を入力すればクリアとなる。

・ロボットとの会話にChatGPT APIを使用している。

 

構成

Webフロントエンド (JavaScript)

AWS API Gateway

AWS Lambda (Python)

ChatGPT API

 

コスト

ChatGPT APIにリクエストするたびに、パラメータで渡す文字列とレスポンスとして返ってくる文字列のサイズ(トークン数)に比例して課金されます。実装時点で一番お安いgpt-3.5-turboモデルだと1000トークンごとに$0.002(0.27円)という設定です。トークンの計算方法は、日本語だと平均して0.91文字で1トークンに相当するのだそうです。

 

今回の仕組みだと、会話1回のリクエストごとにそれまでの会話履歴をまるごとパラメータにして送る形なので、会話の往復回数が増えるほど1リクエストあたりのトークン数が多くなっていきます。また、初期設定としてChatGPTに与える指示の文字数は毎回のリクエストに乗ってきます。実測として、会話の1回目が1000トークン、10回目だと2500~3000トークンくらいになる感じで、10回の会話を行なうと合計4円程度がかかりました。

※会話履歴をすべて送らずに直近数回分に絞ったりすることで、会話の往復回数が増えたときのトークン数を抑える工夫ができるとのこと。

ユーザ数と1利用あたりの会話回数を予想すると、ChatGPT APIの使用料は$100あれば収まる見込みでした。ただ、会話ボタンを連打したらその分だけ課金されるのは危ないですし、急にバズったりしてうれしい悲鳴が上がる場合も考慮して、いくつかの対応を入れました。

    • 会話は10往復を上限とし、それ以上続けられないルールにした(Lambda側のバリデーションでも配列の長さをチェックしている)。

    • 10往復の会話をしたあとに最初からやり直したい場合、1時間のインターバルを待つ必要がある、という仕組みにした(これはフロントエンドでチェックしているだけなので、仕組みが分かれば回避できてしまう)。

    • ChatGPT APIのHard limitに$400(見込みの4倍)を設定した。Hard limitは月の課金額の上限で、この予算額を超えると以降のAPIリクエストに対してエラーを返してくれる。※初期状態だとHard limitとして設定できる最大値が$100なので、この上限解放申請をOpenAI社に送らないといけない。1日で対応してもらえた。

    • API Gatewayのスロットリング(時間あたりのリクエスト上限数という意味合いのもの)を設定した。仮に短時間にどれだけアクセス集中したとしても、$400を使い切るのに24時間はかかる程度のしきい値にした。

結果として、4月1日の24時間で約1万リクエストがあり、API使用料は約4000円で済みました!

 

総括

  • Python初心者でも実装できた
  • ゲームとしてどのように面白くするかの工夫は必要
  • 今までにないユーザー体験を提供できる

 

後記

実装段階ではあまりにうまくいかないので、登場人物を演じてもらうことは諦めて、言うことが一切アテにならない「記憶喪失のポンコツAI」という逆の方向に振り切りました。記憶喪失のAIではあるけど、「青蘭学園」「風紀委員」「東条遥」などのキーワードには反応するように指示しておいて、記憶喪失の原因を解き明かすという部分でゲーム性を出せないか、という狙いでした。

 

「あなたは記憶喪失です」と指示してもダメで、「記憶喪失になったポンコツロボットを演じてください(ロールプレイしてください)」と指示した方が意図に近い受け答えをしてくれました。

仕事が楽しくなる!? プロジェクト把握のためのコード読解のコツ

この記事について

この記事では、全てのエンジニアが必ず行う「コード読む」という行為について、その重要性とノウハウを説明します。

 

想定読者

以下のような方に、特に読んでもらいたいです。

  • 若手のエンジニアさん
  • ソースコードを読むことに苦手意識を感じる方
  • 担当以外のソースコードをあまり読んだことが無い方
  • 普段の業務にマンネリ感や伸び悩みを感じている方


この記事を書いたきっかけ

筆者の若手時代、優秀な先輩を見習い、色々と模倣していたのですが、最も効果が高かったのがプロジェクトのコードリーディングでした。

プロジェクトのコードリーディングは、以下のような理由から、とても大切なことだと考えています。

  • エンジニアの仕事において大切なことは「要望に対する実現可能性を判断し、現在のアーキテクチャに対し適切な形に落とし込んで実装すること」であると考えています。そのためには、コードリーディングによるプロジェクトの構造の理解が必要不可欠です。
  • 新規プロジェクトや新機能を実装する場合でも、過去作の実装を知り・参考にすることはとても重要です。

図でまとめると以下のイメージです。

コードリーディングのメリット

 

また、コードを読むことに対し、苦手意識を持つエンジニアさんは一定数いる印象を受けます。若い頃の筆者もコードを読むのが苦手で、コツを知りたいと思っていました。

以上のような経緯から、コードリーディングをテーマとして記事をまとめたいと思った次第です。

 

具体的なやりかた 〜プロジェクト全体のコードベースを把握する方法〜

ここで説明するのは、プロジェクトの大意を掴むためのものですが、いくつかのテクニックは、詳細な実装を追う際にも使えます。

プロジェクトのディレクトリ構成に着目する

筆者の場合、最初にプロジェクトのディレクトリ構成を確認します。

ディレクトリ構成を確認するだけで、コードの理解に繋がるのだろうか?」

と思う方もいるかもしれませんが、実はとても重要なものです。

ディレクトリ構成は、コードをどのようなモジュールに分けているかの見取り図に他なりません。ディレクトリ構成を見るだけで、コード全体の規模感、どのような機能がありそうか、どのようなレイヤに分かれていそうかが、何となく推測できます。

例えば、以下のような方法が理解に繋がります。

  • ディレクトリ構成を、マインドマップなどに書き起こす(全部でなく、大きな粒度で構いません)。
  • プロジェクトのコードを読みはじめたばかりの時期(例えば1〜2週間目)は、定期的にディレクトリ構成を確認し直す。

ディレクトリ構造

ディレクトリ構造を図にして、全体をイメージで捉える




プロジェクトで使われている主要なデータ構造を把握する

ディレクトリ構成と同じく重要なのが、プロジェクトで使われている主要なデータ構造の把握です。データ構造を事前に把握しておくと、プログラムを読むのがグッと楽になります。

理由は「プログラムの処理の大半は、データ構造に対する整形処理(データ構造のたらいまわし)」であるからです。 また、ソーシャルゲーム業界では、年々開発期間と費用が肥大化してきています。それに伴い、データ構造とそれを扱うプログラムは複雑化してきているため、データ構造の事前把握がより重要となります。

「データ構造は、プログラムによって処理されるあらゆるデータである」ということをイメージしてみると、実に色々なものがデータ構造であると見なせます。以下はほんの一例ですが、Unityのゲーム開発における例を示します。

  • インゲーム用のAPIなど、比較的大きくて複雑なAPI
  • キャラクターの3Dモデル
  • Unityが提供するあらゆる機能
  • 設定項目が多い・エディタ拡張を作り込んでいるMonoBehaviourやScriptableObject

データ構造をどう把握するかの方法は、該当のデータ構造がどのようなものかによって異なりますが、例えば以下のような方法が挙げられます。

  • 該当のデータ構造を説明するドキュメントを読む(何を目的としたデータ構造なのか・何に/どのように使われるデータ構造なのか)
  • どのようなパラメータを持っているのか大まかに把握する
  • 具体例となる実際のファイルを読んでイメージを掴む

もちろん、全てのデータ構造を把握しなくても大丈夫です。小規模なもの・比較的分かりやすいものなどは省略しても良いでしょう。複雑なデータ構造ほど、事前に把握しておくメリットが大きいです。

データ構造を前もって把握しておくと、該当するプログラムを読むのがグッと楽になります。意識されたことがない方は、是非一度試してみてください。

RPGのデータ構造の一例
データ構造を言語化し、図として作成しておくと
複数人での作業も円滑に行うことができます

 

木を見ず森を見るように、大きなモジュール単位で読む

ディレクトリ構成把握・データ構造の把握が済んだら、ようやくコードを読み始めます。

といっても、現場のプロジェクトで使われるコード量は大きいです。一つ一つ丁寧に読んでいったら、なかなか大意の把握に繋がりません。そのため、はじめのうちは大きめなモジュール単位で読むように心がけてください(ここで言うモジュールとは、一つのディレクトリや一つの名前空間など、比較的大きなコード群を意味します)。

特に、モジュールの骨子を掴むために、はじめは以下のような読み方をしてください。

 

  • クラス名や、publicなメンバ、その他重要と思われるメンバにだけ着目する
    • ※クラス数だけでも膨大に存在するモジュールの場合は、一度に全て読もうとせず、段階的に読み進めていくと良いでしょう。以下に例を示します。
      • 1回目:クラス名・クラス間の関係性の把握にのみ集中する
      • 2回目:クラス内の主要なメンバに着目する
      • 3回目:はじめて各クラスの実装を読んでみる
    • クラス図やマインドマップを書きながら理解する
      • 図を作成しながら読むと理解が深まります(重要なクラスだけで大丈夫です)
      • この時クラス間の関係についても、図を作成しましょう。
        • 継承か? 委譲か? 利用か?
        • 1体1関係か?、1体n関係か?
      • 図を作成すると、例えば以下のようなことが分かります
        • 多くのクラスと関係を持つクラスが、(残念だが)特に責務が大きく・把握が必要なクラスだと推測できる
        • どのようなデザインパターンが使われているか・どのようなクラス間関係かを把握できる
      • 枝葉のクラスは無視する
        • 全てのクラスを把握しようとしたらきりがありません。継承関係の末端にいるクラス、具体的な実装を受け持つだけのクラスは、はじめは無視して構いません。
          • 開放閉鎖原則に則り、機能追加が可能なクラス
            ex) 個々のキャラクターや個々のスキルなど、末端の機能を表現するクラス
          • 内部的な実装だけ受け持っており、外部のクラスとほとんど関係を持たないクラス
            • ex) C++におけるPimplパターン

コードを読む際に、併せて心がけたいこと

以上が、コードの全体像を把握するための読み方になります。

併せて以下のような工夫もおすすめします。

アウトプットしながら読む

何かしらのアウトプットをしながら読むと、記憶に残りやすいです。

あくまでコードを理解するためのアウトプットなので、丁寧にまとめることに意識を取られてしまうと本末転倒です。きれいなアウトプットを後に残すことは意識せず、その場の理解を深めることを重視して取り組んでください。

アウトプットの方法をいくつか例示します。人によって定着しやすい方法は異なりますし、複数の方法を組み合わせてみても構いません。色々と実践してみてください。

 

i) 紙に書く

  • 前述したクラス図やマインドマップの作成や、実装上重要と思ったことをメモするなどの方法です。
  • この際、PCではなく、紙に書くことをオススメします。手書きの方が、ふと浮かんだ思考をスムーズに表現できるためです。

ⅱ) コードの作りを説明する

  • 人に説明すると思考が整理されるタイプの人は、こちらの方法をおすすめします。
    前述した筆者の先輩はこのタイプで、プロジェクトのコードがどのような実装になっているかを、周りのメンバーによく説明していました。
  • プロジェクトを担当するメンバー間で、お互いにプロジェクトの全体像や個々のモジュールについて説明し合うのも、理解が深まると思います。

ⅲ) IDEを開きながらやってみる

  • コードを書くのが好きな方は、こちらの方法をおすすめします。
  • 実際にコードを書くようなイメージで、「ブロック単位でコメントを付与する」「よくない実装だと感じた箇所をリファクタリングしてみる」など、実際のコーディングのような感覚でアウトプットをしていきます。
  • また、動きがよく理解できなかった箇所に対し、デバッガーでブレイクポイントを貼り実際の値を確認してみるのも非常に有効です。

特にマップエディタのようなデータ構造とUIが大掛かりなシステムは
図を書くことをオススメします!

 

感想を持ちながらコードを読む

前述のアウトプットの項目と似ていますが、コードを読む際に何かしらの感想を持つのも、記憶の定着に有効です。

感想の内容は些細なものでも全く構いません。何も感想を抱かずに淡々とコードを読むのと、何かしらの感想を持ちながらコードを読むのでは、その後の定着が違ってきます。是非意識してみてください。

例)

自分の現在の理解度を確認する

  • 「読み始めたが、まだ全然分からない」
  • 「1週間経って再度読み直してみたが、前より理解できるようになった」

コードの構成に注目する

コードの第一印象に注目する

  • 名前空間やクラス名からして、あの機能で使われているコードだろうか」
  • 「ここは改修依頼きても、きっと対応できそうだ」
  • 「中々複雑なコードで、初見では頭に入ってこない」

要素技術に注目する

  • 「知らない技術要素がいくつか使われている。併せて、関連する技術の勉強も進めてみよう」
  • 「使ったことがないAPIが多いため、これらのAPI群も併せてメモしておき、後で調べてみよう」
  • 「自分も後で使いそうなコードなので、スニペットとして盗んでおこう」

筆者固有の経験則

おまけで、コードリーディングする際の、筆者固有の経験則を紹介します。

(明確な根拠はありませんので、鵜呑みにしないでください)

 

仕様書を重視しない

一般的には、コードを読む前に仕様書の理解をすべきと言われます。しかし筆者の場合は、仕様書をいくら読んでもコードの理解が深まらず、むしろ悪化することもありました。

理由は、仕様書ベースでコードリーディングにあたると、仕様書と対応付けてコードを理解しようとするバイアスがかかってしまうためです。仕様書と対応付けてコードを読んでいても、コードの全体像や勘所は見えてきません。

また、仕様書とのコードは、必ずしも1対1対応の関係になりません。プロジェクトのコードは、仕様の変更に柔軟に対応できるように抽象化されていたり、歴史的な経緯で古い仕様のコードが残っていたりなど、仕様書と直接対応しているとは限りません。

そのため筆者の場合は、仕様書の読解よりも、実際の動作ベースで概要を掴む・コード読解の方に時間を充てることを重視しています。

※もちろん、機能追加やバグ修正をする場合は、正確な仕様の理解が不可欠です。 実作業に取り組む際は、必ず仕様書を丁寧に読解してください。

 


プルリクエストレビュー時は、関連コードも確認する

これも筆者の場合ですが、プルリクエストベースでのコード読解は、実力UPに繋がらないことが多かったです。プルリクエストは既にある機能に対し、何らかの観点でパッチを当てるような側面が強いからだと考えています。

そのため、時間に余裕がある場合は、プルリクエストのレビューをする際に、プルリクエストの該当部分だけではなく、関連する周辺のコードもまとめて読むようにすると良いです。その分だけ、コードに対する理解が深まりますし、実装者へのFBも良いものになります。

 

まとめ

プロジェクトのコードを読むことのメリットと、読み方を説明させて頂きました。この記事では、業務で担当しているプロジェクトのコードを読むことをテーマとしました。

しかし、読解対象のコードは、必ずしも担当されているプロジェクトのコードでなくても構いません。有名なOSSや、気になっているライブラリなど、業務に関係のないプロジェクトを読解対象にしても効果があります。

「知らない言語」「知らないフレームワーク」「経験したことが無い分野」など、読者の皆さんにとって遠いコードをテーマにした方が、より多くの学びを得られると思います。

この記事で紹介したような手法を試してみたことがない方は、是非実践してみて頂けると、筆者はとても嬉しいです。

はじめは、いつもより少し早く出勤する・少し早く業務を切り上げるなどして、浮いた時間でコードの読解をしてみてください。

数週間単位では効果が出づらいですが、数ヶ月単位で見ると実に色々な側面からの改善が見られると思います。

技術記事コンテストの開催

はじめに

今回は、f4samuraiエンジニア全体で行った技術記事コンテストの話を行います。

技術記事コンテストとは、社内で使用しているConfluenceに、業務や今までの開発を行った経験で得た知識や考えを記載し、作成された記事を表彰しよう!という試みです。

 

初回の1回目は、テーマは決めず

「今一番みんなに知ってもらいたいことかどうか」
「読んだ人が読んで良かったと思うかどうか」
という評価観点だけ伝えて開催しています。

 

開催の理由

技術記事コンテストを行った理由は、技術戦略チームの動きとも関係があります。

 

f4samurai.hateblo.jp

 

技術戦略チームでは、エンジニア全員が個人ではなく組織で戦えるエンジニア集団の一員になることを、理念として掲げています。

そして、組織で戦うための最初の段階として、情報の蓄積・共有を各々が行うこと目標にしました。

情報の蓄積や、共有ができると以下のことの実現に繋がります。

  • 車輪の再発明を減らし、効率的な開発の実現ができる
  • チームごとの課題だけでなく、社内全体の課題に目を向け、個人がよりハイクオリティで生産性の高い開発を行う意識を持つ
  • できていること、できてないことを可視化できるため、個人や組織の長期的な成長につながる
  • 複雑な事象を言語化できるようになり、大人数での作業を円滑に実現できるようになる

今回、記事コンテストを実施することで、個人の情報蓄積、共有を行う事に対してポジティブなイメージを持ってもらい、まずは情報を蓄積することの習慣づけを行うことを目指しました。

 

技術記事コンテストを開催した結果

技術記事コンテストは1ヶ月ほどの期間を用いて行われ、

最後にはエンジニアが集まっての表彰会も行いました。

その結果ですが、

  • 社内のエンジニアの1/3が新規記事を執筆
  • 記事の内容から派生してより深い議論、情報交換が行えた
  • 今まで話す機会がない人と話すことができた
  • 会社全体でのエンジニアの一体感を高めることができた

と、様々な技術ノウハウ、業務情報に関する記事が執筆され会社の資産が生まれました。加えて、リモートワーク下ではなかなか行えなかった、同じエンジニアという職種内での情報交換や、今後会話しやすくなるための交流を実現することができました!

 

最優秀賞について

コンテストであるため、最優秀賞となる記事も決定致しました!

今回最優秀賞となる記事は

「仕事が楽しくなる!? PJ把握のためのコード読解のコツ」

となりました!

 

内容は、本文を一部抜粋しますと

「普段チケットで触る部分のコードだけではなく、PJのソースコード全体を把握するように立ち回るとお得だよ」ということと、「そのためにPJのソースコードの大意を掴む方法」を、筆者の体験談に即しまとめた記事です

 

  • 前述した通り、技術やPJの構成を理解し、顧客が望む機能追加やバグFIXを行うことが、エンジニアの主要な職責であると、筆者は思っています。
  • PJアーキテクチャの把握は、上記を実現するためのメリットを必ずもたらします。
    • 企画から受けた要望の、工数見積の精度向上、そもそもの実現可能性自体のup
    • 機能追加やバグFIXの精度/速度 両面での向上
    • 上記2点の結果、業務スピードが上がる / PJメンバーから信頼度が上がる → 仕事のサイクルが好転のループに乗りやすくなる

というものです。

 

また、具体的なコードの把握のコツについてはコチラです。

タイトルのみ抜粋しました。

1番最初に、プロジェクトのディレクトリ構成に着目する
コードを読む前に、PJで使われている主要なデータ構造を把握する
大きなモジュール単位で、木を見ず森を見るようにコードを読む
何でも良いので、必ずアウトプットしながら読む!

自分もコードを読むときは、この記事にあったような全体感を把握し、紙に構造を書き出したり、チーム内のメンバーに説明したりすることをよく行っていました。

しかし、改めて人に伝えるためにこの記事のように言語化することはできていなかったです。

 

今回、コンテストに応募いただいた記事はどれも素晴らしいもので、すぐに仕事に使えるもの、エンジニア的な開発の指針となるもの、会社の資産となるものなど、各々価値があるものでした。

 

その中でもこの記事は

「すべてのエンジニアの業務に関係するテーマで、みんなに知ってほしいものであった」

「経験に加えて、本人の思考などを踏まえて、読む人の事を考えて丁寧に執筆されていた」
「コミュニケーションのきっかけとなる、読んでよかったと思える記事であった」

という点が優れており、最初に決めた評価観点からみても素晴らしい出来でしたので最優秀賞といたしました! 

 

まとめ

今回の試みは、組織、個人が情報を蓄積するきっかけにもなりましたが、それに加えて、日々の業務を俯瞰して伝えたいことを整理し、エンジニア間でコミュニケーションすることで、リモートワーク化で感じにくくなる会社で働く一体感のようなものを感じました。

また、今回技術記事コンテストで作成された記事については、できるものは外部公開も検討していますのでご期待ください!

 

エンジニア採用特設サイトはこちら

Jenkinsで処理を自動化するために必要な、パイプライン、ジョブ、シェルスクリプトの知識

はじめに

今回はJenkinsでビルド時に使用するパイプライン、ジョブ、シェルスクリプトについて説明していきます。

 

なかなか関連する処理を一通り説明しているサイトなどがなかったので、リファレンス的に様々な処理を把握できるように記載していきます。

 

以前のJenkins記事が設計、構築に関する情報をまとめていますのであわせて見ていただければと思います。

 

f4samurai.hateblo.jp

 

パイプライン

まずはパイプラインについて。こちらは以前もお話しましたが、コードを用いてビルド処理の流れを定義し、ビルドの状況を可視化することができます。

pipeline {
    agent any
    stages {
        stage('FetchSouceRepo') {
            steps {
                script {
                      //チェック処理
                }
                build job: 'ジョブの実行'
            }
        }
        stage('CreateWorkSpace') {
            steps {
                parallel(
                    //iOSジョブの実行
                    //Androidジョブの実行
                )
            }
        }
        
        stage('SetupCache') {
            steps {
                parallel(
                    //iOSジョブの実行
                    //Androidジョブの実行
                )
            }
        }
        
        stage('Import') {
            steps {
                parallel(
                    //iOSジョブの実行
                    //Androidジョブの実行
                )
            }
        }
        
        stage('Build') {
            steps {
                parallel(
                    //iOSジョブの実行
                    //Androidジョブの実行
                )
            }
        }
        
        stage('BackUp') {
            steps {
                //iOSジョブの実行
                //Androidジョブの実行
            }
        }
        
    }
}

上記パイプラインのコードはgroovyという言語を用いて記載を行い

GitHubで管理することも可能です。GitHubでパイプラインコードを管理しておくと

ビルド処理のバックアップや、修正時の反映が非常に楽になります。

 

GitHubでの管理は非常に簡単で上記のパイプラインのコードを

BuildPipelineJenkinsFileというファイルで保存してGitHubリポジトリを作成

実際のパイプライン実行を行う時に以下のように設定することで実現出来ます。

パイプラインにおける、ジョブやシェルスクリプトの実行方法

地味にこのあたりの書き方についてあまり情報がなかったのでまとめておきます。

パラメータの渡し方などが参考になるかと思います。

ジョブを実行する版

testというジョブを実行しています。

stage('CreateWorkSpace') {
steps {
parallel(

iOS:{ build job: 'test',parameters: [ [$class: 'StringParameterValue', name: 'app_branch', value: "${app_branch}"],
[$class: 'StringParameterValue', name: 'resource_branch', value: "${resource_branch}"], [$class: 'StringParameterValue', name: 'platform', value: "iOS"], [$class: 'StringParameterValue', name: 'unity_version', value: "${unity_version}"] ] },
Android:{ build job: 'test',parameters: [
[$class: 'StringParameterValue', name: 'app_branch', value: "${app_branch}"], [$class: 'StringParameterValue', name: 'resource_branch', value: "${resource_branch}"],
[$class: 'StringParameterValue', name: 'platform', value: "Android"],
[$class: 'StringParameterValue', name: 'unity_version', value: "${unity_version}"] ] }
) } }

 

シェルを実行する版

test.shというシェルを実行しています。

stage('CreateWorkSpace') {
steps {
parallel(

  iOS:{     sh "zsh ${WORKSPACE}/test.sh -P iOS -A ${app_branch} -R ${resource_branch} -U ${unity_version}"   },
  Android:{     sh "zsh ${WORKSPACE}/test.sh -P Android -A ${app_branch} -R ${resource_branch} -U ${unity_version}"   }
) } }

ジョブ

パイプラインでもGitのリポジトリにアクセスしたり、シェルを実行し、ビルドやアップロード処理を行うことが出来ますが

「ビルド処理のみ行いたい」

「アップロード処理のみ行いたい」

などといった、個別処理を実現するために、ジョブを活用することがオススメです。

全体の処理はパイプラインで記載し、個別のステップはジョブを使うような方法です。

ジョブ・パイプラインにパラメータを渡す

ビルドを行うときは、ビルドするブランチ、iOS、Androidなどのプラットフォーム、またUnityバージョンを指定してビルドを行いたくなる時があります。

その時使うのが、ビルドのパラメータ化という処理です。

パラメータの渡し方は以下のような様々な方法があります。

今回は選択という、複数の選択から選ぶという方式について説明します。

選択の場合、後で参照するときの名前をつけ、

選択する値を1行ずつ定義します。

 

するとビルドする時に、ドロップダウンにて値を選択することが出来ます。

 

ビルドの実行時、シェルで処理を行う場合は

以下のように${定義した名前}で選択した値を参照する事ができます。

zsh ${WORKSPACE}/test.sh -P ${platform} -A ${app_branch} -R ${resource_branch} -U ${unity_version}

シェルスクリプト

ビルドの実行時には、パイプラインやジョブだけでは行うことが難しいファイル操作やビルド対象の収集などの処理が存在します。

その時に使うのがシェルスクリプトです。

シェルスクリプトの中でもよく使う処理を以下にまとめます。

 

変数の定義

変数の定義は以下のように、=で行います

他の言語のようにダブルクォーテーション""でくくったり、

=の前後にスペースはいらないのでご注意ください

UNITY_TARGET_BRANCH=develop
ASSET_TARGET_BRANCH=develop
UNITY_VERSION=2021

変数の使用

変数の使用は定義した変数の前に、$マークつけて使用します。

${変数名}という呼び方もでき、文字列を連携する時などに境界がわかりやすくなるため

${変数名}で統一することがおすすめです。

echo $UNITY_VERSION
echo ${UNITY_VERSION}
WORKSPACE_DIR=${BASE_DIR}/Workspace${UNITY_VERSION}/

 

引数のうけとり

パイプラインや、ジョブなどから引数を受け取る時には以下のようなコードを使います。

while getopts "P:A:R:U:" OPT; do
  case $OPT in
  P)
    PLATFORM=${OPTARG:-${PLATFORM}}
    ;;
  A)
    UNITY_TARGET_BRANCH=${OPTARG}
    ;;
  R)
    ASSET_TARGET_BRANCH=${OPTARG}
    ;;
  U)
    UNITY_VERSION=${OPTARG}
    ;;
  esac
done

A:

が、Aというオプションで、オプションが引数を持つときの処理で

引数は${OPTARG}で参照する事ができます。

 

${OPTARG:-${PLATFORM}}

は、シェルにおける変数の初期値定義を活用した処理になります。

上記の処理の場合、-Pオプションが定義されてない場合、${PLATFORM}で定義された値が使われます。

 

シェルスクリプトで関数、引数、戻り値を使う方法

関数の定義、使用は以下のように行います

#定義側
function DisplayString() {
RETURN_VALUE=$1
echo $RETURN_VALUE
}

#使用側
FUNC_RETURN=$(DisplayString OutputString)

echo ${FUNC_RETURN}
#OutputStringと表示される

関数は、戻り値を使いたい場合は$()で囲んで呼び出し、引数は関数の後にスペースを開けて渡します。

引数を使用するときは、第1引数から$1、$2で参照します。

 

シェルスクリプトで算術演算

シェルスクリプト加減乗除の計算を強制的に行いたい場合は、

で全体を囲ってください。関数で引数で数値を渡して、中身で計算したい時に使います

 

 

参考サイト

https://qiita.com/akinomyoga/items/9761031c551d43307374

 

 

文字列として扱いたい場合

上記の算術演算の似たパターンとして文字列として強制して扱いたい場合は

" "

で囲ってください。

' '

で囲った場合変数が展開されません。

以下のように関数呼び出しと誤解される場合に使えます

#定義側
function DisplayString() {
#RETURN_VALUE=Hello $1 とすると関数呼び出しになりエラー
#RETURN_VALUE='Hello $1'は変数が展開されずHello $1と表示される
RETURN_VALUE="Hello $1"
echo $RETURN_VALUE
}

#使用側
FUNC_RETURN=$(DisplayString World)

echo ${FUNC_RETURN}
#Hello Worldと表示される

 

ディレクトリの存在チェック

ディレクトリが存在している時true

-d

#リソースワークスペースディレクトリがあれば削除
if [ -d ${WORKSPACE_DIR}/resource ]; then
rm -rf ${WORKSPACE_DIR}/resource
fi

 

 

文字列の存在チェック

文字列が0の時true

-z オプションで

条件文を実行することでチェックできます

 

IDがとれるまでリトライするような処理を書く時などに使えます

while [ -z "$INVALIDATION_ID" ]; do
INVALIDATION_ID=$(ExecIvalidation)
echo "retry INVALIDATION_ID:" $INVALIDATION_ID
sleep 10
done

 

シェルでの変数展開、置換処理、正規表現

シェルでは変数を展開するための特殊な記法や、

置換するための書き方があります。また正規表現も使えます。

このあたりは頻繁に使うことは無いかもしれませんが、

コードを読むために必要となることがあるため一応心の隅に覚えておきましょう。

 

 

remote_all_branch=`git branch -r`
remote_branch_array=(${(f)remote_all_branch//origin\//})

変数展開と、置換処理を使用

改行区切りで保存されたremote_all_branchをorigin/を取り除いた上で配列に保存する

 

 

if [[ $find_dir =~ ^.*${branch// /}/ ]];then

正規表現マッチと置換処理を使用

$branchから空白を除去して、末尾に/を追加する

  develop

develop/

こちらの値を使い$find_dirにある文字列と前方一致した時trueを返す

 

 

 

参考サイト

bashの変数内文字列置換まとめ - Qiita

Zsh 変数メモ · GitHub

Bashで正規表現マッチした文字列を取り出す - Qiita

 

まとめ

今回はJenkinsでビルドを行うために必要な

パイプライン、ジョブ、シェルスクリプトについて、全体を把握できるように

よく使う処理についてリファレンス的にまとめてみました。

 

誰かのお役に立ちましたら幸いです。

 

エンジニア採用特設サイトはこちら

リモートワークでもつながりを作るf4samuraiの工夫

はじめに

自分は、2022年4月にf4samuraiに転職してきました。

現在はどの会社でもリモートワーク中心の業務であるため、コミュニケーション面で会社に馴染めるか、また、自分のスキルを活かせるかどうか不安がありました。

 

しかし、f4samuraiではリモートワーク下でも、社員同士のコミニケーションを促進し、あらたなつながりを作りだすための様々な工夫が行われており、約半年働くことで、長年働いた会社と同じか、それ以上の人のつながりが生まれ、仕事にも活かすことができました!

 

今回は、その仕組みについて説明しようと思います。

つながりを作る仕組み

まず最初に、ポータルサイトが非常に充実していると感じています!

 

note.com


こちらの記事にも書いてあるのですが、メンバー全員の顔写真と自己紹介があるため、話しかけるきっかけにもなります。

加えて、ポータルには座席表もすぐ見られるようになっており、出社して直接質問する時に何度も利用させていただいています!

 

ポータルはこれだけでなく、社内で使う勤怠やスケジュールを管理するツールへのリンク、体制図、秋葉原のランチマップ、社内メンバーのインタビュー記事などなど、会社勤めで欲しい情報が非常に分かりやすくまとまっています。

 

 

続いて、社内での情報発信の仕組みも存在しています。

1つ目は社長のラジオ。

複数人で会社のことから日常生活のことまで、肩肘張らずに話しているので、会社や一緒に働いてる人の雰囲気を深く理解することができます。

 

リアルタイム配信ではチャットでコメントをしたりできますし、加えて、アーカイブにで後から聞けるところも素晴らしいです!

 

そして、テキスト朝会というものも相互理解に役に立っています。

 

こちらは希望者が持ち回りでブログを書いていくもので、ゲーム、映画、カフェ、オススメのお店など趣味の話など、会社で働くひとの日常が見え、コミュニケーションのきっかけにもなりました。

 

他にも、大きなカフェスペースを活かした、チームの懇親会、ヤクルトさんの訪問販売、旅行のお土産のおすそ分け、専用のエスプレッソマシーンなどを使って振る舞われるバリスタデーなど、交流するためのきっかけづくりが充実しています!

 

加えて、社内で行われるイベントが自由参加形式なのも、配慮が行き届いていいなと思っています!

興味があるものだけ参加、見るだけでの参加、積極的に発信するスタイルでの参加、参加しない、どのスタイルも許容しているところが、多様性を許容する社風を表していると感じました。

 

つながりを仕事に活かす

では、このような仕組みで増えたつながりを通して、業務にどのような影響があったかを説明します。

 

雑談から業務改善へ

まず、出社日で顔を合わせた時に会話をすることが増え、その結果業務改善に繋がったというものがあります。

具体的には、ボイスを収録するときの台本作成ツールの改善です。ちょうど帰る時にスクリプトチームが話し合っている所が見えて、そこでヒアリングしたとこから改善に繋がりました。

 

他にもSQL作成ツールの改善も社内でのつながりがきっかけとなり作成しました!

エクセルのマクロによるSQLの作成ツール

日常の温かみのあるやり取り

そして、リモートワークだと、文字情報でのみのやり取りであるため、使い方によっては指示・依頼が飛び交うといった印象になりかねないですが、f4samuraiでは社員同士のつながりがあり、お互いを尊重する空気感があることで、相手を気遣ったやり取りがあると感じています。

 

つながりからアイデアが生まれ行動へ移していく

さらに、社内の仕組みを活かして生まれたつながりから行動が生まれ、どんどん進化していくところもf4samuraiのいいところだと思います!

 

仕事に関係することで言えば、Jenkinsの運用改善情報の共有、GoogleのBillingLibraryという課金システムのアップデート情報などもプロジェクト間で共有され、サービスの安定運用、品質向上に役立っています。

 

また、直接仕事には関係ないですが、最近流行っているコンテンツやサービスを語り合ったりする機会も多く、他にはおすすめの手土産をシェアしあう活動なども最近生まれました!

 

トップダウンだけでなく、ボトムアップで提案されたことがどんどん実行されていくところが、ベンチャー感あって自分はすごくいいなと感じています!

 

まとめ

今回はf4samuraiの社風や特徴を今年入社した自分からの目線でまとめてみました!

再度整理すると以下となります。

  • コミニケーションをするために必要な情報の提供ができている
  • 交流を生み出すきっかけの場が多い
  • 一人ひとりの気配りや気付きで新たな仕組みが生み出される
  • ボトムアップかつ、スピーディに行動していく風土がある

社風が合いそうだなと思った方は、エンジニアが知りたい情報を詳細にまとめた以下のサイトがありますので、是非ご覧いただければと思います!

 

エンジニア採用特設サイトはこちら