DevOps for Business
1. DevOps for Business 2017/6/6 株式会社アトラクタ 取締役最高技術責任者/アジャイルコーチ 吉羽龍太郎 2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/改善/自動化/クラウド関連のコンサルティングとトレーニングを提供 3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / 改善 / 自動化 / チーム育成 / クラウドコンピューティング / ド メインモデリングなどが専門領域 https://www.attractor.co.jp/
「社内横断の技術組織を終わらせました」を読んで思ったこと - 何でも屋エンジニアのブログ
nottegra.hatenablog.com を読んで、思ったことがはてぶコメントに書ききれなかったから、ブログで書いた。思ったより長くなった。 割りと思ったことベースでそのまま書いているので駄文です。あと、会社の元記事も合わせて読んでいますが、認識に間違いがあったらすみません。 はじめに まず最初に、筆者の方には辛い話を共有していただけて本当にありがたいです。色々勉強にになりましたし、今後私にもこのような知見が生きるときがあると思うので、参考にさせて頂きます。 以下に書くことは誰への批判でもありません。客観的に聞いて考えたことです。 思ったこと 複数の事業部が荒く速く進めていることで生じる問題を抑制するために横断的な別の組織が責任を持つようになると、インセンティブが異なる組織になってしまうが、そこに歪みが発生してしまったのだと感じた。事業部は速く進めようとする方にインセンティブ向くけど
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ
トレタ CTOの増井です。 トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。 当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。 人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。 最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。 私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
