タグ

2021年10月28日のブックマーク (6件)

  • エンジニアもマネージャーも、システムを作って課題解決するのは同じ

    この記事ではエンジニア = ソフトウェアエンジニアとして書きますが、適当に読み替えてください。 課題解決をするシステムを作るエンジニアはコードを書いて課題解決するのが仕事マネージャーは組織を作って課題解決するのが仕事どちらもシステムを作るという意味では同じです。 組織を作るというのは、組織境界を引いたり、組織のプロトコルを作ってあげるということです。 組織のプロトコルというのは、ミーティングで話すべきこと、自分で解決してほしいことと相談してほしいこと、組織をまたぐコミュニケーションの方法などです。 処理されなかった例外は人間が対応するプログラムのエラーがアラートされたらエンジニアが対応するメンバーに対応できないことが発生したらマネージャーが対応するメンバーに対応できないことというのは、プロトコル的にマネージャーに委ねるべきと決めてることや、そもそもプロトコル化されていないことです。 組織を

    tmf16
    tmf16 2021/10/28
  • 開発組織で重要なコンウェイの法則ともう一つの原則

    原則を数個決めたら他のことはすべてそれらから導出されるような考え方が好きです。 開発組織の設計あたってはコンウェイの法則というのがよく参照されます。 コンウェイの法則:システム設計は、組織構造を反映したものになる コンパイラーを3チームで開発すると必ず3パスのコンパイラーになる、みたいな例を読んだことがあります。 これが起こる理由は、チーム内でのコミュニケーションコストがチーム間のコミュニケーションコストよりも格段に低いためです。同じチームで開発するシステム内はコミュニケーションコストが低いため密結合になり、チーム間のシステム結合はコミュニケーションコストが高いため疎になっていきます。 これを逆手に取って、最終的に実現したいシステムの形に合わせて組織を分けるのが逆コンウェイの法則です。 大きな単位のシステム設計は、3年、5年、あるいはそれ以上の長期間に渡って影響を及ぼします。ここを間違うと

    tmf16
    tmf16 2021/10/28
  • プログラマ・非プログラマという誤った二分法 - 西尾泰和の外部脳

    イニシエのプログラマからすると、ブラウザ上でブロックを並べたりするのは「ホンモノのプログマラじゃない」と感じるのだろうけど、ビジネスで重要なのは使われてる技術の種類ではなく顧客のニーズを満たせるかどうかだ。

    プログラマ・非プログラマという誤った二分法 - 西尾泰和の外部脳
    tmf16
    tmf16 2021/10/28
  • サステナブルなエンジニア組織デザイン(前編) ~よくある設計とジレンマ~ | フューチャー技術ブログ

    はじめにここ数年来で人材マーケットにおけるIT人材の需要が高まり人材獲得合戦が過熱しています。経済産業省が2018年に公開したレポート「2025年の崖」では2025年にはIT人材不足が約43万人まで拡大すると指摘しています。やや煽り気味だなーと思えるぐらいにメディアも一斉に取り上げました。「今のうちにIT人材を大量獲得せよ!」とトップダウン指示を受けて、人材の囲い込み合戦に参戦して大変になられている人事担当の方も多いだろうなと想像しています。 ※当社ではIT人材をコンサルタント+エンジニア≒アーキテクトと呼称しますが、稿では便宜上エンジニアと表記します。 エンジニアの住む世界迫り来る将来の危機が人材不足というエンジニアの量の問題なのかというとそれは湾曲した認識です。エンジニアはソースコードは短ければ短いほど美しいと思う人種で、クラウドネイティブな作品が増えてきてからはこぞってアーキテクチ

    サステナブルなエンジニア組織デザイン(前編) ~よくある設計とジレンマ~ | フューチャー技術ブログ
    tmf16
    tmf16 2021/10/28
  • なぜ「エンジニアリング組織」は「エンジニアの組織」だけを考えてはいけないか

    Amazonで広木 大地の{ProductTitle}。アマゾンならポイント還元が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽しみいただけます。 決して「エンジニア」と「エンジニア以外」で組織論を分けて語るべきではありません。 サービス開発技術の進化10〜20年前は、30人とか50人とかのチームで一つのウェブサービスを開発していました。大規模開発という言葉がぴったり当てはまる時代でした。 そういう開発スタイルだと、課題解決のためにはまず課題を定義し、エンジニアチームに依頼して、開発されて完成品が出てくる、というやり方でやらざるを得ませんでした。 その反動が2001年のアジャイルソフトウェア開発宣言です。アジャイル開発では、チームで必ず毎週(毎イテレーション)仮説検証をすることを義務としています。 毎週仮説検証をする

    なぜ「エンジニアリング組織」は「エンジニアの組織」だけを考えてはいけないか
    tmf16
    tmf16 2021/10/28
  • ピザ2枚ルールは手札8枚を揃えるゲーム

    人数を増やしたくなったとき人を増やしたいと思っても、まずは絶対に8という数字の死守を考えましょう。 エンジニアが足りないなら、スコープを絞りましょう。8人オーバーするより絶対マシです。または開発環境の効率化を最重要課題にしましょう。開発環境効率化の業務委託を入れるのも手です。 サポートが大変なら、サポートを減らすことを最重要課題にしましょう。外部ツールを入れるだけでだいぶ効率化するかもしれません。またはチームで捌ききれない問い合わせを外に投げることを考えましょう。 どうしても増やすなら、10人までは増やして11人になったらチーム分割するのが良いと思います。(10人まで増やして良いと言うと増えちゃうので、増やしたら毎日チームで腕立て伏せ100回やってください) チーム分割チーム分割には2つのパターンがあるかと思います。 一つは専門職チームを切り出すパターンで、もう一つはPDCAチームを横に増

    ピザ2枚ルールは手札8枚を揃えるゲーム
    tmf16
    tmf16 2021/10/28