インターラプト開発者ブログ

インターラプトのプロダクト・サービスに関する開発ブログ

受託開発会社になるということ

起業する前は、新規事業開発に携わることが多く、ゼロから設計してプロダクト開発していくことが多くありました。ディレクターがいない場合も多かったので、エンジニアで会議室設計やアサイン、ヒヤリングも行ってきました。

だから受託開発で開発するという経験がなく、いきなり起業して新規事業という道しかないようにも思いました。しかしそれでもそこは一旦は目指さず、受託会社として会社を成り立たせることを目指すことに。

自社開発はあこがれますが、様々な会社との付き合いあってこそだと思い、集客をはじめたものの、なかなかうまく行かない。価格とスピードで勝負するものの、それでも負けることが多かった。ありがたいことに技術力に関しては受注頂いてから分かっていただけることが多いですが、公開している比較材料や実績が乏しいことで選ばれずらいことに気づきました。

受託開発こそプロダクトが重要

恥ずかしながら受託開発のことをよく調べていなかったのですが、殆どの会社が売りとなる商品設計を行なっていることを知りました。プロダクトであり、ソリューションであり、どのような価値提供をしているのかをわかりやすい資料やLPでまとめているのです。

それはまさに新規事業開発でした。自社開発も受託開発でも本質的にはプロダクトを持って売っていたのです。受託系でも、元あるプロダクトを自社設計にしたり、OEM提供するという売り方があります。 ですが、動くプロダクトがあるということ自体が、技術力の証明であることに他ならないのだと思いました。

スタートアップ界隈では、プロダクトアウトという言葉をよく聞きます。プロダクトアウトよりマーケットインというのがあり、プロダクトアウトで商品設計してしまうと、独りよがり、ユーザーを無視した設計となってしまいマーケットインが難しくなるというところからしているのだとおもいますが、私もそれに同意していました。

しかし、実際は見たことない会社名の会社がマーケットに参入するためには認められ、名前を覚えてもらうことが入り口でした。協賛企業や出資元企業に大手が入っているわけでもなく、マーケットへの参加など元からできないのです。認められるには、認められるに足りるプロダクトが必要でした。

受託開発会社から自社開発会社へ

これからの話になります。受託開発をやめるわけではないですが、まず会社として自社開発の商品を持つことを目指すことにしました。そして代理店販売を行う会社も目指します。

技術力を証明するには自社開発が必要。それが決してマーケットインしなくてもよくて、「こういうのが作れるんだ」と認めてもらえることが、まずは目指すべきところなのかなと思いました。

UIデザインが出来る様になった瞬間

いきなりですが、小さい頃から授業中にUIデザインをするような子供でした。紙とペンさえあれば、UIデザインは出来ました。

当時は、HSPというプログラミング言語でプログラミングをしていたため、ボタンUIはbuttonという関数で、テキストエリアはinputという関数でした。

関数でそのままUIデザインができてしまう世界に初めから突入していたため、これがボタンでこれがテキストエリアでと紙状に配置して、家に帰ってからコードに書き起こします。

しかし結局はただのWindowsの灰色のボタンだったのでまだUIデザインと言えるようなものではなかったです。

もちろん考えたのはオリジナルのボタンを作りたいと思うようになったこと。CSSのような便利なものはなく、ゼロからボタンを作りしか方法がなかったのでマウスのxy座標を取得して当たり判定ロジックを作りなんとかボタンを作り、オリジナルのボタンを作りました。

当時はグラデーションを多用するようなデザインが多かったですね。しかも全部ボタン。ボタンに命をかけていました。

ここまでやっても、ただボタンが大量に並んでいるだけであまりUIデザインとは呼べませんでした。

そこから数年が経ち、あるプロジェクトでフロントエンドのコードを書くようになり、そこからHTMLやCSS、そしてjQueryによる動的なUIの書き換えを行うようになり、よりシステム開発に近いフロントエンドの開発を行うようになり、UIデザインを意識するようになりました!

それでも、まだ個人的に納得のいくUIデザインというものにはたどり着けませんでした。何をどうしたらUIデザインができるのだろうか、フロントエンドエンジニアはただワイヤーやモックアップをコードに起こすだけなのか、機能的なデザインや、UI/UXなど、まだ個人的に納得のいくレベルにたどり着けなかった。

