はじめまして、ソフトウェアエンジニアの西銘です。私はほぼ新卒で共同創業者としてLiLz株式会社に携わるという奇妙な経歴を持っています。LiLzの共同創業者になってからの6年を振り返ってみようと思います。

自己紹介

91年生まれ沖縄県出身です。学生時代は情報工学を専攻していて機械学習などを学んでいました。新卒でLiLzの前身となる会社に入社し創業メンバーと出会い、そこから6ヶ月後にLiLzがスタートしました。
その時の心情を今は明確に覚えていないですが、現在4名いる創業メンバーの中で、実質一緒に仕事した経験があるのはクバさん(現CTO)だけだったので、どんな会社になるのかと不安があったことを覚えています。

初期の思い出

入社からLiLz立ち上げまでの2017年9月頃までは、類似画像検索を行うウェブアプリケーションの開発や精度評価をしていました。この頃はチーム開発の経験もほぼ無かった為、実装やコミュニケーションで苦労が多かったです。この頃の経験はLiLzでのプロダクト開発を行う際の共通認識や私のエンジニアとしての価値観を形成するのにも大きく影響したと思います。

この時期の印象的だった思い出です。詳細は省きますがタイトルだけ並べておきます:

• 手直しが多いため長い間OpenになっているPRを量産してしまう

• Code Complete を勧められて紙で購入するも半年ぐらい放置

• クバさんのインプットの量が多すぎる

• けんきゅうしゃってほんとにすごいんだ!!

• ボス、いつの間にカメラを...

LiLzでは最初期からリモートワーク制度と20%ルールが存在していたと思います。リモートワークは小さい子供がいる社員が自宅でも勤務する為、20%ルールは新規技術やドメイン知識を学ぶ為にそれぞれ役立っていたと思います。僕はこの2つルールを活用する事により、どこのカフェで当時開催していた輪読会のために準備をしていたこともありました。

業務以外の思い出として、ランチの度に長距離の散歩をしていた記憶があります。近くの弁当屋(片道徒歩12分)や病院近くのラーメン(片道徒歩21分)は結構な頻度で利用させてもらっていました。

往復の散歩と食事をあわせて60分程度あったと思います。大西さん(ボス)や大塚さん(研究者)とプロダクトの問題から趣味に関する内容まで色々と話していました。歩きながら考えたり議論すると悪い方向には進まない印象なので好きな時間でした。ちなみにクバさんは14時ぐらいにランチするスタイルでだったので、そう簡単に散歩には来ません。一緒に散歩できたらラッキーです。

当時のオフィスは大学敷地内の小さな部屋でしたが、周りに自然も多く過不足ない設備だったので、今思い返すと悪くない環境だったなと思います。(割と気に入っていましたが最後は更新不可になりあっけなく部屋を追い出されてしまいますが)

こんな環境で LiLz Gauge の開発が始まっていくことになります。

LiLz Gaugeの始まり

LiLz Gaugeはユーザの課題から発想して生まれたプロダクトだったと思います。記憶が途切れ途切れになっていますが、私の印象では 1)プロダクトのアイデアを聞いた、2)試作のカメラが完成、3)現場で撮影と通信のテスト、というように怒涛の勢いで進んでいたように思います。大西さんのパワーが凄すぎました。
この頃から関わる人間が増え、カメラ開発現場や設置する施設や展示会などで社外の方々との話す機会が増えていきました。オフィスで開発しているだけだとほぼ確実に出会わないであろう方々と関わりを持てたのは非常に良い経験だったと思います。色々な刺激が多すぎた為か、この頃にやったタスクをもう殆ど覚えていないです。。

私は全く覚えていないですが、Geekbotで1日のやるべきことなどを昔から記録していたので、2019年の今頃のログを掘り返してみようと思います:

