f4エンジニアブログ

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

エンジニアからの提案がゲームに反映された事例

「社内のエンジニアが提案してゲームに反映されることってどのくらいあるんですか？」と採用候補者の方から聞かれたことがあったので、社内でヒアリングをしてみました。

まだリリース前のタイトルでの提案もあり詳しく書けない部分もあるのですが、弊社エンジニアの働き方が少しでもイメージできたら嬉しいです。

機密事項でスクショが載せられないので代わりにオフィスのある秋葉原の写真

 

リアルタイムユーザバトルの実装見積り

ディレクターはリアルタイムユーザバトルを実現したかったのですが、社内で実装を経験したメンバーがおらず難易度や工数を見積もれないでいたため、別の機能で代替しようとしていました。

そこで「実装難易度を見積もることを目的としたテスト実装に1週間使う」ことを提案しました。事前に通信ライブラリのドキュメントにも目を通していたので、これを使えばいけるかもという感触がありました。

その時点で検討していたゲーム仕様も、通信タイミングが少なくて済むゲームルールだったため実装がスムーズに進み、異なるPC間で対戦できるところまで3～4日でいけました。これを見てディレクターがリアルタイムユーザバトルをゲームのエンドコンテンツする仕様に変えることができました。

（サーバサイドエンジニア Oさん）

 

タイトル表示や場面転換の演出案

ストーリーを表示するアドベンチャーパートで、タイトル表示や場面転換の演出について素案を作成し、採用されました。

タイトル表示は、キャラとタイトルが一緒に出るといい感じになるのではないかという案を考え、フェードのみの簡単なアニメーションを作成してメンバーに共有しました。結果その案が採用され、デザイナーに作成の依頼を行いました。

場面転換は、VTuberの配信開始時や画面の切り替わる時に使われている演出が作品のイメージに合うのではないかと思い、演出をまとめて共有したところその一つが採用されました。

（ネイティブエンジニア Mさん）

 

ストーリースクリプトの実機確認手法

シナリオチームがスクリプトを作成するツールはUnityを使って実装されているのですが、実際のゲームはcocos2d-x上で動作していました。当初はUnity上でLive2Dや演出も確認する想定だったのですが、スクリプトを実機で確認するとLive2Dのモーションやwaitの秒数がボイスとずれてしまうということがありました。

そこで、スクリプトツール上では値を設定してスクリプトを出力する機能のみとし、演出の確認は実機で行うように提案して改修しました。実装としてはUnityをSocketサーバーとして立てて、そこに実機を繋いてUnityで作ったスクリプトのjsonを送るようにし、受け取ったjsonでストーリーを再生するようにしました。

それまでは何か新規の演出を実装する場合、cocos2d-x側とUnity側で二重に実装する必要がありコストが高かったのですが、演出表示部分を実機にまとめることで実装コストも下がりました。

（ネイティブエンジニア Sさん）

 

描画負荷を下げる改修

ゲーム内に登場するアバターキャラは、部位ごとにパーツを結合しているため描画処理が重くなっていました。

そこで、動的にメッシュとテクスチャを結合してキャラクターのドローコールを削減するように努めました。また、非圧縮テクスチャとしてテクスチャ結合していたものを、圧縮テクスチャのまま結合するように改修して、メモリと描画負荷を軽減しました。

（ネイティブエンジニア Oさん）

 

バトルリプレイ機能の実装

バトルをリプレイ再生したいというプランナーの要望があり、実装方法を検討しました。

結果、バトル内部の計算結果などをjsonデータにして保持することで、そのデータを元にバトルを再生する機能を実現できました。

（ネイティブエンジニア Oさん）

 

自作フレームワークの実装

そのプロジェクトではwicketというテンプレートエンジンを採用していたのですが、そこにbackbone.jsを組み合わせるかどうかという議題が上がりました。画面作成のコストを考えると少し効率悪そうな感じがしたので、backbone.jsまでの機能はないけれど、wicketに合わせた簡略化したライブラリを作り採用されました。

プレゼント受け取りやフレンド一覧、ミッション一覧など画面を切り替えて描画していた部分は、jsonデータのやりとりだけで再描画できるようになりました。

（フロントエンドエンジニア Rさん）

 

画面遷移のひと手間を減らす

画面遷移のひと手間を減らすような提案をよく行っています。

