(所要時間 : 約3〜4分)

先日のエントリでリモートワーク主体に切り替えることついて書きました。4月は取り組みを更に加速させ、21営業日中の10日をリモート日としました。47%なのでほぼ半分のリモート率です。

変化が急過ぎるかなと思いましたが、やってみると全然問題なく仕事はまわってます。むしろまだリモート率上げられるなという感じなので近々逆転させる予定。思ったより速くリモート主体に移行できそうです。

(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)

特別な準備もなくリモート主体に転換できてる訳ですが、要(かなめ)になってるのはチケット管理(タスク管理)を徹底してることにあると感じてます。チケット管理しっかりできてるな〜という実感がある会社は、すぐにでもリモートメインに切り替えれるんじゃないでしょうか。

今回は、急なリモート主体への切り替えに耐えれている、弊社のチケット管理について少し書いてみようと思います。主に、マネジメント側の不安についてです。

弊社のチケット管理

チケット管理、タスク管理、TODO管理、バグ管理….色々と呼び方はありますが、やらなくちゃいけないことを管理するシステムは、自分が雇われエンジニアだった時から結構触ってきました。

• Bugzilla
• Excel
• 影舞
• Google Spread Sheet
• Redmine
• Backlog
• Trac
• Trello
• JIRA
• GitHub Issue

懐かしいものもちらほらありますね。弊社のチケット管理の歴史はシンプルで、

って感じです。10年以上前からチケット管理をやってますので、結構早い頃から社内タスクの見える化ができてたのではないかなと。

今でもまだ運用の仕方に洗練の余地がありますが、チケット管理の徹底が、リモートワークあるあるの「誰が何をやってるか分からない」というマネジメント側の不安を解消しているなと感じてます。

マネジメント側と言っても弊社の規模だと社長である僕だけですが(笑)、まぁ不安は皆無と言って良いです。信頼関係もありますが、チケットに情報が集約されてることが不安の解消に寄与しているのは間違いありません。

(Thanks! the photo on flickr by Pete Tschudy / CC BY-NC-ND 2.0)

全ての仕事はチケットに紐付く

弊社内でのチケット管理ルールは、

• 業務時間中の作業が常にチケットに紐付いていること
• チケットに記録をできるだけ細かく残すこと

の2点。一日の終わりに「◯◯さん、今日は何をして、その状況はどんな感じ？」と尋ねた時に、◯◯番のチケットです。というやりとりだけで基本済むようになってます。チケットに紐付かない仕事はありません。(社外の方とやりとりするBacklogはここまで…ではありません)

実際、弊社では一日の終わりに slack で日報投稿するようにしてますが、だいたいこんな感じになります。

f#XXXXXと書いてる番号がチケット番号。自動的に対応するURLを投稿するhubotが稼働してますので、チケット詳細がワンクリックですぐ見れるようになってます。

slackで一日単位のタスクの動きが把握できるほか、プロジェクト全体のフィードを見てれば、

(モザイクでほとんど何書いてるか分かりませんが…笑)

誰がどのタスクを終えたのか、日中でもどんどん情報が集まってくるようになっています。ってチケット管理に慣れてる方なら当たり前だと思いますので、どちらかというとチケットの種類や中身のほうに特徴があるかもです。

チケットに時系列の記録を細かく残す

弊社がTrelloやカンバン方式をメインにしない理由でもあるんですが、時間軸の記録を結構大事にしてます。時系列に、何した、あれした、どうなった…と結構細かくチケットに書くんですね。

ちょっと極端な例ですが、一例をあげるとこんな感じ。「KUSANAGI for さくらVPSへの移行」というWordPress環境の引越し作業のタスクです。

だいぶ長いですね。印刷するとA4で10ページぐらいになります。

Redmineをご存じの方は見慣れた画面ですが、最上部の黄色いところがタスクの内容、その後に時系列コメントが並びます。移行作業で、サーバで何をしたのか、設定ファイルをどう変えたのか、パフォーマンスはどうなったか等など、ガンガン書いていきます。

会社によっては「もっとチケットを分割すべきだ」となりますが、このタスクについては最小粒度です。「公開鍵を置く」「NGiNXを設定する」「KUSANAGIのプロビジョンを設定する」「MariaDBの設定をする」「DBにdumpをimportする」てな感じまで分割するのかって話なので、そこまでは必要なかろうと。

ま、そのへんは臨機応変に僕がチケット分けて〜と言ったり僕が分けちゃう場合もあります。あと、設定情報等は別途wikiに転記して整理するとか、gitのコミットが連動しているとか、＋αな連携もさせてます。

