Skip to content

Instantly share code, notes, and snippets.

@YusukeKokubo
Last active February 24, 2021 09:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save YusukeKokubo/5e341fedfa05a30ccce0ea59c5d499ab to your computer and use it in GitHub Desktop.
Save YusukeKokubo/5e341fedfa05a30ccce0ea59c5d499ab to your computer and use it in GitHub Desktop.

プロフィール

経歴

(これだけではありませんが、目立つものだけ書いてます)

テレマティクス関連のSIer 2007年9月〜2012年7月

受託開発での仕事だったのであまり語れることがないのですが、テレマティクス関連の仕事でした。 顧客との要件確認をしつつ、社内へのアジャイル開発の普及促進を行っていました。

平鍋さんが提唱するプロジェクトファシリテーションに大きく影響を受けて、社内でもプロジェクトファシリテーターと名乗り、チームビルディングやプロジェクトの見える化に取り組んでいました。 Redmineをゴリゴリとカスタマイズしたり、プラグインをつくったりもよくしていました。

(アジャイルソフトウェア宣言は価値観や原則の話であって具体的な開発手法の話ではありません。その点、プロジェクトファシリテーションは具体的にわかりやすいメソッドとして使えるので平鍋さんはやっぱりすごいなあ、と感心します)

上記リンクから辿れるプラグインはOutdatedなのでご注意ください。

その後、社内では満足できるくらいに開発の体制をつくることができたのですが、受託開発を続けている限りはプロダクトを実際につかうユーザーに満足してもらえるものをつくることがとても難しいと思うことが何度もありました。 プロダクトを使うユーザーに向けて思いっきり開発できる環境で仕事をしたい、と思いから退職に至ります。

このときの課題感とチャレンジ

  • チームで効率よく受託したシステムを開発できる手法
    • アジャイルやスクラムを学習して社内で実践しました
  • マルチベンダー環境でのユーザーにとっての価値ある受託開発
    • 会社間は契約の壁があるため、当時できることはとても限定的でした

(補足ですが、受託開発でも発注先の企業と信頼関係を築いてユーザーに対して真面目に取り組んでいる現場もたくさんあると思います。当時は自分自身が、受託開発とは違う新しい世界を体験してみたい、という思いが強くありました)

クラウド請求書管理のMisoca 2013年12月〜2017年4月

https://www.misoca.jp/

Misoca(当時はスタンドファーム)社が資金調達をおこなった3ヶ月後くらいにジョインしました。 創業者を除くと、フルタイムで開発するエンジニアはMisocaとしては初めてだったと思います。 (当時は自分でファントムタイプという会社をやっていたので、Misocaの社員ではありませんでしたがフルタイムでMisocaの仕事しかしていなかったのでほぼ完全にMisocaの中の人でした)

ソフトウェアエンジニアとしてコードを書きつつ、会社のチームの成長にあわせてチームビルディングをおこなったり、会議体の整理をしていました。

このときの課題感とチャレンジ

  • スタートアップ企業として、チームをどう成長させていくか
    • チーム規模にあわせた会議体の整理
    • 開発プロセスの整理
    • 情報共有の仕組みづくり
  • 自社プロダクトをグロースさせていく方法
    • ユーザーインタビューへの同行
    • デザイン領域への興味関心
ソフトウェアエンジニアとして

いろいろやってましたが、Misocaペイメントと呼ばれる請求書にWeb上での支払い機能を付加する機能の実装をほぼ一人でやってました。(片桐さんという凄腕プログラマーに最初の基礎をつくってもらったので完全に一人ではないです) そこで使ったライブラリについての紹介記事も書いています。

プロセスづくり
チームビルディング

Misocaはスタートアップ企業であり、そういうマインドがもった人が集まっていました。 そのなかで、どういうコミュニケーションの経路をつくれば、チームとしてより高いレベルにいけるのか、試行錯誤しながら取り組んでいました。

UIデザイン

MisocaがiOSアプリを開発するときにTHE GUILDのデザイナーにデザインをしてもらう機会がありました。 このときの体験をきっかけにデザインに興味を持ち始めて、自分でもUIデザインを勉強しはじめてました。

Sketchを使い込んでいたため、自分でプラグインをつくることもしました。CocoaScriptという苦行のような言語です。 (最新のSketchで動くかは自信がないです)

プロダクトマネジメント

機会があればユーザーインタビューに同行し、ユーザーがもってる問題意識やプロダクトへの期待感を調査していました。 Misocaの後半では、エンジニアとしての仕事を止めて、新機能のプロダクトオーナーをしていました。

賑やかし

写真が趣味で、こういう仕事とはまったく関係ない記事を書くのも好きです。

情報共有