例えばクエストのループ状態について、毎回設定がリセットされていたのを設定状態が保持されるように変更しました。

あとはイベントの中でキャラクターのチーム編成を変更する頻度がかなり低いにも関わらず、フローに必ず編成させる処理が挟まっていたのが気になったので、UIチームにフローの変更を提案し、初回だけ編成をするよう改修しました。

（フロントエンドエンジニア Mさん）

 

キャラクターの新スキルレビュー

僕自身ゲームが大好きで多くのゲームをプレイしています。
自分が関わっているプロジェクトに関して、メイン担当はクライアント開発ですがゲーム設計部分で気になる部分があればディレクター・プランナーに伝えています。
例えば、既存のスキルと組み合わせると無限に必殺技が出せるようになってしまう、似たようなステータスを持つキャラクターの上位互換になっていてそのキャラが活躍できなくなってしまう、などです。

（フロントエンドエンジニア Yさん）

 

 

実際にヒアリングをしてみると、ゲームルールに関する提案だけでなく、実装方法やUI/UXの改善、ゲームバランスを踏まえたチェックなど、ゲームに関連する様々なことにエンジニアが関わっているんだなと感じました。

 

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

技術戦略チームを立ち上げました


会社の技術的な課題を、組織横断で解決するチームを立ち上げたときの話をします。
 

会社が抱えていた問題

これまでエンジニアが関係する課題は、技術的な課題であってもチームマネジメントに関する課題であっても、個々のエンジニアが解決にあたっていました。
会社の規模が小さかったときはそれでも良かったのですが、規模が大きくなり複数ラインで開発するようになってからは、課題が解決できるかどうかはそのエンジニア個人の能力に依存するようになってしまいました。
組織で働くメリットの一つとして、各エンジニアの強みや知見を集めることでより難易度の高い問題に対処できることがあげられます。
会社としての技術力を一段上げ、よりハイクオリティで生産性の高い開発をするために、技術戦略チームを立ち上げることにしました。
 

検討チームの立ち上げ

サーバサイドのエンジニアリーダーと、クライアントサイド（Unity）のエンジニアリーダーに声をかけ、検討チームが発足しました。
まずは各自が思っている課題の洗い出しから始めました。
それぞれが付箋に書き、ホワイトボードに貼り出しながら説明、それを聞いて関連する課題があったらそれも貼り出す、という形で進めます。
 

課題の整理中
ある程度挙げられたところで、付箋をmiroに転記しました。
miroでは、課題の抜け漏れがないかを検討するため、ざっくりとグループ分けをします。

miroを使うとグループ分けしやすい
ここでは、以下のような分類にしました。
 
  • 事業に関する課題
    • エンジニアチーム
      • 現在直面している課題
      • 将来への備え
    • プロジェクト全体
      • 立上げ時
      • 開発・運営時（マネジメント）
  • 会社組織に関する課題
    • 人事
      • 採用
      • 配置
      • 評価
      • 報酬
      • 育成
    • 社内システム
 

チームの理念とミッション

このタイミングでチームの理念とミッションも考えました。
 

【チーム理念】

エンジニア全員が、個人ではなく組織で戦えるエンジニア集団の一員になる
 

【チームミッション】

「SECIモデル」と「ダブル・ループ学習」を実践・推進し、エンジニアの常識や文化のレベルを継続的に向上させる
 
活動内容を踏まえ、チーム名称も検討しました。ひねった名前も候補としてありましたが、ここはシンプルに「技術戦略チーム」としました。
 

これからやっていくこと

課題の抜け漏れがないと納得できたら、優先度を付けスケジュールを立てました。
優先度の高い課題のうち、まず最初にエンジニア個人がもっている暗黙知を集約することから始めることにしました。
それぞれのエンジニアがプロジェクトの設計・開発運用フェーズにおいて気にしたこと、意識したことなどのノウハウを明文化していきます。
今はいろんなエンジニアにヒアリングを行っているフェーズなので、まとまったらこのブログでも紹介したいと思います。
 

サマーインターン課題から見えてきたf4samuraiのゲームづくりへの思想

 

はじめに

2022年夏、f4samuraiではサマーインターンシップを実施致しました！

 

サマーインターンシップ内の１シーン

内容は

  • ゲームを作る上での考え方、必要な知識を教える講義パート
  • 6人のチームで、指定された内容のゲームを４日で作る制作パート
  • 所属社員と自由に会話をしたり、フィードバックを受けれる交流パート