他には、こんなチケットもありますね。「◎◎様に提案する為の Dropbox Business Advanced についての調査」という題目。これはちょっと短め。

商流をどうするか、販社はどこを使うか、パートナー制度の調査情報などガンガン書きます。これは僕が担当したタスク。コメントは5,6個ですかね。

この種の情報は、ひょっとしたらSFA(営業支援)やCRM(顧客管理)の範疇かも知れません。が、弊社では、何らかのタスクであって時系列つまり事の経過が重要なものは全部 Redmine や Backlog に集約してます。情報は一つのシステムに集約されてる方が良いですから。

ここまで書くのはちょっと…という方もいます。正直面倒かも知れません。でも、会社の生産性って突き詰めると、情報共有のスピードや共通認識の形成スピードなので、生産性を求める僕的には譲れないところなんですよね。そうじゃないと残業ゼロを促進できません。

だから、なるべく多くの情報を非同期的に共有できるよう、チケット管理システムを使ってガンガン書くことを是としています。あ、別にチケットの更新頻度が査定に関係する…みたいなことはしてないです。

一見面倒に見えるんですけど、社内で「共有」とか「報告」の名の下に開かれる会議や書類作成の無駄に比べたら楽なもんです。エンジニア的には、コマンドやその標準出力、設定ファイルの一部をコピペして見解を書く、とか、gitのリポジトリのコミットログが連動しててそれだけで済む場合もありますから。

(Thanks! the photo on flickr by kiwamuk / CC CC-BY 2.0)

チケットに記録が集約されることのメリット

既に前述してるものもありますが、

1. 報告のための会議や書類作成に要する無駄な時間を無くせる
2. 過去を遡れるので、有事の時の思い起こしコストが最小化できる
3. 誰が何をやっていてどこまで進捗しているか具体的に分かるので管理側は安心できる

あたりでしょうか。

チケットに書く記録の粒度は人にもよりますし、一挙手一投足を捉えられる訳ではない(それはそもそも必要ない)ので、情報共有具合が常に100%って訳じゃないです。体感でせいぜい90%ぐらいでしょうか。

だから不足分は必要に応じて顔を合わせた会話で補います。その場合でも、関係者がチケットを事前確認して現状共有した状態で会議を始めますから、濃密かつ所要時間を最小化した会議運営ができる訳ですね。

記録を残す負荷が余りに高いと組織の生産性が落ちますが、適度に記録を残す癖は組織の生産性を確実に上げます。無駄を無くせるという意味で。

(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)

という訳で、チケット管理のついて書いてみました。冒頭の話に戻りますが、誰が何をやっていて今どういう状況なのかが分かるから、リモート主体にいきなり切り替えても何も困らなかったのでしょうね。

もちろん、弊社の場合は人数が極めて少ないってのも理由の一つです。でも、人数が少ないからと言って、誰が何をしてるか分からない、何をしたら良いのか分からない、という不安が無くなる訳ではありません。なので、人数や会社の規模はリモートワークを採用できない理由にはならないだろうなと今は思います。

チケット管理の徹底が、労使双方にとって不安の解消に寄与するのは間違いないです。リモート主体にするかどうかは別にして。何をすべきかチケットで把握でき、何をしているかがチケットで分かるからですね。チケット管理は奥が深いのでまた書いてみたいと思います。

最近、仕事の進め方が変わってきていて、ふと気が付きました。

案外リモートでもokじゃね？と。事務所に常にいる必要ある？と。

創業からリモートという選択肢は用意してましたが、あくまでオプションだったんです。エンジニア自身や家族の体調がすぐれない時とか、外出控えた方が良さげなインフルエンザ流行時とか自然災害とかの時ですね。

あくまでもメインは出勤、リモートはオプション。

ずっとこの考えでした。でも今後、これを段階的に逆転させていこうと思います。メインはリモート、出社はオプションという就労体制に切替えていきたいなと。

リモートの適不適は人にもよるし仕事の内容やプロジェクトのフェーズにもよるので、集まることを完全に否定する訳ではありません。ただ改めてこの1,2年の自社を見てみると、集まることを前提にする意味が無いと思ったのです。小さい会社だからってのが大きいですけど。

図らずもリモートが増えたが困ってない

最近、取引先やパートナーさんとリアルに会わず仕事を進めることが増えました。出張も増えてるんですが、出先での社内とのやりとりは実質オフィスなしでリモートワークしているのと変わりません。

SlackやChatworkでチャット＆ビデオ会話、RedmineやBacklogのチケット管理、gitでソース管理、VPNでセキュアな接続環境…。

