Photoruction工事中！

Photoructionの開発ブログです！

Photoructionリリースするまでのテストについて（今ある課題と今後の取り組み）

こんにちは！株式会社フォトラクションでQAグループのリーダーをしている塩谷です。 Photoruction Advent Calendar 2021の8日目の記事です。

 

本日はPhotoructionを開発していく中でどのように品質を担保しているのか広めたいと思い、リリースするまでのテスト業務について記事にしてみました。

目次

1.はじめに
2.リリースまでのプロセス
3.開発環境でのテスト
4.リリース環境でのテスト
5.課題と今後

はじめに

私の経歴とフォトラクションのQAグループについてご説明いたします。

 

私は、大学卒業後に某SIer企業に入社いたしました。そこでは仕様策定や評価業務など様々なプロジェクトに従事し、プロダクト開発における上流工程〜下流工程の経験とスキルを積みました。

フォトラクションに入社する直前にはプロジェクト管理者として評価プロジェクトの管理を行っており、その経験が今に繋がっていると感じています。

 

2020年5月に縁があってフォトラクションに入社することになり、その際にCEOの中島からはQAグループを作って欲しいというミッションが与えられました。

当時のフォトラクションにはQAグループが存在しておらず、開発における評価業務はエンジニアがテスターにテストを依頼するという形をとっていました。

ゼロからQAグループを作ることになったので手探り状態でしたが、身の回りの細かいことからコツコツと進めていくことで今のQAグループが出来上がってきたと思います。

リリースまでのプロセス

Photoructionが開発されてからリリースされるまでのプロセスについてご説明いたします。

現在おおよそ1ヶ月に1回新規機能のリリースを行なっており、その際は下図のような開発フローを採用しております。

リリースまでには大きく分けると開発フェーズとリリースフェーズの2つのフェーズが存在しています。

  1. 開発フェーズ
    各開発のフィーチャーブランチで実装を行い、開発環境を作成してテストするフェーズになります。実装〜テスト・各種レビューまで行い開発フェーズが終了します。
  2. リリースフェーズ
    リリースブランチを作成して各フィーチャーをマージしたリリース環境でテストするフェーズになります。 バグが発生したらその都度改修を行い、バグの改修が完了したらリリースフェーズが終了します。

f:id:photoruction_tech_blog:20211202151623p:plain



開発環境でのテスト

開発環境のテストでは、単体テスト・結合テストに位置付けられるテストを実施します。

各開発案件にアサインされているQAエンジニアがテストケースを準備し、テスターにテスト実施を依頼します。

テストケースの内容は企画書・仕様書から機能的な確認項目を作成し、QAグループ内のレビュー、PM・エンジニアとのレビューを経て完成します。

それぞれの開発に対して環境を準備してテストすることで開発毎に品質を確保した上でリリース環境にマージしリリースフェーズに臨みます。

各開発についてリリースターゲットはあらかじめ計画していますが、開発環境でのテストをパスできない場合は、リリースターゲットの変更など対策を行います。

リリース環境でのテスト

リリース環境のテストでは、各開発のテストケース再走行とリリース前テストを実施します。

テストケースを再走行する目的は、マージ後の予期せぬデグレの検出となります。

Photoructionは機能的にも実装的にも複雑化しており、各開発をマージした後に予期せぬバグが発生することがあります。

そのため、マージ後の環境でテストケースを再走行することでバグ流出を防ぐように取り組んでいます。

テストケースの実施とバグの改修が完了したら、リリース前の最終テストを実施します。

リリース前テストは開発内容によらず固定のテストケースを実施しており、

内容は全機能の基本的な動作の確認になります。

以前はリリース前テストは実施していませんでしたが、リリース物に対して総チェックを行うべきとの考えからリリース前テストを実施することにしました。

導入した当初は開発に関わるものそうでないものなど様々なバグを検出していましたが、徐々にバグ検出数が減少し、品質が向上してきていると考えています。

全てのテストをパスしたらリリースされます。

課題と今後

フォトラクションのQAグループでは、様々な課題を抱えておりますが、

当然ながら最も重要な課題は市場へのバグ流出を防ぐことだと考えています。

「リリース環境でのテスト」の項でもご説明した通り、リリース環境では各開発の２サイクル目のテストを実施しております。

マージによるデグレリスクを低減させることができれば、同じテストを２サイクル実施するのではなく、別の観点でのテストを実施することで今まで防げなかったバグの流出を防げる可能性が出てきます。

デグレの低減についてはQAグループだけの取り組みでは、改善させることが難しいので開発部門と連携をしながら改善に取り組んでいます。

また、リリース前テストなど定型的なテストについては、自動テストの導入に取り組んでおり、自動テストでまかなえるテスト工数の分だけ別のテストを導入することができます。

自動テストは誰でも実行できるようにすることで、例えばエンジニアが任意のタイミングで実行し早期にデグレなどのバグを検出できる効果も期待できます。

他にも発生したバグ分析やバグの発生数を減らす施策の検討などQAグループとして課題は多く残っている状況ですが、QAグループがリリースされる前に最後までPhotoructionを触っているので”最後の砦”とという自覚を持ち、地道にコツコツと品質を上げていけるようにこれからも努力を続けていきたいと思います。

 

 

今回の記事を通してフォトラクションも品質を向上できるように考えているということが少しでも伝われば幸いです。

