そんな京都へ行くぐらいの気持ちで発足したのが、「timerr（タイマー）」というプロジェクトだった。

かなり長くなってしまったが、ウェブ制作会社を立ち上げてからtimerrをリリースするまでのストーリを綴ったので、良かったら読んでみていただきたい。

Web制作会社ができたぞ！

元々代表の小副川（私）は、フリーランスとしてウェブ制作に長年携わっていたが、
仕事も増えてきて、フリーになって5年目に法人化した。
その頃は「ウェブ制作会社を作ったぞ！」という事だけで、毎日やりがいがあったし楽しかった。

でも法人の運営はそんな簡単じゃない。
まして人を雇うとなると経営者の苦労というものは計り知れない。
最初に雇った社員には見事に裏切られたし、取っ組み合いの喧嘩になったこともある。
その後も人を入れたり離れて行ったり、経営者なら誰しも経験するであろう人の悩みを抱える事となった。

コロナで高まる危機感

ある程度売上も安定してきたころ、コロナという厄災が世界中を襲った。
アダプターも例に漏れず仕事が止まった。
そんな折、常日頃から抱えていた危機感が露呈してきた。

「今の単価では給料も上げられない・・フリーの価格帯だとやっていけない」

「このままウェブ制作を続けているだけでいいのだろうか？」

ウェブ制作事業はレッドオーシャンで、新規参入も多く、ググると「Web制作会社 オワコン」なんてサジェストまで出てくる始末だ。
実際のところ、自分には"技術力"という武器があると思って（根拠のない自信を糧に過信しまくって）いたけれど、戦略も無くとにかく我武者羅に頑張って、そうすると有難いことになぜかお仕事を滞ることなく頂けて、「なぜか何とかなっている」現状に甘んじている自分がいたのだと気付いた。

「差別化をしなければ」

「なにかに特化したサービスを生み出さなければ」

「・・終わってしまう！！」

そんな危機感が、もやもやと心を埋め尽くしていった。

差別化ってどうするんだっけ

ウェブ制作で差別化する方法はいくつかある。
例えば、業種に特化して「医療関係専門のウェブ制作会社」としたり「マッサージ・整体に特化したホームページ制作」と謳う方法だ。これはかなりやりやすい方法だろうと思う。
他には短納期を売りにしたり、無料でホームページを作れるサブスクモデルにする方法もある。

でもどれもしっくりこなかった。
上記のような差別化はすでに一般化しており、すでにどのエリアでも誰かがやっている方法で、
そこよりも強みの効いた良いサービスを作れそうになかった。No1になれるものが必要だと思った。

そんな状況でいいアイディアも出ないまま半年が過ぎた。

今まではやりたい仕事、稼ぎやすい仕事を念頭にアイディアを出してきたが、それでは行き着く回答がどれもありきたりなものばかりだった。そこで発想を転換して、ウェブ制作会社をやっていて一番やりたくない仕事を考えてみた。

保守運営ってやりたくないな

その中でホームページの運営保守は本当にやりたくないなと思った。
細々といろんな依頼が飛んできて、苦労の割に金額にして数千円〜数万円程度の売上にしかならない。
周りのウェブ制作会社でも、「保守をやめたい」という声はよく聞いていた。

数千円のために毎回見積書や請求書を作ったり、プロジェクトを振り返ってどういう仕様だったか確かめ、いったいどれだけの工数がかかっているのかもよく分からない。でも単価は上がらない。
そんな運営保守を積極的にやりたいウェブ制作会社など殆ど存在しないだろう。

根本的に運営保守の仕組みが変わらない限り、は。

そこでひらめいた。

本当に変えられないのか？方法はないのか？

もし今までの保守運用サービスを根本的に変えられるなら、
これ以上に差別化出来るものはない。でもどうやって？

やりたくない事をやりたい事に変えればいい

そうして、何となく「保守運用」が突破口になるような気がして、頭を使って考えてみた。

一体なぜ保守運用は面倒くさいのか？儲からないのか？
それは解決できないのか？解決できる方法があっても普及出来るのか？