仕事の進め方や就労環境の考え方が、元々リモート最適化されていたんだと思います。生産性を高めるにはどうしたら良いかという追求の結果たまたま…なんですけどね。例えばこの本、

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

posted with ヨメレバ

ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン 早川書房 2014-01-24

フルリモート体制の37signalsのCEOの著書ですが、これを読んだ時も共感できたし自社でやってたことも幾つかありましたから、考え方もリモート主体を元々是とするところがあったのかも知れません。

ならば37signalsのように、あるいは国内先駆けのソニックガーデンさんや近年だとIncrementsさんのように、思い切って自社をリモートを主体とする会社に衣替えしてみようと思った次第です。

でも既に当たり前の企業さんにとっては当たり前のことだし、リモートワークという言葉はもう何年も前から言われているので、何も目新しさはないのですけどね。

まぁ世間的に目新しいかどうかはともかく、どうせやるならスピードが常に正義なので、3月中旬頃にリモート主体にしようと思い至ってすぐに行動しました。

(Thanks! the photo on flickr by ★Kumiko★ / CC BY-SA 2.0)

1. 花粉が酷い日でもリモートワーク

一つ目は出社しない日の設定。出張の日や外出メインで僕がオフィスにいない日(最近は結構多い)と、エンジニア本人の体調が悪い日を原則リモートワークとしました。

後者は7,8年前からそうだったのですが、リモートワークの特別感がなくなるよう僕から「リモートにする？」と提案するようにしました。その効果もあり「今日ちょっと花粉が大変なのでリモートでいいすか」「了解です」ってやりとりもあったりでハードル下げるのに成功してます。

3月中旬から2週間の間に既に4日(営業日ベースで3,4割)ほど実践してますが、生産性は落ちてないという印象。経営者の僕的にも、早速リモートワークを実践したエンジニアの @t0shiya 的にも同じ感覚です。まぁこれは労使相互の信頼感あってこそですけどね。

2. リモート前提で自社プロジェクトをおまかせ

もう一つは、自社プロジェクトで新しい取り組み。3月下旬から岩手県に在住の @mtane0412 さん (ブログ:ニートが東京に行った話) に平日、完全リモートでお仕事して頂いてます。

(週1回の頻度のビデオmtg。ご本人の許可を取ったうえでキャプチャ/掲載しています)

弊社では、常時SSL化上場企業対応状況レポートをやってるんですが、随分前から常時SSL化促進のためにもっとWebから情報発信をしたいと思っていたのですよね。esparという自社プロダクトの一環として。

自社のものは自社内で…が僕のポリシーなので、「Webデザイナーさん雇うしかないかなぁ、社内に席は1つ空いてるけど今雇うならエンジニアだよなぁ…」ってずっと悩んでたのです。で、たまたま@mtane0412がリモート前提で仕事を探しておられることを知り、速連絡。お仕事をご依頼するに至ったという訳です。

@mtane0412 さんは、Geek Office Ebisu やベビログの板羽さんとの繋がりで知り合った方。ライティングの力やWebの知見、制作力、技術的センスなど、惹かれるものがあったのですよね。実績もお持ちでした。(サルでもわかる葬儀の新常識)

(制作されたサイトの例。クオリティも高く1年でPVも収益も稼ぐサイトに育ったそうです)

少しお話して、僕の「あらゆるサイトの常時SSL化を促進したい」という考えにも共感して貰えたので、今、特に期限を定めることなくアルバイト的な感じでお仕事をお願いしてます。

これは会社に出勤することを主としていたらできなかったことですね。リモートワークを主とすることで仲間を増やせるということなんだろうなと実感した例でもあります。

とまぁそんな訳で、リモートワークを主体に切り替えていこうと思います。冒頭でも書いた通り集まることを完全否定する訳ではなく、あくまで出社かリモートかの主副の入れ替えに過ぎません。適度なバランスが探れると良いなぁと思います。

弊社は、創業来10年以上エンジニアにとって幸せな働き方とは何かを追求してきました。そうやって生まれた変な制度や変な取り組みが沢山あります。

でも、集まる前提という思考の拘束が解けた今、制度や取り組みについてアイディアが色々出てきてます。労基法を改めて読み直したり、社労士にアレはokかコレはダメかと確認しまくってるのは自分らしいかもですね。リモートを主としたらできること。遅れ馳せながらですが、追求してみたいと思います。

(所要時間 : 約1〜2分)

新年あけましておめでとうございます。始まりました2018年。

(正月も変わらず朝のお参り。今年はちょっと遅め)

気がつけば会社として年賀状を出さなくなってから6年たちましたね。