Sketchを初めて触った日

SketchというUIデザイン様のアプリが登場し、PhotoShopより楽だくらいの理由で触り始めました。そこでまず驚いた機能が、今は「components」と呼ばれている「Symbol」という機能でした。よく使うボタンなどのデザインをSymbol化すると、そのSymbolから新しいオブジェクトを生成し使うことができる機能で、コピペとは違いSymbol時代を編集すればそのSymbolが使われているオブジェクトのデザインは全て書き変わるというものでした。

このSymbol機能を使い、アプリの中でよく使うSymbolをたくさん作り、ボタンやテキストエリアなどを自分好みのデザインにして作り込んでいきました。このSymbolのUIのまとまりを「ui component system」と呼ぶようです。

一度作ったこのセットを用いて一つ一つのアプリのページを作成すると、アプリの全体的な雰囲気が揃い、ちょっとUIデザインをしたように感じてきました。 そういえば、Twitter bootstrapも、UI componentだったなと気づいたりしましたね。

UIデザインが出来るようになった瞬間

UIコンポーネントを使いはじめてしばらくすると、Bootstrap使ってるねというのが一発でバレたり そのアプリやサイトの趣旨とは合っていないような雰囲気に気づくことが多くなりました。

しかしこれは、Bootstrapを使っているからという理由から来ているものではなかったのです。Bootstrapを使っていても、UIがスッキリしていてお洒落なサイトはあったので、そもそもここの境目の何かが違うことに少しずつ気づいてきました。

試行錯誤を重ね何度もUIデザインを重ねてここでようやく「余白の扱い方」に気づきました。気づくのが遅かったですね💦

余白にはルールがあり、といってもルールは自由に決めていいです。15pxにするとか、画像の周りは20pxあけるとか、段落の下は30pxあけるとか、各セクションは15pxあけておくなどです。シンプルナイトでも余白の幅は規則性があります。計算してみると面白いです。同様に、フォントなどの大きさにもルールを作ります。ジャンプ率と呼ばれているものですね。色にもルールを、なぜこの色なのか、なぜ、この余白の幅なのか、すべてに理由をつけて縛ります。意味を持たせます。別に訪問者に意味を語る必要はないんですが、そうやって特に余白という無色透明なコンテンツこそ、ルールや意味をつけてあげることが、UIデザインが出来るようになった瞬間でした。

もっとたくさんのルールや色の組み合わせ、トンマナ、ロゴにあう画像を使うなどデザインとしての手法はもっとたくさんありますが、UIデザインにおいては、UIコンポートと余白の扱いの二つを気をつけることで大きく変わるので、ぜひ試してみてください。

オウンドメディアどこで始める?って話。

最近オウンドメディアをどうしようかと悩んでいます。noteはプラットフォームだから資産にならないよなどという話もあるけど、集客できなきゃな〜〜って思います汗

それでnoteはじめてみたんだけど、記事の書きやすさって大事だなって別な視点で気づきました。今は電車で書いてるんですが、いつでもどこでも最新の情報を届けられる手軽さも良いなと思いました。

小さな会社ですので、専属でオウンドメディアのライターを雇ったり、記事を外注するのもなかなかできないので、電車などで書くのが非常に大事だなと思ったわけですね。

noteのアプリはカクヨムみたいで大変かくやすくてめっちゃいいですね。オウンドメディアはスマホアプリがあってかきやすいものが良いねというおはなしでした。

追記

そして、はてなブログに引っ越しすることにしました。 スマホアプリが快適でかなり使いやすいところが気に入ってます。

一日一記事書いてみる

代表の髙橋です。 弊社は主な業務としてWebシステム開発を業務としている会社です。また、マーケティングのスキルを活かして集客力のあるWebシステムを作るところを強みとしています。

しかし、問題がありWebシステム開発が忙しくなかなか自社のWebマーケティングが出来ない状態が続いています。このままではマズイ・・と思い。

とりあえず続けることが大事とnoteをはじめてみました。マガジンもいくつか作ったので、時間があるときに更新していこうと思います。

タイムトラッキングでノルマを管理する方法

