"ものづくり"を大切にし続けたい

techners株式会社 CEO じゃっきーです。僕たちは"ものづくり"を非常に大切にしながら、日々一歩ずつ前に進んでいます。

まだ組織の規模は小さく日々変化する内容が大きいものの、"ものづくり"に関しては比較的早い段階から根っことなるような価値観が強く形成されてきました。

今回はその"ものづくり"に対する価値観について触れながら、将来どこかで一緒に働く機会があるかもしれない方に向けて、僕たちなりの"ものづくり"文化を共有できればと思います。

誇れる"ものづくり"とは

僕たちは美容室向けSaaS KaruteKunのプロダクト開発を通じて、日々"ものづくり"を実践しています。

創業当初からプロダクト開発の経験そのものはあったのですが、0からプロダクト開発に取り組むことで、改めてものづくりのあり方を全て見直したといっても過言ではありません。

現在は"ものづくり"に対して誇りを持つにはこう進めたい！と考えが醸成されてきましたが、それに至るまでに直面した課題を3つ取り上げてみようと思います。

課題1：何を作るかコントロールできない

まだプロダクトが未熟で、あれもこれもやらないといけない、やりたいと感じていた時期のことです。

当時のユーザーヒアリングや、商談の過程で「XXXができるようになったら導入を検討したい」との声が多く挙げられていました。

その中でも事業インパクトが特に大きそうな声は、非常に魅力的に聞こえてきました。しかし、その声の中身は正直なところ「本当に必要なのか？」「それは課題解決につながっているのか？」と感じるものが多かったのも事実です。

そして何度かその声に負けて開発に進めたものの、想像いただける通り次に繋がることはありませんでした。残ったものは顧客の課題解決にはつながらなさそうな機能だけでした。

また、似たようなケースが社内から発生することもありました。外部からの資金調達を実施していなかったため、事業資金を稼ぐ必要があった僕たちは開発の優先順位を「要望が多く、売れそうな機能から順に」と設定していました。そしてこれもご想像の通り、事業に寄与することはありませんでした。

確かに握りが甘かっただけだったり、ユーザー調査が甘かっただけかもしれません。しかし、この経験を経て僕たちは「誰かの要望に応えた」という言い訳をやめました。

そして「顧客の真の課題を自らが考え、プロダクトの提供価値にこだわって開発しよう」こう考え直すようになりました。売れる気配は全くないが、現場を観察していたら間違いなく必要だと感じる内容は、優先的に取り組むようになりました。

結果的にはこのスタンスに切り替えてからプロダクトの評価も高くなり、事業成長も後からついてきました。

ものづくりに誇りを持つには「自分達でプロダクトの提供価値を決め、自分達で責任を持つこと」が重要だと理解するに至っています。

課題2：スケジュールに縛られすぎる

プロダクトを開発するにあたって、スケジュール通りに進めることは重要だと誰もが認めることでしょう。開発当初の僕たちもそう育っていましたし、疑うことは一切ありませんでした。

しかし、プロダクト開発は不確実性が十分に高いものです。大きな開発項目であればあるほど、その正確な仕様や完成時期を見積もることは大きな労力が必要です。

また、一度スケジュールが設定されると必達の如く見なされることも大きな負担でした。終盤に新たな発見があり、顧客にとってはより良い変更だとしても、追加開発は遅延を意味します。その遅延を避けるために数日踏ん張った開発が実施されますが、開発担当者の心身を共に疲弊させるものになっていました。

そもそも開発チームとしてコミットしたいのはスケジュールではなく、顧客への提供価値です。より良いものを提供することが、最大限チームとしてできることですが、これを妨げるスケジュールでは本末転倒でした。

現在はスケジュールに縛られすぎない体制にはなっています。あくまでも目安として設定し、優先すべきは顧客への提供価値との認識が揃っています。

これは締切が厳しくない、甘い環境だと言いたいわけではありません。自律的に動機付いているチームが、全力でプロダクト開発に取り組んでいる前提に立つとしたら、スケジュール厳守はデメリットの方が多かったと感じています。

課題3：分業体制をひく

プロダクト開発においては、分業体制を引いていることが一般的です。僕たちも一時期分業に取り組んだこともありました。

事前に整理された課題背景を共有し、非同期でも開発プロセスが進むようにバックログの管理を行ってみたことがあります。

