「悩める技術者の役に立ちたい」——Slack分報を生み出したクラフトマンソフトウェアのカルチャーを作り出す根源的価値観とは

クラフトマンソフトウェアの共同創業者で、取締役を務めるsuin。「プログラミングは自分のアイディアを創意工夫して形にし、世の中に広めていける楽しみのある営み」だと言います。創業以来、自社プロダクトの開発のほか、TypeScriptのコミュニティ活動やブログ、入門書の執筆といった対外的な発信を積極的に行ってきたsuinに、取り組みに至った背景や想い、クラフトマンソフトウェアの価値観について聞きました。

取締役　野澤 秀仁（@suin）
https://twitter.com/suin
https://qiita.com/suin
TypeScriptが好き。入門書『サバイバルTypeScript』(typescriptbook.jp)執筆者のひとりです。Qiitaユーザーランキングは4位。「開発者の幸せを最大に」をコンセプトに、AWS専門家じゃないアプリ開発者のために、AWSの良さはそのままに、難しい部分をシンプルにして、開発体験を劇的に向上させるツールFocasの開発に携わっています。

アイデアの出発点は「自分たちの悩み」。開発者の負担を軽減するサービスで起業

——はじめに、suinさんがクラフトマンソフトウェアに参画した経緯について聞かせてください。

クラフトマンソフトウェアを立ち上げるまでは会社に所属したり、フリーランスの立場だったりで、業務システムの開発に携わっていました。そんなとき、ある技術者の勉強会に参加して森（クラフトマンソフトウェア代表取締役）と出会い、意気投合したのです。当時、森は受託で業務システムの開発に携わっていて、私もそれを手伝うことになりました。

同時に森は、開発者向けに開発を支援するプロダクトのプロトタイプを作っていました。開発者が手動で行っているテストを自動化するもので、手作業で行っている不具合のチェックなどの作業工程が10分の1まで削減できるようなプロダクトです。

森とは一緒に仕事をする中で気が合うのもあって、開発中だったプロダクトのプロトタイプができて、どうやらビジネスとしていけそうだというタイミングで、一緒にクラフトマンソフトウェアを起業をしました。

受託開発をする際、テストは避けて通れません。当時、私たちが取り組んでいた受託開発のプロジェクトでももちろんテストをする必要はあったので、その負担を軽減するためにプロダクトを作り始めました。

こうした悩みを抱えているのは、ほかの開発者たちも同じです。このプロダクトを自分たちだけの秘伝のタレにするのではなく、公開すればみんなの手助けになりますし、ひいてはビジネスになるのではないか。そうした観点から、開発者に役立つサービスを作っていこうということになりました。

現在、クラフトマンソフトウェアでは、創業当初のプロダクトとは形を変えましたが、新しく「Focas」というプロダクトを開発しています。このプロダクトも、インフラ管理の負担を極限まで減らそうというコンセプトで作っています。自分たちがアプリケーション開発をしてWebサービスでリリースしようとすると、インフラを管理するのが苦痛だったり、難しかったりということが起こります。この点も、同じ悩みを抱えている人は多いことでしょう。

このように、基本的にプロダクト開発のアイディアの出発点は「自分たちの悩み」から始まっています。「Focas」については実際に顧客とも対話しながら、どんなプロダクトが必要とされているのか、確認しながら開発を進めているフェーズですね。

すべての活動に共通して言えるのは「技術者の役に立ちたい」という想い

——suinさんはブログやSNSなどで、対外的にさまざまな情報発信をしています。こうした取り組みについて、具体的に教えてください。

情報発信の取り組みとしてメインで行っているのは、Qiitaですね。Qiitaはもともと特定の誰かに向けて発信しようと思ったわけではなく、技術的に自分が困ったことや疑問に感じたことを調べて、備忘録として投稿してきました。

自分が悩んでいることは、ほかの人にとっても疑問だったり、困ったりしていることのようで、情報発信が少なからず誰かの役に立っていたようでした。

投稿数も気がつけば1,200記事に達していて、どれだけ記事が評価されたかの指標となるコントリビューション数が、全体の4位になっていました。

