こんにちは、GIGのおすぎです。6月某日、株式会社ベーシックにて、Workship MAGAZINEを運営する株式会社GIGとのコラボイベントが開催されました。

イベントタイトルは「エンジニアがスキルアップするための文化・組織づくりLT大会！」。エンジニアがどのよう組織文化・組織作りに貢献し、自分のスキルアップに繋げるかが語られました。

これはさぞ難しい専門用語が飛び交うLT大会になるだろうと思っていましたが、モチベーション管理のお話が多く、これは職種を問わず参考になりそう！　ということで、その知見を当日の様子とともにお伝えします。
 

自分用サービス開発から学ぶサービス作り

最初に登壇したのは株式会社GIGの荒井 雄治朗さん。「自分用サービス開発で学ぶサービス作り」というテーマでお話してくれました。

今までさまざまなサービスを個人開発してきた荒井さん。その経験から「形にする」「いいものを作る」ためのポイントを教えてくれました。

   

「いいね！」って言ってくれる人を周りにおく

個人開発のメリットであり、デメリットでもあるのが「一人」であること。一人での開発作業だと、どうしてもモチベーションが続かなくなる時がありますよね。

荒井さんは、個人開発でのモチベーションの保ち方を教えてくれました。

荒井：「開発からリリースまでを全て一人で作り上げるのって、結構大変です。途中でやる気を失くすことも多々あります。そこでおすすめなのが、『いいね』ってすぐ言ってくれる人に、こまめに自慢することです」

サービスを思いついたとき、サービスがある程度形になったとき、こだわったところを見てもらいたいときなど、自分の成長を周りに報告し、褒めてもらうことでモチベーションを保てるのだそうです。「いいね」とポジティブな声をかけてくれる人がすぐ近くにいると、確かに開発の手が進むかもしれませんね。

   

自分の欲しいものを作ってみる

個人開発のメリットとして「自分で経験して納得できる」ことを挙げてくれた荒井さん。開発段階で経験した「ユーザーは自分が欲しいものを知らない」についての腹落ちエピソードを紹介してくれました。

荒井さんはiPhoneのボイスレコーダーアプリがフォルダでまとめられないことに使いづらさを感じ、アルバムでまとめられるボイスメモアプリを自身で開発しました。その時、あることに気づいたそう。

荒井：「自分の声を自分で聞くと気持ち悪いんです。自分のためにアプリを作ったのに、使いたくないアプリを作ってしまった。私は私の欲しいものがわかっていなかったんです」

このエピソードの優れている点は、荒井さんがデベロッパーとユーザーを同時に経験できたことでしょう。簡単なプロトタイプを作って動かしてみて、早く課題を認識する重要性に気づいたそうです。

荒井：「一生に一度、欲しいものを思ったままに作ってみるのはおすすめです。効率は悪いかもしれませんが、理解すべきことをより深く理解することができます」
   

”巻き込む”エンジニア

次に、同じくGIGの石黒雄介（@kokushing）さんが「”巻き込む”エンジニア」についてお話してくれました。


当日のスライドはこちらです。



石黒さんは「巻き込むこと」を「何か新しいことを始めるときに、周りの人を誘って一緒に始めること」と定義しています。そもそもなぜ個人のスキルで勝負するエンジニアに「巻き込む力」が必要なのでしょうか。

石黒：「エンジニアは技術面のスキルアップを重視されますが、いろんな人とコミュニケーションをとるときに自分からアクションを起こさないとサービスをヒットさせられません。精神面の成長を意識して活動するのが重要です」

巻き込むことによるメリットも挙げてくれました。

• 物事を始めるときに感じるハードルが下がる
• 他人に迷惑をかけては行けないという気持ちから、スケジュール管理をするようになる
• 違う視点からの意見を得られる
• 自分の意見を主張するアウトプット力が身につく
• リーダーシップが身につく
• 実績を残すと仲間から信頼されて、次の仕事につながる
  
  

 

また実際に周りの人を巻き込んでイベントやコンテストに参加したときの経験をお話してくれました。

石黒：「去年の夏、Alexa Skill Awardに同僚を誘ってエンジニア2人、ディレクター1人で参加しました。参加したメンバーが全員同い年で、刺激を与え合いながらスポンサー賞を受賞できたのは良い経験です」

石黒：「また、技術者向けの同人誌即売会『技術書典』に同僚を誘って出店してきました。作ったのはUIの名称と写真、どんなライブラリを実装できるかをまとめた本です」

石黒：「参加して良かったことは『どんなエンジニアをターゲットにするか』『そこに需要はあるのか』『宣伝をどうするか』『印刷コストの管理』などマーケティングの目線を知れたこと、それを役割分担でうまく回せたことです」

石黒さん曰く、巻き込むなら実績が残りやすいコンテストやイベントがおすすめとのこと。どんどん周りを巻き込んでガンガン作るのが、自分の成長に一番の近道のようです。

楽しいOSS開発

続いて株式会社ベーシックの狩野 恭平さんが「楽しいOSS開発」についてお話してくれました。



狩野さんはベーシックで『formrun』を開発しながら、OSS活動として個人でVuexORMのバグを直しています。「楽しく」OSS開発を続けるために、休日にはほとんど活動していないそう。土日の時間を確保することで無理のないワークスタイルを確立しています。狩野さんは自分にあったOSSを選ぶ基準を3つ教えてくれました。

• 身近なものか
• 活発に活動しているか
• どのようなフェーズか

  プロダクトや事業と同様、「0→1」「1→10」「10→100」の各フェーズがOSSにもあるそう。

【各フェーズの特徴と必要なこと】

