サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
こんにちは。BASE株式会社上級執行役員SVP of Developmentの藤川です。2023年のアドベントカレンダーも実施したいと思っており、この記事が１日目になります。 自分自身がBASE社に正式ジョインしたのは2014年8月、取締役CTOとして入社しました。僕は２代目のCTOですが、その後、３代目にCTOを渡し、今では上級執行役員SVP of Developmentというちょっと珍しい肩書で仕事をしています。組織としてはCTOの上長でもあり、自己紹介では技術担当役員と表現することもあります。 自分がBASE社に入社した段階ではシリーズBを迎えていました。象徴としては藤田ファンドから出資をいただいてから、上場を意識した組織に変えていくという空気感だったと思います。 BASE社には正式ジョインする前から技術顧問として関わっていて、週一だけ会社にあらわれるおじさんだったのですが、そのタイ
Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない)仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。blog.pragmaticengineer.com また本稿はDeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated toJapanese: https://t.co/4uynyyhm4E The author was transparent andnoted that the article is a modification of an ML-translated article. This person managed to transl
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。スクラムマスターの最も重要な職務である「観察」が行えなくなります。スクラムマスター自身が観察を行わない場合、各メ
トピック部下への任せ方 部下の視座の上げ方 なぜ書くのか？最近、部下と話していて言語化が進んだのでメモとして書いておく。また、いつもどおり書きなぐりの文章です。推敲などはしていません。 前置き今回あえて部下という言葉を使っています。普段は部下という言葉よりもメンバーという言葉を使います。今回は上司と部下の関係であり、上司として私が気づいたことを書くので明確に部下という言葉を使っています。 部下への任せ方仕事を任せることは非常に難しいと思っていた。しかし、難しいと感じる場面が最近減った気がする。その理由を考えたのでメモとして残す。 私は1年ほど前に今の会社に転職した。今は執行役員／VPoEを担っている。入社当初からずっとマネジャーという立場である。最初は研究開発部の副部長という立場であり、数カ月後に部長、その数カ月後にVPoE、さらに数カ月後に執行役員になった。なので、全く現場のことや配下に
この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基本的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという
いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上
absinthe @absinthe9999999 いつも機嫌良く、決して部下に怒らず人材育成に取り組んでいると評判の管理職にその秘訣を聞いた時「ぶっちゃけ期待しないことです。期待するから期待外れの時に怒りが湧く」って淡々と返されてから、結果を出すマネジメントスタイルは様々だと知った。 2021-11-20 21:21:08 absinthe @absinthe9999999 さらにこの人の表現を借りると「早く走る馬と脚の遅い馬に同じことさせないようにしてる」って。 人を人とも思わない感覚でも人を扱うことはできるんだよね。それを表に出すか出さないかだけの話。 2021-11-20 21:24:04
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
視座が高いってそもそもなんやねん問題1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
ホーム > 「マネージャー不要」という人いますけど、大抵の人はマネージャーが管理してくれないと仕事ができないんです。 こんな記事を拝読しました。 どう考えてもマネージャなんて不要だからそれで上手くいくなんて期待しない方がいい 色んなマネージャがいる。何をやる仕事だろうか？役に立ってる？要らないだろ？って話をまとめたい。 別段批判という訳ではないんですが、思ったことを書きます。 私はシステム関係の仕事をしておりますので、この話を「一般的なシステム開発におけるマネージャーの仕事」の話として解釈してみます。 数人から十数人程度のメンバーが、それぞれ細分化されたタスクを割り振られて、当該タスクの達成を日々のミッションとして働いている現場と、その現場をまとめているマネージャーを想定しましょう。 で、そのマネージャーが不要かどうか、と考えます。 web上で「マネージャー不要論」というものを目にする機会
本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。 さらに管理職の採用や評価、機能不全に陥ったチームの立て直し、管理職についてからの技術力の維持など、様々なハードルを乗り越えるための考え方やテクニックを多数紹介。技術系管理職の全体を視野に入れ、各段階で必要なスキルを学ぶ本書は、マネジメントのキャリアを志すエンジニア必携の一冊です。 推薦の声 まえがき はじめに 1章 マ
いまさら聞けない！？ メルカリ社をはじめ、国内でも目標設定・管理に「OKR」を取り入れるチームが増えています。そもそもOKRとは？グーグルやFacebookでも導入され、「飛躍する企業の共通項」のひとつとして注目。解説レポートをお届けします。 ［寄稿者プロフィール］勝木健太 1986年生まれ。幼少期7年間をシンガポールで過ごす。京都大学工学部電気電子工学科卒業後、新卒で邦銀に入行。現場では法人営業、本店では外貨バランスシート経営の企画、グローバル金融規制対応（BaselⅢ、ドッド・フランク法etc）、各国中央銀行との折衝に従事。外資系コンサルティングファームを経て、2016年12月より監査法人にて、ブロックチェーン技術をはじめとするFinTech領域の戦略立案に従事。 OKRメソッドとは？ まずOKRとは「Objective and Key Result（目標と主な成果）」の略で、チー
去年チームでやったワークショップで、みんながどんなチームを望んでいるか話し合ったので、その結果を見て2016年はこんなチームにするぞ！という意気込みと、帽子の使い分けについて話した
In an attempt at damage control, theCEO of the equity management startup Carta, Henry Ward, todayemailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundredblocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
もう定年してますが、郵便局の管理職歴うん十年の父親に社会人の大後輩として、 「管理職としてダメなチームをデキるチームにする必勝パターンみたいなのってあるの？」 と聞いたら 「あるよ」 とあっさり。その話が面白かったので紹介します。 背景父親は郵便局員で公務員だった。郵政民営化する前の話。公務員は一般企業と違い犯罪でも犯さない限り首にならない。（管理の難易度が高い）郵便局の仕事は大きく「郵便」「貯金」「保険」の３つに分かれている。父親は「保険」のセールスマンの管理職を長年やっていた。郵便局の管理職は３年（？）毎に別の局（調布市郵便局とか）に移動する。 1. 新しい職場（チーム）に赴任したらそこの中心人物の協力を取り付ける中心人物：顔役的な人で大抵が年長者やリーダー気質の人。どこの組織にも必ずいて、誰にでもすぐに分かるそうです。（役職的には自分より下の人です。） 父「誰に聞いても山田（仮）さん
「あなたは、同期30人の集まるパーティの幹事になりました。 あなたが最初にすべきことは何ですか？」 －－これは、わたしがプロジェクト・マネジメントを学生や社会人に教えるときに、最初に出すクイズの一つである。出てくる答えはたいていの場合、まちまちだ。「店を探して予約する」「日取りを決める」「参加者を確定する」、等々。いや、パーティといってもいろいろだから、どれを先にするべきかはシチュエーションによる、との答えもありうるだろう。 だが、この問題には、どんな状況にも当てはまる、唯一の普遍的な正解がある、とわたしは続けて説明する。ためしに、ちょっと読者の方も考えてみていただきたい。少なくとも、わたしの勤務先のプロジェクト・エンジニア（＝プロマネ候補生）たちにたずねたら、若い人でもきっと正解を答えてくれるだろう（と思う）。 その答えとは、『計画を立てる』である。どんなイベントでも、(1)計画を立てる
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
