小さなチームのままフルスタック問題を乗り越えたい
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「プロダクト開発チームがプロダクトに集中できるように、専門性の高い技術課題を解決するチームを作りたい」という弊社の組織設計についてパブリックなところに公開してみたいと思います。 理想の組織とフルスタックの限界会社組織が大きくなっても、プロダクト開発チームはできる限り当事者のみで意思決定ができるように小さくしたいと考えています。 そうすることで開発スピードが上がり、その結果ユーザーへの価値提供がより高められるという信念からです。 ですが、プロダクト開発チームを小さく保つということは、各人のスタックを広げる必要があることを意味します。担当を分業するとその分専門性は高まりますが、同時に関係者が増えてしまいますよね。 そして専門性がないと乗り越えられない技術の壁も存在
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
組織の壁みたいなもの
こんにちは、Reluxの篠塚です。35歳の最終日、超大作の1.4万字のNoteができあがりました。書いてみたは良いですが、長すぎてニーズあるのかが実は不安です。頑張ったので、Twitterをフォローしてくれたり、シェアしてくれたらすごく喜び… 経営者ではないけど、自分は5年以上、とあるプロダクト開発組織の初期のメンバーとして関わってきている。 その組織内のエンジニアリングマネージャーであるのと同時に、なんとなく、組織全体の空気感だったりとか慣習を作ってきたうちのひとりだと今振り返ると思う。多分、在籍期間が長いのと、組織のほぼ半分がエンジニアで、それをマネジメントする立場だから自然とそういう立場も引き受け続けてきたのかなーと思う。 そういう中で、やっぱり組織の壁は存在していたし、今もかなりソレと戦っている。5人くらいで開発を始めた当初はしばらくは、非常に良い意味で本当に好き勝手にプロダクト開
事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた
青山学院大学大学院博士課程前期修了後、新卒でニフティ株式会社に入社し、ブログサービス「ココログ」を開発。その後、株式会社はてなの取締役CTOに就き、はてなブックマークの開発などを主導した。フリーランスでの活動などを経て、2016年4月、一休の執行役員CTOに就任。 スターフェスティバル株式会社 柄沢 聡太郎[@sotarok] 中央大学大学院卒業後、ソフトウェアエンジニアとしてグリー株式会社に入社。その後2011年株式会社クロコスを共同創業、2012年にヤフー株式会社へ売却。2015年より株式会社メルカリで執行役員CTO及びVP of Engineeringとして技術領域全般を統括し、エンジニア組織20人規模から数百人規模、そしてプロダクトの急成長に貢献。2020年2月よりスターフェスティバル株式会社に執行役員CTOとして参画、同年9月より取締役就任。 登壇者の自己紹介からスタート。3人の
大企業でプロダクトエンジニアとして働いたら、コーディングのスキルが下がっていた
背景 Shopifyという会社に1年半前に転職しました。あれよあれよと会社が拡大して、現在は従業員一万人弱くらいです。 画像元 公式ではない雑な情報です。あくまでイメージ その前はChartmogulという、せいぜい20人、30人ぐらいの会社にいました。 なぜ表題のようなことを思ったか 面接インタビュアー側として、出題することになるコーディング問題を自分で試しに解いていました。一年半前には自分が受ける側の立場だったので、自分の腕前の定点観測ができました。 やってみてどうだったか。 コーディングにおけるシャープさという観点では明らかに衰えているな、と思いました。問題が与えられて、それに短時間で、論理的に向き合う力とでもいうのでしょうか。 自分は現職でマネージャの立場になったわけでもないので、これはマズイ。なんとなくこの一年くらいそんな気はしていたので、これを機会にもうちょっと深堀してみます。
人月の神話
人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり
一休における開発組織の変遷（目的型組織への移行） - 一休.com Developers Blog
メリークリスマスイブ！ 皆様クリスマスイブはいかがお過ごしですか。 データサイエンス部所属のエンジニア 笹島 id:sisijumi です。 年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 （現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。） 一休における収益の変遷 宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 （近年非上場になった為、直近の収益に関しては資料はありません。） 創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。 事業のステージに合わせて変化してきました 創業期、成長期を支えてきた組織構造 各部署内に宿泊・レストランチームが存在しています 各部署が都度エンジニアのマネージャーとコミュ
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)
The Patternsハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。 1. Stable Teams 2. Yesterday's Weather 3. Swarming: One Piece Continuous Flow 4. Interrupt Pattern: Illigitimus Non Interruptus 5. Daily Clean Code 6. Emergency Procedure 7. Scrumming the Scrum 8. Happiness Metric 9. Teams that Finish Early Accelerate Faster https://www.scruminc.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaste
【前編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡
【後編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力
7年間のCTO人生を振り返ってみる
2015年8月、株式会社ビズリーチにおいてCTOから事業責任者へと職務が変わり、もうすぐ半年が経過しようとしているところですが、一度、7年弱に渡るCTO人生を振り返ってみようかと思います。 CTOとは何をする人ぞCTOとはChief Technology Officerの略。最高技術責任者とも言われます。AWSさんや、TechCrunchさんなどが主催する、CTOを集めるイベントに参加させて貰うと、たくさんのCTOの方とお話する機会もあり、時々、CTOの役割って何なんでしょうね？なんていう話になることがあります。お話を聞くと千差万別、まだ役割が完全に決まっていないくらい、歴史の浅い役割であるということと、結局はトップの一人なので、最終的にはその人ができる限界値が役割になっているのだと思うのですが、ひとつのケーススタディということで、僕がやってきたことを綴ってみようと思います。 サービスの立
プロダクト開発でドキュメントを書かないとどうなるか
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
忙しい人のために「相対見積もり」を超簡潔に解説！｜はち@PIVOT株式会社のProduct Manager
「時間」はみんな平等 どんなに忙しい人でも人は1日24時間しかありません。これはエンジニアも一緒。その中から働く時間を何割捻出するかの差でしかありません。 ただ、仕事に時間を振り過ぎると心身を壊したり、家族との関係性が壊れてしまうのも事実です。 そう考えると大事なのは時間の"量"ではなく1時間当たりの"質"なのではないかなと思います。 その前提を置いて見積もりについて考えていきたいと思います。 アジャイルにおける見積もりとは そもそもアジャイルにおける見積もりに対する考え方は 「完璧な見積もりは不可能」 という立ち位置です。 なぜなら、私たちが取り組む課題は "経験したことはないもの、もしくは状況" 同じ内容でももう一度やると前回より上手になっているので状況は異なります。つまり、全く同じ状況ではないものを予測するのは「完璧」にはできません。 そんな「完璧」にならないもののために私たちは多く
リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう｜mtx2s
ソフトウェアプロダクトをビジネスの中心に据える企業にとって、プロダクトの競争力を高めることは、一番の関心事です。だからこそ、プロダクトをより顧客価値の高いものに磨き上げようと、アップデートを繰り返すことに腐心する。 しかし、残念なことに、魅力的なプロダクトというものは、すぐに競合他社に真似されてしまいます。一度獲得した優位性を、長期間持続することは難しい。むしろ、競争優位性など一時的であることが普通だと考えた方が良い気さえします。 だからこそ、「プロダクトの競争力を高めること」と同時に、「プロダクト開発能力の競争力を高めること」が重要だと、私は考えています。魅力的なプロダクトを作ることに再現性があり、それを短期間で実現できる強い開発組織を作り上げるということです。競合他社も、プロダクトを真似することは簡単にできても、開発能力を真似することはさすがに難しいはず。 プロダクト開発に実行責任を持
開発組織を分散モノリスにしないチーム分割と協働のデザイン - mtx2s’s blog
複数チームに分かれたプロダクト開発スタイルをかえって不自由に感じてはいないだろうか。チーム間に張り巡らされた無数のチェーンが自由を奪い、チームの活動を束縛する。そんな感覚だ。 組織を複数のプロダクト開発チームに分割する組織アーキテクチャは、マイクロサービスアーキテクチャに例えることができる。そこから見いだせる原則は、チームをコンポーネントとして捉え、凝集度を高く、結合度を低く設計することだ。この原則を軽視すると、チーム間の依存関係が互いをチェーンのように繋ぎ、絡み合い、組織全体を「分散されたモノリス」に変えてしまう。その結果として、チームは日々、多大な調整コストや遅延コストを支払い続ける羽目になる。 では、既存のソフトウェアプロダクト開発において、個々のチームが活動しやすい分散型組織の設計とはどういうものだろうか。あくまでも私の経験や考えに基づくものではあるが、本稿はこれをテーマに書いてみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織の持続可能性について
1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断
Startup Tech Night #2 ビズリーチの開発環境などなど
