デジタル庁に入庁して2年ちょっと経ちました。 これまで、周りの人から、デジタル庁どうなん?ってよく訊かれることがあるので、思っていることまとめて書いてみる。そういった質問をされるのは、採用文脈、つまりデジタル庁で働くことに興味はあるが、全く中身にことがわからない、という意味で訊かれることが大半なので、そういった疑問に答える内容にしている。だが、全く参考にならないかもしれない。 前提として、筆者は新卒から民間企業で育ってきて、デジタル庁で初めて行政の仕事をすることになった。民間出身の「民間専門人材」という立ち場で入庁し2年あまり仕事をしている。何をやっているのか、と言われれば、2022-2023年にやったことの個人まとめがあるのでそちらを参照していただきたい。 さて、この記事に書いてあることは、下記のいずれかである。 ①既に公開されている情報をあつめた客観的な事実 ②筆者が感じている個人的な
NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2
人は無能に到達するまで昇進するという「ピーターの法則」というのがある。 「階層型の組織においては、どんな人も、昇進を繰り返すことでいずれは能力の限界に達し、十分に職責を果たせなくなって無能化する。その結果、「あらゆるポストは、職責を果たせない無能な人間によって占められる」という。 https://mba.globis.ac.jp/about_mba/glossary/detail-20919.html グロービスとくにリーダーが劇的な環境変化に異動、転職、抜擢で放り込まれるとこの法則が強烈に作用する。なぜなら周りの方が知識や経験があり自分がその組織内で最もそれがない人になってしまうからだ。一方で、この人は何かしてくれるのでは?という期待を関係者からは持たれる。「組織内で最も無能なのに最も期待される」という特殊状態を過ごすことになる。 12年ほど前に突然、社長をというキャリアチェンジを経験を
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…
はじめに 最近、チームってどんな構成にするのがいいんだろうか?と考えることがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか? チーム間のコミュニケーション(インタラクション)をどう設計するか? 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか? チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、1つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編) アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク(Dmytro Yarmak)氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション)」という興味深いポストをX(旧Twitter)で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション) コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
こんにちは。株式会社ペライチの執行役員開発部長の佐藤です。 ペライチではスクラムで開発しています。 ペライチのスクラム開発は、かれこれ 3、4 年前に 1 つのスクラムチームから始めました。 幸いなことに、チームも機能ごと 4 つに拡大しそれなりに長い期間、スクラム開発を続けられています。 今回はスクラムを始めた導入機から拡大期までの変遷と振り返りを記事にしてみようと思います。 ※この記事はペライチの通ってきたスクラムの歴史を振り返る n=1 のストーリーを記載します。スクラムはこうすべき!というわけでなく、各社ごとのスクラムのスタイルがあって良いと考えている上での記事ということをご承知おきいただけると幸いです。 スクラム導入以前 導入以前は issue ベースで開発案件をエンジニアに都度アサインする形式の開発をしており、CTO から各エンジニアが直接作業指示を受けているような形式を取って
(この記事はVPoE handbookの目次&サマリパートです) 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 (この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。) VPoE handbookを書こうと思った理由まずはなぜ書こうと思った?の問題意識から。 この記事にあるように、三
本記事は BASE アドベントカレンダー 2023 の5日目の記事です。 はじめに こんにちは。 Shop to Shop チームでマネージャーをしている髙嶋です。 役割としてはエンジニアリングマネージャー(以下 EM)と言われるものを想像していただくとイメージしやすいかもしれません。 そんな私から、開発チーム内で取り組んだ10個の実験もとい取り組みについてご紹介させていただきます。 開発プロジェクトを遂行するチームの開発現場をスコープにした話になりますが、一つでも参考になるものがあれば幸いです。 ちなみにチーム構成としては PdM 1名、デザイナー1名、エンジニア5名、EM 1名(私)の総勢8名となります。 最後まで読むのが億劫になる可能性もあるので、この記事で伝えたいことだけ先に列挙しておきます。 出社(オフライン)とリモートワークの使い分けが難しいためにチームとしての活動はリモートワ
トヨタ生産方式(TPS)とはムダを徹底的に排除する生産方式のことで、トヨタ自動車が提唱しました。ジャストインタイムと自働化の考え方をもとに、7つのムダを排除します。製造現場はもちろん、他業界でも取り入れられていますが失敗例は少なくありません。 この記事では、トヨタ生産方式の基本思想や、それを実現する4つの方法をわかりやすく解説します。 生産工程の管理方法にお悩みの方は、工程監視システムの導入もおすすめです。製品を比較したい方は以下より資料請求が可能です。 トヨタ生産方式(TPS)とは まずは、トヨタ生産方式の概要を簡単に説明します。 ムダを徹底的に排除する生産方式 トヨタ生産方式とは、ムダがない生産体制を構築するためにトヨタ自動車が生み出した生産方式です。 かつて戦後のころに弱小メーカーだったトヨタは、技術以外の面で工夫する必要がありました。そこで当時の副社長がムダを省くためにトヨタ生産方
本をよく積みます。よく読むではなく、ともかく積んでいます。 俺たちの本積むスピードには誰も追いつけない(読んでない本、まだまだあるのにまた本を買ってしまう) pic.twitter.com/RxrHrRl8KX — フジイユウジ (@fujii_yuji) 2021年12月17日 毎週土曜の朝から積読を強制的に消化する会というのをオンラインでやってまして、「誰か来るだろうから起きて読まなくては……」と強制力が働くことで本を少しずつ読むことができています。参加者のみなさん本当にありがとう。 時期によって人が増えたり減ったりして、ここ最近は数人しかいない状態なので新規参加者を募集しております。誰でも参加できるので参加してみたい方は連絡くださいな。 というわけで、今日は読んでよかった本をまとめて紹介していきたいと思います(今年じゃないのもちょっとあり)。 まとめてみたらニンゲン的な原理や不合理と
あなたがITエンジニアをやっている限り、そのキャリアの中で1回は思ったことはあるだろう。 プロジェクトが失敗する原因は、コンサルタントのせいだ。 プロジェクトが失敗する原因は、コンサルタントのせいだ。 コンサルタント―――企業の全社戦略や、事業統合のサポート、新規参入戦略など、企業経営のトップレベルに関わる問題解決を謳う連中だ。全員が全員クズだとは言わないが、中には極悪非道なやつもいる。 顧客を財布、しかも巨大な財布だと見なし、知ったかぶりの業界通を気取り、難解な経営用語で煙に巻き、「お客さまと一体となって」嘘八千を並べ、プロジェクトが焦げ付く前にトンズラする、そういう連中である。 やつらが掲げる「最先端の経営理論」なんてものは、たまたま成功した特殊な事例の拡大解釈であり、一般化することはできないのに、法外なコンサルティング料を請求してくる。 それにも関わらず、経営者は喜んで財布を開く。
働き方が多様化した時代にも柔軟に対応し、最短距離で成果を最大化する「チームマネジメント」について、3回にわけて特集した株式会社SmartMeetingと株式会社SmartHRのセミナー。 本記事では、「成果を上げるための会議」をテーマに、『超・会議術~テレワーク時代の新しい働き方』の著者・越川慎司氏が登壇した、3回目のセミナーの模様をお届けします。日本企業における労働時間に占める社内会議の時間割合や、「会議の成功」の定義、そして会議でアウトプットが出ない理由など、さまざまなトピックが語られました。 延べ17万人超の労働時間を減らし、売上を上げる支援 越川慎司氏(以下、越川):クロスリバーの越川でございます。はじめの40分で「815社に対応してきた会議データの実情」と「質と量を改善するためにどうしたらいいのか」といった資料を共有させていただきます。「こうやったらうまくいくよ」ではなくて、実例
会社や家庭、学校などさまざまな集団に存在する「ルール」。細かくルールを設定するとやるべきことが明確になりやすい一方で、細かすぎると窮屈さを覚える人もいるのではないだろうか。 大阪で天然エビ専門の加工会社「パプアニューギニア海産」を営む武藤北斗さんは、工場で働く従業員に向けて、あえて「好きな日に休んでよい」「嫌いな作業をしてはいけない」といった、一般的な職場ではまず見かけない細かなルールを数多く設けている。 「細かいルールこそが人を生きやすくする」と考える武藤さんに、組織を良くするためのルールを作る上で大切にしていることを伺った。 ルールとは一般的に、集団に属する人たちが、秩序を保って行動できるように制定されるものだ。それゆえに「人を縛るもの」というイメージが根強くある。ルールが細かくあればあるほど、息苦しく思えてくる人もいるだろう。 だが、ルールがなければ「窮屈さ」から解放されるのだろうか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く