創業時ぐらいにしか使っていなかった、ビジネスフレームワークをフル活用して考えた。

そこで現在の一般的な運営保守がどのような課題を抱えているかを洗い出してみると、以下のようなものが挙げられた。

• 簡単なテキスト更新でも営業経費がかかるため1万円以上になることがある
• 簡単な修正でも依頼・見積・決裁・作業・請求ととにかく時間がかかる
• 細々と依頼が飛んでくると管理ができない
• 月額契約している場合、対応範囲が曖昧で、作業しすぎると制作会社が損をし、作業しなさ過ぎるとお客様が損をするシーソー構造になっている（繁忙期・閑散期で利益が変動する）
• 営業マンが忙しいといつまで経っても作業が終わらない
• お客様の指示が分かりにくくコミュニケーションコストがかかる
• お客様からすると作業内容に対して見積の正当性が判断できない

一見すると構造上改善が不可能なように見える問題ばかりだが、まずは机上の空論でもいいからと解決できる方法を考えた。

アイディアができた！

そうして生まれたのが「Tickett（チケット）」というアイディアだった。
※ 実はTickettはtimerrの前身で、UIの殆どを受け継いでいる。

Tickettは、

• チケット制で1枚1000円のチケットを購入して頂く
• 毎月チケットが付与され、そのチケットを使って更新が出来る
• 作業ごとにチケット枚数が割り振られていて作業ごとに消化する
• チケットは付与から3ヶ月繰り越して使用することができる
• ホームページの画面キャプチャ内を選択して指示（作業）を追加できる（指示書ができる）
• 決済は管理画面から行える
• 作業担当者と依頼ごとにチャットで直接やり取りができる

というものだった。

チケット制にするというのはAdobe Stock等の素材サイトから着想を得たもので、作業担当者とチャットが出来る機能や、ウェブ上で指示書が作れる機能はMonjiやAun等の修正指示ツールなど様々なウェブサービスを研究して仕様を考えた。

プロトタイプを当時学生だったアルバイト君（今はコアメンバー）にとにかく出来るかどうかわからないけど作ってもらい、UIはコーポレートサイトしか作ったことがなかったデザイナーの女性に丸投げした。

プロトタイプのUIは今思えば本当にひどいものだったが、機能として会員登録やログイン等の基本的な要素と、チケットをStripeと連動させて決済するみたいな機能、さらに画面キャプチャからタスクを登録できる修正指示ツールみたいな機能と、超基本的な機能を、クライアントワークの傍らで、少しずつ探り探りで作っていった。

もういいおれがやる

プロジェクト開始から1年が過ぎて「何となく方向性としては合ってる・・のか？」ぐらいのものが出来てきたが、実際にサービスとしてリリースするには程遠い状態だった。
クライアントワークをやりながらでなかなか進みが悪かったのもあるが、一つ改善すると一つが破綻する、みたいな構造になってしまっていて、アイディアが歪んだ形で作られている事にモヤモヤしていた。

「これは人任せにしてはいけない・・」

そう思っていた頃、デザイナーの女性が会社を辞めた。

正直今まで作ってもらったものに対して細かくレビューを入れすぎないようにしていた。
入れだすと本当にキリが無くなってしまうからだ。
しかし、遊びじゃなくサービスとして本気でやるのであれば、ゼロイチで全て綿密に設計していく必要があったため、自らUI設計を行って作り直すことにした。2022年の夏頃である。

tickett（チケット）をちゃんとサービスにする

それから2ヶ月かけて新しいUIを作り上げた。今までバラバラだったパーツをコンポーネント化し、再利用しやすい設計にし、静的なコーディングまで自分で行って細かい動きなどにも徹底的にこだわってすでに出来ていたプロトタイプにデザインを組み込んでいった。

それから数ヶ月かけて細かいバリデーション等の実装を行い、何とかサービスとして動くものが出来た。

しかしここで問題がおきた。