代表の高橋です。 最近は個人的に多忙な毎日の時間管理を全て管理したいと思い、業務関係はToggl、業務も含めそれ以外の時間管理をHoursというアプリを使って管理しています。

フルトラッキングはHoursを使っているのですが、これにはAPIがないためサードパーティツールを使って時間の計算が出来ません。スクレイピングCSVをダウンロードすればできなくはないでしょうが、出来ればAPIを使いたいものです。

Togglだと、なんと無料プランでもAPIが使えるので業務時間だけでも自動集計し、ノルマ管理を出来る様に実装してみました。

ノルマ管理で使用するTogglの3つのAPI

TogglのAPIには、開始日と終了日を指定してその期間の記録と、今稼働中の時間を取得と、プロジェクト一覧APIがあります。

これで、下記のような数値がわかります。

  • 今月の稼働時間
  • 今日の稼働時間
  • 昨日の稼働時間
  • それぞれのプロジェクト毎の稼働時間

ノルマを設定する

ノルマは目標稼働時間で設定します。 一ヶ月は必ずこの稼働時間を確保したい時間を設定します。 これはプロジェクト毎に設定しても良いですが、合算値のほうが日々のノルマを追いやすいです。

ノルマを計算する

ノルマの計算方法は、下記のようにします。 * 月の残りの稼働時間 = 月の目標稼働時間 - 月の実稼働時間 * 月の残り時間 = 月の最終日 23:59:59:999 - 現時間 * 1日のノルマ時間 = ( 月の残りの稼働時間 / 月の残り時間 ) * 24

これで、1日に必要な稼働時間を計算することができます。プロジェクトによっては通常よりも稼働が必要になる場合があったりと、時間配分のバランスや、事務作業に割くことができる時間の計算も必要になっていますが、これで可処分時間をリアルタイムに把握することが可能になります。

Botでリアルタイムに計算したノルマ時間を通知する

計算した時間は、

  • 1日の稼働ノルマ時間
  • 1日の実稼働時間
  • 1日の差分時間
  • ノルマ達成かどうか
  • 前日のノルマレポート

を用意します。 計算結果は定期的にLINEなどに通知すると便利です。

f:id:interrupt_inc:20201214121438j:plain

画像はノルマ時間だけですが、このようにお好きなプラットフォームに自動送信すると便利です。

実際にTogglから数値を取得する

開発言語はRustを採用しました。 Rustのライブラリでtoggle-rsがあったのでこちらを利用しました。

cargo.tomlからは直接組み込めないようで、ダウンロードして利用しました。この時に作業中の時間の取得するメソッドにバグがあるようで、ライブラリ本体に一部修正を行いました。 データの取得は下記のようにしました。

期間を決めてその範囲の記録を取得する

let entries = toggl.get_time_entries_range(Some(start_time), Some(yesterday_end_time))

稼働中の記録を取得する

let running_entry = toggl.get_running_entry();

稼働中のデータもリアルタイムに取得できるのが便利です。 これによって、稼働中でもノルマ時間が増えていかず、リアルタイムに現状の状態を把握することができます。

リモートワークに便利?

働く時間に場所でなくワークライフバランスを重視して時間も自由になっている会社も多くなっていると思います。 「今日あんまりできなかったけど、明日取り返す」といったことも、増えてくるかもしれません。そういった場合に、こういったリアルタイムにノルマを管理できるものがあると全体の管理がシームレスになって来るのかなと思います。

動いているものを使ってみたい!

現在トライアルでノルマ管理bot「QuaTime」のモニターを募集しています(規模問わず) 無料で使えますのでご連絡ください。

■QuaTimeって?

月間の時間または売上目標または目標ポイントを決めてその数値を満たせるように進捗を毎日教えてくれるbotです。

■どう使うの? Togglでタイムトラッキングするだけ、あとはLINEやSlackなどでbotが「今日のノルマは5時間です。今日は3時間やりました。残りは2時間です。」と教えてくれます。

■毎日やらないとどうなるの? 毎日のノルマ時間が増えていきます。サボるほど、月の後半が辛くなっていきます。

■どんな人におすすめ? 昼夜逆転で時間リズムがすぐに狂う人、寝過ぎてる人、何かを成し遂げたい人、サボりがちな人、三日坊主な人、最初遊んであとから始めようとしてどこまでやればいいのか覚えてない人、お金を稼ぎたい人、勉強時間を確保したい人におすすめです。

