テックタッチと出会って3年経ったので現在の面白みを書きました

エンジニアの misu です。写真は日光サウナリゾートです。サウナ → 湖(水風呂) → ウッドデッキでのんびりしたのは最高でした。今回は、テックタッチと出会って 3 年が経ったので、テックタッチでの仕事の中で特に面白みを感じているソフトウェア設計について書こうと思います。少しでもテックタッチで働くイメージの共有ができたら幸いです。

私がソフトウェア設計に対して感じる面白みと難しさ

私のソフトウェア設計のイメージはこのようなものです。

あるユーザーニーズによって実現した機能を進化させたいときに、指針に沿えば実現できるようになっている状態。一定未来を見通してみて、ソフトウェアの柔軟性を確保する作業と言えるかもしれません。

なぜソフトウェア設計が面白いのか、それは一言で言えば難しいからです。難しいからこそ、設計を実現してうまく運用できたときに達成感があります。運用と書きましたが、設計は、実装と違って実現時点では成果がわかりません。設計し、実装したものを顧客が使って「一度実装したものをさらに進化させたい」となった時に真価が問われます。私は、この進化させたい時に、下記のような状況だと設計はうまくいっていないのではと考えています。

【1】既存のしくみを大きく変えないといけない

一定、未来のことを見通して機能を実現しているので、何か次の関連したユーザーニーズがあったときにもは、ある程度柔軟に対応できるはずです。もちろんすべてを予測するのは不可能なので起こりえますが、そのニーズが予め予想できたものかどうかは振り返って次に活かすのがよいと思っています。私の経験では、「えいや」で実装してしまったものほど後の変更がやりづらく、実装前に設計検討を詰めればよかったと後悔しがちです。

【2】実現のためにどう次の設計をすればよいかわからない

これは、既存実装の設計ルールが明確になっていない場合に起こります。指針がないので関連しそうな領域を包括的にしらべ、適切な設計をしていかなければなりません。たとえば、設計文書が残っていない、属人化してしまっているようなケースが考えられます。

テックタッチでソフトウェア開発に関わることの面白さ

上記の2点のような問題に対し、テックタッチでは、機能の仕様レビューが実装前に存在するのでこういった問題は発生しづらくなっています。

機能の仕様レビューとは、「プロダクトオーナーが実現したい機能をこう実現する」という文書をチームで決定する仕組みです。ここで話し合って、見通しがついたら実装フェーズに移ります。文書は Notion にストックされていきます。

また、技術的な詳細設計は知見のあるエンジニアで集まってレビューし、意思決定の履歴を残すような取り組みをしています。この文書では、具体的な実装に絡めた設計のトレードオフを示し、よりよい決定ができないか、あるいは提案された案で進めていくのか、ということを決めます。こうすることで、新しく入社された方が今の設計に至るまでのコンテキストや今後の展望、スムーズに議論に入り込めるようになると考えられます。

ここまでで、テックタッチでのソフトウェア設計のイメージが多少共有できたかと思います。このほかに設計の材料として、CSM(ユーザーと伴奏しテックタッチ運用をサポートする役割を持つ担当）と仕様の話をしています。社内の様々な人と話しながら色々なケースを考えて機能を作っていくのは、非常にやりがいがあると思っています。そして、実現したものを設計に沿って進化させ、素早くユーザーに届けることができたらプロダクトとして強いですよね。私は、正直テックタッチで仕事をする前はユーザーニーズを点で素早く解決することばかりに頭が向いていて、「点と点がどうつながりそうか」はそこまで考えられていませんでした。過去の仕事は受託案件の開発がメインで、納品後に機能要望が少なかったから気づけなかったのかと思います。テックタッチではそんなことはありません。テックタッチの開発に日々関わるなかで、機能要望や実現したいことはたくさんあります。機能のリリース前だけでなく、リリースした後にも、 CSM からこんな要望があるという声が続々届きます。そういったものに早く、安全に応えられるようにどうなるか、どうなっていくかを話し合って機能設計を行うようになりました。

プロダクト開発をやってきた方々には当たり前かも知れませんが、これが私がテックタッチで働いてきて一番面白みを感じている部分になります。

テックタッチでは、進化に素早く追従できる強いプロダクトを作るために、設計から運用までエンジニアが主役です。しかし、人がまだまだ足りていません。一緒に設計から楽しく、大きなものを作っていける方を待っています！