こんにちは。Sansan事業部プロダクト開発部 兼 人事部社内コーチの谷内です。 これまで、プロダクト開発の現場でチームリーダー、エンジニアリングマネージャー、プロダクトマネージャーをしてきました。いまはプロダクト開発部 組織デザイングループで開発組織の運営をしています。 先月開催されたSansan Builders Box 2019で法人向けクラウド名刺管理サービス『Sansan』の開発組織の取り組みについて発表しました。 本稿では本ブログの関連記事を紹介しながら、発表ではお伝えできなかった詳細についてお伝えします。 speakerdeck.com 実は話したいことがいっぱいあった 準備段階でいろいろとお話したいことが山ほど出てきてしまい、25分では到底お伝えしきれない量になってしまいました。 こちらはイベントサイトに載せた発表の紹介文です。 どのような開発・組織体制でSansanを作っ

自社の企業文化を誰にでもわかりやすいように「明文化」し、それを「Culture Code」「Culture Book」といった形で公開する企業が増えてきています。 その特徴としては、自社が大切にする文化やバリュー（行動規範）をただ単語ベースで記載するだけではなく、より具体的に「自社のメンバーにどういった行動を求めるか」を表現している点です。 例えば、FacebookのCOOシェリル・サンドバーグに「シリコンバレーから生まれた最高のドキュメント」と絶賛された、Netflixの「Culture Deck」は、その中でも最も有名なもののひとつですね。 ▼2009年に公開された最初のスライド 最新版は同社の採用ページに掲載されていますが、例えば「コミュニケーション」については、下記のように記載されています。 Communication You are concise and articulate

NETFLIXの最強人事戦略 自由と責任の文化を築く 作者: パティ・マッコード,櫻井祐子出版社/メーカー: 光文社発売日: 2018/08/17メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る 2018年に読んだ本でダントツ一番おもしろい本でした。 この本はどんな本か？ Netflixが自社の文化をまとめた「カルチャーデック」という資料をベースとし、Netflixの人事哲学が語られています。 jobs.netflix.com tkybpp.hatenablog.com Netflixの人事哲学 コミュニケーション 徹底的に正直であること。 徹底的に議論を戦わせること。 コミュニケーションは双方向であること いつでも間違いを認め、正しい選択ができなければならない。 そのために徹底的に議論を戦わせる必要がある。 Netflixでは「問題がおこったら当事者同士でオープン

database/sqlの*sql.DB.Pingでerror: bad connectionにはまった話 #golangGo こちらは、Gopher道場 Advent Calendar 2018の19日目の記事です。 私は、MySQLデータベースを用いるAPIサーバの実装において、疎通確認のエンドポイントを作成するために、*sql.DB.Pingを利用したのですが、その利用に際して、設定チューニングが必要な事例があったので紹介したいと思います。 何にはまったの database/sqlパッケージは皆さんよく使いますよね。その中で疎通確認する際に、DB.Pingを利用するかと思います。例えば、次のようなヘルスチェックのエンドポイントを作るとします。 // DeepCheck is health check handler whether database connection is ali

Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab

Goってシンプルで書きやすいですよね。 しかし、シンプルなGoでもいくつか躓きやすいポイントがあると思っています。 その最初のポイントがポインタではないでしょうか。特に、ポインタの概念が存在しない言語から始めた人にとっては、なかなかとっつきにくいものだと思います。そこで今回は、なんとなく使っていたポインタを、ちゃんと理解するためのエントリを書きました。ポインタをちゃんと理解しようとすると、その前提として知らなければならないことが多々あり、そこから説明するので、やや遠回りをした説明になっています。 「これちげえじゃねえか」とか、「ここわかりにくいぜ」っていうのがあったら、ご教授ください。 ※ 技術的な話は「です、ます」調よりも「である、だ」調の方が書きやすいので、以降は「である、だ」調で書きます。 前提知識Part 先ほど述べたとおり、ポインタを理解しようとすると、前提知識が必要になってくる

人の評価は難しい 納得感のある評価 技術力評価会 定量化しない オープンな評価 揚げ足取りをしない 複数人の専門家による評価 社外評価者 ビジネス指向 エンジニアの評価制度の設計と導入 ランクと給与をマッチさせるべきか？ 給与テーブル 市場価値で給与を決定 人を正しく評価する社会であってほしい 参考文献 先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。 人の評価は難しい （エンジニアに限らず）人の評価は難しい。自分も人を評価する立場になって改めて思う。 付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがある

Photo by Wonderlane こんにちは。倉内です。 ITエンジニアを対象にしたアンケート調査で、今の職場環境や仕事内容に不満を感じていると答えた人が挙げた理由でもっとも多かったのが「仕事上の評価が正当でないと感じるから（給料が安い）」という結果が出ています。 でも正直なところエンジニアの評価って難しいですよね…。技術力で測るといっても、「そもそも技術力とは？」に対して簡単に答えを出せるなら苦労しません。 エンジニアの仕事は短期間で結果が出ないものも多いですし、コードが書ければ業績や経営課題への貢献度を一切考慮しなくていいのかという悩みもあります。ましてや頑張り度なんかで測れるものでもありません。 ただ、最近はさまざまな企業が評価制度を公開していて、技術力をどういった定義で評価しているか、制度としてどのような工夫がされているか…などを知ることができます。 そこで今回は評価制度を公

前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・　良い仕様書がもたらす 5 つの効果 ・　仕様書の重要性が増していく 2 つの理由 ・　仕様書に含めたい 14 の項目・実戦編 ・　仕様書作成時に心に留めたい 3 つのこと ・　具体的な仕様書サンプル（

今まで、バンクーバー→バルセロナ→シンガポール→香港で働いてきました。それでいろいろな職場を見てきたので、海外のゲーム会社であった制度について、列挙してみました。 日本の会社でも、既に同様の制度をやっていて、珍しくない場合も多くあると思います。 複数の会社のケースを混ぜて書いています。 ゲーム開発技術に関することは、ほとんど書いていません。 ご指摘がありましたら、修正したり詳細を追加しますので、お気軽にどうぞ（内容が後で変わる可能性があります） 人事（採用） 面接 ビザ リファラル採用 リファレンスチェック（照会） カンファレンス時の招待者限定パーティー 人事（評価） 相互評価制度 OKR（Objectives and Key Results） 人事（解雇） 解雇 PIP（Performance Improvement Plan） スタジオ閉鎖 人事（その他） 若手が海外スタジオで1年間働

Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。

価格高騰が続いているウイスキー。 3000円台で購入できなくなってしまった銘柄も多いですが、今でも1000～3000円台で購入できる美味しいウイスキー銘柄はあります。 今回は、3000円台以下のおすすめウイスキー銘柄をまとめました。

Go 言語の http パッケージにある Handle とか Handler とか HandleFunc とか HandlerFunc とかよくわからないままとりあえずイディオムとして使ってたのでちゃんと理解したメモGo