しかしこのやり方には2つの課題がありました。1つ目はチームとしての一体感の欠如です。バックログに用意された課題を持っていくような進め方では、どうしても同じ方向に向かっている感覚が薄れてしまい社内作業者のようになってしまいました。

2つ目は細部の認識のズレが埋められなかったことで生じる、詰めの甘さでした。背景整理の稚拙さが原因だったかもしれませんが、どうしても非同期でのコミュニケーション前提では「なぜそれが必要か？」「何が根本課題なのか？」が伝わり切らないことが多々ありました。

これら経験から一見すると、それぞれが自分の仕事に集中して効率的に思える分業体制そのものに疑問を持つようになりました。それよりも、前提を揃えるためのコミュニケーションの時間を多く取り、チームとして前に進むことの重要性を学んできました。

全員参加型のプロダクト開発

上記で挙げてきた課題に直面し試行錯誤してきた中で、現在は極力チームを分断させず各プロセスを全員参加で実施するようになりました。

一例を挙げると、プロダクト開発の起点となる「今取り組みたい課題は何か？」のディスカッションには全職種参加が必須となります。

プロダクト開発でちらほらと見かけるような「上流の課題設定ディスカッションは事業側とプロダクトマネージャーで議論する」といった形は志向していません。

ビジネスサイドの視点だけではなく、プロダクト開発を担っているエンジニアやデザイナー、そして顧客接点を持っているCS担当者も参加して活発な議論をおこなっています。

「自社が目指している大きな方向性」と「これまでの取り組み内容」「現在抱えている課題一覧」等を整理しながら、これから取り組んでいくテーマを各人の視点から話し合います。時には技術的な負債の返却も取り上げてチーム全体で議論します。

これはプロダクト開発はチームで一丸となって取り組み、チームとして責任を担っていきたいと考えているからです。チームとして責任を担うためには、各参加者には必要な情報は共有されるべきですし、個々人がその責任を負う内容に対して納得感を持っている必要があると考えています。

提供価値にこだわる

全員参加型でプロダクト開発を進めていくと、リリースが近づいている後工程に近い段階でも、仕様そのものへの再検討や議論が発生し続けます。

当初議論していた段階ではこれでいこう！となった内容でも、実装を進めていく中で担当者が違和感を感じ、改めて設定された課題に立ち戻ることでより良い仕様に改善されることも多々あります。

繰り返しになりますが、大事なのは「何を作るか」ではなく「なぜそれを作るのか」です。チームがコミットしているのは、仕様でも期日でもなくお客様に対しての提供価値です。

「仕様通り作られているか」ではなく「設定した課題を解決できる最良の方法になっているのか」にこだわりたいです。

そのため「〜さんがそう決めたから」といった話は当然にありませんし、「どうして今になって気づくんだ！」といった話もありません。むしろ「出す前に良い方法に気づけてよかった〜」と歓迎した形で受け入れられています。

これも個々人が最初から議論に参加し、チームとして責任を負う体制になっているからだと感じています。

誇れる"ものづくり"で勝ち取る尊敬と信頼

"ものづくり"を支えるのは、結局のところ会社の価値観であり文化だと思います。各社それぞれに価値観がありますし、どれも否定されるものではありません。

今回の内容も、あくまで僕たちが良いと考えているひとつのあり方です。僕たちは提供価値にこだわり、チームで前に進むことで誇れるものづくりが実現できると信じています。

ものづくりにおいては、白黒はっきりすることはそうありません。不確実な中でどのように進みたいか、といつも恐る恐る前に進んでいるようなものです。

だからこそ、自分たちのものづくりに誇りを持つことは非常に重要だと思います。誇りがなければ、生み出すものの細部にこだわりを持てなくなるかもしれませんし、作業者として立ち振る舞うことで誰かに責任を投げてしまうかもしれません。

誇りを持ったものづくりには責任が伴います。そしてその責任を果たし続けることで、お客様からや他のチームメンバー、経営からも尊敬と信頼を勝ち取ることになります。

そして、尊敬と信頼を勝ち取ることで、より大きな期待がものづくりチームにかけられ、結果的により広範囲での裁量と挑戦の機会が生まれると考えています。

technersではものづくりを今後も大切にしていきたいからこそ、その責任を十分に果たせるチームでありたいと願っています。

この内容も未来の仲間になるかもしれないあなたに、どこか響くところがあればとても嬉しいです…!

もう少し掘り下げた話を聞いてみたいな…と感じられた方は、ご遠慮なくじゃっきーのtwitterまでDMください！大歓迎です！