Photoruction工事中!

Photoructionの開発ブログです!

VIMで開発する

 

開発者の中でも黒魔道士しか使わないツールがあります。

Linuxサーバーのcrontabを更新する必要がある時または、設定ファイルを修正する時など、必ずどんなマシンにでも入っているエディターを使わなければなりません。しかしよくあることはWimしか入ってないことがあります。

Vimはエディターの中で使いづらいことや、小さなスクリプトだけならなんとか修正可能などと言われていますが、実際やろうとすると、結構効率よく開発もできます。

まずは、基本のVimで何ができるのかを紹介してから、プラグインを入れてみるとどこまでモダーンなIDEにできるのかお見せしましょう。

免責:これはあくまで個人的に「ほぉ、これは便利だね」と思った機能とプラグインだけです。

 

基本操作と知識

モーダルエディタ

Vimはモーダルエディタです。モードを切り替えて、ファイルの編集やコードの操作を行います。

デフォルトは Normal モードです。キーを打つとコマンドが実行されます。

一番よく知られているのは i キーを押すと Insert モードに切り替えます。

このモードで打つ字が入力されます。つまり、通常のエディタと変わりません。

Insert モードから Normal モードに戻るために Esc を打ちます。

: キーを打つとコマンドを打つことができます。

基本操作は vimtutor で勉強でき、これは日本語に翻訳されています。シェルで vimtutor ja を実行してみてください。

 

検索

検索はアクティブウィンドウの中で行います。

/ を打つと検索できます。つまり、 function getHolidays() 文字列を探すために /getHoli でマッチできます。打てば打つほど完全一致できます。

そして、コードを読む際に、カーソルオーバーして、 * を打つと文字列の検索となります。 ? を打つと、さかのぼり検索になります。検索の結果は n で次のマッチに飛び、 p で前のマッチに戻ります。

検索が終わったら、 :noh で検索ハイライトを解除できます。

 

バッファ、ウィンドウ、タブ

Vimのレイアウトアイテムの名前は普段のアプリケーションとちょっと違います。

バッファは基本的にファイルです。

ウィンドウはバッファを閲覧するGUIスペース。複数ウィンドウが同じバッファを違う箇所で開くことができます。

タブは簡単に言うと、ウィンドウのセットまたワークスペースと考えられます。

バッファを閉じると、このバッファを使うウィンドウが全て閉じます。

 

Vanilla VIMプラグイン無し)で開発

このセクションで、一般のVimと.vimrcで開発用のTipsを紹介します。

プラグインがなくても、ある程度効率よくコーディングができます。個人的パソコンまたはよく使うサーバーであれば、ちょっとぐらい設定ファイルを更新して、Vimの機能を開放できます。

設定ファイルは通常 $HOME/.vimrc です。

早速ですが、下記の設定を追加します。

 

""""" あった方がいい設定 """""
" これでいろいろな言語のハイライト機能をオンにする
syntax on
" ファイルタイプに応じてオート設定
filetype on
filetype indent on
" vimの反応速度を上げる(screen redraw)
set ttyfast
" いつもステータスを表示する
set laststatus=2
" backups フォルダを作成する
silent !mkdir -p ~/.vim/backups
" swap ファイルフォルダ
set directory=~/.vim/backups//
" バックアップフォルダ
set backupdir=~/.vim/backups//
" 編集されたファイルを保存しなくても、他のファイルを開ける
set hidden

" タブをスペースに
set expandtab
" タブのサイズと自動インデント幅を4文字に
set tabstop=4
set shiftwidth=4
set softtabstop=4

""""" エディター """""
" 長い行をwrapしない
set nowrap
" 行数を表示する
set number
" オートインデントを有効に
set smartindent
set autoindent

" 打っている最中検索を行う
set incsearch
" 小文字のみで検索すれば、ケースに関わらず検索する。大文字を使えば、ケースマッチを有効に
set smartcase
" 検索マッチをハイライトする
set hlsearch

" 貼り付けモード切り替えキー(勝手にインデントをしないモード)
set pastetoggle=<F2>
" diffを縦で開く
set diffopt+=vertical

" 保存する際に末尾のスペースを消す
augroup Cleanup
	autocmd!
	autocmd BufWritePre * :%s/\\s\\+$//e
augroup END

""""" レイアウト """""
" 縦スプリットを下に開く
set splitbelow
" 横スプリットを右に開く
set splitright

""""" netrw (ファイルブラウザ)"""""
" バナーメッセージを非表示
let g:netrw_banner=0
" スプリットファイルブラウザを開くとウィンドーのサイズ設定(%)
let g:netrw_winsize=50
" プレビユーを縦スプリットで開く
let g:netrw_preview=1
" ツリー表示
let g:netrw_liststyle=3

Netrw:ファイルブラウザ

Vimはすでにファイルブラウザがついています。

全画面で開く: :Ex

スプリットして、下に開く: :Hex

スプリットして、左に開く: :Vex

タブで開く: :Tex

操作はかなり単純で、通常の移動+エンターキーでフォルダを展開またはファイルを開きます。

f:id:photoruction_tech_blog:20211220094501j:plain

p を打つとプレビューウィンドウを開きます。

Ctrl+w z でプレビューを閉じます。

R でファイルまたはフォルダの名前編集ができます。

v を打つとファイルをスピリットで開きます。

 

画面スプリット

新しいウィンドウを右に開く: Ctrl+w v

新しいウィンドウを下に開く: Ctrl+w s

カーソルを別のウィンドウに移動: Ctrl+w [移動キー]例えば、右のウィンドウに移動する: Ctrl+w l

アクティブウィンドウを拡大する(他のウィンドウを閉じる): Ctrl+w o

アクテイブウィンドウを閉じる: Ctrl+w q

もちろんスプリットの中にさらにスプリットもできます。どんどん読みづらくなりますけどね。

f:id:photoruction_tech_blog:20211220094737j:plain

 

タブ機能

新しいタブを作成する: :tabnew

次のタブに移動する: g t

前のタブに移動する: g T

他のタブを閉じる: :tabonly

タブを閉じる: :tabclose

タブの使い方は色々有るのですが、個人的にタブ毎にアプリケーションコードとのファイルに対するテストファイルを開くことが多いです。

タブ1:
- BookingController
- BookingControllerTest
タブ2:
- BookingLogic
- BookingLogicTest

オートコンプリート

はい、一応単純なオートコンプリートが付いています。

非常にスマートというわけではないが、一応開いているバッファのなかを分析して、合いそうな文字列で推奨するような機能です。

ようするに、複雑な変数名があれば、問題なくこれで入力できます。

Insert モードで Ctrl+n を打つとオートコンプリートが表示されます。選択1つしかなければ、表示せず自動入力されます。 Ctrl+n で次の選択(下)に移動して、 Ctrl+p で前の選択(上)に戻ります。

f:id:photoruction_tech_blog:20211220094828j:plain

f:id:photoruction_tech_blog:20211220094841j:plain

 

タグでナビゲーション

tags ファイルが存在したら、vimがそのタグファイルを読み込んで、それぞれの箇所に飛ぶことが可能です。カーソルを文字列にオーバーして、 Ctrl+]でタグの定義箇所に飛べます。 Ctrl+t で元のファイルに戻れます。たまに同じタグに複数定義箇所が存在します。その時、 g] を打って、どのファイルを開くのを選択できます。 :tags <タグ名> でも使えます。

f:id:photoruction_tech_blog:20211220095106j:plain

タグファイルを生成するために ctags と言うツールをインストールする必要があります。コードが変わるとまた生成する必要があるので、ちょっと使いにくいです。ただし、プラグインを使うと自動化できます。そして、あまり変わらないコードだったら、一応手動でもタグファイルを生成する価値があります。

そして、タグナビゲーション機能をVimのヘルプで使えます。 :help でアクセスでき、リンクを Ctrl+] または g] で開けます。

 

ターミナル

Vim 8 以降だと、ターミナルが付いています!

:terminal で起動できます。ターミナルはデフォルトで Insert モードです。

Normal モードに切り替えIMはエディターの中で使いづらいやるために Ctrl+w N を打つ必要があります。

また Insert モードに戻るには、通常通り i を打てば良いです。

Normal モードでは通常の動き、コピーなど、すべての機能を使えるので、便利です。