チームビルディング、組織づくりのための情報共有にも積極的に考えるようになりました。 もともと前職でプロジェクトファシリテーターとしてやっていた頃から「プロジェクトの状況がひと目でわかるスコアボードを用意する」という考え方に強く惹かれていました。 Misoca時代にはesa(Qiita teamから移行)を使って、有効な情報共有について考えていました。

Misoca領収書 for 楽天市場 2015年4月~6月

https://www.misoca.jp/press/702

楽天市場で消費者の方が物を購入したときに店舗共通で領収書を発行できる機能を楽天市場のアドオンとして開発しました。 このプロジェクトではプロジェクトマネージャー件プロダクトオーナーとして、楽天の担当者の方と仕様の調整や、プロダクトの意思決定を行いました。

プロジェクトとしては、大きな遅れもなくリリースまで至りました。楽天市場の中でも好評のアドオンになり、使用していただける店舗が増えていくのを見ているのは嬉しい経験でした。 特別嬉しかったのは、リリース後に、妻が楽天市場で購入する機会があり、Misoca領収書で出した領収書を見せてくれたときです。自分がつくったプロダクトがごく身近に使われていることがわかり、特に嬉しく思ったのが印象深いです。

(現在は別会社に譲渡されています)


Misocaは何度か追加で資金調達をして、ユーザーも増やして、チームも人が増えてきました。 その過程で、プロセスを見直し、プロダクトを成長させるためにチームの体制を考えて、変えていく過程はとても楽しく、メンバーのみんなとも常に前向きに難しい問題にトライできていました。

何度か資金調達とグロースを繰り返した結果、弥生会計に買収されることになりました。 自分が携わっていたプロダクトが無事にexitし、自分の次のキャリアを考えるようになりました。

ちょうどその頃、東京のカンファレンスで、当時ヌーラボの縣さんに会う機会があり、その後のながれでヌーラボ入社へと至ります。

プロジェクト管理ツールのBacklog 2017年6月〜2021年1月

https://backlog.com/ja

働きかた

Misoca時代にもリモートワークはしていましたが、ヌーラボに入社してからその頻度は高まりました。 ヌーラボは福岡、京都、東京に拠点があり、名古屋からだと新幹線でわりと簡単に移動できるので色んな拠点に顔を出せるメリットがあります。

チームビルディング

ヌーラボでもMisocaのときと同じようにチームビルディングにも取り組んでいます。 やっていることは基本的にはMisocaのときと同じように、チーム内でのコミュニケーションを活性化させて、風通しをよくしていくことです。

プロダクトオーナー

Backlogのインテグレーションのプロダクトオーナーとして、Slack/Chatwork/Typetalk連携をリリースしました。 初めて開発のエンジニア3人のうち2人が入社して初めての長期プロジェクトというなかでチームビルディングをし、3つのチャットツールそれぞれの関係者と同時に調整しながら進める大変さを感じましたが、やりがいのある難しさであり、開発チームともうまく協力することででき、無事にリリースまでできました。 リリース後のユーザーの反応もポジティブなものが多く、安心してます。

エンジニアリングマネージャー

エンジニアリングマネージャー向けのPodcastであるEM.FMを聴いて、自分がMisocaでやっていたプロセスづくりや会議体の整理も、Backlogでやっているチームビルディングも、根源的にやりたいことを突き詰めていくと、エンジニアリングマネージャーにたどり着くような感覚を覚えました。

そして今はBacklogのエンジニアリングマネージャーとして、チーム全体の生産性を向上させる仕組みづくりをしています。(エンジニアリングマネージャーとしてはエンジニアの採用や評価はしていません) 全体の流れを整理しつつ、メンバー個々との1on1を通してチームの活性化に取り組んでいます。

プロダクトマネジメント

Backlogでは15年続く歴史のあるサービスです。 その歴史を整理して、プロダクトが大事にしたいビジョン・ミッション・バリューを整理する手伝いをしました。

コスト削減のための支出管理プラットフォームLeaner 2021年1月〜現職

あいかわらず名古屋からフルリモートで仕事してます。 エンジニア組織づくりに注力しています。

趣味

得意だと自分で思っている or やっていて苦にならないこと

  • プロダクトのミッションやビジョンを整理する
  • プロダクトの成長にあわせた組織の体制を考える
  • 会社に適した情報共有の方法を考える
  • 1on1での対話とメンタリング
  • ミーティングで参加者の視点とは異なる見方から意見を出して議論を活性化させる

ビジョンをもったリーダーとなる人と、それを支えるチームを橋渡しする役になること。組織の中での潤滑油となる動きをしたいと常に思っています。 チームみんなが同じ方向を向いて頑張れることを支援するのが好きです。

また、自分が一人でプロダクトを頑張ってつくるよりも、チームで取り組むことを好みます。 チームで取り組むことにより出てくる刺激であったり気づきであったりが、よいプロダクトを生み出すものだと信じています。