ありがとうございました。

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

 

 

Vueのシングルファイルコンポーネント(SFC)を生Javascriptアプリで使おう！

株式会社フォトラクション WEBチーム所属 ジョンです！
Photoruction Advent Calendar 2021の7日目の記事です。

Vueのシングル・ファイル・コンポーネントをSPAではないプロジェクトに使える方法を紹介したいと思います。

目次


フォトラクションでは、アプリケーションの改善を常に行っています。それの一つの計画としては今のアプリケーション内に古く書かれているBackbone.jsとjQueryを最もモダンなフレームワーク、Vue.jsに書き直すことです。

だが一つ問題があり、レガシーコードを書き直しながら新しい機能を増やすことも大事で私たちのリソースをコードの書き直しだけに無駄に使うのがふさわしくない。そのため、Backbone.jsやjQueryで書かれているコードにも新しい機能を追加することもよくあるのです。ソースコードをすべてVue.jsに書き直すついでにBackbone.jsやjQueryをこれ以上増やしたくないので、新しい機能もVueで開発したかったです。

なお、Vueにはいろいろ書き方があります。その一つはSFCを使わずに直接Vueのインスタンスを作ることです。もちろんこのような書き方にしても問題ないですが、VueのSFCのメリットを得られなくなる上に管理もしにくくなります。

<!DOCTYPE html>
<html>
    <head>
        <title>俺のものすごいアプリ</title>
    </head>
    <body>
        <div>
            <!-- 既存コード -->
        </div>
        <div id="my-vue-component">
            <other-component />
        </div>

        
        <script
            src="https://code.jquery.com/jquery-3.6.0.min.js"
            integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4="
            crossorigin="anonymous"
        ></script>
        <script src="https://cdn.jsdelivr.net/npm/vue@2.6.14/dist/vue.js"></script>
        <script>
            $(document).ready(() => {
                ...既存コード
            });

            Vue.component('other-component', {
                data() { ... },
                template: '...'
            });
    
            new Vue({
                el: '#my-vue-component',
                template: '...',
                data() { ... },
                methods; { ... }
            });
        </script>
    </body>
</html>


では、早速始めましょう！

前提条件

Node.js - npmからVueやwebpackなどをダウンロードするため、Vueのシングル・ファイル・コンポーネントはそのままJavaScriptに使うことができないため、コンパイルする必要があります。

シングル・ファイル・コンポーネント（Single-File Component）

<template>
    <button>
        <other-component />
        <slot />
    </button>
</templaet>

<script>
import OtherComponent from './OtherComponent.vue';

export default {
    component: {
        OtherComponent
    },
    data() {
        return { ... };
    },
    methods: { ... }
};
</script>

<style scoped>
button {
    padding: 1rem 2rem;
}
</style>

Vueのシングル・ファイル・コンポーネントは基本的に.vueという拡張子が付いています。この.vueファイルにはHTML、JavaScriptとCSSをまとめてバンドルすることができます。Vueでシングル・ページ・アプリケーション（SPA）を作ったことがある人には見慣れたコードになると思います。このファイルはSPAを作るときの.vueファイルと全く同じのため、他のコンポーネントやライブラリーをインポートすることはできますし、JavaScriptの代わりにTypeScriptを使うこともできますし、SASSなどを使うこともできます。

ローダーのスクリプト

先ほど作ったSFCを使えるために、ローダースクリプトを作ります。ローダースクリプトはVueコンポネントをアプリケーションにマウントさせるためのスクリプトになります。これがないとSFCを使用できません。

import Vue from "vue"; 
import MyComponent from "../components/MyComponent.vue";

const el = document.querySelector('#some-element'); 
new Vue(MyComponent).$mount(el);

VueでSPAを開発したことがある方は.vueファイルのようにこれも見慣れたコードになっていると思います。Vueのシングル・ページ・アプリケーションのindex.jsに書かれているものと同じです。ここで何をやっているのかというと、まずVueとプロジェクトに使いたいコンポーネントをインポートします。そして、new Vue(MyComponent)で新しいVueのインスタンスを作り、コンポーネントをパラメータとして渡します。それから、.$mount(el)でアプリケーション内の好きな場所にマウントします。

コンパイル

コンポーネントとローダースクリプトを完成したら、コンパイルする必要があります。コンパイルするためにはNode.jsが必要です。Node.jsはまだインストールしていない方には先にインストールしてください。Node.jsをインストールした後次へ進んでください。

Nodeで既に開発している場合

もしNodeですでに開発をしている場合はnpmから必要なパッケージのみインストールしてください。自分のプロジェクトにすでにインストールされているパッケージはインストールしなくていいです。プロジェクトにインストール済みのパッケージはpackage.jsonに確認できます。


まずは、vue、vue-loaderとvue-template-compilerをインストールします。

npm install -D vue vue-loader vue-template-compiler


次はwebpackをインストールします。

npm install -D webpack webpack-cli


最後は.vueの中にあるCSSなどのためのローダーをインストールします。

npm install -D @babel/core babel-loader css-loader vue-style-loader

今回はシンプルにしたいため、SASSなどを使わないですが、もしSASSが必要であればsass-loaderなどをインストールする必要があります。


次は、webpack.config.jsを修正します。


webpackが使われていないプロジェクトにはこのファイルが存在していない可能性あります。であれば、プロジェクトのrootにwebpack.config.jsのファイルを作成してください。

