Photoruction工事中!

Photoructionの開発ブログです!

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 ※2
├── [Readme.md](<http://readme.md/>) お好きにどうぞ
├── debug-env.json ※3 
├── events
│   └── request-sample.json ※3
├── libs ※4
│   ├── Makefile
│   └── nodejs
│       ├── package-lock.json
│       └── package.json
├── samconfig.toml ※5
├── src ※4
│   └── lambdanodejsMaster
│       ├── lambdanodejsMaster.js
│       └── package.json
└── template.yml ※1

template.yml ※1


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 ※2


.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ファイル ※3


debug-env.json

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

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

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

request-sample.json

lambda関数に渡すリクエス

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

{
  "key": "sample value"
}

src ※4


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

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

lambdanodejsMaster.js 最低限必要なもの

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

samconfig.toml ※5


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年経ったということで、これまでに1日の振り返りも兼ねてツイートしていた#業務日記 を振り返っていこうと思います。

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

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

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年目編〜」を書く予定なのでそちらも読んでいただけると嬉しいです!

 

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

建設テックのCEOがコード書いてた頃を思い出して、建設テックならでは(?)のマニアックな便利機能の実装を振り返る

こんにちは!株式会社フォトラクションでCEOをしている中島です。

 

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

 

 

普段は色んなところで建設テックについての記事を書いたりしているものの、今回は「開発」がテーマ。

 

ということで、社内で「自分もAdvent Calendar書いてみたい!」と立候補したは良いものの、何を書いたら....と困りながらタイプしています(汗

 

仕事柄コードは全然書かないものの、プログラミング自体はすごく好きで昔からプライベートでアプリを作ったりとか、もう4年も前ですがPhotoructionのリリース前ぐらいまではコード書いてたりしました。

 

せっかくなので、そんな過去も活かしてPhotoructionにあるマニアックで普通のアプリではあんまりやらなさそうな便利機能の実装について書いてみたいと思います。

 

最初から言い訳ですが、もう4年も前の話ですので既にPhotoructionでは使われてなかったり、間違った内容になってしまっているところもあるかと思いますので予めご了承ください!

 

さらに、ただの振り返り記事であり、具体的な実装に関しては忘れてしまったので本記事にコードは一切出てこないです!

 

そんな適当な技術記事(?)ですが、頑張って面白く書くのでぜひ最後まで見てください!

 

 

自由入力とリストを組み合わせたcombo boxフォームの実装

最初にどうしてもPhotoructionにつけたかったけど実装が大変だった思い出の機能がcombo boxです。

 

combo box自体はあんまりWebアプリで見ないですが、WIndwosアプリではよく(?)使われていて、自由入力のフォームとリストを組み合わせたものです。

 

f:id:photoruction_tech_blog:20211129124156p:plain

これです

Photoructionは建設業向けのアプリですが、工事現場では入力する内容が決まっているけど、イレギュラーも多く、その場で自由入力したいこともある項目が多いため、便利に使ってもらうことを考えるとどうしても実装したい機能でした。

 

そこで調べるとjQueryにcombo boxがあることを見つけ、めでたしめでたし....と思ったのですが「入力した文字で検索する機能」と「入力してリストになかったらリストに入れる履歴保存機能」をどうしてもつけたくてそれをやると超大変に。

 

当時このページを参考に検索機能はautocompleteでjQueryの標準でなんとなくいけたのですが、問題は履歴保存機能。

https://jqueryui.com/autocomplete/#combobox

 

保存して出すということは、非同期通信でデータベースから持ってきてフロント部分を変えるのですが、元のソースがjQueryの中にあるので素人に毛が生えたぐらいのエンジニアレベルしかない私からすると大仕事。

 

非同期通信でフロントを更新したはずなのに、内容が書き変わらなかったり、無駄なinitialize関数を連発したりととにかく悪夢かと思うぐらい大変だったのですが、実装した後は出来ないことは何にもないと改めてプログラミングの可能性を感じた実装でありました。

 

dwgやdxfなどCADファイルの変換サーバーの実装

Photoructionには建設業の図面(設計図)を扱う機能があります。

 

ただ、建設業では図面をCADで書くためpdfだけではなくdwgやdxfといった少し特殊なファイルも扱えるようにする必要があったりします。

 

とはいえそんな特殊ファイルを扱えるようなライブラリは当時なかったですし、ゼロから実装はとてもじゃないけど大変でした。

 

そこで選んだのは全て汎用的なフォーマットであるPDFに変換する方針。

大枠はこうです。

 

  1. dwgやdxfファイルをアップロードされたらS3に格納
  2. SQSに変換タスクをキューに入れる。同時にデータベースには変換中のステータスを入れる。
  3. SQSから変換サーバー(EC2)に変換メッセージを送信
  4. 変換サーバーはS3からdwgを取り出しpdfに変換してS3に格納
  5. データベースが変換完了を受け取りUIへフィードバック

f:id:photoruction_tech_blog:20211129124302p:plain

雑ですが絵に描くとこんな感じ

dwgやdxfを変換するライブラリだったり製品は海外製であるものの、世の中にいくつか存在しているためそいつをサーバーで動かして変換してしまおうという感じです。(Photoructionで何を使っているのかは秘密ですが....。)

 

AWSの機能を活用して開発した初めての機能ということもあり、動いた時は「こんなことまでできちゃうんだAWS!」と感動したのをよく覚えています。

 

巨大な画像を高速表示させるタイリング機能の実装

PDFに変換できたから「これでdwgもdxfも怖くない!」という感じではあるのですが、実はPDFをそのまま表示するだけだと不便な点が。

 

dwgなどのCADファイルは実は多数のレイヤーが作られていて、作り方次第ではPDFファイルそのものが非常に重たいケースがあります。

 

私が知っている中で一番重たいやつだと1枚のPDFで500MBみたいなやつもありました....。

 

そのため、これをフロントで表示しようとすると色んな問題点が出てきます。

 

そこでどんなに重たい図面でも高速で表示できるよう、Photoructionではタイリングの技術を用いています。

 

どうゆうことかというと、1枚のPDFからdpiの異なる画像を複数生成してそれらをタイル状に切って、ユーザーが表示させているところの画像だけをロードします。こうすることでPDFではなく画像かつ全てロードしなくても良くなるため、非常に高速で図面を表示することが可能です。

f:id:photoruction_tech_blog:20211129124402p:plain

当時の社内企画資料からの抜粋

Google Mapをはじめとする地図で使われている技術で、フロントはleaflet.jsというライブラリを活用して実装した記憶があります。

https://leafletjs.com/

 

とは言えバックエンドでdpiの異なる画像生成、画像を切ってのタイル生成、さらにはそれらを部分的に読み込む機能など、さまざまな要素が絡むため実装するのに非常に苦労した機能です。

 

動いてるところを見ると簡単そうなのですが、こうした技術の積み重ねが使い勝手の良い魔法のようなアプリケーションを実現しているんだなと実感した瞬間でありました。

 

まとめ

読み返してみると、これほどに役に立たない技術記事をAdvent Calendarの1発目で出して本当に大丈夫なのか...と不安でいっぱいにあります。笑

 

一方でここでの実装経験があるからこそ、テクノロジーが持つ無限の可能性を心から信じることができています。

 

Photoructionにはまだまだマニアックな機能がたくさんあり、そしてこれからも開発を続けていく必要があります。

 

それだけテクノロジーの力を使って解決できる課題が数多く残されているということで、重厚長大な巨大産業をスマートな世界に変えていきたいと思っているエンジニアの方はぜひ一緒に開発しましょう!

※ 冒頭にも書きましたが筆者はもう長いことコーディングには携わっていません....。


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