本年も昨年中に新たにご縁頂いた方を含めて沢山頂いているのですが、本エントリをもって新年のご挨拶とさせて頂きたく、御理解賜われましたら幸いです。無礼をご容赦下さい。そしてお送り頂いている皆様、有難うございます。

さて。

2017年が新しいことを始めた挑戦の年だとすれば、2018年はその挑戦を実績という形に結実させるため、やるべきことを忍耐強く愚直に継続する年だろうなと思っています。

主にはWebサイトの静的化事業である espar ですね。

(Webサイトを静的化して高速化とセキュリティ強化を図るサービス)

おかげさまで色んな御客様に御評価頂いてます。

Webサイトのスピードが重要であるという認識の広がり、Webサイトセキュリティへの変わらない関心の高さ、両方とも確実にあって本年その機運は更に高まってくると考えています。

それぞれの課題を解決する技術は色々とありますが、弊社はその中でも静的化という技術を主軸に据えて戦ってまいります。静的化は、理論的にもコストパフォーマンス的にも御客様や制作会社様にとって最善なんですよね、どう考えても。その理由はまたエントリ書きたいと思います。

2018年、Webサイトの高速化やセキュリティ強化の専門家と広く認識して頂けるよう、商品力UPや各種の発信・啓蒙にも力を入れます。

あと。

例年書いてるアウトプット。2017年は社長ブログが47エントリ、寄稿が1つの計48件。少な過ぎなので今年はもっと増やしたいと思います。

(Thanks! the photo on flickr by Fredrik Rubensson / CC BY-SA 2.0)

昨年、技術的なことを時々書いてました。

• ICOを達成したALISのWebサイトはもっと評価されても良い
• Mobile Safari の PWA 対応で変わるのは企業向けアプリ

こんな感じで事業に関係ある技術的なエントリを増やしたいなと。一方で労働や雇用や経営に関するエントリは、結局昨年も更新できてないハフィントンポストに書くとか、カテゴリ毎に媒体を変えるということを一度やってみようかなと思ってます。

ということで新年のご挨拶エントリでした。静的化とアウトプットの2018年にしてまいります。本年もどうぞ宜しくお願い致します。

(所要時間 : 約2〜3分)

2017年も終わりますね。今年も本当に早かった。昨年に比べるとまだ静かな1年だったように思いますが、事業面を3つに分けて振り返りつつ来年のことも書いてみたいと思います。

1. Webサイトの静的化サービス「espar」始動

WordPressなどのCMSサイトを静的化するesparという事業を立ち上げました。今年の6月ですかね。

Webサイトの静的化に関して弊社の動きは、

• 2015年 → 静的サイトジェネレータ(SSG)の研究開始
• 2016年 → SSGには見切りをつけ、サイトの静的化エンジンをGo言語で自作
• 2017年 → クラウド型のサービス化と本格導入開始

となってまして、もう3年も静的化のことばかり考え続けてます。今年はようやく静的化の価値が評価されてきたのだなと実感できる年でした。

espar発表後、わずか半年で上場会社様から外資系大手様・行政系・財団法人様・医療系など業種関係なく多様な導入実績を残すことができたのがその根拠。事業として確かな手応えを感じていますので、来年は更に「静的化や静的サイトと言えばフィードテイラーさん」と思って頂けるように発信を強化していきたいと思います。

あと、実はWebサイトの静的化にブロックチェーンに似た技術を絡めると面白くなりそうってことも分かってきていて、そのへんも色々実験してみたいですね。

また、Let’s Encryptのスポンサーになって非営利団体を御支援するという初めての経験もさせて頂きました。常時SSL化もまた時代の流れで啓蒙する価値があるので続けていきたいです。先日発表した国内常時SSL化対応状況レポートも続けていきます。

2. 技術顧問やコンサルティング事業

創業来、じつは地味に続けている事業でして。毎年何らかの企業様の事業立ち上げご支援をさせて貰ってます。もちろんIT系メインですけども。

今年大きなところでは、2年強続けさせて頂いたヴァル研究所様の技術顧問が12月をもって一段落となったことが上げられるでしょうか。位置情報系の新たな事業SkyBrainが立ち上がりチームも形成され、ぼちぼち僕の役割は無くなったということで一区切りとさせて頂きました。

他にもデータ分析系のKSKアナリティクスさんのこれまた新規事業立ち上げとか。色々と各社様のお手伝いさせて頂きました。開発が絡むお問い合わせはちょいちょいあります。「作るべきじゃない」ことを前提に話をする開発会社が珍しいからかも知れませんね。

変わりどころでは、今年も「ウチにJOINしませんか？」というお誘いを頂くことがありましたが、自社事業があるのでさすがにお断りしています。お気持ちはホント有り難いのですけどね。

3. アプリ開発事業

2016年にアプリ開発を内製することはやめたのですが、やはり過去の経験や、B2Bアプリのノウハウ保有企業が少ないこともあってか、今も御相談を受けることがあります。

今年も2,3個ですがアプリの開発や法人向け導入支援をさせて貰いました。開発の場合は、弊社から独立したエンジニアの協力を貰って僕がマネジメントして…って結局前とやってること一緒じゃん！な形態なんですけど。あ、もちろんそれ以外のパートナーと一緒にやる場合もあります。

関わらせて頂いた今年のアプリの一つは、MacFan様にも取材頂いて掲載もされました。

(いわゆるガワアプリについて。online版がMacFanのサイトで御覧頂けます)

弊社が手がけるのは、やはりB2BアプリでAppStoreには載らないものばかり。来年も既に御相談頂いているものありますので、アプリのフィードテイラーさんという見え方はもう暫く続きそうです。

答え合わせの1年

ザックリと振り返りましたが、(新事業始動というイベントはあったにせよ)落ち着いた1年だったですね。事業譲渡もなかったし(笑)、新たな人が増えることもなかったですし。

総じて自社で発信してきたことが正しかったことを実感できたのかなぁと感じれる良い1年でした。静的化しかり。システム開発は極力避ける論しかり。いまさら副業容認だ残業ゼロだを言ってる働き方改革しかり。確実に世の中はそっちに向かってます。

2018年はどんな年になるでしょうか。今から楽しみです。本年のエントリはこれが最後となります。弊社に関係して下さった皆様、本年も大変お世話になりました。来年もどうぞ宜しくお願い致します。

2017年7月7日をもって創業から丸っと11年が経ちました。いよいよ12年目に突入です。今も変わらず会社を続けられているのは、家族やスタッフ、パートナーや御客様など弊社に関わって頂いている全ての方々あってこそ。改めて御礼申し上げます。いつもありがとうございます。

(本が収まらなくなってきたミーティングスペース)

創業日って何かしら節目の会話をしたり、お祝いしたりしてきたもんなのですが、今年は後から人から言われて「そう言えば一昨日が創業日やった」と気がつくという何とも珍しやら情けないやら。

祝う余裕すらないのかその暇すらないのか…、ある意味どちらもでして。振り返ってみると、それも致し方ないよなぁというぐらいに、ここんとこドタバタしてました。2016年から立ち上げに力を注いでいる新事業に、御客様に目を向けて頂いて加速し始めている証なのでしょう。色々平行稼働しておりホントにありがたいことです。

で、12年目突入の今、振り返り的なことは年末にやってるので、この1年でやりたいことか未来の話を。

12年目に取り組みたいこと

色々ありますが特に3つ。

1. B2B iOS 事業 MICSS の強化
2. Webの静的化サービス espar の強化
3. 新しい労使のあり方の模索や発信

創業記念日を忘れるぐらい多忙だったのは特に1,2が加速してたからですね。12年目はいずれも勢いつけて厚みをもたせていきたいと思ってます。B2BなiOSアプリ開発・運用の話は依然と需要がありますし、Webサイトの静的化は需要の高まりを感じますしね。

後者はやってみて感じたことですが、実はセキュリティよりWebの高速化の観点で静的化を望まれるケースが圧倒的に多いんですよ。高速化を追求していけば、静的化が最終ゴールなんですよね。静的化する以上に効果の高い高速化手段はなくて、静的化はそれ以上やその先もない約束の地な訳です。ここは商品の見せ方を少し変えるべきだなと気づきを得たところ。そのへんも軌道修正しながら前進していきます。

まぁそれはともかく、総じて足りてないのがアウトプット。特に1は強化すべきで、MDM、DEP、AppleConfigurator、等などまだ世に出てない知見が沢山あるなぁと思い当たることも多く、ここのアウトプットが案件も含めて色々引き寄せることになるのは間違いない感触を得ています。

3も含めて、とにかくOUTPUTをしていきたい。その為には、そもそも「書く」のが遅いので、なんか根本的な工夫・改善をすべきであると考えてます。書く以外にもやっぱり「話す」もですね。11期の後半が特にそうであったように、今期も機会があれば色々と話してみたいと思います。

という訳で12年目はアウトプット頑張る宣言。B2B iOS の、またWebの高速化やセキュリティ向上の、フィードテイラーを今後とも宜しくお願い致します。