ターミナルを専用タブで開いても便利です。

もちろん、 vim 自体を Ctrl+z でバックグランドに落としてもいいです。

そしてシェルから fg を実行するだけで復活できます。

 

セッション

例えばVSCodeを開く時、最後閉じた状態のままでまた開きます。

vimでも似たような機能が存在します。

:mksession! を実行すると同じフォルダに Session.vimファイルが作成されます。

このファイルをロードするとファイル作成時の状態に戻ります。 :source Session.vim で実行できます。

またはシェルでエディタを実行する際に、 -S パラメタを追加すると自動的に Session.vim をロードします。

このコマンドの弱点は手動で実行する必要があることです。 .vimrc でキーマッピングを追加したら、自動コマンドを追加するのが便利です。

個人的に、専用プラグインに任します。

 

プラグインを入れましょう!

プラグインを使うと、機能は爆発的に広がります。

プラグイン管理

vim 8 が既にプラグイン管理ができるのですが、個人的には VimPlug を気に入り使用しています。

プラットフォームによってやり方がちょっと異なりますが、基本的に、プラグインのコードを autoload フォルダに入れればOKです。

そして、 .vimrc の中で

call plug#begin()
call plug#end()

のブロックを作って、欲しいプラグインをここに入れれば簡単に管理できます。

流れは:

  1. Plug 'xxxx/xxxx' の行を .vimrcbegin...end の中入れて
  2. vim を起動して(またはリロードする)
  3. :PlugInstall を実行する

たまに :PlugUpdate を実行するだけで更新できます。

 

基本設定とUI

デフォルト設定の見直し

まずはVimのデフォルト設定を軽く変えた方がいいです。

これは tpope/vim-sensible に任せます。

ステータスバーのレベルアップ!

VimのデフォルトUIは静かで邪魔にならないのですが、たまにちょっとスパルタ過ぎます。

ステータスバーを vim-airline/vim-airline で拡張します。

そして、より格好よくするために vim-airline/vim-airline-themes も入れます。

vim-airlineでいろいろな情報が目の前に現れます。モード名、ブランチ名+ファイル変更まとめ(インサート、変更、削除の行数)、ファイルタイプとエンコード、ファイルタイプ等。

スクショや機能の詳細と設定はGithubで確認するのはおすすめです。

カラースキーム

あくまで好みの問題ですが、自分は sainnhe/sonokai のダークカラースキームが好きです。

VimPlugでの管理も簡単です!

そして、微調整のため(カラースキームのオプションなど)のため、設定ファイルに下記を追加します。

" ダークモードは正義!
set background=dark

" フルカラーターミナルだとOKです
set termguicolors
" カラースキームオプション
let g:sonokai_style = 'shusia'
let g:sonokai_enable_italic = 1 
let g:sonokai_transparent_background = 0 
let g:sonokai_diagnostic_text_highlight = 0 
let g:sonokai_diagnostic_line_highlight = 0 

" カラースキーム選択
colorscheme sonokai
" 更にオプション(他のプラグインと連携)
let g:airline_theme = 'sonokai'
let g:airline#extensions#coc#enabled = 1 

 

共通コードツール

このカテゴリは通常のIDE機能をVimで再現できるプラグインについてです。

Ctrl+P

それぞれのIDECtrl+pでファイルを開いたりができます。もちろん、Vimでもできます!

そのために ctrlpvim/ctrlp.vim を入れましょう。

そして、興味のないファイルを省く設定を追加します

