持続的に開発するための考え方メモ #1

kunimasu
·

全体通してどんな持続的な開発をするべきなのか。

最低限考えることだいたいこんな感じ。ビジネスと開発、調達、顧客の目線で考えている。

  • これから作るものがどこにどういう影響範囲を与えるのか。

  • どう作れば最小のコストで目標を達成できるのか。

要は、作らないといけないもの、納品しないといけないものを、今後の関係性も考慮して作るということになるが、ドライに言うと、顧客が望まなければ、CI/CDのことは考えない。CI/CDに頼った作るになると却って困る顧客がいることも見てきた。ただ今後の開発が見込めるならビジネス的に負担のない範囲で極力後続の開発を意識した開発を心がける。自身に跳ね返る部分でもあるので。

開発途中で入るパターンだと、郷に入っては郷に従う精神を尊重する。スタイルがある程度確率されていてもどうしてもDIYの精神的に今後ここをケアしないとっていう部分はリファクタを行うが、スタートアップも中小零細企業レベルではそんなところにかまけている時間はないし、捻出しても大した評価にはならないと思われ。むしろ作ったけどリリースしない、リリースしたけど使わない、使ったけど売上に寄与しないといった様々な理由で、長期的に使うものばかりではなかったりする。マーケティングするために機能を作るということだけど、作る前にマーケティングってどの程度やったら作らずにすむのだろうか。ある程度意識はしたいところだけど、そこで止まってしまうなら1、2日レベルで作れる機能なら作ってしまうというところが多いのでは?と思うけど、みんなのところはどうなんだろ。結局作ったけど長期的にメンテしない機能なら、CI/CDに掛ける時間は確かにもったいない。売上に貢献してからやればいいと思う。

でも、こういうことをやっているとDIYは増えるし、よくない作りの部分を複製するにも抵抗がある。不具合の温床になり、後々自分自社に不利益として返ってくるのが少し見えたときにやり直したい気持ちもある。が、結局それも明日生き残れるかで命張っているスタートアップ直後ではやはりデリバリーを早めた方がいいのだろう。といってもエンジニア一人動かす費用を日5万程度と考えると1日5万払うほどのものかどうかは頭に入れた方が良いと思う。やはり人件費が圧倒的な費用になる。

リプレイスするといっても生き残らなければ出来ないわけで、生き残るかどうかの最中にリプレイスできる程の決断ができる人も多くはいないと思う。部分的にやっていくというのは推奨したい。が、それも出来なければ積み残っていくばかりで、生き残った暁にはフルリプレイスが英断できるかもしれない。

自分含め、個人開発、零細企業だとある程度作れると、1週目は開発、次の1週は営業・マーケ、更に次の1週は開発といったスタイルが自由に組めるので、合間にリファクタとか入れても良いかもしれない。だけどやっぱり組織でやっている以上難しいよね、そういう判断って。お金を生まない活動と捉えるか、開発体験向上と捉えるか、あまりにも開発体験が悪すぎて離職を防ぐ施策と捉えるか、トップに判断させるには難しい課題だと思う。

個人的なポイントは、今後の流動性を意識しながら、開発前に開発で必要なパターンを洗い出して試作しておく。クラウド系サービスをAPI的に使うなら、想定するデータを投入してパフォーマンスが出るのか?とか含めて。本開発が始まって出てくるパターン、漏れていたパターンは、後回しせず順次修正していく。大部分を作るまでにはそのパターンが確率されているはずなので、全体通してブレが少ないはず。という考え方でやっている。

自分の場合、案件をヒアリングしてから自分が見積作成するので、その時点でどう作るかがある程度確立していることが大きいかもしれない。自分で案件取って見積もりして開発するというスタイルだと物事を最初から最後まで見れるので効果を発揮しやすいが、分業されているのが大半だと思うと、結局は顧客との対話と社内のコミュニケーションで大きく左右される領域だと思う。

@kunimasu
しずかなインターネットのファンの一人。いまやっていること、おもっていることを筆ののるままに。