member,date,昨日取り組んだことは？,今日は何に取り組む予定ですか？,困っていることはありますか？,今日のイチオシ
"Taiki Nishime (@nishime)","2019-08-30 10:40:30","k形計器読み取りアルゴリズムのマージ, 共同研究 mtg","円形計器読み取りアルゴリズムのマージ(残り), shift detector のリファクタリングとPR作成",とくになし,とくになし
"Taiki Nishime (@nishime)","2019-08-29 12:03:55","円型計器読み取りアルゴリズムのマージ(1/3), mtg など","円型計器読み取りアルゴリズムのマージ(残り 2/3), 共同研究 mtg",とくになし,"かっこいいPC; https://www.dellemc.com/en-us/optiplex/optiplex-7070-ultra-coming-soon.htm "
"Taiki Nishime (@nishime)","2019-08-28 13:32:01",ベイズ輪読会、円型計器読み取りアルゴリズムのリファクタリングと動作確認スクリプトの追加,円型計器読み取りアルゴリズムをマージする,アルゴリズムのクラスはリファクタリングと小さくPR作るのが難しい...,"https://shiropen.com/seamless/real2sim "
"Taiki Nishime (@nishime)","2019-08-27 13:06:31",円形ゲージ読み取りアルゴリズムのリファクタリング,"ベイズ輪読会、円形読み取りアルゴリズムのPR作成とshift detectorのリファクタリング",とくになし,とくになし
"Taiki Nishime (@nishime)","2019-08-26 09:23:27",休暇,"lilzgauge (円型読み取りアルゴリズムのPR作成)",とくになし,"https://refactoring.guru/ "
"Taiki Nishime (@nishime)","2019-08-23 10:39:04","lilzgauge (円型計器読み取りアルゴリズムの導入確認とリファクタリング, mtg)","lilzgauge (円型計器読み取りアルゴリズムをリファクタリング, PR作成する)","lilzgauge の issue が多くて、タスクの状態がわからない物が多かったけど、昨日で少し整理できた感じがする。
決まっていない仕様の確認とかも一緒に出来るので、定期的に issue 整理とかやりたい感じもする。","https://github.com/aquasecurity/trivy  :eyes:"
"Taiki Nishime (@nishime)","2019-08-22 10:56:08","lilzgauge (loggingのアップデート、gocdユーザ追加、円型計器読み取りアルゴリズムのコード確認)","lilzgauge (新しい円型計器読み取りアルゴリズムを追加する)",とくになし,"https://changelog.com/ "
"Taiki Nishime (@nishime)","2019-08-21 10:12:02","ベイズ輪読会、azure deployment history の掃除とinvoke task追加(lilzgauge)","lilzgauge (slackにlogを流さないようにするなどのlog関連の変更)",とくになし,"https://medium.com/@blattmannmedia/no-sound-after-upgrading-to-macos-mojave-heres-your-fix-f6d3ea807634 "
"Taiki Nishime (@nishime)","2019-08-20 11:05:44","lilzgauge (mtg & intro, logglyの導入PR), gocd にユーザ権限を導入する","azure deployment のエラー対処, gocd 改善など","- gocd の docker だと何故か pipeline が作れない
- DeploymentQuotaExceeded; azure は deploy履歴を保存するのだが、履歴はリソースに影響しないので古い物から順に削除したら良いのになーという気持ち","https://probcomp.github.io/Gen/ "

この頃は円形計器の読み取り処理の実装をしていたようです。実装の詳細までは覚えていないので、近いうちに実装を確認しないといけません。

この頃からもう既に約4年が経過しているのは驚きです。私の体感では2年ぐらい前に円形計器の読み取りアルゴリズムを実装したような感覚です。

ざっくりとした振り返りでしたが、LiLz Gaugeの始まりからサービスインまでは大西さんのこちらの記事に詳しく書いているので、気になる方は一緒に読んでみてください。

LiLzの開発チーム

ここからは、今の LiLz の開発チームと仕事の進め方の個人的な印象を紹介していきます。

初めはクバさんと私だけだった開発チームも今では倍の4人になりました。LiLzの開発チームは、沖縄には私1人が常駐していて、あとの3人の開発メンバークバさん、エリックさん、ソフィアさんは他県、海外に常駐しています。(リンク先は英語ですが皆とても日本語会話がお上手です)
この4人でLiLz GaugeのWebアプリケーションの開発、運用、計器読み取りの実装や改善、カメラから送られるデータの処理など様々なタスクを実施しています。色々なタスクの中から、個人の好みに応じたものをアサインされる事が可能です。明確な評価指標は無いですが、素早く作ってデプロイする事が最優先ではないのは確かです。

私は割と実装や設計が速い方ではないと思います。過去の経験だと、研究者の大塚さんが開発した円形計器の読み取り処理を LiLz Gauge に組み込むタスクに3日ぐらい使っていた事がありました。

既に大部分の実装は終わってたので、コードを移植してテストするだけなら、1日で終わっていたと思います。意図してそうした訳ではないですが、処理内容を確認したり、リファクタリングしたり、実際のサンプルで計器の値を読んだりして3日が経過していたような感覚です。
このように仕様や問題を理解する時間を十分に確保して開発しているのは今も変わってないと思います。

また、コミュニケーションパスが短いというのもありますが、まだ開発チームの中で明示的にルールを定めた事は無いです。特別な事は何も無いので、ここでは取り上げないですが、チーム内にはコードの質やコミュニケーション方法などの開発者体験に関する共通認識は構築されていると思います。

開発チームのルーティンとしては、1日のタスクをslackで共有、それに加えて月1の開発者ミーティング、さらに半年に一度のCTOとの1on1ミーティングを行っています。1日のタスク共有では今日やること今困っている事を共有、月1のミーティングでは最近やっている事をより細かく共有、1on1では半年先までどのようなタスクが欲しいかなどを共有しています。

各メンバーがリモートで作業をしていますが、今の時点ではコミュニケーションで困っている事は無いです。強いて言えば私が英語を使えればもっともっとコミュニケーションがスムーズになるぐらいです。

さいごに

振り返ってみると、私が共同創業者として経験してきた事は、他の共同創業者の判断や振る舞いを最も近くで見てきた、LiLz Gaugeに立ち上げから関われていて、幸運な事に今でも開発を継続できているということです。ざっくりとした振り返りとはなりましたが、以上になります。

最後の最後になりますが、LiLzでは、LiLz Gaugeを更により良いサービスへと継続して開発していく為、仲間を募集しています。少しでも興味があれば、気軽にお声がけください！