errorsパッケージの代わりにgithub.com/pkg/errorsを使うと良いです。 自分でerrors.New()しているところ 今から修正するとして、自分でerrors.New()しているところについて、やることはこれだけ。 errorsの代わりにgithub.com/pkg/errorsをimportする 従来通りerrors.New()でエラーを生成する github.com/pkg/errorsを使用しているが、errors.New()の記述は一緒なので修正する必要なし エラーハンドラなどスタックトレースを表示したいところで、フォーマット文字列に%+vを使う サンプルコード package main import ( "fmt" "github.com/pkg/errors" ) func main() { err := level1() fmt.Printf("erro

はしがき 以前、go vetについて触れましたが、 公式以外でも循環複雑度解析をしてくれたりとか、 いろいろ良いライブラリがあるので、その辺の紹介を。(後おまけでvimの設定:p 静的解析ライブラリ 御三家的なアレ。 go vet 前の記事でも紹介したgo謹製のツールですね。 go imports 保存時とかに掛けると、使ってないimportを自動でお掃除してくれたり、追加してくれたりする、賢い子です。 go lint 構文上微妙なものとかをsuggestしてくれます。 私はvimのファイル保存時にgo fmt,go lintは自動で掛けるようにしています :) 静的解析ライブラリ 複雑度、重複コードチェックとか少し凝ったやつ go cyclo 分岐数などのプログラムの構造の複雑さ、循環複雑度を測ってくれます。 あくまで指標なので普段からゴリゴリ使うものでもないですが、リファクタの対象探し

■パワポの色はダサいどうも今回は脱パワポっぽさ！ということで、色をテーマにまとめていきたいと思います！ みなさん、パワポでスライドを作る際、色をどのように決めていますか？ 図形を挿入した時のデフォルトの色を使っていますか？ 図形の塗りつぶしから色を選んでいますか？ もちろん、もともとパワポに設定されているカラーでも問題はありませんが、どうしても普段から目にすることが多いので、パワポっぽさを感じる配色になってしまいます。 今回のテーマ「パワポっぽさを脱却する」ということですから、私がいつもやっている方法を紹介したいと思います！ ■色を決めるのはめちゃくちゃ難しいということを自覚する実際に私がおすすめする方法を紹介する前に、色を決めることの難しさについて話したいと思います。 フランスの国旗（イタリアでもルーマニアでもドイツでもチャドでもポーランドでもいいですが笑）で考えてみたいと思います。もし

システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 9月12日と13日の2日間、都内で開催された日本におけるソフトウェア品質に関する最大級のイベント「ソフトウェア品質シンポジウム 2013」（日本科学技術連盟主催）の特別講演として行われたのが、米谷氏の講演「進化するIT組織と開発スキーム ～リクルートのサービス開発の事例紹介とともに～」でした。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。

LITALICO CTOの岸田崇志(@takish)です。 2017年のアドベントカレンダーもついに最終日となりました。 入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。 特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。 はじめに 筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。 一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。 そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。 成長フェ

若手エンジニアを不幸にしないための開発の「べからず」集　組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい

この記事では、４章２節「人事管理の導入」について記載されていることをまとめました。 （一部４章１節、３節の内容にも踏み込んでいます） 太字部分は私個人が特に印象的に感じた点、赤字の部分は私個人の所感・注釈です フォーマルな人事管理の必要性 人事管理は、次の３つの領域のマネジメントとは明確に異なる。 テクニカルマネジメント チームが技術的な意思決定を適性に下すよう計らう仕事 プロジェクトマネジメント プロジェクトが計画通りに進行、完遂されるよう管理する仕事 プロダクトマネジメント 顧客の望む製品が構築されるよう管理する仕事 「共通の目標を達成するための骨格と筋肉をチームに与えてくれるのが、適正な人事管理なのだ」by ジョー・ゼイビアー 創業フェーズではフォーマルな管理者を設置せず、創業者が直接エンジニアを束ねるケースが多い（アドホックな人事管理） アドホックな管理手法の効果は、チームが成長拡

こちらは グロービスアドベントカレンダー 1日目の記事です。 グロービスの開発組織を作ってきたこれまでの3年間を振り返る形でお伝えしたいと思います。 （1年目の記事もあわせてどうぞ） https://www.wantedly.com/companies/globis/post_articles/85713 自己紹介 グロービスのデジタル部門（グロービス・デジタル・プラットフォーム）で開発チームの横断統括をしている @sue738 です。このデジタル部門に1人目のエンジニアとして3年ほど前に入社をし、開発チームとしても開発文化としても何もなかったところからプロダクト開発を推進し、メンバーを増やし、制度設計を改善し、組織としても大きくしてくる事ができました。最近ではプロダクト開発にはそこまで関わってはおらず、組織全体のマネジメントや制度設計を中心に担っています。 3年経ったグロービスの開発組織

フリーランスプログラマになって、かれこれ10年近く経ってしまった。 昨日をもって退職しました。今日から(しばらくは)フリーランスとしてがんばります。 — 武藤スナイパーカスタム🔫 (@__tai2__) November 30, 2010 会社を辞めて、とくに深い考えもなくなんとなくフリーランスになった。しばらくすればどこかの会社に就職するのかなあ、きっとそうなんだろうなあ、とかぼんやりと思ってたことを考えると、そのまま10年近くも続けてしまったのは感慨深い。 ぼくにとって、ほかの業種、ほかの立場の人の職業生活がどういうもんなのかわからないのと同程度に、ほかの人にとってもフリーランスプログラマがどういうものか、きっとイメージがあまりわかないんだろう。そこで、フリーランスプログラマ生活を振り返って、それがどのようなものだったのかを思いつくままに語ってみたい。フリーランスプログラマという語は

プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 追記

森山大朗(たいろー) Work in Tech! @tairo テック系ニュースを「わかりやすく、直感的に」解説。ビズリーチ→メルカリHead of AI & Search → スマニューで開発がんばったり、最近は生成AIで遊んでます。毎朝6時に配信中の【voicy】はこちら👉 voicy.jp/channel/1232 森山大朗(たいろー) Work in Tech! @tairo とにかく「怒る人」と一緒に居てはダメです。経営者や管理職にありがちだけど、自分の思うように行かないと怒る。期待に応えてくれないと怒る。察してくれないと怒る。怒りの力を「相手を変えるための手段」として使う事に慣れた人からは、人が離れて行くだけ。 2020-08-03 03:22:41 森山大朗(たいろー) Work in Tech! @tairo そういう経営者や管理職に限って「ありえない期待値」を従業員にぶ