const { dirname } = require("path");
const VueLoaderPlugin = require("vue-loader/lib/plugin");

module.exports = {
  entry: {
    "favorite-cat": "./vue/loaders/favoriteCatLoader.js",
  },
  output: {
    filename: "bundle.js",
    path: __dirname,
  },
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: "vue-loader",
      },
      {
        test: /\.js$/,
        loader: "babel-loader",
      },
      {
        test: /\.css$/,
        use: ["vue-style-loader", "css-loader"],
      },
    ],
  },
  plugins: [
    new VueLoaderPlugin(),
  ],
};

webpack.config.js確認

  1. webpack.config.jsはすでにあるプロジェクトには上記の内容が自分のwebpackコンフィグに存在しているかどうか確認してください。
  2. module.exportsのmodule.ruleの順番が大事なので、webpack.config.jsを修正するときに注意をしてください。


新しいコンポーネントやローダースクリプトを追加するときに、module.exportsのentryに追加しなければなりません。

module.exports = {
  entry: {
    "comp1": "./loaders/ComponentLoader1.js", 
    "comp2": "./loaders/ComponentLoader2.js",
    "comp3": "./loaders/ComponentLoader3.js",
  },
　...
}

プロジェクトのrootにpackage.jsonを開いて、下記を追加してください。

"scripts": {
    "build": "webpack --config webpack.config.js --mode development"
},


プロジェクトに初めてNodeを使った場合にはwebpack.config.jsみたいにpackage.jsonも存在していない可能性があります。その場合は、下記を実行し、プロジェクト情報を入力してください。

npm init

そのあとは上記のpackage.jsonファイルの編集を行ってください。


最後にはビルドをします。

npm run build


上記のコマンドを実行したら、プロジェクトのrootにbundle.jsが生成されます。そのbundle.jsをHTMLの中にインクルードします。

<html>
    <body>
        ...
        <script src="bundle.js" defer></script>
    </body>
</html>


そのあと、HTMLにコンポーネントのマウント先を作ります。
ロードスクリプトに#some-elementにコンポーネントをマウントしようとしているため、<div id="some-element"></div>を追加すれば、Vueコンポーネントはこのdivの中にマウントされます。

まとめ

自分のプロジェクトはVueのシングル・ページ・アプリケーションではなくてもVueのシングル・ファイル・コンポーネントを使えます。上記でいろいろやりましたが結局３つのステップで済むことができます。

1. Vueコンポーネントを作成
2. ローダースクリプトを作成
3. ビルド

今までのスパゲッティコードを何とかしたいけど、今のプロジェクトをSPAに書き換えることができない人は是非やってみてください！


株式会社フォトラクションでは一緒に働く仲間を募集しています
corporate.photoruction.com
www.wantedly.com

AWS Lambdaを効率良く開発する！

株式会社フォトラクション WEBチーム所属 下川原です！ Photoruction Advent Calendar 2021の6日目の記事です。

この記事ではAWS Lambda for Node.jsを効率良く開発するためのTipsを紹介します！

まずはじめに必要なもの

  • windowsの方はwslなどインストールしておくと吉（コマンドプロンプトプロフェッショナルは、読み替えてください）
  • IDEは自分が馴染むやつ
  • AWSのアカウント

目次

 

初期構築

インストールしておくべきもの

https://aws.amazon.com/jp/cli/

  • AWS SAM CLI　（Lambdaをローカルで実行するのに必要）