というボリュームたっぷりのものです。

 

今回、エンジニア、プランナーが組んで自由にゲームを作るパートがあったため、ゲームをしっかり開発できる人に参加いただくことが重要でした。

そこで、エンジニアについては簡単なゲームを作る選抜課題を行っていただく事にしました。

 

今回は、この選抜課題を作ることで、見えてきたf4samuraiのエンジニアの思想をお伝えしたいと思います。

課題は以下の内容となっております。

 

課題内容

以下のPDFを確認し、環境構築、実装、動作確認を実施してください。

Unity公式玉転がしチュートリアル

 

作成するゲーム

作成するゲームは玉転がしゲームです。

キーボードを使って白いボールを転がし、触れるとゲームオーバーになる赤いブロックを避けながら、黄色いアイテムを取得するというものです。

 

課題となる玉転がしゲーム



 

 課題実施にあたり考慮すべきこと

今回作成するゲームは、エンジニア、プランナー、デザイナーのチームでステージを量産するという想定で実装してください。

その際、何人のチームで、各々のメンバーがどのようなスキルを持っているか、想定したチーム構成を記載してください。

 

実装における条件

実装を行う上で、チームで分業しやすくするためと、運用時のデータ量を考慮して、

ステージの配置情報をデータからロードし、動的にステージを生成するようにしてください。

（データ形式はJSON、csv、バイナリ、ScriptableObjectなど自由です。

但し、PrefabやSceneを作成し、それをロードすることは禁止します)

 

課題の意図

課題の内容については複数人のエンジニアで話し合い作成したのですが、重視したのは以下の要素です。

  • ゲーム制作能力を図れる課題であること
  • データから動的に画面を作る能力を確認できること
  • 使用者の事を考え、運用方法を考えられる能力を確認できること

ゲーム制作能力を図れる課題であること

まず考えたのは、技術力のみを図る課題ではなく、ゲーム制作能力を図る課題とすることです。

ゲーム制作は正解がない事が多く、加えて面白さを理解し実装していく必要があります。

 

実装していく上で感じる

「こういう機能を作ったらプレイする人は更に楽しめそう！」

「この機能をまとめると、次のプロジェクトでも使えるようになるのではないか？」

といった考えが浮かんだ時に追加実装が行いやすい課題と致しました。

 

実際に提出頂いた作品の中には、プレイヤーを強制移動させる床、画面内を移動するオブジェクトなど、ギミックを作り込んでエンジニア的なものづくりを楽しんでいると感じられるものがありました。

ギミックを作り込んできた作品


また、操作操作難易度が高いステージを作り、制限時間をつけることで、ゲームバランスを考慮した作りとなっているものなど、製作者側になった時のゲームに対する向き合い方が感じられるものもありました。

ゲームバランスにこだわりを感じた作品

 

データから動的に画面を作る能力を確認できること

次は、スマートフォンで運用型のゲームを作る上で重要となる、運用を考慮し、マスターやテキストファイルなど、データから画面を作る要素を入れました。

 

運用を行うゲームを作る場合、定期的にイベントを開催し、また機能を追加していく必要があります。

このためデータの設計、実装をしっかりしておかないと、イベントを行う度に実装が必要になり工数を圧迫したり、新機能を行う場合に大改修が必要になり、工数の圧迫に加えて不具合が発生する可能性も格段に上がります。

 

このため、データから画面を作るという条件を入れ、上記のデータ設計、実装のセンスを見る事にしました。

加えて、ただ作るだけでなく、課題を行ったことで、実際に仕事でも役に立つノウハウや知識を得てほしいという思いもあり少し難しいですが必須の条件といたしました。

 

提出していただいた作品では、スプレッドシートやエクセルからCSVを作り

そのCSVを読み込みステージを作るという方法が多かったです。

以下のように、関数化などをしっかり行い、コメントも適切で読みやすいコードも書いている方もおられました。

 

    /// <summary>
    /// ステージを生成するメソッド
    /// </summary>
    /// <param name="stageData">ステージデータ(ScriptalObject)</param>
    public void GenerateStage(StageData stageData)
    {
        //初期化
        InitializePlayerPosition(stageData);
        InitializeMainCameraPosition();
        //csvファイルを二次元配列に変換する
        int[][] objectPosisionDates = CsvReader(stageData.csvFile);
        for (int y = 0; y<objectPosisionDates.Length; y++)
        {
            for(int x = 0; x<objectPosisionDates[y].Length; x++)
            {   
                // オブジェクトを設置する                      
                DeployObject(objectPosisionDates[y][x], x, y); 
            }
        }
    }

 

