技術的負債より文化的負債を返済できる人材が圧倒的に足りない件
「パンがなければお菓子を食べればいいじゃない」とマリー・アントワネットは“言ってない”そうですね。 そんな事からも、自分の言葉でこのようにブログなど で文章をしたためるのは大事なのかもしれません。 Photo by Youjeen Cho on Unsplashいやね、 「必要な人材が足りなければ、育てればいいじゃない」 なんてフレーズを思いつきまして。なんとなくマリー・アントワネット思い出しちゃった。レッテルって良くないですね。 去る、2021年4月15日 DevOpsDays Tokyo 2021 で発表をさせて頂きました。 話しの風呂敷を広げすぎて、なんだか「上澄み」の発表になっちゃいました。でも、楽しんで頂けたようでなによりです。 そのうち YouTube や記事化が予定されているので、今回観れなかった方は気長にお待ち下さい。 14ケースにわたる文化的負債のお話しをさせて頂いたので
事業内容によって必要なエンジニア組織は異なる - Melting Pot of Thoughts
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
新人の方によく展開している有益な情報 - Qiita
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
技術的に難しいことを力技でやってしまうこと - orangeitems’s diary
まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、本当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え
「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
A guide to distributed teams – Increment: Teams
This guide is a collaboration between:Katie Womersley, VP of engineering at Buffer. When I’m writing, you’ll see this: ● Juan Pablo Buriticá, VP of engineering at Splice. When I’m writing, you’ll see this: ▲ When we’re both writing, you’ll see this: ■ ▲ All teams past a certain size become distributed, whether across rooms, floors, buildings, cities, or continents. But tech is only starting to exp
Event storming - Wikipedia
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) The topic of this article may not meet Wikipedia's general notability guideline. Please help to demonstrate the notability of the topic by citing reliable secondary sources that are independent of the topic and provide significant coverage of it
能力成熟度モデル統合 - Wikipedia
能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、英: Capability Maturity Model Integration, CMMI) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである[1] 。 平易な言い方をすると、ソフトウェア開発組織及びプロジェクトのプロセスを改善するために、その組織の成熟度レベルを段階的に定義したものである。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。 概要[編集] 成熟度レベルの特性 CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを（組織に対して）出すことができる
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
Wantedly Engineering Handbook | Wantedly Engineering Handbook
Amazon.co.jp: Scaling Teams 開発チーム 組織と人の成長戦略 ~エンジニアの採用、マネジメント、文化や価値観の共有、コミュニケーションの秘訣~ (Compass Booksシリーズ): David Loftesness (著), Alexander Grosse (著), 武舎るみ (翻訳), 武舎広幸 (翻訳): 本
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド | Camille Fournier, 及川 卓也(まえがき), 武舎 広幸, 武舎 るみ |本 | 通販 | Amazon
Amazon.co.jp: 図解 はじめての「開発のためのCMMI」とプロセス改善 第2版: 橋本隆成: 本
Amazon.co.jp: カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで: 市谷聡啓, 新井剛: 本
Amazon：ピーター・センゲ『学習する組織──システム思考で未来を創造する』（英治出版、2011）
エンジニアリングマネージャー（EM）は、自らをいつかクビにしなければならない
)
Lava flow (programming) - Wikipedia