https://aws.amazon.com/jp/serverless/sam/

  • aws-vault (MFAを使用しているAWSアカウントは、インストールしておくと幸せになる）

https://github.com/99designs/aws-vault#installing

  • makeコマンド（それぞれの環境に合ったインストール）下記はapt例
$ sudo apt install make
$ sudo apt install make-guile

ディレクトリ構成

lambdanodejs　
├── Makefile　※２
├── [Readme.md](<http://readme.md/>)　お好きにどうぞ
├── debug-env.json　※３　
├── events
│   └── request-sample.json　※３
├── libs　※４
│   ├── Makefile
│   └── nodejs
│       ├── package-lock.json
│       └── package.json
├── samconfig.toml　※５
├── src　※４
│   └── lambdanodejsMaster
│       ├── lambdanodejsMaster.js
│       └── package.json
└── template.yml　※１

template.yml ※１

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: AWS Lambda Nodejs

Resources:
   lambdanodejsMaster:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: lambdanodejsMaster
      Role: ${lambdaを実行するロールのARN}
      Handler: lambdanodejsMaster.lambdanodejsHandler
      CodeUri: ./src/lambdanodejsMaster
      Runtime: nodejs14.x
      Timeout: 300
      MemorySize: 128
      Layers:
        - !Ref LibsLayer
      Environment:
        Variables:
          ENV_SAMPLE: SAMPLEDONE
  LibsLayer:
    Type: AWS::Serverless::LayerVersion
    Metadata:
      BuildMethod: makefile
    Properties:
      LayerName: libs
      Description: Libraries
      ContentUri: ./libs
      CompatibleRuntimes:
        - nodejs14.x
      RetentionPolicy: Retain

参考

AWS Lambda テンプレート Cloud Formation

LambdaのMemorySizeによってCPUのスペックが決まる話

AWS Lambda のリソースモデルでは、お客様が関数に必要なメモリ量を指定すると、それに比例した CPU パワーとその他のリソースが割り当てられます。メモリサイズが増えると、関数で利用可能な CPU にも同等の増加が発生します。

makefile ※２

.PHONY: build clean test

LAYER_ARTIFACTS_DIR=.aws-sam/build/LibsLayer
LAYER_NODE_MODULES=$(LAYER_ARTIFACTS_DIR)/nodejs/node_modules

.aws-sam/build.toml: template.yml samconfig.toml src/*.js libs/nodejs/package-lock.json
   sam build

build: .aws-sam/build.toml

deploy:
   make clean
   make build
   sam deploy

clean:
   rm -rf .aws-sam

test:
   cd libs &&ARTIFACTS_DIR=../$(LAYER_ARTIFACTS_DIR)make build-LibsLayer-test
   cd src &&PATH=../$(LAYER_NODE_MODULES)/.bin:${PATH} NODE_PATH=../$(LAYER_NODE_MODULES)npm test

jsonファイル ※３

debug-env.json

ローカル実行時の環境変数ファイル

デプロイするときは必ずtemplate.yamlに記載する

{
  "lambdanodejsMaster": {
    "ENV_SAMPLE": "SAMPLEDONE"
}

request-sample.json

lambda関数に渡すリクエスト

nodejs内関数Handlerの第一引数で受け取れる（変数名: event）

{
  "key": "sample value"
}

src ※４

nodejs本体のディレクトリ　詳しいことはnodejsを参考に

Node.js の AWS Lambda 関数ハンドラー

lambdanodejsMaster.js 最低限必要なもの

exports.lambdanodejsHandler = async (event, context, callback) => {
	console.log(event);
	callback(null,event);
}

samconfig.toml ※５

AWS SAM CLI の設定ファイル

例）

version = 1.0
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "stack"
s3_bucket = "${配置するS3のARN}"
s3_prefix = "${配置するS3のprefix}"
region = "ap-northeast-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"

ローカル実行！

# nodejsをビルドする
$ sam build

# ローカル実行
# -n envファイルのパス
# -e 関数へ渡す引数のパス
$ sam local invoke lambdanodejsMaster-n ./debug-env.json -e ./events/request-sample.json

# AWS Lambdaへデプロイをする
$ sam deploy

これで、AWS Lambda関数をローカルで快適にガシガシ開発できます！

よいデベロッパーライフを！

 

株式会社フォトラクションでは一緒に働く仲間を募集しています


 

フォトラクションのCREって何やってるの？

こんにちは！株式会社フォトラクションでCREグループのリーダーをしています脇田慎平です！ Photoruction Advent Calendar 2021の5日目の記事です。

フォトラクションのCREチームがどんなことをやっているか、紹介します！

CREとは？

Customer Reliability Engineering（顧客信頼性エンジニアリング）の略で、2016年にGoogleが提唱した専門職です。

日本でCREを組織として持っている会社だと、メルカリさんやはてなさん、アンドパッドさんなどが有名でしょうか。

CREはまだ歴史が浅く、会社によってもCREの定義・役割は様々なようです。

フォトラクションは、2021年1月にCREチームを発足しました。

開発チームが抱えていた課題

CREチーム発足以前のフォトラクションにおける開発組織の喫緊の課題として、「緊急性の高いバグ対応により、新規開発のスケジュールが遅れる」というものがありました。

そもそも不具合が発生しないようにしなければならないのは大前提ですが、システム開発をしている以上どうしてもバグは発生してしまいます。フォトラクションは建設現場で使用される施工管理アプリであり、バグの内容によってはお客様の業務が完全に止まってしまうことになります。

そうした緊急性の高いバグが発生した場合は、新規開発を止めて全力でバグ対応を行います。無事にバグ改修をリリースした後、新規開発に戻ります。

しかしこれでは、"いつ起こるか分からない"バグ改修に新規開発のリソースが使われることになり、スケジュール通りの開発は困難になります。

また、これまではどちらかというと「ガンガン作っていこう！」という開発スタイルだったので、解消されるバグ数よりも新たに発生するバグ数の方が多くなってきました。「本当にクリティカルで今すぐ直さないとお客さまの業務に大きな支障が出る」というレベルのバグ以外は、少しずつ後回しになりがちになっていました。

フォトラクションのCRE

そんな課題を解決すべく、フォトラクションでは2021年1月にCREチームを立ち上げました！

現在フォトラクションのCREが担う役割は以下です。

  1. お客さまからの問い合わせおよびバグ改修において責任を持つ
  2. 資産となる既存アプリケーションの価値を守る
  3. 他グループがアプリケーション開発、価値創造に集中できる環境を作る

当初の課題であった「新規開発とバグ改修とのリソースの分離」の文脈だけでなく、CREの本来のミッションである「顧客信頼性を高めること」、つまり「お客さまの不安を取り除くこと」にもフォーカスした役割設定になっています。

具体的な業務内容

ではフォトラクションのCREが具体的に何をしているのか、簡単に紹介します。

バグ改修

前述の通りです。これまで新規開発チームがやっていたバグ改修はCREで行います。おかげで、新規開発チームは集中して開発を行うことができるようになりました。

カスタマーサポートチームが受けたお客さまからの技術的な問い合わせ対応

こちらは多岐に渡ります。問い合わせへの対応はカスタマーサポートが担当するのですが、回答する上で技術的な知識が必要とされる問い合わせに対し、CREチームが窓口となって調査を行います。「今まさに現場で困っている！」というご相談もあり、スピーディーな対応が求められます。

あくまで調査の窓口であるので、CRE内で全てを解決するというわけではありません。QAチーム、PMチーム、新規開発チームと連携をとり、必要な協力を仰ぎながら解決を目指します。ここは窓口であり一次切り分けを行うCREの腕の見せ所でもあります！

カスタマーサポートが要望する社内ツール開発

フォトラクションでは、カスタマーサポートからお客さまへ提出するレポートの出力などで、一部社内向けに開発も行っています。こうした社内向け開発もCREで担当しています。

やりがい

個人的に一番のやりがいは、「お客さまの生に近い声が聞ける」ことだと思います。お客さまとの直接の窓口であるカスタマーサポートチームと密にやりとりをする中で、お客さまからの声（良いもの・良くないもの両方）に触れることが多くなります。

フォトラクションもそれなりの規模感になってきて（社員60名弱）、なかなか開発チームにお客さまからの声が届きにくくなってきているのが正直なところです。

「目の前で困っている人の課題を解決し、その感謝の声を聞くことができる」というのは、やはりやりがいがあります。

CREの使命の一つは「バグを解消してお客さまの不安を取り除く」ことですが、そもそもバグが発生しない方がイイに決まっています。開発組織全体の課題として、「バグの発生を抑える」ことに現在全力で取り組んでいるところです！！！

どんな人が活躍できそう？

フォトラクションのCREでは、どんな人が活躍できるだろうか？ということをしばらく考えてみた結果、

  • WEB開発経験がある
  • 柔軟なコミュニケーションが取れる

という結論に辿り着きました。「『技術力とコミュニケーション能力が大切』なんて誰でも知ってるわ！！！百万回聞いたわ！！！」って感じですが笑、やっぱりここに集約されると思います。

WEB開発の経験がある

「カスタマーサポートが答えられない技術的なサポートをする」という役割である以上、そのベースとなるWEB開発の経験は非常に大切であります。

前述したように、お客さまの業務が止まってしまうようなバグが発生している時には、スピーディーな対応が求められます。時には、「まず業務が再開できるような一次対応を短時間で行ったのち、同じバグが二度と発生しないための恒久対応を行う」といった柔軟な判断も求められます。

フォトラクションのCREも、経験豊富なメンバーの技術力によって支えられています！

柔軟なコミュニケーションが取れる

お客さまとの直接の窓口であるカスタマーサポートチームだけでなく、バグの再現やリリーススケジュール調整のためにQAチームとも連携をとりますし、仕様のすり合わせのためにはPMチームと、そして当然他のエンジニアとも連携して動く必要があるのでエンジニアチームともコミュニケーションが発生します。

開発関係者だけでなく営業サイドとのやりとりも多いです。

特に非エンジニアであるカスタマーサポートチームと会話する際には、技術的な用語をできるだけ使わない・お客さまにも伝わる言葉で伝えるといった意識が必要です。

相手によって柔軟に対応できるコミュニケーションスキルは、非常に大切になりますね。

これからやっていきたいこと

CREという概念自体5年ほど前に生まれたばかりで、世の中にもモデルケースと呼ばれる事例はとても少ないです。また、ビジネスモデルやサービス規模によっても、CREが求められる役割は大きく異なるはずです。

現在フォトラクションのCREは、バグ改修やカスタマーサポートの支援（技術的課題の解決・社内ツール開発）などを主な役割としています。世の中に正解がない中で、「CREチームはフォトラクションの中でどういう役割を担うべきか」という議論は、まだまだ社内でも必要だと思います。というより、サービス・会社の成長とともにCREの役割も常にアップデートし続けていかなければなりません。

まだ歴史の浅いCREという領域において、フォトラクションの事例が代表的な一例となっていけるよう、今後も精進していきます！

まとめ

フォトラクションアドベントカレンダー、明日からも現場のリアルな声が詰まった魅力的な記事が続きます！ぜひ見てもらえると嬉しいです。ありがとうございました！

 


株式会社フォトラクションでは一緒に働く仲間を募集しています


入社直後のエンジニアのプロジェクトをPMとして振り返る(後編)

はじめに

qiita.com

Photoruction Advent Calendar 2021 4日目です。

株式会社フォトラクションのPMチームに所属しています。神澤です。

最近は海外Youtuberのデスクツアーを見るのが好きで、机の裏を光らせようか真剣に悩んでいます。

3日目に投稿された記事は見ていただけましたでしょうか。

今回は別視点で、このプロジェクトの担当PMの、様々な問題点を赤裸々に語ろうと思います。

まず自分語り

一年半前、2020年4月にフォトラクションにジョインするまでは、建設業の世界で生きていました。

主に、建物の新築や改修工事の予算を計算するお仕事。他にも色々していましたが割愛。

これまでは、人と話すなら対面か電話、文章連絡やデータ送信はメールで、他社の話を聞いた際にNAS（ネットワークHDD）が設置されている会社に出会うと「進んでいるなぁ」と感じるほど。

Excelのvlookupと最低限のVBAが扱える程度で「お前はシステムに特に強いから」という評価を受けていました。

そんなIT素人とも言える私ですが、ビジョンへの共感と業界を良くしたいという想いを評価いただき、当初はドメインエキスパート（業界出身としてのシステム企画担当）として入社させていただきました。

現在では、プロジェクトマネージャーとしての役割に、この職務を吸収した形になっています。

新米PMでバックグラウンドが業界知識特化のため、とにかく初期はメンバーに支えられました。

プロジェクトマネジメントを先人（入社当時はCEO中島さんしかPM担当者がおらず兼任状態）から教わり、PMとは、システムとは、を学びながら仕事を進めていました。

現在も学びの連続です。

職人の技量頼りの監督

PM経験一年程で、3日目に投稿された記事のプロジェクトがスタートしました。

何回か案件を重ね、それなりに開発サイクルの理解も深まってきたと感じていた頃です。チョットワカル曲線でいう「完全に理解した」状態だったと思います。

この時点では「企画段階で新機能の期待動作が網羅出来ているドキュメントを作れば、とりあえず開発は上手くいく！！！」と考えていました。

これが間違っていたと考えた事象を以下に挙げます。担当エンジニアと記載していますが、一人ではなく、プロジェクトメンバー全員に対しての記載です。

  • 担当エンジニアの経験則に依存していた
    • 既存コードの理解が追い付いていない可能性のフォロー必要性が抜けていた
    • プロダクトの仕様の理解が追い付いていない可能性という発想がなかった
    • 「ワカッタツモリ」を「今のところ開発進行上には問題がないだろう、詳細を詰めたら分かるだろう」と受け取ってしまった
  • 担当エンジニアの技量に依存していた
    • どのエンジニアも時間をかければ既存コードの書き方に同意できるし、そのやり方に沿った改修が出来るもの、と考えていた
    • 期待動作のアクションは他の機能の傾向を見てよしなに判断できるだろう、と考えていた
    • メンバーの「正解が分かってないんだけど何が分からないのか分からない」問題を、ヒアリングで解決できると信じていた
  • チームとして必要になるタスクを軽視していた
    • OS差分や、ブラウザとアプリの差分、他諸々の懸念点はメンバーレイヤーで全て解決できると思っていた
    • 他メンバーに依頼しなければならないタスクの洗い出しを行わず、とりあえず自分の領域を終わらせようというスタンスで考えていた（合わせるための検討や考え方の統一を後回しにしてしまった）
    • 個々人が100点になれば総じて100点になると信じていた

振り返ると、相当酷いマネジメントだったなと思います。

「信じる」の言葉の履き違え方がすごいですね。

チームタスクはチームで支え合って進められている

自分のプロフェッショナル領域に責任を持つという価値観は大事だと思います。少なくとも私は尊重したいなと思っています。

しかし、だからといって一方的に任せてよいという理由にはならないことを改めて痛感しました。

個々人のタスクが各々で完了すれば全体も完成する、というのは、全体に必要なタスクを個人タスクに落とし込めている前提です。

チームである以上、各メンバーは他のメンバーに「支えてもらっている」面があります。

PMとしても「各メンバーのタスクを終わらせるためには」の視点以外に「他の人の仕事がスムーズに終わるには」「チーム全体のタスクを達成するには」と、メンバー同士のコミュニケーションを促進する働きを行う責任があると考えています。

もっと言うと、メンバー同士が自主的に尊重し合える文化作りまで必要ですね。

どうしていくべきか

誰しもが成長途中で、その時々の仕事内容で不足する知識や技量は往々にして存在します。なので失敗しない仕事もないし、攻略本のように全て予測可能なマニュアルを作る事もできません。

ただし、だからといって毎回失敗していいという訳でもありません。可能な限り、失敗を減らそうと考え続けることが大事だと考えています。

主にマインドの話になりますが、以下がまとめです。

  • その場にいるだけで人を支えているし、人に支えられている。支えられてなくて無関係ということはない。リスペクトが大事。
  • 問題が起きてから消火活動を始めるのではなく、起きる前の防災活動が大事。作りたい成果物から逆算して必要なタスクや懸念点を考える必要がある。
  • 個々人で100点が出るのを待っていたのでは確認が遅い。早く失敗して、早く改善したかった。
  • 単純な仕組み（部分プロセスの最適化）だけでは解決しない、新たなプロセスのたびに考え、正しい結果を出すための方法論を都度模索していくべき。

これらはPMである私だけでなく、チームメンバー全員で持っているべきマインドであると思っています。そのためには、まず火種役の私から持つべきだ、とも強く思っています。

これらは、フォトラクションMVVに通ずる話が多いです。私の体験談からでも紐づけることのできる、とてもよく出来ているバリューなので、今後も意識し続けていきたいです。

https://www.wantedly.com/companies/photoruction/post_articles/339794

おわりに

前編、後編、という形で、プロジェクトの振り返りをしてみました。

案をくれた田中さんへ、スペシャルサンクスです。

「完全に理解した」って本当に成長曲線の通りなんだな、これ考えた人天才だな、と思っています。とはいえ、なにもわからない、と言える自信はないです。

プロジェクトマネジメント、マジデゼンゼンワカラナイ。

明日は更に後編へ、、、とは続きません。

また別の視点でのエントリーをお楽しみください。

 

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

職業エンジニアとしての初プロジェクトを振り返ってみた(前編)

こんにちは！株式会社フォトラクションでWebエンジニアをしている田中喜規です。 この記事は、Photoruction Advent Calendar 2021の3日目の記事になります！

今年2月に異業種から転職して、職業エンジニアとしてフォトラクションに入社。

その初プロジェクトで、プロジェクトが大幅に遅れるという、大失態がありました。

その時の経験を糧にすべく、本記事を執筆しようと考えました。。！

続きを読む

入社して2年間を業務日記から振り返ってみた〜1年目編〜

こんにちは！株式会社フォトラクションでWebエンジニアをしています南風原（はえばる）です。

Photoruction Advent Calendar 2021の2日目の記事です。

導入

早いもので、フォトラクションに入社して2年1ヶ月1日が経ちました。

初めての自社開発ベンチャーかつ転職前は開発という開発をした経験がなく、入社後はベンチャーならではの目まぐるしいスピード感と日々の業務に食らいついていくのに必死だったのを思い出します。

入社から2年経ったということで、これまでに１日の振り返りも兼ねてツイートしていた#業務日記 を振り返っていこうと思います。

この業務日記から、南風原のこれまでの奮闘と弊社のこれまでの歩み的なのも感じられれば幸いです。

では、振り返っていきましょう〜♪

2019/11 編

[振り返りコメント]

入社初日はとてもワクワクしていた記憶があります。

当時は今よりも人数が少なく、小さいオフィス。

これがベンチャーかって気持ちと、これからバリバリ開発が出来ることに楽しみしかなかったです。

 

[振り返りコメント]

何百行、何千行といった膨大なソースコードを見たのは初めてだったこともあり、どういう風に処理を追っていいかに戸惑いまくりだったのが懐かしい。

今となってはあまり驚かなくなりました笑

 

[振り返りコメント]

入社後初めての業務はとある機能開発のUI設計でした。

当時はデザインチームもなくエンジニア自身がUI設計も担当していました。

どうしても開発していく中で「開発者目線」に考えが寄ってしまいがちですが、その度にこの日アドバイスいただいたことを思い出しユーザーにとって良いのはなんだろうって考えるようにしています。

 

[振り返りコメント]

何を作るのか・なんで作るのか・どうやって作るのか

実装に入る前に自分の中にしっかり落とし込むのと落とし込まないのとで全然変わって来るなと思います。

普段からちゃんと考えるようにしよう（自戒）

 

[振り返りコメント]

初めて触れるBackbone.jsとMVCモデルの理解に当初苦戦してた記憶があります。

一緒に案件を担当していた方が全体像を図に起こして説明していただいたのが本当感謝でしかなかったです。

2020/01 編 

[振り返りコメント]

当時は、機能開発と同時並行でシステムトラブル対応もしていました。

今となってはCREチームができ別チームとして対応してますが、当時はなかなかに忙しかったのを思い出します。

あと、不具合調査ってとても勉強になる！

やればやるほどこういう風にデバッグしたら良いんだなとか、先輩エンジニアがどういう流れで調査しているのかを見て学べたのは良かったなと思います。

2020/02 編

[振り返りコメント]

ベンチャー感満載ですね笑

当時は開発以外にもいろいろなタスクをメンバーみんなでやってました。

毎日自分のできなさに心折れそうになりながらも必死についていこうとしていた時期でした。（懐かしい）

 

[振り返りコメント]

入社して驚いたことの1つは、対応言語の多さ！！

海外でもPhotoructionって使用されているんだ！すごっ！って感心したのと、特にインドネシア語は1単語1単語が長いのでUIが崩れまくりで調整が大変でした。（最初から考慮して実装していなかったのも悪いですがね）

 

[振り返りコメント]

先輩エンジニアからのコードレビューはとても勉強になってました。

あまり考えず何気なく書いたコードを「なぜこういう実装にしたの？」の質問にうまく答えられなかったり。。

ちゃんと自分が理解して書いたコードとそうでないコードって全然違うんだなって学びでした。

 

[振り返りコメント]

エンジニアは普段ユーザーと接点がないので、こういった経験はとても学びが多かったです。

実際にユーザーが使用している様子を見るともっと良いもの作ろうと開発のモチベも上がって良いなと思ったりしました。

 

[振り返りコメント]

入社当初は先輩エンジニアにだいぶ助けてもらったなーと。

本当感謝してもしきれないです。

2020/03 編

[振り返りコメント]

入社して4ヶ月後にはチームリーダーをやらせていただいたりしました。

手を挙げれば挑戦させてもらえる環境っていうのもベンチャーならではだなと思います。

 

[振り返りコメント]

この時期からコロナが流行りだし、全社的に在宅勤務になりました。

今まで、面と向かってコミュニケーションとっていたのがSlack上でのやりとりとなり次々とくるSlackの通知にあたふたしまくってました。

2020/04 編

[振り返りコメント]

リーダー業務をするようになってからは、完全に開発からは離れ環境整備やチームの課題に対して向き合うことが多かった印象です。

とは言っても、初めてのリーダーなのでどう動いいていいのかもよく分かってなく毎日ワタワタしてたのを思い出します笑

 

[振り返りコメント]

この時期はPHPバージョンアップデートの対応をしていた頃ですね。

テストの範囲も全ての機能なのでテストケースを作るのが大変だった思い出があります。

 

[振り返りコメント]

この時期から目まぐるしく組織体制が変わっていきました。

新しいプロダクトの開発が始まったり、人が増え新しいチームが立ち上がったり。

2020/05 編

[振り返りコメント]

問い合わせが来る度に調査して仕様を把握するってことをやっていた時期でした。

Photoructionは機能が多いので仕様把握はなかなか大変。。

 

[振り返りコメント]

待望のQAチームができたのはこの時期！

一気に組織として大きくなってきたなと。

当時はQAって言葉自体初めて聞いて、どういうことをするチームなんだろって思っていました。

今となってはQAチームのありがたさが身に染みてわかります。

テストのフェーズでなるべくバグを出さないようにエンジニアはもっと頑張らないとなとは思ってますが、、

2020/06 編

[振り返りコメント]

リモート勤務でのコミュニケーションの取り方に悩んでた時期。

ただでさえ全体の把握って難しいのに、リモートだと余計に難しいですよね。

 

[振り返りコメント]

CSの方って本当ユーザーにプロダクトの仕様や機能の利用シーンついて分かりやすく伝えるスキルめっちゃ高いなって感心しまくりでした。

直接ユーザーの声が聞ける機会って中々ないので新鮮でした。

定期的にこういう場にエンジニアも同席するのありなんじゃないかなと思ったり。

 

[振り返りコメント]

新オフィスに移転した時期！

とにかく前オフィスと比べてめっちゃ広い！！ってなりました。

あと集中スペースがあったり、会議室が建設にちなんだネーミングだったりと遊び心もあったり。

実際に工事する過程でPhotoructionを使って施工管理をしていたようです。

 

新オフィスに関する記事はこちら↓

www.wantedly.com

www.wantedly.com

2020/07 編

[振り返りコメント]

リーダーって思っていた以上に大変なんだなって毎日のように思っていた時期でした。

また、コミュニケーション力がより一層求められるポジションだなとも思いました。

 

[振り返りコメント]

この時期はひたすらシステムトラブルの対応をしていました。

不具合の調査、改修はこなせばこなすほど目星の付け方や解決までのスピードも上がってくるのでとても鍛えられた気がしています。

調査するもなかなか原因特定できないときはツラい時間ですが、それを乗り越えた時の達成感は気持ちがいいものですよね。

 

[振り返りコメント]

リリース前はより一層いろんなチーム（メンバー）と連携しながら作業を進めていくのでチームワークって大事だなって思います。

 

[振り返りコメント]

この日はなにがあったのでしょう？笑

ほんと入念な確認って大事ですよね。

2020/08 編

[振り返りコメント]

リーダーという役割を経験して一番の学びは、視野を広く持って一歩先を見据えての思考or行動するってことでした。

目の前のことで必死な毎日で大変なことも多かったですが、この経験が今の業務で活かせている部分もあるので結果的にやってよかったなと思っています。

 

[振り返りコメント]

この日はリブランディングワークショップというのを全社でやりました。

部署問わずシャッフルでチームを作り、チーム内で会社の今後についてや建設業界のことを話すというのはとても新鮮でした。

レゴブロックを使って未来の建設現場を作ってみようのワークではメンバーの斜め上を行く発想が見られたりして楽しかったです。

 

リブランディングに関する記事はこちら↓

www.wantedly.com

 

[振り返りコメント]

あれもこれもといろんな課題がある中で、課題の本質を捉えるというのはとても難しいなと思います。

抽象的な課題に取り組むのってめちゃくちゃ難易度高いなって学びました。

2020/09 編

[振り返りコメント]

不具合対応に振りまわされている時期ですね。

今も重要課題となっているのは変わりないですが笑

 

[振り返りコメント]

プロってこういう人のことを言うんだなと思える方が会社には多くいらっしゃいます。

そういう方のslackのやりとりを見たり、どういう風に考えているのかなどを観察しつつ、いいなと思ったところは取り入れて真似していることも多々ありました。

2020/10 編

[振り返りコメント]

逃げなくてよかったです笑

 

[振り返りコメント]

ホント詳細設計って難しいなと思います。

大体、あとになって変更加えることが多い。。

 

[振り返りコメント]

新規機能のフロント開発を担当することになった時期です。

今までの開発は既存機能の改修がメインだったので今回始めて新規開発をやれたのはとても嬉しかった思い出です。

実務でVue.jsをガッツリ使って開発したのもこの案件が初めてでした。

まぁ、毎日苦戦して大変でしたね笑

まとめ

入社1年目は開発・不具合の対応・問い合わせや調査依頼など日々のタスクをこなすのに必死だった1年間でした。

スキル不足で先輩エンジニアに助けてもらうことも多々ありたくさん負担をかけてしまった1年だったなとも思います。

また、リーダーとしての役割を担当していた時期は、普段の開発タスクとは違ってより視野を広げて考えることや行動すること、マネジメントの大変さや難しさなどを知ることができました。今後のキャリアを考える上でもとてもいい経験ができたのではないのかなと思っています。

 

会社としても2019~2020の1年間はメンバーが増え、新チームが次々とでき組織がどんどん大きくなっていく過渡期真っ只中でバタバタな1年だったなと。

前職の生ぬるい環境から打って変わり変化の激しい環境で働くのはなかなか大変なこともありましたが、なんだかんだ楽しくやれたのではないかなーと思っています笑

 

次回、「入社して2年間を業務日記から振り返ってみた〜2年目編〜」を書く予定なのでそちらも読んでいただけると嬉しいです！

 

株式会社フォトラクションでは一緒に働く仲間を募集しています