使用者の事を考え、運用方法を考えられる能力を確認できること

そして、エンジニアとして時に忘れてしまいがちな、使用者の事を考え、運用方法を考えるという要素を課題に追加しました。

 

ゲーム開発は、ユーザー様が遊ぶゲーム内のバトルや育成要素を作成するのに加えて、

ゲームを開発するためのマスターやスクリプト等のデータ構造や、マスター編集ツール、スクリプトエディタ、マップエディタなど、開発ツールを作る事があります。

この時重要になるのが、運用する時にミスが少なく、誰でもすぐに理解できるデータ構造や、ツールを作ることです。

 

実際のインターン生の作成例では以下のように、マップデータの作成例や

使い方についても丁寧なドキュメントが作られていたものもありました。

 

スプレッドシートによるステージデータの作成例

ステージデータの作成マニュアル

 

エンジニアは時に技術の追求にのみに走ってしまいがちです。

しかし、重要なのはユーザー様や、一緒に開発する仲間がどう感じるかです。

f4samuraiのエンジニアは、使ってくれる人の視点を考えて作るようにしています。

f4samuraiのエンジニアの思想とは

今回の課題を作成する作業を経て、f4samuraiのエンジニアには以下のような思想があると感じました。

 

  • 発想、思考力を活かし、言われたことをこなすだけでなく、面白いゲームを作る
  • ただ作るのではなく、面白さや、運用コストを含めて考えて作る
  • 技術を活かして、誰に何を届けるかを考えて作る

 

一言でまとめるなら、「考えてものを作る、作るだけでなく、使う人の事を考えて作る」といったところでしょうか。

 

 

f4samuraiが気になった方は、エンジニア採用特設サイトを作成しましたので、ご覧いただければと思います。

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

Jenkinsの運用に必要な関連知識

 

はじめに

ソフトウェア開発では、テスト、ビルド、デプロイなどの作業をCIツールを使って自動化することはよくあります。
エンジニアだけでなく、プランナー、デザイナーといった職種の方も使うため、安定運用することが非常に重要なシステムです。

弊社ではCIツールとしてJenkinsを採用することが多く、

今回、社内でJenkinsの運用改善を行ったため、その情報を共有いたします。


Jenkinsで行っていること

プロジェクト内でJenkinsは以下のようなところで使われています。

  • Unityアプリケーションのビルド
  • Unityアセットバンドルのビルド
  • アセットバンドル、画像、サウンド、動画などリソースファイルのサーバーへのアップロード

今回は特に、構成要素が多く処理が複雑化していた

  • アセットバンドルのビルド
  • アセットバンドル、リソースファイルのアップロード処理

について詳細に掘り下げて説明していきます。


Jenkinsで自動化を行う時に必要な知識

まず、Jenkinsを構築する時に必要な知識を、他のプロジェクトへの共有を考慮して整理してみました。

プロジェクトごとに細かな実装や構築内容は変わってきますが、要素を分解しておくと、そのまま流用できるものと、手順が参考になるものが明確になるため、情報交換が円滑になり、属人性も下げることもできます。

 

次に、個々の要素について詳細に説明していきます。

 

Jenkinsで作成するシステムの評価ポイント

まず、Jenkinsで作成するシステムはどのような点で評価されるのかを整理しておきましょう。

ここができていないと、システムを変更、更新した時に以前より使い勝手が悪くなりチームのアウトプットを低下させることにもなります。

 

例として、３点わかりやすい評価点を説明します。

  • Jenkinsで単位時間あたりにこなせる仕事の量（ビルド時間、並列性）
  • 安定性（稼働率、ビルド失敗する確率）
  • 復旧手順の容易さ

 


１つ目はビルドの時間や、同時に実行できるビルドの数です。特にゲームでは大量の素材を使用するため１回のビルドが長くなりがちです。

ビルドが完了しないと、動作の確認が行えないため、ビルドにかかる時間をいかに短くするか、また並列実行なジョブにするかということが重要なポイントです。

 

2つ目はビルドの安定性です。ビルドは繰り返し使用し、一つ一つの時間がかかるものであるため、ビルドが確実に成功するようにしておくことは非常に重要です。

