Yuri’s Tech Note

技術系アウトプット

スタートアップのMBOはエンジニアにとって嬉しい

f:id:yuri_iOS:20180704214316p:plain

よくある話ですが、スタートアップではなんでも経験させてもらうことができます。


"なんでも"ってちょっと抽象的すぎるし、私も他の会社はどうなのか知っているわけではありませんが、一例として私の場合はフロントエンドエンジニアですがデザインとサーバーもいっぺんにやらせてもらいました。


また、スタートアップでは文化を作るフェーズをどんどん体験することができます。
例えば私はReact Nativeでアプリを作っていますが、去年まではアプリの土台作りがメインでとにかくプロダクトをつくろう!というフェーズだったので、テストが文化としてありませんでした。


今年に入ってからユーザー数の増加から品質をあげるという目標を組織で掲げ、私自身もテストを本格導入する目標をMBOとして立て、テスト文化の確立の一旦を担うことができました。


まだできあがっていない世界で、なんでも自分で好きなことで貢献していいよって言われて、本当になんでもやらせてもらえる。
それも0から作り上げるという貴重な体験も選択可能である。


月並みながら、そういった点が私がスタートアップのMBOが素晴らしいなと感じる理由です。
タイトルにしておいてなんですが、エンジニアに限ったことではないですね。😅


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


個人的な振り返りになりますが、2018年上半期はたくさん成果を出せました。

私はこの上半期に大きく3つを目標としました。


また、MBOとして掲げたもの以外にも、途中で取り組みだしたものもあります。

技術
今後業務で扱いそうなものを先取り

健康
体が資本。集中力向上のために。

  • b-monster

5月 26回 21位 / 6月 24回

具体的な実施内容は下記に記載しました。


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

納期を守る・クリティカルなバグを出さない

重要度 40% 難易度B

実施したこと

1: リリースチェックシート運用

TDD的に開発時に自分が確認する確認項目を書き出し、リリース前に開発者以外のメンバーに同じ項目を別のOSや環境(STGor本番)で確認してもらう項目としました。

コードレビューやタスク名・コミットなどの文言から修正内容を推測した動作確認では、確認すべき項目が人によってばらつき、抜け落ちも多いと感じたので導入しました。


2: コードレビューガイドラインの作成

せっかくPRを出してもなにをレビューするのかが明確でないと確認がザルになるので自分の確認の意味も込めてコードレビューのガイドラインを作成し、社内のBitbucketのwikiに記載しました。


3: デザイン関連業務の効率化

弊社にはデザイナーがおらず、副業として仕事を受けている外注の方に依頼をしていたため、
多くの時間を割いてもらうことができないという状況でした。

結果、いくつか問題が生じていました。
・納期に作業が間に合わない
・せっかく話し合った内容のデザインのfixがされず、後から議論の重複や見直しなど無駄な工数が発生

途中一緒にデザインファイルの管理をできるようにAbstractというSketchのGitツール(差分・バージョン管理)の導入や、ガイドラインの作成をこちらで巻き取ろうとStorybookの導入を検討しましたが、最終的にはinVisionの機能で十分であることがわかりデザインファイル管理作業を巻き取りました。

また、何人かの手を渡ってきたデザインファイル自体のデータの整理や今後も使っていくことを見据えてSymbolの作成なども実施していました。

まとめ

リリースチェックシートにより軽微なバグが減った事。デザイン業務の改善が評価され"目標達成"


テスト環境の整備と文化の定着

重要度 40% 難易度A

実施したこと

1: Circle CIの導入

だいぶ前のことなので記憶が曖昧ですが、config.ymlというものを作成する必要があるんだなーとか、1コンテナなら無料なんだなーなどの事前調査から実際にコミットしたらCircle CIが動くようにしました。


2: テスト方法の模索

React Nativeでのテストは情報が多くはないのでつまることがありましたが都度調べてチーム全体で解決していき、解決できた事に関しては社内のwikiやqiitaにアップしました。
Test on React Native - 小さなチームではじめるテスト運用


Atomic Designの勉強

Atomic Designを学んでコンポーネント設計の粒度を下げる事により、Atomsによるデザインの統一やテストの網羅性の向上などを期待できると考え、まずはデザインデータをAtomic Designの粒度に分けて作成しました。
ただ、自分はデザイナーではないので、将来しっかりデザイナーがきたらこういう風に運用したいな。という考えは確立できたものの、メンバーに共有したり、実際に導入してテストの網羅性をあげるまでには行動に移しませんでした。
変に線引きしているわけではなく、導入にコストがかかるのでコストとリターンのバランス、エンジニアとしてチームへの貢献方法や重要度を踏まえての判断です。

まとめ

テストの数はこの半年で700近くになりました。
開発時にテストを書くことも定着したことが評価され"目標達成"


サーバー側のドキュメンテーション化

重要度 20% 難易度S

実施したこと

Swaggerを使って既存コードにアノテーションをふってドキュメントを吐き出す方法を模索しました。
途中他のメンバーが先にPublic用のドキュメンテーションとしてgo-swaggerドキュメンテーションを作成したので、同じくgo-swaggerで内部用のドキュメントの出しわける方法を模索しましたが見つからず、アノテーションの記述を分けることで出しわけでるのではないかと考えswaggoの採用を検討しました。

swagger.yamlが生成され、Swagger Editorで見ることができるところまで実施できました。

まとめ

実はこれはswagger.yamlを使えばSwagger Editoでドキュメントがみれるという事に気がつかず、MBO面談後に気がつきました。
それまでは調べたけど何もなしてないということで"目標に至らず"


その他

MBOには策定していませんでしたが社内でReactを使うことになりそうであるということと
Goで書いているサーバー側の修正をやらせてもらえたことがあり、ReactとGoの勉強をしました。


React & Node
Webアプリをつくりました。


Go
A Tour of GoやWebやサーバーに関してわからないことだらけなので知見がまとまったタイミングで情報をブログにまとめました。

A Tour of Go vol.1 - 5


Flutter
React Nativeの対抗馬として興味があったので実際に触ってみました。
Dart/FlutterハンズオンでNews閲覧アプリ作ってきた - yuri’s diary



総括

これらを踏まえ、個人的には充実した上半期を終えられたと思っています。
スタートアップなのでむしろ当たり前のことがまだ導入されていなかったりするかもしれませんが、全てが揃っている世界を知らないので日々試行錯誤して少しずつながら色々なことを改善していけている感覚があります。

そして会社が大きくなってしまったら今みたいにサーバーやデザインも気軽にできないので今のうちにどんどん経験を積みたいと思い、実行できました。

上司からの評価ももちろん大事なのですが、なによりも自分が自分をよくやったと思えるということが1番誇らしいです。

下半期も頑張ります。