" CtrlP
set wildignore+=*/tmp/*,*.so,*.swp,*.zip     " MacOSX/Linux
set wildignore+=*\\\\tmp\\\\*,*.swp,*.zip,*.exe  " Windows

let g:ctrlp_custom_ignore = {
  \\ 'dir':  '\\v[\\/](\\.(git|hg|svn)|node_modules|vendor)$',
  \\ 'file': '\\v\\.(exe|so|dll)$',
  \\ 'link': 'some_bad_symbolic_links',
  \\ }

 

ワードハイライト

カーソルがオーバーしているワードをハイライトするプラグインも個人的に好きです。

それは RRethy/vim-illuminate で解決します。デフォルトはアンダーラインでマッチを表示するのですが、ブロックハイライトが好みです。

" ハイライト
hi link illuminatedWord Visual

 

セッション管理自動化

さすがに毎回 :mksession!を実行するのは手間がかかります。もちろんそのためのプラグインがあります!早速入れましょう: tpope/vim-obsession

Tim Popeのプラグインが必要なパラメタのみを保存しています。

そして、セッションのトラッキングを開始したい時: :Obsess を実行するだけです。 -S フラグを使ってセッションをロードしたら、 :Obsess を実行する必要はありません。

注意:バッファを開く・閉じる際に Session.vim ファイルが更新されます。したがって、ステートを保存するために全てのバッファを一括で閉じる必要があります。すなわち、 :q ではなく :qa で終了しましょう。

タグファイル生成

ctagsを自動的に実行してくれるプラグインの登場です!

では ludovicchabant/vim-gutentags も入れましょう。プロジェクトが大きかったら、タグ生成は時間がかかる場合あります。

ローカルvimrc

プロジェクト毎設定を変えて欲しい時がある場合、 embear/vim-localvimrc で設定の微調整ができます。

このプラグインを入れると 各プロジェクトに .lvimrc ファイルを作って、設定を入れて、この環境だけで適用します。

デフォルトは毎回「 .lvimrc の設定をロードしていい?」と聞かれてしまうので、下記の設定で、ファイルが変わらない限り、承認を覚えてくれます。

" lvimrc
let g:localvimrc_persistent = 1

 

特にデバッガの設定や、ソースコードフォルダマッピングのためにこのプラグインは非常に便利です。

ソース管理対応(Git)

もちろんターミナルでいちいち実行して、何が変わったのを確認できますが、流石に大変ですね。

エディタで一目で分かるようにしたほうが良いに間違いありません。

Vim-GitGutter

airblade/vim-gitgutter は左側の行目のさらに左にファイル変更の印を入れてくれます。

f:id:photoruction_tech_blog:20211220095336p:plain



上記のサイドバーでは - は削除、 ~ は編集、 + は追加と明確に変更の内容と箇所を示します。変更の内容は \ h p で確認できます。

もちろん印、色など、全てカスタムできます。他の機能もたくさん有ります。

詳細はvim-gitgutterのGithubで確認するおすすめします。

" vim-gitgutter
if exists('&signcolumn')  " Vim 7.4.2201
  set signcolumn=yes
else
  let g:gitgutter_sign_column_always = 1 
endif
set updatetime=200
let g:gitgutter_override_sign_column_highlight = 1

 

Vim-Fugitive:いろいろなツール

tpope/vim-fugitive からインストールできます。

このプラグインはいろいろなGit機能をWrapしています。全部説明する余裕はないですが、例えばgit blameをvim内で確認できたり、ファイルの古いバージョンと比較したりできます。

詳細はGithubページで確認ください。

ViMagit

Magit( jreybert/vimagit )パネルを開くとワークスペースの様子を確認や、変更をステージングスペースに追加するもしくは捨てるやコミットもできます。

VSCodeのGitタブみたいな感じです。ファイル単位だけではなく、ハンク(変更ブロック)単位と行単位も対応します。

https://user-images.githubusercontent.com/533068/28827790-ee0ec640-76ce-11e7-840b-10a4f5e4eae4.gif

下記の追加設定で \ g sマッピングします。

" vimagitパネルを開く
nnoremap <leader>gs :Magit<CR>       " git status

 

スマートコードコンプレッション

VimVSCodeみたいにスマートにできますか?もちろんですとも!

このゴールを達成するためにLS(Language Server:言語サーバー)を使います。

LSとは何でしょうか?まぁ、簡単に説明すると、裏で動いている特定言語サーバープロセスとやり取りして、コードの様子を確認し、オートコンプリート選択肢を計算などします。

このLSとやり取りをするために、LSP(LSのプロトコル)を扱うプラグインが必要です。

インストール

このプラグインの名は neoclide/coc.nvim です。

プラグインをインストールするだけでは足りません。使いやすくするために、設定も更新しないといけません。

おすすめの設定はこちら:https://github.com/neoclide/coc.nvim#example-vim-configuration

全部必要と言うわけではないですが、デフォルトとして安定で使いやすいです。

運用になれてから設定変更するのがおすすめです。

言語サーバー登録

CoCプラグインを入れるだけで、なにもできません。言語サーバーが必要です!

そのためにそれぞれのCoC拡張をインストールする必要があります。

基本的に、https://github.com/neoclide/coc.nvim/wiki/Language-servers に参考しながら、インストールすべきです。

その他、おすすめのやり方は vimrc で登録するのではなく :CocInstall で管理することです。

例えば、Javascript/TypeScriptサーバーをインストールするには

:CocInstall coc-tsserver でできます。

念の為、一旦vimを閉じて、開いたら、シンタックスチェックやオートコンプリートが使えるはずです。

f:id:photoruction_tech_blog:20211220095429p:plain

f:id:photoruction_tech_blog:20211220095444p:plain

 

まとめ

ここまで読んでいただけたら、「よく頑張ったね!」と感謝致します。

Vimは間違いなくちょっと変わったツールで、だいぶ古いイメージがあるのですが、モダーンな開発ツールとしても使えます。

もちろんVSCodeや他のIDEVimっぽい動きはできますが、中途半端なできで使い物になりません。これで満足できませんでした。

Vimでないエディタを毎日使って涙を流している皆様のために、この(かなり雑な)ガイドを作りました。自分に合う開発環境を作る踏み台になれば幸いです。

 

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

corporate.photoruction.com

www.wantedly.com

パッケージの管理ルールを制定してみた

こんにちは!今年の5月から株式会社PhotoructionでAIエンジニアとしてインターンをしている渡邉圭太郎です。 Photoruction Advent Calendar 2021の24日目の記事です。

はじめに

僕の所属するチームではパッケージ管理をgithubで行っていましたが、特に管理ルールはなくリポジトリの扱い方はメンバーによって異なっていました。加えて、CI/CDを積極的に行っていこうという意見がチーム内で上がっていました。特にチームの核であるAIモデルの精度向上などAI開発の方に時間を割きたいというメンバーが多かったからです。

そこで、この度チーム内でのパッケージ管理ルールを制定したのでその内容を一部紹介します。

ブランチ戦略

ブランチ戦略とは

ブランチ戦略とは、Git上でブランチを分けて作業を並行して行う際にそのブランチを計画的に作成し運用していくことである。定めておくことでチーム開発での開発の柔軟性とコードの一貫性という2点が確保できる。

Github Flow

ブランチ戦略自体はたくさん考案されているが、今回はGithub flowというブランチモデル(master, develop, 各topicごと...)を採用した。その内容を簡単に下図に示す。

f:id:photoruction_tech_blog:20211217104819p:plain
git flow

masterブランチを本番環境ブランチ、developブランチを開発環境とし、エンジニアが個々に開発を行う場合はbranch1, branch2, ...のように分けていく。

この運用方法では以下の基本ルールがある。

  1. masterは常にデプロイ状態にする
  2. masterから必ずtopicブランチを切りmasterに直接コミットすることがないようにする
  3. ブランチは定期的にpushする
  4. pull requestを用いてコードレビューを行う
  5. コードレビューが完了したらすぐにmergeする

様々な記事を読むとこの他にもカスタムルールを制定している場合もあるようなので、ぜひ自チーム流にブランチ戦略を制定してみてほしい。

リポジトリ事前設定

前項で挙げたルールのうち1, 2そしてCIに関してはGithubリポジトリの設定項目から事前に制約をかけることができる。

今回は1例として、masterブランチへCIを成功したブランチのみmergeを許す方法を記載する。

  1. "settings" → "Branches"と選択

    f:id:photoruction_tech_blog:20211217105033p:plain
    github_setting01

  2. "Branch protection rules"から"Add rule"を選択し、下図のように設定をする。

    具体的には、リポジトリ管理者を含めmainブランチにおいてCIを成功させないとmergeできないように設定している。また、この設定によりmainブランチへの直pushも防いでいる。

    f:id:photoruction_tech_blog:20211217105127p:plain
    github_setting02

  3. "Save Changes"(作成時は"Create")を選択して終了

また、他の設定項目については詳しくはこちらを参照。

開発環境のコンテナ化

コンテナ化と実装理由

コンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することです。(コンテナ化とは

また、開発環境のコンテナ化を行うと以下のことができる様になる。

  1. チェックや改修の際の環境構築を楽になる
  2. osのバージョン等に左右されずに開発を行える

以上の理由から開発環境のコンテナ化を行うこととなった。

dockerでのコンテナ化実装

今回コンテナ化にはDockerを用いて行う事になった。そこで実際の実装例を紹介する。

なお、Dockerについての事前知識については以下を参照。

  • Dockerコンテナーの概要

  • pc内にDocker Desktopをインストールする

  • Dockerfileとdocker-compose.ymlを用意する

    フォルダ構成

     ├── docker-compose.yml
     ├── Dockerfile
     ├── README.md
     └── src
    

    Dockerfile

     FROM python:3.8
    
     ENV APP_PATH=/code \
         PYTHONPATH=.
     # 開発物のソースコードはcodeデイレクトリ下に配置する
    
     WORKDIR $APP_PATH
    
     RUN apt-get update && \
         apt-get upgrade -y && \
         pip install poetry
     # コンテナのセットアップ
    
     COPY . .
    
     RUN poetry install 
     # 必要なパッケージ等をインストールする
    
     EXPOSE 8080
    

    docker-compose.yml

     version: '3.8'
     # 使用するDockerEngineリソースに適応するバージョンを指定する。
    
     services:
       test_src:
         container_name: test_container
    
         build:
           context: .
           dockerfile: ./Dockerfile
         ports:
           - "8080:8080"
             tty: true
         volumes:
           - ./src/:/code/src
           - ${PIP_CACHE_DIR_WORKER:-cache-test}:/root/.cache
    
     volumes:
       cache-test:
    

    なお、さらに詳しい引数等の内容に関しては、以下のドキュメントを参照。

  • 必要なファイルの準備ができたらDockerfileとdocker-composeを使用してコンテナを構築する

     docker-compose up -d --build test_src
     # イメージのビルド
    
     docker exec test_container poetry install
     # 必要なパッケージのインストール
    
     docker-compose up -d
     # すべてのコンテナの起動
    

これだけで環境のコンテナ化が完了する。

あとは、各々開発をゴリゴリすすめる。

まとめ

本記事では、実装例を紹介することを目的としたため基礎知識について深く解説できなかったので、その部分についての詳細は参考文献を参照してください。また、こうした方がより使いやすい等ありましたらぜひ教えて下さい!

パッケージ管理ルールを制定したことでチーム開発内で無駄に考えることが減ったと感じます。より開発自体に注力できる様になったのは良いことであると感じました。

また個人的には、チーム開発に関することは個人で行うには限界があったので、インターンという立場でこのようなことが学べたのはとても勉強になりました。これからも開発を頑張っていきたいと思います!

参考文献

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

corporate.photoruction.com

corporate.photoruction.com

ローカルでAPI Gateway, Lambdaの構成を再現する

こんにちは!株式会社Photoruction AIグループでエンジニアをしています酒井です。 Photoruction Advent Calendar 2021の23日目の記事です。

導入

APIGateway, LambdaのサーバレスアーキテクチャでWebAPIを開発する際、APIのレスポンス確認のために都度、クラウド上にデプロイするのは手間がかかります。

そこでServerlessFrameworkというフレームワークとserverless-offlineというプラグインを使用してローカルでレスポンスを確認できる環境を整えました。

ServerlessFrameworkとは

serverless-offlineとは

  • ServerlessFrameworkで使えるプラグイン
  • ローカル環境でAPI Gateway + Lambdaの構成を再現することができる

実施内容

クライアントによる「APIGateway」へのPOSTリクエストをトリガーにして、「Lambda」で定義した関数を実行することを想定しローカルでの開発環境を整える。 f:id:photoruction_tech_blog:20211217160020p:plain

手順

1. ServerlessFramework、serverless-offlineのインストール

$ npm install serverless
$ npm install --save-dev serverless-offline

2. プロジェクトの作成

sls create -t <テンプレート名> -n <プロジェクト名>でプロジェクトを作成します

ServerlessFrameworkが提供するテンプレートはこちらを参考にしてください

今回は aws-python3を使用しました。

任意のディレクトリに移動したあと、以下を実行します。

$ sls create -t aws-python3 -n serverless-sample

すると、ディレクトリ内に handler.pyserverless.ymlが作成されます

$ ls
handler.py   serverless.yml

3. handler.pyを編集する

  • handler.pyにLambda関数を定義します。
  • デフォルトでは以下のようにシンプルな関数 helloが定義されています。
import json

def hello(event, context):
    body = {
        "message": "Go Serverless v1.0! Your function executed successfully!",
        "input": event
    }

    response = {
        "statusCode": 200,
        "body": json.dumps(body)
    }

    return response

4. serverless.ymlを編集する

以下の設定を行います。

  1. functionsのhelloにeventsの追加
  2. 使用するプラグイン(serverless-offline)の記述
service: serverless-sample # プロジェクト名
frameworkVersion: '2'
provider:
  name: aws
  runtime: python3.8
  lambdaHashingVersion: 20201221
functions:
  hello:
    handler: handler.hello # handler.pyの関数helloを実行する

    # 追加
    events:
      - http:
          path: /test # <- 任意
          method: post # <- POSTリクエストをしたので post を指定

# 追加
plugins:
  - serverless-offline

5. 起動

以下コマンドでプロジェクトを起動すると、エンドポイントが表示されます。

$ sls offline start
 
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                                                                         │
   │   POST | http://localhost:3000/dev/test                                 │
   │   POST | http://localhost:3000/2015-03-31/functions/hello/invocations   │
   │                                                                         │
   └ ────────────────────────────────────────────────────────────────────────┘

レスポンスを確認する

  • エンドポイントに対して {"name": "yamada"}というデータとともにPOSTリクエストを送ってみます。
  • すると handler.pyに定義したbodyの内容が正しく表示されます。
  • データも正しく送信できていることが分かります。
$ curl -X POST -d '{"name": "sample"}' http://localhost:3000/dev/test
{"message": "Go Serverless v1.0! Your ...", "input": {"body": "{name: yamada}", ...}

まとめ

ServerlessFrameworkのserverless-offlineというプラグインを使うことでローカル環境でAPIのレスポンスを確認することができました。

開発していく中で挙動を確認するために都度、クラウド上にデプロイする必要がないので時間短縮につながりました。

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

corporate.photoruction.com

www.wantedly.com

木工(家具)職人とAIエンジニアの共通するところ

目次

  1. はじめに
  2. 物作り
    1. 早いということ
    2. 綺麗だということ
    3. 正確だということ
  3. 木工職人と工場長、エンジニアとPMの関係性
  4. 共通しないこと
  5. 最後に

1.はじめに

2021年も早いもので残すところ2週間くらいとなり、「今年も一年早かったね」なんて言葉を言ってみたり聞いたりすることが多くなってきました。今冬は寒くなるんでしょうか、雪は降るのかな、来年の干支ってなんだっけなどと考えたりしてます。

さて、私はというともうすぐAIエンジニアとなってまる2年が経とうとしています。

社会人になってから飽きることなく繰り返してきたこの「今年も一年早かったね」とともにこの2年間を振り返りつつ、16年ほど携わった前職の木工(家具)職人と現在のAIエンジニアの共通することってなんだろうを考えてみたいと思います。


2.物作り

「段取り八分」

職人をしているとよくこの言葉を聞きます。

段取り(準備)さえしっかり出来ていれば仕事の8割は出来たようなもの、みたいな意味です。

8割は言い過ぎだろという思いが頭を掠めまくっていましたが、経験を重ねれば重ねるほどこの言葉の意味を意識することは多かったように思います。

木工職人にとって**「早くて綺麗で正確に」**という絶対的に正しい結果を追求する上で「段取り八分」(いかに効率的なプロセスを辿るか)はもっとも重要な考えの一つだと思ってました。

AIエンジニアと木工職人の間には、アナログとデジタルの違いはあるものの「モノを作る」という大きな共通点があります。

木工職人にとって大切だと思っていたことを半ば無理やりAIエンジニアにとって大切だと思うことに結びつけてみたいと思います。

木工は作り手が図面をもらった時点で何を作るかは明確に決まってます。(まれに途中で変更があったり、一部決まっていない中進めることもありますが、、、)

製作スタートと同時に数時間は図面と睨めっこしながら、部分的な詳細図を描き(組み立て説明書を自分で考え思考を整理し書き起こすみたいな作業)、完成形や製作工程を頭に叩き込み、最短距離でゴール(完成)するにはどうすべきかを考えます。

1つの家具・什器(店舗やオフィスの家具)でも作り方は何通りかあり、製作物の大きさや難易度によって、どの手法をとるかで手間と時間が大きく変わります。この辺りは経験と知識が大きくモノをいいます。(ゴールを「目的」に置き換えるとその時考えてたことはphotoructionのvalueである「目的逆算」に近い気がします)

早いということ

そこで家具や什器をコードに、鉋(カンナ)・ノコギリ・電動工具等をPCに置き換えてみると、この「早くて綺麗で正確に」という価値観は職人からエンジニア業務への延長線上にしっかり乗っかってきます。

IT業界でも「脱・完璧主義」や「7割の完成度」を意識するみたいなことはよくいわれると思います。エンジニアとしても早ければその分多く開発できるし、開発コストも抑えることができるし、組織にとってもメリットは多いはず、やはりエンジニアとしても早いは正義だと(個人的に)思います。

綺麗だということ

AIエンジニアが使用するプログラミング言語PythonにもPEP8というコーディングスタイルガイドがあります。

その目的は読みやすくて、可読性が高く、一貫性のあるコードを書くためにこういうことは守ろうね、みたいなことが書いてあります。Python開発者たちがコードを読みやすく綺麗に書くことを非常に重要だと考えていることをスタイルガイドを通して感じることができます。

開発において、一度リリースしたからといってコードは未来永劫そのままか??というとそんなことはなく、開発したものが使い続けられる限り改修は行われます。その際、開発者本人が改修するとは限らない上に場合によっては、開発者が退職しているケースもあるかもしれません。改修担当者にとってどのコードが何の目的で書かれているかわかりやすければわかりやすいほど、作業も進みます。コードが他者から見てわかりやすいと改修やデバッグする上で作業性を大きく左右する、保守性において重要ではないかと考えます。

正確だということ

AI開発の最終段階では、それまでの開発内で使われていた学習データ(教師データ)とは別に使われていないテストデータをもとに評価検証を行います(開発したAIモデルの精度や処理時間など算出するため)。

リリースした後に扱うデータがテストデータと同じようなものかというと、そんなことは全くなく、開発中には遭遇していない未知のデータに対してもロバスト(頑健)であることが求められます。

ロバストな開発ができるどうかは開発物の品質を大きく左右します。


3.職人と工場長(現場監督)、エンジニアとPM

関係性が似ていると感じることは多いです。

(*木工職人の場合、やりとりの多くは工場長や制作担当リーダーみたいな人とが多いんですが、他の職方だと監督とやりとりする場面が多いと思うので置き換えた方がわかりやすいかもしれません)

制作においては工場長はあくまでもハブです。というと語弊があるかもしれませんが、工場長は内装業者から案件を受注し家具図・什器図をもらい図面だけでは読み取れないこと、スケジュール、お金に関することなどを内容業者と調整します。そして、各制作物ごとに工場長が担当の職人と打ち合わせを通し、制作物の詳細やスケジュールを共有します。職人は制作中に図面に書かれておらず、自身では判断できないことがよくあります。その際は工場長を通し内装業者に問い合わせを行います。。

とざっくりですが、ここまで書いているとエンジニアとPMの関係も同じとはいわないまでも近いと感じる人もいるのではないかと思います。

私はAIエンジニアしか経験がないので、他のエンジニアがどうかはわかりませんが、少なくとも木工職人と工場長、AIエンジニアとPMの関係性は共通点が多く、エンジニアとして仕事を始めた早い段階からエンジニアとPMの間に境界線を引いていたと思います。こっからここは、エンジニアが考える、そっから先はPMの領域、、、みたいな感じに。

ただ、この境界線の置き所が難しく、微調整を繰り返しながら最適なやり方を模索している途中です。

4.共通しないこと

思いつくことはまだあり時間をかけるとまだまだ書けそうですが、そろそろ今行っている開発に戻った方が良さそうなので、最後に共通していないことを書きたいと思います。

一番大きい違いは、グループやチームの存在を近くに感じるかどうかではないでしょうか。

木工職人としてはあまり意識することはなかったように思います。(途中、工場長みたいなこともやっていた時期があり、その際は作ることはどうしても二の次になりチームや組織としてどうするかみたいなことは考えていたような気がします)

Photoructionではいくつかの部署があり縦横無尽に連携していると思います。そういった組織の複雑性みたいなものは木工時代にはなかったので、新鮮であり勉強になることが多く、他者との関わり方みたいな部分で意識の修正が必要でした。

私に開発の話が届くまでに社内で幾つかのプロセスを経てきます。そのプロセスの具体的な内容まではわかっているわけではないですが、色々なプロセスの内容に触れる機会があると小説の一部を読んでいるようで面白いなと感じることもあります。

(あまり関係ないかもしれないが、組織人としてPhotoructionが掲げているvaluesに「敬意尊尚」とういうものがあり、それがどういったものかを共有する勉強会の参考図書となっていたTeam Geak(Googleギークたちはいかにしてチームを作るのか)は非常に参考になり、これから何度も読み返そうと思う)


最後に


思いつくままつらつらと書きましたが、技術的なことを書くにもう少し時間が必要だと思ったので、あまり考えずに済む題材をチョイスしましたが思っていた以上に時間がかかってしまった。

おが屑に塗れながらにしろ椅子に座ってキーボードをカチャカチャするにしろ、物を作るというのは面白いものですね。

これをエンジニアが読んでためになるとはあまり思えませんが、最後まで読んでいただきありがとうございますmm


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

 

AIエンジニアという職業に対する考え方 before and after

こんにちは!株式会社PhotoructionでAIエンジニアをしています志賀です。 Photoruction Advent Calendar 2021の21日目の記事です。


目次

  1. はじめに

  2. AIエンジニアになろうと思った経緯

  3. AIエンジニアという職業に対する考え方 before

  4. AIエンジニアという職業に対する考え方 after

    (1). 巨人の肩の上に乗る

    (2). エンジンだけでは車は動かない

    (3). 高度なものはいずれ民主化する

    (4). AI民主化による回帰は悪か

  5. 最後に


1. はじめに

時が過ぎるのは早いもので、AIエンジニアとしてキャリアをスタートしてから、早2年経とうとしています。

そんな中過去の記憶を辿ってみれば、色々な思いや考えが沸いてきては消え、沸いてきては消えを繰り返している事に気がつきます。まるで、般若心経の作者に「色は空で空は色なのだよ。」と日々語りかけられているように感じています。

ただその繰り返しの中でふと後ろを振り返ってみると、細胞が破壊と再生をただひたすらに繰り返す中徐々に姿形が変わっていく成長期の子供のように、思いが沸いたり消えたりする中で実はAIエンジニアの職業観も大きく変わってきている事に気がつきます。という事で、この2年でどんな風に、AIエンジニアとしての職業への考え方が変わったのか振り返ってみたいと思います。


2. AIエンジニアになろうと思った経緯


実は前職では、今やっている事とは殆ど関係ないSalesforceというシステムのSIer業をしていました。

当時前職の会社に入社したばかりの頃は、ITに関して何の知識も持たない、いわゆるポテンシャル採用系のザ・新入社員だった為、ITの事もそんなによく分からなければ、残念ながら自社の導入しているシステムが本質的にどんな価値があるのかもあまりよくはわかっていませんでした。

そんな迷える子羊のような状態で、端からみればビクビク怯えていそうですが、当時の心境としては、新しい仲間、先進的な技術で世界の先頭に立てる事への期待で、ワンピースのルフィよろしく「どんな冒険が待ってんだ!!?」とウキウキしていました。

やがて、そんなこんなで新卒研修や業務に携わり色々と学んでいく中で、Salesforceの何がすごいのかを少しずつ知るようになりました。

しかし、それとは反比例するかのように段々とSalesforceという先進的ITシステムへの興味を失っていきました。普通に考えれば、すごい!ということを知れば知るほど、どんどんのめりこんでいきそうな気がするのですが。。この原因に関しては、4章(3)で話そうと思います。

そんな中、機械学習なるものと出会いました。それから、機械学習に関する書籍を買い、難解な理論を理解する事に次第に快感と感動を覚えるようになり、AIエンジニアとして転職する事を決意しました。

3. AIエンジニアという職業に対する考え方 before

当然の事ではありますが、AIエンジニアとして転職を決意してからすぐに転職できるわけではありません。

という事で、独学及びスクールでその後約半年間一から勉強するわけですが、当時勉強していたのは、例えば「ゼロから作るdeep learning」を読んで実装してみて、や、決定木やSVMなどのアルゴリズムをスクラッチで実装してみたりなど、いかにも機械学習入門者が最初やりそうな事をやってました。

このようにして、色々とアルゴリズムを勉強して自分で実装していく中で、「様々な機械学習アルゴリズムの仕組みを深く理解し、それを実装していく。」これがAIエンジニアだと思ってました。

ちょうど、スクールに通っていて三分の二ぐらいを過ぎた位までの、AIエンジニアという職業への認識なのですが、ここまでをbeforeとします。

4. AIエンジニアという職業に対する考え方 after

(1) 巨人の肩の上に乗る

スクールでの学習も最後の方になると、実際に論文を読んでFaster R-CNNという物体検出アルゴリズムを実装しようということになりました。

当然今まで、線形回帰から畳み込みニューラルネットワークまでスクラッチで実装してきたので、スクラッチとは行かずともTensorflowやPyTorchで一から実装していくのだと考えてました。

ただそこで行ったことは、何時間も費やして一からアルゴリズムを組み立てる事ではなく、論文を元に実装されgithubで公開されたアルゴリズムを流用する事でした。この時に、少し何というか拍子抜けする感覚がありました。ですが、実務を考えれば確かに既存の実装されているアルゴリズムで学習して応用する方が遥かに効率が良いと納得しました。

これは自分の中で、アカデミックな観点から認識していた「実装」という概念を実務的な観点から捉え直した瞬間でした。

(2) エンジンだけでは車は動かない

その後現職に就職し様々なプロジェクトを通して、どんなアルゴリズムも目的を達成する為の一つの道具でしかないという事を認識しました。

極論を言ってしまえば、たとえ機械学習ディープラーニングアルゴリズムをより深いところまで理解していなかったとしても、実務的な課題をクリアさえ出来るならそっちの方が良い。それぞれの道具をより深く理解する事よりも、その道具をどう活かし組み合わしで課題を解決するかの方が実務では遥かに重要だと理解しました。

その為、実課題を達成するためには機械学習アルゴリズムを理解するだけでなく、例えばPDFのデータから情報を抽出する等の前処理や、実課題に合わせた適切な評価検証、更にはAPIとして公開する為のインフラの構築、他プロジェクトに関わるメンバーとの円滑な意思疎通など、実課題を解決するために必要な道具は実に多くあるという事を思い知らされました。

ここで、「AIエンジニア」というのは、(勿論大分抽象的な言葉で捉え方は多岐に亘ると思いますが私の中では)「機械学習などのアルゴリズムを実課題を解決する為の一つの道具として、他の様々な道具とともに用いる事ができるエンジニア」というものに変化していきました。

(3) 高度なものはいずれ民主化する

このような事を実際の実務の経験を通して肌身で実感してから、「Salesforceを深く理解したエンジニア」ではなく、「Salesforceを課題解決の為の一つの道具として使いこなす事ができるエンジニア」をSalesforceエンジニアであると捉え直した上で、改めて前職で経験したSalesforceとは何だったのかを考える直すようになりました。

その結果、Salesforceは、CRMシステムという複雑で開発に大変手間がかかる一つのソリューションサービスを、誰でも使いやすい形に道具化したもの、つまり「ITシステムを民主化した」サービスであると今では認識しています。

思い返せば、当時、前職の会社のCTOの方がSalesforceに感動してSalesforceに惚れ、Salesforceを愛しているから今の職業をしていると言っていたのが記憶から蘇ります。当時のCTOは、このSalesforceによって得られる「ITシステムの民主化」による恩恵の素晴らしさにこそ感動し惚れていたのではないかと今では思います。では、なぜその感動が自分にはなかったのか。逆に興味を失っていってしまったのは何故なのか。

私の中では、それは「リープフロッグ」が原因であると結論づけています。

リープフロッグとは適当に訳せば「跳ぶカエル」となりますが、これは端的に言えば、様々な技術の変遷をすっ飛ばしていきなり新しい技術から参入するという意味です。リープフロッグの例として有名なのが、発展途上国のキャッシュレス化です。韓国に至っては決済比率の90%近くがキャッシュレスであるそうです。そんな国にそんな時代で生まれた人にとっては、キャッシュレスなど当然の事でその有り難みを実感することは難しいでしょう。一方で私のような現金で生きてきた人間にとってみれば、改札でわざわざ切符を買わずにスマホ一つで抜けられる有り難みを肌で感じ、いつも感動に身を震わしています。

リープフロッグの話が長くなりましたが、同じように、あらゆる技術をすっ飛ばしてSalesforceから始めた自分は、Salesforceによってもたらされた「ITシステムの民主化」の恩恵を肌身で感じていない為に、その素晴らしさもまた、理解はできても肌身で感じる事が出来なかった。それに加え、民主化されてしまったことに逆につまらなさを感じてしまった。それゆえに、興味を失ってしまったと理解しました。

今後AIエンジニアの在り方も将来のAIのあり方とともに変わっていくでしょう。では、今後AIがどうなっていくかと言えば、ITシステムが民主化されていったのと同じようにAIも民主化されていき、それに合わせてAIエンジニアのあり方も大きく変わっていくだろうと想像しています。

その場合、扱うサービスの対象がSalesforceから例えばAWSGCPに変わるだけで、本質的には職業のあり方として前職と何ら変わらなくなるのかも知れません。

(4)AI民主化による回帰は悪か

では、今後Salesforceに興味を持てなくなったのと同じようにAIにも興味が持てなくなるか、と言えばそうではないと確信しています。その理由は(3)で述べた通りですが、前職のCTOがSalesforceに自分なりの意義を見出していたように、AIを扱うAIエンジニアという職業を、「リープフロッグしていない」AIエンジニアとしてより強く意義づけする事ができると確信しています。

最後に


ちょっと、最後の方はエモい感じになりましたが、職業観を考える事はあまりないので良い機会になったと感じています。読んで何か得られるような内容ではないですが、「この人は自分の職業に対してこう考えてるんだな。自分はこう考えているけど。」と言った感じで、何か考えるきっかけにでもなっていたら嬉しいです。最後まで読んで頂きありがとうございました。

 

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

 

corporate.photoruction.com

www.wantedly.com

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

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

Photoruction Advent Calendar 202120日目の記事です。

導入

アドベントカレンダー2日目の記事に引き続き、今回は入社して2年目を振り返っていきたいと思います。

 

2年目は新規開発や機能改善案件とガッツリ開発に携わった1年だったと思います。

こんな人間が働いてますってことと、Photorucution開発の様子などがざっくりとでも伝われば幸いです。

 

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

 

1年目編の記事はこちら↓

photoruction-tech-blog.hatenablog.com

 

2020/11 編

[振り返りコメント]

当時やっていた案件は新規開発の案件だったので事例がなく、どういうUI/UXだとユーザーにとって分かりやすいかなどPdM、デザイナー含め何回も擦り合わせた記憶がある。

こういうUIだと操作性良さそうだな、けど工数結構かかりそうだな、けど、、ってなりながらどこまでを実現するのかのラインを話し合ってたな。

 

[振り返りコメント]

都度、PdMと確認取りながら開発していくって大事ですよね。

最近できてないな😂

 

[振り返りコメント]

分かりみが深い。

 

[振り返りコメント]

一年前まではIEの対応をしていました。

IEだと上手く動かない、スタイル崩れてる、重い。

当時は、早くIEを対象外にして欲しいと願いながら対応してました笑

 

[振り返りコメント]

実装の大半がやったことないことだらけなので、どのくらいでできそうかの見積もりはいつも難しいなって思います。

特に、既存機能の改修案件は影響範囲によって工数も大きく変わってくるので安易に見積もってしまうと全然足りなかったってなることも。

この辺は実務経験積んでいくと分かってくるのかなと思ったりしてますが、どうなんでしょうね?

2020/12 編

[振り返りコメント]

人の書くコードで性格がわかる!?!?笑

変数名のつけ方とか、人によって変わるから面白いですよね。

 

[振り返りコメント]

ユーザーからのフィードバックは仕事やってて一番嬉しいし、ドキドキな部分でもある。

普段の業務で使用するツールだからこそ、直感的な操作性って一番大事だなって思います。

2021/01 編

[振り返りコメント]

UI/UXってほんと奥深いなって思います。

シンプルが正義ってことでもない。

なぜこういうUIにしたのかとか、色々聞いてみたいからデザイナーさんともっと業務で絡みたいなと思ったり。

 

[振り返りコメント]

面接を担当するようになってからはより視野広く物事を見れるようになった感じがします。

弊社を知らない応募者にいかにして弊社のことだったりチームの課題感とかをわかりやすく伝えるか、興味を持ってくれるかなど伝える力が鍛えられる気がする。

あと、単純に社外のエンジニアとお話するのって楽しい。

自分のキャリアについての参考にもなるしね笑

 

[振り返りコメント]

いいプロダクトを作るためにそれぞれがそれぞれの立場で意見を出し合って進めていく感じとてもいいなと思う。

スケジュールがタイトになってるくと余裕がなくなりそういう話し合いすら蔑ろにしちゃいたい時もあるけど妥協せずにいいものを作ろうという姿勢って大事ですよね。(自戒)

 

[振り返りコメント]

ホント名前は大事!!!

誰が見てもわかる名前をつけるの&省略のし過ぎは後々見返した時になにこれ?ってなるので長くてもちゃんと意味が分かる名前をつけるようにしてる。

あとは、コメント添えてるかな🤔

2021/02 編

[振り返りコメント]

目先のことだけを考えての設計、実装は後々負債となってしまうのでちゃんと先の先まで考えて設計するのって大事ですよね。

あとは、運用コストが大きくならない設計にするのも大切。

どのくらい先まで考慮すればいいのかは難しいところですが、、

 

[振り返りコメント]

ドキュメントの作成は本当めんどくさいなって思うタスクの一つ。

けど、先延ばしにすればするほど毎回同じことをメンバーに共有する時間が発生したりしてそれはそれで自分の首を絞めるだけなので開発しながら合間に整備していかないとなって思うけどいつも最後にまとめてやっちゃいます笑

2021/03 編

[振り返りコメント]

わかる、だっっっるい。

 

[振り返りコメント]

PhotoructionはWeb側とモバイル側のデータ同期も考慮してAPI実装とかもしないといけないので頭の片隅には常にモバイル側への影響とかも考えながら設計、開発する必要があります。

2021/04 編

[振り返りコメント]

一つのバグは氷山の一角に過ぎないってやつですね。

 

[振り返りコメント]

この時期は、ずっとリモート勤務ということもありこっそり沖縄に帰省して仕事をしていました。

こういう働き方ができるのはありがたいなと思ったり笑

 

ちなみに、弊社にはリモートワークポリシーというのが存在しています。

こちらもぜひ読んでみてください↓

www.wantedly.com

2021/05 編

[振り返りコメント]

詳細設計って本当難しい。

いろんなことを考えて複雑な設計になってしまったり、考え過ぎて前に進めず停滞してしまうことも多々ある。

初めてやるような開発は、これ自分で実装できるの?ってのもあるしね。

この時期から担当した案件はまさにそう。

 

[振り返りコメント]

ユーザーからの反応を共有してくれるビジネスサイドのメンバーには感謝しかない。

こういう声が力になってるし、苦労して開発した甲斐があったなって今までの大変だったこととかが報われた感じがして次の案件でも頑張ろうってなるのでどんどんユーザーの声を伝えてほしいとひそかに思ってたりしてます笑

 

[振り返りコメント]

ガチでこの日は喜びのあまり震えた。

IE対応から解放されるだけでもだいぶ開発の負担減るので嬉しかったです。

 

[振り返りコメント]

本当に今までお世話になりましたぁぁぁ!!!

2021/06 編

[振り返りコメント]

チーム内でGatherというツールを取り入れて、バーチャルオフィス内で仕事をするようになりました。

ずっとリモート勤務でチーム内でのコミュニケーションが減ってるのもあり、こういった遊び心あるツールを用いることで少しでも楽しく仕事ができるのかなって。

この日は、リーダーと海辺で語りました🌴

 

WebエンジニアチームにGatherを導入した時の話はこちら↓

photoruction-tech-blog.hatenablog.com

 

[振り返りコメント]

ついに業務でもTypeScriptを書くようになりました。

最初は、手こずりまくりでしたが書けば書くほど型のありがたさだったり、開発のしやすさが感じられてめっちゃいいってなってます。

2021/07 編

[振り返りコメント]

ひぇーーーーー🥺

そういう日もありますよね。

2021/08 編

[振り返りコメント]

開発チームだけじゃなくビジネス側も含め全員でプロダクトを作っているってことが感じられるから実装レビューの時間って意外と好き。

 

[振り返りコメント]

毎日の仕事に少しでも癒しをということで、この時期あたりからPRレビューでLGTMに猫を添えるようになりました。

猫って正義🐈(私が一番癒されている)

 

LGTM画像はこちらのサイトから作れます↓

lgtmoon.herokuapp.com

 

[振り返りコメント]

現在担当している案件は大半がこんな感じなのでメンタル鍛えまくり。

スキルをもっとつけたいものです。それか時間止まってほしいっていつも思いながら仕事してる。

2021/09 編

難しいところから先に進めていくのがいいって言うけど、そこでずっと詰まってると時間だけが過ぎてく&モチベ低下&自信なくなってくる。 

なので、最近は一旦切り上げて別のタスクに取り掛かることでやる気とメンタルの維持を図ってる。 

楽しく働ける環境を自分で作るの大事😌

#エンジニア #業務日記 2021/09/17 

[振り返りコメント]

自分で自分の機嫌を取りながら働くのって大事ですよね。

じゃないと、ただただ辛いだけ笑

他の方が楽しく働くために工夫していることとか知りたいな。

 

お客様とのMTGほど緊張するものはない。

会社ごとに運用方法が様々なため、こういう風に使いたいんだけどできる?という斜め上からの質問に終始ヒヤヒヤ。

まじでプロダクトの仕様完全に理解してないと終わる😅

#エンジニア #業務日記 2021/09/28 

[振り返りコメント]

ほぼ毎日顧客とMTGしている営業の人たちは尊敬でしかない。

2021/10 編

最近チームの雰囲気が良い気がする。

一人ひとりの行動がチームに伝染していっていい方向に変わってきている感じ。

いいね、素敵だ。

#エンジニア #業務日記 2021/10/01

[振り返りコメント]

一人一人がチームのために動けるチームって強いよなって思う。

そういうチームにより一層していきたいですね。

私にできることってなんだろう?ってたまーーに考えたりしてる。

 

先週からずっと苦戦していた実装がやっと一段落ついた。

まだまだ作らないといけない機能があるから達成感に浸っている場合じゃないけど、出来なかったことが出来た瞬間は半端なく嬉しい😳

#エンジニア #業務日記 2021/10/04

[振り返りコメント]

出来なかったことが出来た瞬間は半端なく嬉しい

こういう瞬間を定期的に味わえるから、開発って楽しいなって思う。

なんなら仕事って楽しいって思ったりする。

 

時間かけて書いたコードを消すのは一瞬で忘れるのも一瞬😳

今の構成が今後の機能開発する上でどんどん複雑な実装になっていくのが見え見えで自分の首を自分で絞めてる状態になってたのをリファクタした。

自分で書いたコードなのになんだこれ状態。。

ま、あるあるだよね?w

#エンジニア #業務日記 2021/10/05

[振り返りコメント]

プログラムってすぐ書き換えることができる点はいいところでもあるけど、あんなに時間かかって書いたのに一瞬で消し去ってリファクタする時はちょっと虚しい。

けど、未来のことを考えるとリファクタリングは大事。

 

[振り返りコメント]

こういうツッコミをしてくれるテックリードのキャラ結構好き😊

2021/11 編

入社して2年が経ちました!

感覚としてはまだ2年しか経ってないのかという感じですがw

入社当初は、エンジニアとして全然過ぎて上司に負担かけることも多かったが、今はそれなりに開発スキルもついてきて自走してタスクをこなせるのはもちろんのこと周りにも少しは貢献できているのかなって思っているところ。

現在は、開発以外にも開発組織の改善に関する取り組みにも携われているので引き続き精進します💪

#エンジニア #業務日記 2021/11/01

[振り返りコメント]

フォトラクションに在籍して3年目突入ということで、色々できることが増え楽しい反面、チームの中では古参という責任感も若干ありますが引き続き楽しく働けたらいいなと思ってます。

まとめ

2年目は新規開発や機能改善案件とガッツリ開発に携わった1年だったと思います。

エンジニアとしての開発スキルもそうですが、案件をリリースまで持っていくために他メンバーとの関わり方やプロダクト開発の進め方など色々学ぶことの多い1年になりました。

 

3年目は、開発業務以外にも組織やチームへ目を向けて組織改善などにも取り組めたらいいなと思っています。

 

フォトラクションアドベントカレンダーもラスト1週間となりました。

明日からはAIチームの記事が続きます。乞うご期待!!

 

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

受託開発から自社開発になって変わったこと

こんにちは。

株式会社Photoructionでwebエンジニアをしている土岐(とき)です。

Photoruction Advent Calendar 2021の19日目の記事になります。

目次

1、はじめに

2、受託開発の頃に大事としていたこと

3、自社開発で大事にしていること

4、これからやっていく上で大事にしていきたいこと

 

はじめに

まずは軽く私の自己紹介から。

IT業界に入る前は異業種の仕事を色々していましたが、ちょうどブロガーという仕事が生まれた頃でしょうか。私はブログの中身を見て楽しむよりサイトのデザインを見て惹かれていき、そのうち自分で作ってみたいと思うようになりました。まだHTMLやCSSすら知らなかったど素人ながらもググってwordpressテーマを作り、更にそこからVPSサーバでLAMP環境をググって構築しドメインを借りて公開をおよそ2ヶ月半程度でやってみた事がIT業界に入ったきっかけでした。

1社目はmovabletype、DoやLumen、wordpress、laravel、その他javaandroidアプリなど、主にphpがメインであるものの割となんでもいろんな案件を受託しちゃう10人程度の小さい規模のシステム開発会社で、PMやデザイナーはおらず全員エンジニアで構成された会社でした。

そこで私は初めてデスマーチというのを体験しました。おおよそ4〜5ヶ月間常駐先に缶詰になりながらjavaでできた巨大なレガシーシステムを読み解いていき、設計書やフロー図・シーケンス図などに落とし込むのが仕事でした。何日も泊まり込みというのはザラで家に帰っても寝る時間ぐらいしかいなかったので、残業時間だけで月150時間位はいってました。そして残業代はどんなにしても一律3万円までという会社でしたので中々のブラックだったな...と勉強になりましたね(泣)

2社目はwordpressをメインの受託会社。自社商品の仮装マシンも売りにしており、割と誰もが聞いたことがあるような結構大手な会社から受注し、そのサイトの開発から保守まで受け持つ、なかなかやり手なベンチャーでした。

1社目とは異なりPMやデザイナー、シニアエンジニアなどが揃っており、基本1案件を一人で行うものの、何かあった時は頼れる先輩エンジニアがいたことは心強かったですし、色々と教えて頂けたのは本当にありがたく私の財産になりました。

 

受託開発の頃に大事としていたこと

いろんな案件をこなしてきましたが、やはり受託の場合は「納期までに実装して納品する」事が第一です。

ミッションをクリアするために主に3つの事を気をつけていました。

 

1、コミュニケーションのルールを決めておく

よくあるのが実装・テストフェーズに入った後などPMや顧客とのやりとりで

「こんな機能作ってって前に言ったよね?」

「聞いてません。提出した設計書を確認時にそちらからもOKを頂きましたよね?」

みたいな「これは言った、言わない」問題。いわゆるコミュニケーションの不足による仕様の認識がズレることです。まぁよくあることですね。

実際、依頼側が言い忘れていた場合もあるし、受注側が忘れていた場合もあります。また実装したものを触ってみて細かいところまで考慮漏れだった事もありますし、依頼側の要望が途中から変わってくることもあります。

そういう時はムキになってこちらは悪くない!と言い張る争いをしても案件は終わらないし、相手と気まずい嫌な空気が生まれてしまうだけ。そんな不毛なやりとりが大の大人でも現場でよく起こったりします。

そこで私はキックオフや割と最初の段階で相手といろいろ取り決める際に以下のことを提案します。

  • 基本やりとりはslackで。口頭だと聞き漏らすことや忘れることもあるので必ず文章化して残したい。
  • 画面名や機能などの名称を統一・共有しておく。こうすることで、コミュニケーションを取る際に双方の認識が合致しスムーズにやりとりできるため
  • チームの全員の認識が一致するために、最新の確かな仕様をいつでも誰でも振り返って確認できるようにして欲しい。そのため仕様書の更新をその都度して頂きたい(口頭やslackだけでは不確かだったり二転三転するため)

こういうことを最初に取り決めておくことで、なるべくコミュニケーションコストを下げお互いにとってイラつかないようにするのが双方にとってスムーズだと学びました。

 

2、まずは30%でもいいのでなる早で作る

じっくりと丁寧なものを期限ギリギリに提出するよりも、完成度が30%でもいいのでプロトタイプを早めに提出してそれに対しフィードバックをもらう。

そしてまたそのフィードバックに対しサクッと作る。

そういうサイクルを繰り返す。

上記の1でも少し書いたのですが、実装したものを触ってみて細かいところまで仕様を決めていくというのはよくあります。

というのも要件が固まり仕様を決めても、細かいところまでは決めていない・気づかない事はよくあります。(完璧な仕様書というのは最初から作れないもんです。人間だもの)

そのためざっくりでもいいのでまずは動くものを提出し触ってもらうことで、依頼側と開発側、双方の認識が噛み合ってきます。

口頭や文章だけではうまく伝わらない事もあっても、実際のものを通して認識をすり合わせる事で完成度を高める事ができるので、なるだけ早く形にするのは大事だと知りました。

早いは正義!

 

3、早い段階で別チームに知らせる

大きい規模のシステム開発など、別の会社やチームと組んで一つのシステムを作る時、自分達の領域だけでは解決できない機能があります。(例えばスコープ外の機能と連携しないと表示できない部分とか、webとモバイルでデータを受け渡さないといけない部分が出てきたりなど)

そういう時に大事なのは、何か疑問が出てきたらすぐに別チームのエンジニアと早めに情報を共有することでした。

なぜなら別チームにもそれぞれスケジュールや優先順位があるからです。

別チームと連携しないと進めない問題が出てきた時に、できるだけ早い段階で共有しておかないと別チームが切羽詰まってきます。そして別チームが遅れることで、こちらもそれに合わせて対応が遅れてきたりと...まぁ全体的に遅れてくるので、やはり連絡・共有は早いことに越したことはありません。

早いは正義!!(2回目)

 

自社開発で大事にしていること

さて。そんな受託の頃とはうってかわって、このPhotoructionではなかなか他では味わえないような面白いメンバーで構成されています。

まずこのPhotoructionは「建築業界をスマートにする」というミッションで立ち上がった会社なので、建築業界出身の方とIT業界出身の方がおおよそ半々。

そのうちシステムの開発部にはエンジニア(web,IOS,android)、デザイナー、PMチーム(プロマネ)、QA、CREチームと構成されていますが、PMは全員が建築出身の方で構成されています。

受託の時は「納期までに納品する」ことが第一になっていたのですが、ここでは「ユーザに価値のあるものを届ける」ことが第一になってきます。

とはいえ、はじめは「ユーザに価値のあるものを届ける」と言っても具体的にどういう姿勢でやっていけばいいのか慣れませんでした。

今までは決められた仕様を期限までに作るやり方に慣れていたため、仕様が二転三転するのに困惑しましたし、仕様を決める時からエンジニアも参加できるのですが、エンジニアは現場の空気感や使っているユーザのことはあまりわかってる人はいません。

そのためエンジニアが加わるとどうしても「どう作るか」な目線で決めたがります。これはシステム的にまたはデータの観点からベストなやり方で作ろうとするからです。

ですがユーザのニーズからかけ離れたものを作ってしまったら本末転倒です。

そのため建築業界出身の方と一緒にうまく協力していく必要があります。

受託の時とは違って1人では良いものは絶対に作れません。「みんなで作っていく」ということが受託との1番の違いだという事を教えて頂きました。

 

これからやっていく上で大事にしていきたいこと

「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで

仕様を決める際、ユーザの要望に向けてあれもこれもやろうかといろいろ案が出てくるのですが、どうしても期限を考えると現実的に実装できる機能を絞り、この機能は「リリースまでにできるか・できないか」というスタンスになりがちです。

ですが本来私たちのミッションは「ユーザに価値のあるものを届ける」こと。

時間の許す限り、よりユーザにとっていいものを作るのが大事になってきます。

そのためエンジニアとしては設計や実装において「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで取り組むのが大事なのではないか。と私は思っています。

なかなか大変であろう機能をお願いされた時、「他の案でカバーできないか」「別のやり方(簡単な機能)でいいか」などとすぐに返すのではなく、まずはどうしたら実現可能かを考えユーザの求めるものに寄り添う姿勢でやっていくこと。

限りある時間の中でいかにクオリティの高いものを作れるか、そこがエンジニアとしての腕の見せ所になってくるのではないかと思います。

 

一緒に作っていくチームメンバーとのコミュニケーションにおいて

どうしてもエンジニアという仕事をやってると細かい所まで目が行くようになります。

具体的に言えば設計だと

  • 求められている機能の確認
  • 既存仕様とそのコードの確認
  • 機能を追加する事によって生じる影響範囲の確認

実装だと

  • 求められている機能を作って動くようにする
  • 書いたことでクリティカルなバグが発生していないか
  • 他の機能にも影響がないか
  • 書いた処理が他の処理と被ってる部分がないか、コードをもっとスマートに省略できないか

テストだと

  • 想定外のバグがないか
  • そもそもこちらの認識の抜け漏れがないか

……などなど。

システムを細かいところまで確認し作り上げるのがエンジニアの仕事なので「細部まで厳しくチェックする目」を持つようになり、それを要件やコードだけでなく色んな部分に向けるようになってきます。

 

でもそれは決して「人の至らなさ」に対して向けるべきではないはず。

一緒に案件をやってるメンバーはあくまで「良いものを作りたい」という同じ目的の下集まってる同士であり仲間です。

加えて人間なのでどうしてもコミュニケーション不足による認識の齟齬や勘違い、言葉足らず・逆に一言多い、積んできた知識・経験の差などというのは必ず発生します。

そもそもITと建築というバックグラウンドが違う人間同士のコミュニケーションなのでそういう事が起きて当たり前です。

そのため人の発言に対し重箱の隅をつつくような揚げ足を取ったり、間違った知識や認識に対して人間性を否定するかのような批判をする、といったことは絶対にあってはいけない事です。

 

ちなみにPhotoructionにはそんな人は誰一人いません。それはPhotoructionの理念の一つに「敬意尊尚」というのがあるのですが、これは心理的安全性の高い組織を作るために「互いをリスペクトし、立場に関わらず相手の意見に耳を傾け、建設的な議論をすること」を良しとしてる風潮です。これによりチーム内のやりとりはフランクな空気でとても仕事がしやすくなっています。

今、Photoructionはいろんな機能が密結合しており開発するたびにバグが多数出てきてしまっているのが現状です。

 

そのため自分達が書いたコードや成果物には「性悪説」な目を向けて。

ですがチームメンバーには「性善説」な目を向けて、これからもやっていきたいと考えています。

 

最後まで読んでいただきありがとうございました。他の記事もぜひご覧ください!

 

 

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

corporate.photoruction.com

www.wantedly.com