一度稼働させるとビルド時間が長くなり、検証にも時間がかかるため、Jenkins構築し運用を始める前の段階で取りうるパラメータを変えてのテストをしっかりしておきましょう。

 

3つ目は復旧手順が容易であるかということです。

長く運用していると、ハードディスクの故障などで急遽Jenkinsサーバーを再構築することも発生します。

そうなった時のため、Jenkinsのスクリプトや、設定値、システム構成をドキュメント化し残しているか？という事が、システムの評価要素となります。

 

Jenkinsに関する知識

そして、Jenkinsをインストールするために必要なセットアップのための知識が必要です。

特に、Jenkinsはビルドを行うために様々なアプリ(ツール)と連携するため、基本的な処理を行うためにどのようなプラグインが必要かという知識も必要となってきます。

 

セットアップする時に注意したいのは外部サービスに接続するときの、キーを設定するなどの権限付与の方法です。

JenkinsではCredentialsという仕組みを用いて外部サービスのキーを保存することができます。

プラグインがインストールされていれば、Jenkinsの管理-Securityの項目にManage Credentialsに存在しています。

 

参照するときはJenkinsのスクリプトで、CredentialsProviderを使用し取得します。

エラーが出やすい部分なのでセットアップ時にエラーがでたら、権限周りの処理を確認するのが良いかと思います。

 

加えて仕事で使う場合、複数のビルドを複数のPCを用いてさばけるようにするために、マスター、スレーブ（エージェント）の構成でJenkinsを立てることができることも把握しておくと選択肢が広がります。

 

Jenkinsのスクリプトに関する知識 

現在のJenkinsでは、シェルの実行などの単体の処理を行うジョブに加えて
初期化・ビルド、デプロイなどの複数のジョブをスクリプトを書くことで、連続して実行・また制御することができます。この仕組がパイプラインです。

 

可視化されたパイプラインの構造は以下になります。

詳細など一部削除しましたが、こちらのパイプラインを作るスクリプトは以下になります。