• 0→1：とにかくわーっと作る。
• 1→10：一人で運用するのが難しくなる。チームビルディングと機能を改修する能力が必要。
• 10→100：機能をどれだけ突き詰められるかが重要。
  
  

狩野：「VuexORMは1→10のフェーズですね。自分の得意な能力を基準にして、どういうフェーズのOSSに関わるのかを選ぶのもいいと思います。全部できる人は全部やればいいんですけど、僕は凡人なのでできることで貢献すればいいかなと」

狩野：「VuexORMでやっているのはバグフィックスがメインですが、メンテナンスをしていても楽しいです。とても泥臭い仕事で、華々しくもないんですが、それでも楽しい。楽しいと継続できますが、辛いことは継続できない。何かを自制しながらのOSS活動は長く続けるのが難しいです」

OSS活動に興味があれば、gemfileやpackage.jasonの中から自分の得意なフェーズのライブラリを探してバグ修正するのがおすすめだそうです。その理由は、バグ修正についてのコミュニケーションは基本的に短文で済み、ディスカッションほどの英語力が必要ないからです。

失敗から学ぶ個人開発

最後にお話してくれたのは、ベーシックのCTOである桜庭 洋之さんです。テーマは「失敗から学ぶ個人開発」。個人やチームでのライブラリ・サービス開発の経験から、なぜ失敗したのか、失敗しないためにはどうすればよかったのかを振り返ってくれました。

   

自分の欲しいサービスを作っていたときの失敗談

【最初から完璧を目指してしまった『seed_builder』（個人開発）】

Railsでテスト用データを自動生成してくれるgemです。完璧にeasyな使い勝手を目指しすぎて要件が肥大化してしまいました。終わりが見えない開発はモチベーションのバーストにつながる恐れがありますね。

桜庭：「最初から完璧を目指すのは無理なので、割り切った仕様にしたほうがいいと思います」

【ニーズのないアプリを作ってしまった『mailcraft』（個人開発）】

指定のメールアドレスに届いたメールデータをAPIで受け取れるメールライブラリです。開発途中に20〜30人くらいにヒアリングしたが、「使わない」と言われて開発をやめてしまったそう。

桜庭：「話を聞いた人がツールを欲しいと思っていないことの方が多いので、誰のために作るのかを明確にしておくべきです」

【中途半端に終わった『pushnate』（チーム開発）】

ブラウザにプッシュ通知するサービス。ディレクターに開発以外を担当してもらっていたそうです。個人開発だったために、他の企業からの類似サービスに優位性を取る施策が取れなかったことが失敗の要因だと振り返っていました。

桜庭：「ずるずると開発・メンテしていたんですが、中途半端にやっていてもユーザーは増えないので、撤退戦略をしっかり決めるべきでした」

【権限移譲した『webpush』】

pushnateの開発過程で配信ロジックをOSS化したものです。ブラウザのpush APIが標準化されたタイミングですぐに公開したので、プルリクやissueをもらいやすい状況だったそう。それにもかかわらず、pushnateのサービス停滞とともにwebpushを自分で使わなくなって、プルリクやissueを溜めてしまったのです。

桜庭：「そこで、初期からコントリビューションをしてくれていた人が手を挙げてくれたので思い切って権限委譲しました。使われてるけど自分にメンテする気がないのなら、しっかり他の人に委譲すべきだと思います」

   

いろんな人に使ってもらうための試行錯誤

桜庭：「権限の移譲をきっかけに自分でももう1回メンテナンスしようかなと思って、いろんな人に使ってもらうサービスを作ろうとモチベーションをスライドさせました」 いろんな人に使ってもらうために必要なことは以下の3つだと桜庭さんは言います。

• 存在を知ってもらう
• 多くの人が使いやすいサービスにする
• プルリクを投げてもらいやすくする

  【必要な機能だけに絞った『LightningQR』『 NotifyHub』（個人開発）】

前者はURLをQRコードに変換するサービスで、後者はGitHubの情報を通知するサービスです。

桜庭：「本当に必要だと思った機能を1つだけに絞って開発したのでだらだらせずに済みました。シンプルなのでデザイン要素が少なく済んだのもよかったです」

【1人で抱え込んでしまった『raysCl』（個人開発）】

プルリクごとに、コードのパフォーマンスベンチマークを自動で計測できるサービスを開発。クローズドリリースまでいったものの、その後凍結してしまいました。

桜庭：「ニーズのあるサービスだったのですが、一人でやるには規模が大きすぎたうえに、ユーザーの使い勝手をリリース前から重要視しすぎてしまいました。巻き込み力を持ってライトな状態からユーザーに使ってもらうべきだったと思います」

【チームの認識をすり合わせたnoco（チーム開発）】

桜庭さんは現在、縦書きできるプラットフォーム「noco」を開発しています。しかし、3人のチームメンバーでそれぞれ実現したいことが異なり、認識が少しずつずれてしまったそうです。

桜庭：「3人それぞれの大事にしたいことと、いつまでにどの状態にしたいかを改めて話し合って定義しました。また、早めにユーザーにヒアリングを行なって、大胆なピボットを行えているのは良いと思います」
   

まとめ

この後もさまざまな人のLTが続きました。

登壇者の皆さんはスキルアップのために、自分で楽しく開発できる環境づくりをするのがお上手でした。エンジニアだけでなくどんな職業の方でも、社会人としてのモチベーション管理について学ぶことが多いのではないでしょうか。

GIGでは毎月社外の方も参加できるイベントを開催しています。connpass上で随時参加を受け付けておりますので、どうぞご参加ください！

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。