お試しください。

コロナ禍と同時に起業した話

代表の高橋です。 色々と落ち着いてようやく会社ブログを書けるようになりました。 このブログでは初めての記事になります。

これまで個人でブログやQiitaでたくさんの記事を書いて来ましたが、このブログに集約していきたいと思います。

実ははてなブログなんです。

2008年ごろからはてなダイアリーで記事を書いてまして、その頃からはてなブログのユーザーでした。さまざまな記事を書いて、たまにバズったりすることもありました。

その時の経験から使い勝手に慣れていることもあり、ちょうど法人プランがでたことで使うことを決意。既にはてなのオウンドメディアというプランはありましたが、純粋な法人向けはてなブログとは違うらしく、要望で法人向けはてなブログをお手頃な価格帯で出して欲しいと思っていました。

それからたった数ヶ月後、なんとはてなは法人プランを出して来たのです!しかもサブディレクトリプランといって、サブドメインはてなブログを運用できるプランまであることを知りました。そして、執筆段階では、契約手続きが進んでいるところです。

この記事はiOSはてなブログアプリから書いているんですが、文字数もちょうどいいですし、クラッシュして落ちて書いた内容が消えることもないので、かなり良いです。ブラウザのようにエディタが拡大縮小することもないですからね。この体験が、2020年になり法人として、またできるようになったことは嬉しいことでした。

会社を立ち上げたきっかけ。

実はコロナ禍が来てから起業したのではなく、そのほんの数ヶ月前の事でした。

元々は「自分のプロダクトが欲しい」という思いがあって、いつかは自分のプロダクトとして成長を共にできるようなものを生み出し、もしくは出会いたかったと思っていました。しかし、それはなかなか叶うものではありません。

そもそもプロダクトの成功が難しいですし、時間がかかります。少しずつの積み重ねがプロダクトと、そして会社を大きくしていきます。しかし、いつかは終わりが来るというもので自分の意思とは関係なく終わってしまうことが多々ありました。

会社なので、それは当然ではあるのですがこれではいつまで経っても自分のプロダクトにで会うことは難しいと感じました。終わらせない、伸ばしたい、それには会社で一番偉い人になり、そのプロダクトの意思決定を全て握ることだと気づき、起業となりました。

そしてそのとき、ネット上にはたくさんの仲間が出来ていた。昔は学生同士でも、今ではビジネスパートナー。インターネットだって学校での出会いのように将来の繋がりへと昇華していくタイミングが到来していました。

会社をはじめて

会社を維持するには、まずお金が必要でした。今ではありがたいことにいくつかお仕事を頂き、会社を維持できておりますが、最初はかなりギリギリでした。もろもろの事務作業が莫大に残っていて、会社を維持しつつも、売り上げの発生しない煩雑とした作業をこなしていました。労働時間の計算、事務に避ける時間のコントロールがなかなかうまくいかず、エクセルシートに時間管理を行いバーンダウンチャートを書いて毎回確認していました。

誰かに聞いた「社長は手動かせなくなるよ」というのは本当でした。売上の発生する仕事の何%が、申請用紙や議事録を書くことに変えたのでしょうか。多い月だと50%はあったんじゃないかなと思います。

コロナがやってきた

退職日の12月、退職日と同時に社会保険を切り替え、代表の報酬を決定し、独立したその日にはすでに中国で新型コロナウィルスが発生していたようです。自分はまだ気づいていません。

当時は営業代行の業者にもちょうど契約が完了したタイミングで、月々のバーンレートも増えたタイミングでした。もっと早くコロナについて知っていれば、とも思いますが、経営戦略は変えず、営業代行に依頼しリードの獲得を進めることにしました。

コロナが日本にやってきたタイミングでしょうか、案件が来なくなりました。非常に良い案件もあったのですが、なかなか難しい状況が続きました。年明けだからかな?と思ったものの、数は少なく、案件が取れない状況が続く...。

コロナ禍が続く今も案件が取れることはなく、契約に基づく支払いもあり、身動きが取れない状況に陥りました。

ギリギリでの調達