「様々な作業に対して、チケットの枚数を定義するのに限界がある。」

テキストの修正やテーブルの修正など、その場所場所でそれぞれチケットを自動積算する仕組みになっていたのだが、見積を行わないと枚数がわからないような作業もたくさんある。そうなった場合都度見積対応を行うのか？その場合どういうUIになるのか？など複雑な問題が山積みだった。
サービスの根本を揺るがす問題の登場で、プロジェクトは一時中断となった。

別サービスとして既に動き出していたtimerr（タイマー）

そんな中Tickettとは別で動かしていたサービスがtimerr（タイマー）だった。

timerrは、

• 作業時間を購入して頂き、作業時間を作業者が使うことで消費する（スマホのギガのイメージ）
• 作業時間は作業者が開始時・終了時にタイマーを使ってカウント
• チケットと同じく毎月の繰越もできる

といったサービス内容となっており、既にこの仕組みで提案して実施しているクライアントが1社居たのでサービス化したものだった。

当初は「需要がある方を残そう」ぐらいの気持ちでtimerrとTickettの2サービスを同時運用するつもりだったが、2023年2月頃の定例会で「timerrとtickettを一緒にしたらだめなんですか？」という意見が出た。

正直自分の中に無いアイディアではなかったが、「現実的には無理そうだ」と思っていた。
チケットとタイマーではコンセプトが違うし、作業ごとに時間を正確に割り振れるわけも無い。
そもそも同じUI内で上手くまとめられる気が全くしなかった。

一方で現状お客様の居ないチケットにこれ以上の労力を割くのか、という経営上の問題もあった。
そうなると、残された選択肢は「チケットは廃止して、チケットのUIを使ってタイマーとして作り直す」しか無かった。

チケットを捨て、タイマーに

まず開発工数を圧迫していたのが、「チケットで指示書を作る」という機能だった。

かなり便利な機能でチケットのコアバリューともいうべき機能だったが、これを一切使わず、依頼を送信するだけの画面に変更した。さらにタイマーにするために管理者用の管理画面が必要だったので追加して、時間の計測が出来るようにした。

プラン設計も作り直し、全てを再度一から練り直した。

そうして半年かけて、チケットはタイマーに成った。

思いの外UIの大部分は活かすことが出来たし、ベースのコンセプトは似ていたのでチケットの概念を時間の概念に変更していく作業がメインで移行することができた。

2年かけたコンセプトを切り離して2つのサービスが一つになったものの、なぜかサービスとして本来それがあるべき姿だったように全てが丸く収まった。

2023年9月timerr（タイマー）のWebアプリをリリース

そしてついに我らの希望の船が出来上がった。

アプリになっていないtimerrは、既に需要があって何社か契約を頂いていたので、Webアプリ版のβリリース後はスムーズに乗り換えてもらった。

それから数カ月はバグ取りに次ぐバグ取りで、Githubのissuesが毎日5個は追加されてそれをエンジニア君がなんとか4個さばく、みたいな日々だったが、何とか新規のお客様もチラホラご契約いただける様になってきて、社内体制も出来てきた。

ここまで開発を行ってくれたエンジニア君と、開発原資となるクライアントワークを頑張ってくれたメンバーには本当に感謝しかない。

これからはどんどんサービスを売っていくフェーズに入るが、他社の保守サービスと比べると強みが明らかで、しかも開発にかなりの工数がかかるため模倣もしにくい唯一無二の最強サービスになったと思う。

これをしっかり売っていき、そのお金で更に良いサービスにしていきたいと思う。

さいごに

ここまで長々とこれまでを振り返ってストーリーを書いてみたが、私のサービスに対する想いは伝わっただろうか。

先ほども書いたがタイマーはこれからどんどん売っていくフェーズに入っていくため、営業マンやマーケターが必要だ。

このサービスはウェブ業界の保守運営を根本から変えるサービスになると思うから、一緒にこのサービスを広げていける仲間がほしい。

想いに共感してくれる人がいれば、ぜひ応募していただきたい。