読者です 読者をやめる 読者になる 読者になる

Viibar Freaks

株式会社Viibarのブログです。Viibarを色々な角度からご紹介していきます!

Viibarの開発において大切にしていること

エンジニア

f:id:Viibar:20160803102050j:plain

こんにちは、Viibarエンジニアのgaoohです。好きなgemはpunditです!

Viibarではリードエンジニアとして開発全体の設計だったり、効率化だったりを担当しています。今回はViibarの開発においてエンジニアとして大切にしている3つのことを書きたいと思います。

 

目先の問題より、解決すべき本質の課題を解決しよう

 

まだまだ成長過程のプロダクトにおいて改善したい点、追加したい機能、社内からの要望、エンジニアとして直しておきたいコード、みたいなものはきりがありません。

Viibarではプロジェクト管理としてJIRAをつかっているため、そこに基本的に蓄積されていくのですが、リソースの問題だったり、調整の兼ね合いだったりで思うように消化できないのも事実です。

 

そうなると焦りから短期的な絆創膏をあてる処理だったり、修正後の反応が近い社内からの要望を先にやろうとしてしまう重力に引っ張られがちです。それ自体は問題ではないのですが、そればかりやっていると本質の問題がいつになっても解決しない状態に陥りがちです。

 

特に問題なのはこういうタスクは「仕事してる感」を味わいやすいという点です。

もちろんスピードや今解決するべきことを適切に天秤にかけ、そういうタスクをやることも、重要です。

 

ただ本質の課題を見失わないことを重要視しています。

そのためにできることは非常に地味ですが、以下のことを心がけるようにしています。

・issueにゴールを書く

・機能要望は「困っていることは何なのか?」「なんのために必要なのか?」をきちんとヒアリングする

もちろん心がけるだけでは限界があります。

 

そのため、Viibarではスクラムで開発を回しているので、毎週やっているスプリントプランニングにおいて、必要な理由が不明確だったりゴールがよくわからないものは、差戻すようにしたりとか、エンジニアが作業をすすめるうちにゴールとそれたタスクになっていたら、見直すこともしています。

最近ではこのマインドをさらに広げるために、社内に修正した内容を共有する際に、なぜ変更したかを共有するようにしました。

地味ですが、そういう日々の運用が大事かなと思ってます

 

 

開発効率化やプロダクティビティに関わることは熱量重視

 

日常のタスクをこなしながらこれらのタスクの優先順位を上げるのはなかなか厳しいです。

ViibarのサービスはRailsをつかっており、Railsのバージョンアップなどきちんとスケジューリングして行うべきものもあります。これらはリソースと相談しながらきちんと計画して進めるようにしてます。

 

一方開発効率化のgemの導入やちょっとしたリファクタリングなどはタスク化して、プランニングしても、優先順位はあげられないので、ずっと放置されたままになりがちです。

 

具体的には 「READMEの情報古いな、これ更新したい」とか「この設定ファイルぐちゃぐちゃしてるから整理したいな」とか「このgemもう使ってないから削除したい」みたいな、やったとしても1時間もかからない粒度のものですね。

 

これらはものによってはissueにまとめるより、PRを作って、コード見ながら話したほうが早い場合も多いでしょう。

 

個人的には、特にそういう小さなタスクはカッとなったときにやるのが一番片付けやすく、見積もった頃には本人の熱量が覚めている場合が多いです。

 

Viibarはそういうタスクは見積もりを必須とせずカッとなったらだせるようなルールにしています。ルールといっても `spark/#{description}` というブランチ名でPRを出すだけです。

 

必要性に関してはそのPR内で変更をみながら議論しましょうという方針です。

 

全員のタスク管理の観点からいえば、そういうタスクも全てissue化をしてプランニングで見積もるのがいいという判断もあるでしょう。ただやはり熱量も大事ですし、そういうタスクは「チーム全体で」というスクラムのルールで割り振ろうとしても、やはり課題感を感じている当人がやる方が良い場合も多いので、あえてルールにしています。

 

変化を楽しもう

ベンチャーはときに方向性が変わったり、プロダクトとして求められることも変わる場面があります。それにより、つける機能もあれば、削ると判断することもあるでしょう。

 

場合によっては新規プロジェクトごとやっぱりやめようという場面も珍しくないでしょう。

 

エンジニアとして自分が作った機能がつかわれなかったり、最終的に削ることになるのはいい気持ちにはならない人もいます。でもそれも本質の課題を解決できないのであれば「この方法ではなかった」と学んだ上で違う可能性を考えらるようになるので、ネガティブに捉えないようにしています。

 

もちろんそうならないように、小さく始めるとか、作る前にヒアリングするとか、検証期間を設けるとか、やれることはやった上でです。

 

Viibarの開発においては、そうやって今は使わなくなった機能の削除やコードの整理は積極的に行うようにしています。

 

そういう作業をしても、機能が増えるわけではないので、優先度を上げないという選択肢もあるとは思いますが、古いコードは「そこはレガシーな書き方だから真似しないで!」みたいなことも多いですし、「放置してたら、事情を知っている人がいなくなってしまったので、すごい消しにくい!」みたいなことにもなりがちなので、バランスを持って作業しています。

 

以上です。

 

Viibarではこんなことに共感してくれるエンジニアを絶賛募集中です!