pipeline {
    agent any

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

 

パイプラインは、Scripted Pipelineという記法と、Declarative Pipelineという記法がありScripted PipelineはGroovyをベースとしたスクリプト言語的性質を持ち、if文などで複雑な制御を行うことができます。

Declarative Pipelineはシンプルな記載方法となっており、scriptというタグを使うことでScripted Pipelineで使用できるif文なども使用可能です。

 

基本的にはDeclarative Pipelineを使うことが推奨されているので、Declarative Pipelineをベースとして使い、分岐や条件が複雑になる時はscriptタグを利用し制御文を記載するようにしましょう。


シェルスクリプト

Jenkinsのジョブでビルドを行う時に便利なものがシェルスクリプトです。

シェルスクリプトでは、OSのコマンドや他の言語を呼び出すことで、

素材などのファイルのコピーや削除処理、その他素材の加工処理を順序だって実行することができます。

 

言語仕様的には高度な抽象化などを行う仕組みはないため、誰でもすぐに使いやすいですが、変数の展開、関数、引数の取り扱いなどシェルスクリプトの特有の記載方法があり他人のコードを理解する上でも重要ですので、一通り把握しておきましょう。


OSのコマンド

ビルドを行う時には、シェルスクリプトの中で、ファイル、ディレクトリの作成、コピー、削除を行うOSのコマンドを利用し、ビルドの準備を行うことがあります。

 

繰り返しビルドを行う場合には前回の生成物をいかに利用するかが重要になってきます。

その時使用するのが、cpやrsyncなどのコマンドです。

ファイルが消えたときの処理、サイズが変わらないがタイムスタンプが変わる時の処理などが問題になりやすいため、コマンドの活用方法を正しく理解しておきましょう。

 

UnityのAssetBundleビルドに関する知識

UnityのAssetBundleビルドの仕組みは日々変化、発展しており

所属しているプロジェクトによって、AssetBundleManager、AssetGraphTool、Addressable Asset Systemなど使われているAsssetBundleビルドの仕組みを理解しておく必要があります。

加えて、基盤となるAssetBundle自体の仕組みを理解しておけば、アップデートなどで変化があった場合も正しい判断ができます。

このため、基盤の仕組み、ビルドの仕組み両方を把握しておきましょう。

Gitなどソースコード管理システムに関する知識

アセットバンドルや素材などのリソースビルドを行う際には、ゲームに使われる大量のリソースをいかに早く、Gitなどのソースコード管理システムから取得することが重要になってきます。

 

ゲームのビルドにおいては、日々少しずつリソースが追加されるため、差分だけをいかに効率的に取得するかといいう点が重要でGitなどのソースコード管理システムのコマンド、仕組みも理解をしておく必要があります。

 

リソースのアップロードに関する知識

ビルドの最終工程としては、作成したものを、開発環境や本番環境に反映する作業が必要になります。

ビルドが正常に終わっても正しく反映出来ていないと、更新した作業を確認することが出来ません。

  • 素材の差分のみを反映する仕組み
  • 常に新しいもの上書きする仕組み
  • 素材の反映状況を確認する仕組み

など、頻繁に使う作業などを把握した上で、Jenkinsでのビルドの仕組みに加えて、確認用のツールも容易しておくと良いかと思います。


まとめ

少々長くなりましたが、今回はJenkinsで処理を自動化する際に必要な要素の全体像を整理してみました。

この情報があれば、現在課題となっているところを見つけ、深堀りするための目次に使えるのではないかと思います。

 

実際に使用するコマンド、機能、注意しておくべき所は別途まとめる予定ですのでご期待ください！

 

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

f4samurai エンジニアブログ開設！

 

ご挨拶

はじめまして！
この度、f4samuraiエンジニアブログを開設することになりました。
このエンジニアブログでは、技術情報を共有したり、f4samuraiの特徴をエンジニア目線からお伝えしていければと思います。

エンジニアから見たf4samuraiの特徴

早速エンジニアの自分から見て、f4samuraiの特徴をお伝えしていこうと思います 。

現在の勤務形式

まず、2022年9月 現在の勤務形式は、基本的に在宅勤務を推奨しています。オフィス自体は、常にオープンしているため、家に作業スペースがない方や、会社の方が集中できる方はオフィスを利用することも可能です。

 

オフィスはJR秋葉原駅の目の前にある秋葉原UDX内にあり、どこに住んでも通いやすく、雨の日もあまり濡れずに通勤が出来ます。

始業開始が10:30であるのも、朝の通勤が混まずに助かるところです。

 

オフィス外観



オフィスは、PCに加えて２つの外付けディスプレイが支給され

椅子だけでなく机も昇降する形式で非常に快適な開発環境となっています。

昇降式の机

 

自分は、基本的に在宅のほうがプログラムや設計に 集中できるので好きなのですが、オフィスが非常に綺麗で、快適、かつ秋葉原駅目の前とアクセスも非常に良いため、出社して働くのも楽しいと感じるようになりました！

オフィスをより知りたい方は、写真や設計思想が以下にあるので是非見ていただければと思います。

https://ibasho-ob.com/archives/7625

会議の頻度について

在宅作業が中心であることで、エンジニアとして気になるのは会議の頻度についてです。

こちらについては、担当するプロジェクト、立場、担当範囲によって異なりますが

定常的に行われるものは

・月１の全社会議

・毎朝のチーム、エンジニアの朝会

となっており、会議は多すぎず、開発に集中できる状態です。

 

オフィスにおけるリモートでのミーティングは、自席や会議室以外にも使えるスペースがあり、場所の確保や会話のハウリングなどでのストレスもなく快適です。

具体的には以下の写真のようなスペースが存在します。

カフェの作業スペース

集中ブース

窓際の作業スペース

エンジニアの傾向としては、全体的に大人しく、しっかり考えて行動する人が多い印象です。

このこともあり、定常以外の会議でも短い時間で有益な情報交換や議論が行なうことができ開発に集中できると感じています。

 

最後に

f4samuraiに入る前は、あまりf4samuraiで働いている方の情報がなく、どのような会社かイメージがわかなかったですが

実際に働いてみると

  • 快適な開発環境
  • エンジニアとして適切なコミュニケーション頻度
  • これから成長していけそうな組織風土

と、エンジニアとして求めるものが揃っているなと感じています。

 

オンラインでのカジュアル面談なども行っているので、直接お話しを聞きたい方がいらっしゃいましたらぜひ申し込んでください！

https://open.talentio.com/r/1/c/f4samurai/pages/48992

 

また、エンジニア採用特設サイトを作成致しました。

こちらもご覧いただければと思います。

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