——ほかに、コミュニティ活動などもしていますね。

YYTypeScriptといって、TypeScriptが好きな人が毎回6名ほど集まって、雑談して交流を深める会をしています。この取り組みは2年半ほど続いて、開催数は120回を超えています。

雑談の内容はTypeScriptに関することだけでなく、キャリアの悩みなど非技術的なことや、プロジェクトの進め方など、多岐にわたっていました。毎回、最初に雑談トピックを出してもらって、司会の人がファシリテートしながら話を進めていきます。当日、実際に集まるまで何を話すか決まっていないという、偶発性を楽しむ会です。

ですが、新型コロナが蔓延したことで、オフラインで人と会って雑談することが難しくなりました。それなら、オンラインで何かできるのではないかというところから始まったのが、TypeScriptの技術書「サバイバルTypeScript」の執筆です。

執筆には通算で20〜30名の方が携わってくれています。誰かにどこかの章を割り当てて執筆をしてもらうのではなく、YYTypeScriptに参加してくれた人の中からメンバーを募って、書きたいときに、書きたいところを書くというように、自由に活動してもらっています。

紙の技術書だと出版したらそこで一旦完成になりますが、Webの技術書なので「完成」という定義はありません。TypeScript自体が新しくなっていくので、直すところは直して、常にアップデートしていけるのはWebの強みです。

——どのような思いや考えがあってこうした活動に取り組んでいるのでしょうか。

それぞれ、活動ごとに異なるモチベーションがあります。たとえば、Qiitaは自分のために備忘録としての記録を残すこと。それが誰かの役に立ってくれれば、という気持ちで取り組んでいます。

YYTypeScriptは、エンジニア同士の交流の輪を広げるという目的があります。その中から、自社でのTypeScriptのエンジニアの採用につながればという思いもあります。そして、自分たちもTypeScriptを勉強し続けているので、会社で勉強会をホスティングしつつ情報交換ができる場があればと考えました。

TypeScriptの入門書を書くことになった理由の1つは、先ほど申し上げた新型コロナの蔓延のほかにもう1つあります。それまでYYTypeScriptというリアルの雑談イベントをしてきてはいましたが、何度か開催するうちに参加してくださる人がある程度固定化されてしまっていたのです。そこで、関東在住でイベントに参加できるようなTypeScriptの開発者が少ないのではないかと仮説を立てました。また、TypeScriptに興味を持っている開発者自体がほかの言語と比べて少ないのではないかとも考えました。

であれば、多くの方にTypeScriptに興味を持っていただいて、実際にTypeScriptを学んでもらうことで、TypeScriptの開発者の数自体を増やせばいいのではないか。そう思い、入門書を書くことに行き着きました。

このように、いろいろな活動をしてきてはいますが、すべてに共通していえるのは、「誰かの役に立ちたい」という思いです。

開発者にとっての「よりよいカタチ」を追求し続ける姿勢が生みだしたSlack分報

——今では多くの会社で見かけるようになった「Slack分報」。最初に取り組んだのはクラフトマンソフトウェアでした。こうした取り組みを始めた背景について教えてください。

Slack分報は、自然発生的に始まりました。

クラフトマンソフトウェアではもともと、社内wikiに日報を書き込んでいました。ですが、日報を書くのは1日の終わりであることから、その日午前中に何をしたか、忘れてしまうことが多かったのです。

そこで、社内wikiの中に個人個人でメモを残すようになりました。1日のうち不定期に、今やっている作業や困っていることをメモして、最後に日報を投稿するようにしていたのです。そのメモを、社内wikiではなくSlackに投稿しはじめたのが分報の原型ですね。

たとえば、「野澤の作業メモ」といったチャンネルを1つ作って、そこに悩みや困りごとを書くようにしていたら、それを見た誰かが答えやヒントを置いていってくれるようになりました。そうした体験が積み重なることで、「これは日報に代わるコミュニケーションになり得るのではないか」と気づき、社内で一般化しようと考えたのです。