得意ではないこと

  • AWSなどインフラに関する知識
  • 機械学習やデータサイエンス関連
  • 最新の技術への素早いキャッチアップ
  • 社内政治

自分がフィットしそうだと思っている領域

  • A. スタートアップしてグロースフェーズに入った企業にジョインして、成長するチームのチームビルディングやプロセス設計のお手伝いをする
  • B. 軌道に乗ったプロダクトのビジョンやミッションを整理して、組織体制を強化していくためのお手伝いをする

これからやりたいと思っていること

  • 組織の体制づくりと文化づくり
  • プロダクトマネジメント
  • エンジニアリングマネジメント

よいモノづくりをするために、よいチームをつくる仕事をしていきたいと思っています。 自分にとってよいモノづくりとは、エンジニアやデザイナーやマーケターやカスタマーサポートなど色んな立場の人が自身の専門性を出し、お互いを尊重しあいながらプロダクトをつくることです。 そういったチームの一員として、プロダクトのビジョンを描き、ユーザー体験をデザインし、使いやすいユーザーインタフェースをそなえたプロダクトをつくることに携わるのが理想です。

仕事のスタイル

Misocaでも、ヌーラボでも、最初はエンジニアとして日々の仕事をしつつ、組織の問題を見つけ、課題として提案し、改善策を実行していく、という流れでやってきました。 エンジニアチームと一緒に仕事をすることで同じ問題を共有し、同じ目線で改善していくことができていると思います。

仕事にたいしての価値観・信条

個人と組織の関係について

こちらに書いています。社会人の心得4つ

  1. 目の前の仕事に全力を尽くす
  2. 会社に依存した人間にならない
  3. 健康管理は自分の責任
  4. 自分が闘うべき場所を間違えない

チームワークについて

One of them

チームの中のひとりとして、チームへ貢献にすることを考えて行動したいと心がけています。 コンサルタントやコーチという立場でチームに関わるのは好みではありません。外部の立場で意見を言うだけでなく、考えたことを実行することまでコミットしてチームと成功を共有したいと思ってます。 あくまでもチームのひとりとして計画から実行まで責任をもって関わることが自分の仕事にたいしてのスタイルです。

そして、チームとして仕事をすることで、自分が一人で考えていること以上の発見や問題の検知がチームからフィードバックされます。 仲間の意見によって自分が考えてもいなかったアイデアに育っていく過程を感じられることが、チームで仕事をするうえでの大きなモチベーションになります。

Belive in power of team work

プロダクトの問題、チームの問題は、すべてチームの行動で解決できると考えています。 優れたプロダクトは優れたチームによってつくられます。 チームの成果を最大化するためには、メンバーみんなが協調してコラボレーションできる必要があり、それができる環境づくりに貢献したいと思ってます。

No hero

チームにヒーローやカリスマは必要ありません。 自分しかできない、特定の誰かがいないとチームがまわらない。 そういう状況はチームにとって健全ではないと考えています。 そのためにチームへのオンボーディング、チームで共有する情報の透明性にこだわるべきだと思っています。

組織づくりへの考え方

行動はボトムアップから、文化はトップダウンから

組織の文化はトップダウンでつくられる、文化を起こす行動はボトムアップで積み上がる、と思っています。健全な組織ではボトムアップでコラボレーションが起こり、メンバーの多種多様な行動が積み上がっていきます。それが組織の文化として定着するかどうかはトップダウンによって決められます。

例えば、リモートワークをどこまで認めるのか?仕事と家庭のどちらを優先するのか?といったボトムアップの問題提起に対してトップがどのように考えるかで文化が醸成されていきます。

基本は守破離

どんなチームや組織でも最初は守りの姿勢が必要です。 トップダウンな階層だろうと、ボトムアップでフラットな階層になっていようと、基本はチームの約束事やルールを守った上で、破って離れていくプロセスが必要です。

守るべき約束事やルールが曖昧で、透明性のないチームは成長しません。 そもそも自分たちが何者で、どういうチームなのかわかる術がないので、どういう状態を目指したらよいのかわからないからです。

イノベーションは無駄や余裕から生まれる

今の仕事を改善するマインド、プロダクトを改善するアイデアは、余裕があるところに生まれます。

機能開発やマーケティングなど眼の前の課題にぶつかっているだけではどこかで行き詰まります。 ロードマップを計画するときには意識的に余裕を入れることが必須だと考えています。

人生における価値観

  • 人間社会は自然環境と調和して燃費に暮らしていくべき
  • みんなが性別、年齢、職業、国籍、人種にかかわらず、他人や自分に関係ないコミュニティに寛容になれる社会にしたい
  • 環境を破壊し、人類の神経をすり減らす資本主義ではない新たな社会の仕組みが必要とされている
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment