s-dev talks についての個人的お気持ち
少し前から s-dev talks というサービス開発について話すイベントをやっていて、organizer のひとりとして参加しています。
第2回も終わって一旦落ち着いたので、このイベントについて抱いている気持ちについて書いてみようと思います。
はじめに
これは僕個人の気持ちです。 僕が思っていることを書きたいように書いています。 s-dev talks 公式の見解や声明などではありません。
こういう考えを持った人間が現時点で organizer にいるのは事実ですが、今後 s-dev talks が向かっていく先は他の organizer との議論や参加者からのフィードバックを元にして決まっていくはずです。 フィードバックお待ちしています 🙏
s-dev talks とは？
Connpass のグループページから引用します。
以下のようなコミュニティです。
s-dev talks はサービス開発者の草の根コミュニティです！
ここでの「サービス開発者」は良いサービスをつくりたいと思っているすべての人を意図しています。 典型的にはプロダクトオーナー、ディレクター、デザイナー、エンジニアなどが含まれますが、そういった人たちに限らず多様なバックグラウンドを持った方に来てほしいと思っています。 我々は「良いサービスをつくるためには様々なスキルを持った人たちが協力し合う必要がある」と考えています。
s-dev talks はあらゆる垣根を越えて、サービス開発のためのスキルや知見をカジュアルに共有できる場を目指しています。
Organizer は僕 @s_osa_ の他に @spicycoffee66、@ukstudio、「とくなり餃子大好き」こと @to9nariyui でやっていて、諸々のグラフィックデザインを @tomoya_tsuji_ に手伝ってもらっています。ありがとう。
#1 「仮説検証」、#2 「チームビルディング」と順調に回を重ねています。
s-dev talks をつくった理由
厳密には「s-dev talks をつくるのに乗っかった理由」です。 発起人をひとり選ぶなら @spicycoffee66 だと思うので。
さて、肝心の理由ですが、だいたいは上の引用文に書かれている通りです。 上の文章は僕が叩きをつくって organizer のみんなにいろいろ修正してもらいました。
と、これで終わらせるのもアレなので、もう少しだけ詳しく書いておきます。
チームにはサービスをつくる上で生じる課題を解決するために、いろいろなスキルや視点を持った人が集まっています。 僕だったらエンジニアリングという専門性を持ってチームに加わっていますし、デザインやマネジメントをはじめとして、みなさんそれぞれの専門性を持って加わっているでしょう。
「フレンズによって得意なこと違うから」
これがチームを組んでサービスをつくる主な目的だと思います。
しかし、いろいろなスキルや視点を持った人が集まっている一方で、我々は全員「ユーザーの課題を解決するサービスをつくる」という目的の下に集っています。
持っているスキルや視点は違えど、最終的な目的は同じです。 そのために同じ方向を見て、同じものを思い描いて、チーム全員で「良いサービスをつくる」ということを考えていく必要があります。
こうして考えたときに、前者の各専門領域については勉強会などが活発に開催されていますが、後者の「サービスをつくる人」が集まるイベントがあまり見当たらなかったので「じゃあ、つくるか」となりました。
s-dev talks をどういう場所にしたいか
いろんな人が集まる場所
いろんなところに書いているように、様々なバックグラウンドを持った人が集まる場所にしたいです。
「全員『サービスをつくる人』だ！ バックグラウンドなんて関係ない！」という気持ちがある一方で「望むと望まざるとにかかわらず、それぞれの専門によって見えているものが違う。ある人の当たり前が他の人にとってそうではないことは結構ある」という気持ちがあります。
現時点ではまだまだ Web 界隈のエンジニア・デザイナ・PO・PM といった人たちが多いですが、業種も職種も飛び越えていろんな人に来て欲しいし喋って欲しいと思っています。マジで！！！
いろんな人に届けられる場所
サービスをつくっている人たちに聞いてほしいことがあったときに、それを効果的に伝えられる場所にしたいと思っています。
実は大阪の人から「中継とかはないんですか？」といった問い合わせも貰っていて*1、そういう意味でももっといろんな人に届けられるようにしたいと考えています。
勉強会というよりコミュニティ
「s-dev talks 〜サービス開発勉強会〜」と銘打っていますが、「勉強会」という感じにはしたくないなと思っています。
学びがあるのはもちろん良いことですし、過去のイベントではいろんな学びがあったんですが、いろんな目的で来る人がいて良いと思っています。
そのときどきで抱えている課題を懇親会で相談する人がいても良いと思いますし、他の人が難題に立ち向かっている姿を見て元気をもらうのも良いと思います。
明日の行動が少し変わる場所
s-dev talks で話されることは必ずしも「すごいこと」じゃなくて良いと思っています。
世の中には日々試行錯誤しながらサービスをつくっている人たちがたくさんいます。 そんな人たちが現場で得た学びや気付きを共有することによって、他の人の「これ試してみよう」とか「明日、チームの人に話してみよう」といったアクションにつながれば良いなと思っています。
小さな行動がたくさん生まれる場所にしたい。
おわりに
以上、現時点での個人的なお気持ちを書いてみました。
s-dev talks 〜サービス開発勉強会〜 #3 「ユーザーインタビュー」の募集が始まっています。以前からの 5分枠（LT）に加え、今回から20分枠も公募になったので、ご応募お待ちしています！！
Slack で簡単かつ公平にくじびきをする
前に書いた「Ruboty でくじびきをする」というエントリの続編です。
何をつくったのか
Slack の slash command を使うことによって、簡単かつ公平にくじびきをできるものをつくりました。
なぜつくったのか
日常にくじびきをしたいシーンは結構あります。
たとえば、issue の assignee を決めるとか、飲み会の予約をする人を決めるとか。弊社でよくあるのだと、ランチのためにご飯を炊く人を選ぶなんていうのもあります。
そういったケースで公平にくじびきできるようにするために、2年ほど前に ruboty-kujibiki という gem を書きました。
この gem は社内の Slack で今も便利に使われていますが、当然ながら「Ruboty がいるところでしか使えない」という問題があり、別の Slack workspace で「くじびきしたい！」となったときに「ここ Ruboty いないじゃん……」となることが結構ありました。
とはいえ、いろんな Slack に Ruboty を入れて回るのは面倒すぎるので絶対にやりたくない。
そこで、Slack App にしてサクッと入れられるようにしました。
使い方
/kujibiki {number} from {comma-separated-elements} でくじびきを行なうことができるようになります。
その他の使い方は /kujibiki help で見ることができます。
インストール
下のボタンをポチッとするとインストールすることができます。
なお、現時点では Slack の審査を通せていないので Slack の App Directory には表示されないですし、認可画面にも「This app hasn’t been reviewed or approved by Slack.」と表示されてしまっています。
どうやって動いているか
全然大したことはしてないんですが、簡単に。
Slack command が実行されると、事前に登録してあるエンドポイントに対して POST リクエストが飛んできます。
このリクエストに対してレスポンスを返すと Slack command の結果として表示されるんですが、今回はこの API を AWS の API Gateway と Lambda (Node.js) で実装しています。
API Gateway と Lambda を選んだ理由は以下のようなものです。
- 複雑なことをしていない
- いかなる状態も持たなくて良い
- サーバー代を払いたくない 💰
今後の課題
自分が使えればいいやという感じでつくっていて細かい処理を全然実装してないので、そのあたりをちゃんとしないといけないのと同時に、せっかくなのでちゃんと Slack の App Directory に登録したいと思っています。
ただ、App Directory 登録のためには審査があり、
- アイコン
- インストール説明用ランディングページ
- プライバシーポリシー
- サポートページ
- サポート用メールアドレス
あたりを用意する必要があります。
いい感じのアイコンとか LP を用意するの厳しいなという気持ちがあり、さらにテキストはすべて英語で用意する必要があって「英語のプライバシーポリシーなんてどうすればいいんや……」と途方に暮れています。
おわりに
Slack でくじびきをするためにつくった slash command について紹介しました。
「使ってみたよ」とか「なんか壊れてる」とかあれば @s_osa_ まで連絡していただければと思います。
もし、「アイコンつくるよ」とか「LP デザインするよ」とか「英語のプライバシーポリシー書けるよ」という神がいたらそちらもよろしくお願いします 🙏
報われてほしい人たちと万人のための Web
ちょっと前からぼんやり考えてることがあるので、そのモヤモヤを整理しようと思ったものの、まだ整理できてないのでモヤモヤしたまま一度書き出してみる。
TL; DR
チラ裏
気になっているもの
最近、note というサービスが気になっている。
description によると、
note（ノート）は、文章、写真、イラスト、音楽、映像などを手軽に投稿できるクリエイターと読者をつなぐサービスです。ブログのように使うことも、SNSのように使うことも、コンテンツを販売することも自在に活用いただけます。
とのことらしい。
自分がよく目にするのは主にブログとしての使われ方なんだけど、作者に対して投げ銭的な支援をできたり有料記事を販売したりという使い方ができる。
そして、有料記事というものに対して少し前からモヤりを感じている。 つまり、誤解を恐れずに言ってしまうと、記事が有料であるというところにひっかかりを感じているのだと思う。
「お金を払いたくない」わけではないはず
なお、自分はコンテンツだったり情報にお金を払うことには比較的抵抗がない人間だと思っている。
物理書籍には昔から課金しまくっているし、Kindle も1600冊以上買っている。 App Store でソフトウェアに課金するのに抵抗はないし、某デジタル配信商品を扱っているサイトでもそこそこお金を使っている。
何かをつくっている人や価値を提供している人は尊重されるべきだと思っているし然るべき対価が支払われてほしいとも思っている。
なのに、note の有料記事に対してはなぜかひっかかりを感じていて、その感覚と上記のスタンスの間に矛盾を感じていた。
「無料の Web」という呪い
そこでいろいろと考えてみると、なんだかんだ言いつつも「Web は無料」という呪縛から逃れられていないのではないかという気がしてくる。
Web を日常的に使うようになったのは中学生のころだったが、その頃 Web に転がっていたものはだいたい無料だった気がする。 Web には楽しい無料コンテンツがいっぱいあったし、無料でいろいろなことを学ぶことができた。
一方、電子書籍は生まれたときから有料だった物理書籍の延長線上にあるし、ソフトウェアはパッケージの、映像はディスクメディアあるいはビデオテープの延長線上にある。 だから、心理的に課金への抵抗感が少ないのではないか。
課金は対価にすぎないのか
じゃあ、課金するいう行為が単に何かを得るためだけの行為かというと、そういうわけでもないのがコトを複雑にする。
たとえば、自分は Mozilla Foundation や Wikimedia Foundation などいくつかの団体に課金してるんだけど、これらの団体に課金したところで自分が得る直接的な利益はたぶんほとんどない。
「無料の Web」という願い
とまあ、いろいろ考えてみると、自分は「誰でもアクセスできる Web」が欲しいだけなんじゃないかという説が浮上してくる。
幸い、今は労働者として日々を過ごしているため収入があり、note にある大半の有料記事くらいならまあ払える。
でも、みんながそうかというとそうじゃないと思っていて、自分も数年前までは学生でそんなに余裕がなかったし、もしかすると数カ月後には失職するなどしてまた余裕がなくなっているかもしれない。
自分が学生だった頃には Web にめちゃくちゃ楽しませてもらったし、いろいろなことを学ばせてもらった。 Web に無料で転がっていた情報のおかげで、今の職業に就けているという自信がある。
だから、情報は可能な限り誰でもアクセスできるようになっていてほしい。
そんな気持ちが note へのモヤモヤの原因なんじゃないかなーというのを、現時点での暫定的な答えとしている。
まあ、こんなエラソーなことを言っておきながら、「やっぱり無料がいい」みたいな気持ちもたぶん存在している気はしていて、それも否定しない。
さいごに
最後になったが、note の有料記事が悪いとか嫌いとかいうつもりは一切ない。
ニッチな領域だったり分量がそれほどでもなかったりして、書籍にするのは難しい知見などが有料記事という仕組みで吸い上げられてくると良いなとも思っている。 それに、note に上がってるのも大半は無料記事だし、他のサービスでは今も無料で情報が提供され続けている。
今回、「何かを生み出している人たちが報われてほしい」という気持ちと「誰でも情報に到達できてほしい」という気持ちがあることに気づいたが、それらのバランスの取り方についてはほとんど何も考えられていないし特にスタンスも持てていない、というのが現在の状況。
むずかしいなー。