とはいえ、運用方法をガチガチにルール化したわけではありませんでした。唯一、Slackのチャンネル名だけ「times_suin」といったように統一して、あとはみなさんの自由に任せました。お互いのチャンネルに一応招待はするけれども、チャンネルに入るのはその人の自由。悩みや困りごとに回答するかどうかも自由です。

——実際に分報を運用してみて、どう変わっていきましたか？

日報は、困りごとを解決できるまでの時間にタイムラグがありました。Slack分報であれば、困っていることを気軽につぶやけますし、自分の考えの整理にもなって一石二鳥だという人もいます。日報と比べて問題解決までが速いと実感しています。

わからないことは誰かに聞けばいいのではないかといった意見もありますが、誰かに助けてもらうとなると心理的なハードルが高くなります。自分なりに調べてから聞かなければ失礼なのではないか、誰かの時間を取ってしまうのは迷惑なのではないか。そうした遠慮が働いてしまいます。

Slack分報に残すのはあくまで自分の「つぶやき」であって、「助けてほしい」というメッセージではありません。つぶやきを見て、「困っていそうだから助けてあげる」という善意の通行人が通りかかるだけなのです。

分報で解決しないのであれば、誰かに質問するというプロセスを採ればいいだけです。「自分の考えを整理する」「困ったことを質問する準備をする」「誰かに助けてもらえるかもしれない」といった複数の可能性を並行して行うという意味で、分報にはメリットがあると思っています。

——こういった取り組みの根底には、どういった価値観があるのでしょうか。

これは個人的な想いなのですが、自分自身がエンジニアとして課題を抱えていて、周りにも同じような課題で困っている人がいると、できれば助けてあげたいなという気持ちになるのです。

クラフトマンソフトウェアには、いまよりもいい方法はないか、常に模索する姿勢があると感じています。既存の概念を意図的に打ち壊そうとしているのではなく、「よりよいもの」を常に追い求めることで、結果的に既存の概念を壊しているのではないでしょうか。

エンジニアが「楽しい」と思える環境を提供するために、常にチャレンジを続ける

——今後どんな開発組織を作り、どんなカルチャーを築いていきたいと思っていますか？ビジョンや想いがあれば教えてください。

インフラのチームは従来どおりドメスティックな市場をターゲットとしていきますが、現在取り組んでいるFocasというプロジェクトに関しては、今後は国際的なサービスとして世界に広げていきたいと考えています。

GitHubのような、開発者向けの国際的なサービスにしたいですね。そうなると、チームも国際化する必要があります。日本発のベンチャーではありますが、日本人に限らず、さまざまな国や地域の方と一緒に働きたいですね。

——そのために、具体的に取り組んでいることはありますか？

従業員が日本人に限らないとなると、社内の言語は日本語だけでないほうがいいのだろうと思っています。Focasのチームの中でも英語を勉強している人がいますし、ふだんSlackでコミュニケーションをするときでも、一部で英語を使うようにしています。

国際的なチームを作ることができたら、その上でプロジェクト自体をオープンソースにして、海外の方と接点を持っていきたいですね。そこから興味を持ってくれた方に、Focasの開発に関わっていただけたらという想いもあります。

クラフトマンソフトウェアのメンバーが共通して抱いている価値観として、開発者として自分が困っていることや、エンジニアが苦労しているポイントを解決しようとする点が挙げられます。裏方の仕事が好きで、誰かの課題を解決することに労力を惜しまず取り組めるような方と一緒に働けると嬉しいですね。

——suinさんは、「プログラミングは自分のアイディアを創意工夫して形にして、世の中に広めていける楽しみのある営み」であるとブログに書いています。そうした観点から、将来にわたって実現したいことや思いがあれば聞かせてください。

本来プログラミングは楽しいもののはずなのに、テストをしたり、インフラ保守をしたりするために遅くまで残業をする。仕事をするうえでは、そういった「楽しくない」ことも起こります。

クラフトマンソフトウェアでは、そうしたインフラの保守やテストを人の手でやらなくてもよくなるように、常にチャレンジしていきたいと思っています。「プログラミングは楽しい」と思う人の比率を高めていって、最終的にはエンジニアが楽しく仕事ができる、そんな現場を増やしていきたいと考えています。