起業は受託案件をメインに経営しておりますが、会社としての成長のためにはギリギリでも投資をしたいと考え調達をする方向で動きました。創業融資の方向で進めていましたが難しいようで、調達は難航しました。

ところが、ちょうど区の方で新型コロナウィルス対策の支援融資があり申し込むことに、無事審査に通ることができたのです。 それのおかげもあり、無事コロナ禍の最初の時期を乗り越えることができました。

案件を頂くまで

投資のため会社のバーンレートも上げていきコロナ禍でも会社の成長戦略を考え人員を採用活動も進めていきました。しかし想定外のことの連続で、チームビルディングは中々思うようにすすみませんでした。

投資をした方が良いのか、抑えた方が良いのか選択しなければならず、私は投資する方向を選びました。会社のギリギリまでバーンレートをあげ、戦略的に動き、複数人のチームが出来ました。

戦略を間違い損失をだしてしまったことも多いですが、その損失も大きなリターンとして返ってくることを実感しています。

大きな波もあり小さな波もあって、小さな波の時は自分から波をおこなさいと、波に乗れないような感覚でした。

そして、大めな案件も対応可能な組織へと変化していきました。

教育が組織を大きくする実感

一年間の中で、外注することもありました。しかし持続的な製品開発をすることは大変難しいことを知りました。継続的にお願いすることが難しい事が多々ありました。 外注の場合指示する権限があまりないので、そもそもとスキルを強化していく方向に舵を取る事が難しかった。

そして、社員に対してもそもそも指示を受け入れて頂くことが難しい時もあり、お金を支払っているのにも関わらずコントロールが全くできない状態になり、ただネットサーフィンをし続けるだけで一日が終わってしまうような状況を許容していたこともあります。権限の委譲も本当に任せてスケールできる人でないと、、難しいと知りました。

これではよくないと切り替え、自分のコントロールが効かない事を全て消す戦略を取りました。そして、それによって我慢していたことを全て我慢せず進めることにしました。まるで経営者の暴走です。自分でもそう思いました。

まず不要な管理サービスは全て解約しました。メンバーが欲しいと言って使っていたとしても、自分がいらないと思えば解約しました。そして、従業員の候補探しをしました。これはこれで難航してまして、でも探していると、不思議なことに向こうからやってくるんですね。そうやって仲間は増えていきました。

権限委譲は本当に任せられると思った時だけだと決めていたのでお願いしたいことだけをお願いするという非常にシンプルな体制で始まりました。

そして弊社はもともとリモートワークが多いためシフト制を導入し、ワークライフバランスを実現。スケジュールベースで柔軟な働き方が可能です。

わかりやすい指揮系統と、指示管理をおこない仕事を割り振っていたところ、段々と全体の成長を実感できるようになってきました。それは、自分も含めてでした。権限委譲しているわけではなかったのですが、任せられる安心感もありました。

怖くて指示が出せないということもなく、円滑に指示が出せるようになったことに正直自分でも驚きました。マイクロマネジメントほどではないですが、プロジェクト管理サービスできめ細やかな指示を出し、、どんどん消化してくれる光景は、コロナ禍で全く仕事がなかったあの時にどう指示すればわからなかった頃と比べると大きな変化でした。

そして、何よりもメンバーが課題解決にあたってわからない点が出てきた時には、一つ一つ解説して解決方法を明示してあげることで解決できることが多くなっていき、だんだんとチームパフォーマンスがあがっていったことです。

きめ細やかなプロジェクト管理は、そのまま課題の発見、解決のルーチンと合わさることで会社は円滑に進んで行きました。

コロナに強い組織の作り方

弊社は、withコロナで事業戦略をコロナ禍の初期から進めていました。それもあり、案件の性質もwithコロナだったから生まれた案件が非常に多くあります。

しかし、一つ間違えればバーンレートは一気に飛び越え、資本をショートさせてしまうリスクがある綱渡りな状態がコロナ禍であるように感じます。多くの企業がコロナ禍によってオフィスを解約した中で、私はオフィスを契約しましたし、崖を飛び越えるようなことも多かったです。

コロナ禍でこそ、きめ細やかな経営戦略とプロジェクト管理が、少しずつ会社を成長させる力になっているのではないかと思います。