開発工数を減らす技術

こんにちは！まずは副業から働いてみることができるサービス「workhop」をやっているkmagaiといいます。

ぼくはスタートアップのエンジニアとして3年働き、ここ2年は数人の会社で自社開発をしながらクライアントワークもするという生活をしています。

普通に働くとリソースが足りないという環境にずっといるので「どうすれば開発工数を下げられるのか」ということについて、日頃よく考えています。わりと当たり前のものも多いかもしれませんが、思いついたものをいくつか書き残しておこうと思います。

スマホ版レイアウトだけを作る

当たり前ですが、開発工数を減らすには「作るものを減らす」ということが大事になります。

そして作るものを減らすためにできる、最も単純な方法は「PC用のレイアウトを作らず、スマホ版のみを作る」と、してしまうことです。

というのも、ほとんどのC向けサービスの場合、よく使用されるデバイスはPCではなく、スマートフォンだからです。

さらに、スマホ版のUIから作ることで、PC版はそれを適度に引き伸ばしたもので代用することができます。漫画サイトのアルさんなんかも、そうなっていると思うのですが、意外と違和感がないです。

また、後々PC版をつくるにしても、PC版を作ってからスマホ版をつくるよりも、スマホ版から作ったほうが、比較的作り易いはずです。
というのも、スマホのUIは、画面の狭さが制約として働き、自然に表示の優先順位が整理されるからです。

こうすることで、UIデザイン・実装の工数が単純計算で1/2になります。
まあ実際は、似ている画面を作るので、そこまでは削れないのですが。

ABテストも1つのデバイスだけでOK

似た話でいうと、ABテストもすべてのデバイスで行う必要があることは少ないです。

デバイスごとに正確な結果を出したい、あるいはデータをより多く集めて結果を早く出したい場合はこの限りではありませんが、、ほとんどの場合、どのデバイスでもユーザーの行動は似たり寄ったりになるはずです。

そのため1つのデバイスでABテスト行い、結果は全体に適用するようにしても、問題のないケースは多いのではないでしょうか。

デザインを仕様書にする

ここ数年は、仕様書らしい仕様書は書かない文化の組織にいます。
それでも、今の所はとてもうまく回っているように思います。
むしろ、これによってコミュニケーションが円滑になり、工数は大きく減っていると感じます。

では「代わりにどうしているか？」というと、基本的にはデザインを仕様にしています。
つまり、詳細な項目・振る舞いのみを仕様として記述し、デザインを見て分かるものについては省略してしまうという塩梅です。

実はこれには良い副作用もあります。
デザインがよく出来ていれば、ユーザーにはもちろん、開発者にも「あのボタンを押したときに何が起こるか」などは自明になる、ということです。直感的に分からないのであれば仕様かデザインが悪い、というフィードバックとしても機能してくれます。

具体的な方法論としては、弊社ではNotionを使い、デザインをFigmaのURL埋め込みをした上で、仕様を追記するという形を取っています。
こんな感じですね。

もちろん開発メンバー全員に一定のプロダクトスキルが求められるため、すべての組織に合うものでは無いとは思います。
しかし、もしうまく機能させることができれば、コミュニケーションコストを大きく減らすことができます。

ちょっとしたページはNotionで作成する

FAQ、β版のサービスのランディングページ、コーポレートサイトなど、ちょっとしたページはNotionで作ると管理がとても楽になります。
workhopではFAQなんかはNotionで作成しています。

「それくらい自分で作ればいいじゃん」と思うかもしれませんが、これらは案外実装コストが高くつくものです。実装自体に時間がかかるというよりも、ビジネス都合での修正依頼が多発することにより、リリース後のコミュニケーションに工数がかかるという印象です。

それがNotionであれば、気付いたときに気付いた人がパパッと変更できてしまいます。

メインのシステムから切り離して作ることができる部分に関しては、とりあえずNotionで作ってみる、というのを検討してみても良いかもしれません。

データ入力はGoogle Spreadsheetで

これはおそらくみんなよくやるやつかと思います。

入力フォームを作るのは、意外としんどいです。
しんどいだけでなく、最初の頃は入力項目が定まらないことも多く、そのたびに変更を入れるとじわじわ工数が増えていきます。

最初のうちはSpreadsheetにしておけば、ほとんどの追加は1行足すだけで事足ります。誰でも編集作業ができて、履歴も残るので安心です。

未知と厄介はオペレーションで捌く

奥の手ですね。オペレーションで捌くことが有用になるパターンは大きく分けて2つあります。

1つ目は、未知なときです。
ユーザーがどんな反応や行動をするのかわからない、未知な領域に対しては、作り込みすぎた実装が逆に仇になることがあります。
そのため最初は「どんなことがあり得るのか」を理解するために、システムの代わりにオペレーションで捌くようにします。
その後、ユーザーの振る舞いを理解してから、徐々にシステム化を進めるという手順です。

2つ目は実装が厄介なときです。
厄介な割に発生頻度が低いものに関しては、特に当てはまります。
この場合も、当面はオペレーションで捌き、ボリュームが増えて実装が割に合うようになったタイミングで、システム化するのが良いでしょう。

その際のコツとしては、完全にオペレーションに丸投げすると怒られてしまうので、Slack通知で「半自動化」ぐらいは行っておくと良いかもしれません。
オペレーションが必要な事象が発生した際に、オペレーション対象へのリンクや、そのチェックリストのリンクを付けて、Slackに通知を投げるといった感じです。

また、複数人が同じオペレーションを行ってしまわないようにするための対策もしておくと良いかもしれません。
誰かがSlackのオペレーションリンクを開いたら、リアクション絵文字が付くように実装しておく、などが考えられます。

最後に

と、書いてみると当たり前なものも多い気がしてきましたが、どうなんでしょう？
こういうノウハウは、個人や組織で持っている人は持っている気もするので、ネタを持っている人はぜひ読みたいので書いてみてほしいです！