将来のCTOを迎えるために エンジニアリングマネージャーが半年でやったこと｜miyamoto
カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。 カミナシには現在CTOがいません。 ただ、採用活動は進めておりますので、近い内に採用活動が花開くことを切に願っております。 本記事では、将来のCTOを迎えるにあたり、EMである私が直近半年で何を考え、どんな対応をしてきたかについてまとめました。 カミナシが求めるCTOとはCTOを採用したいという話が挙がった際、カミナシは具体的にどういった方をCTOとして迎えたいのか議論になった事があります。 ここでよく議論の分かれ目になるのが、実務者のTOPとしてのCTOか、経営者としてのCTOか、という2つの観点です。 当然、両方の性質を備えているのが望ましいのですが、究極的にどちらの要素しか満たさざるを得ない場合、どちらを選択すべきか関係者の認識を揃えておく必要があると思います。 結論、カミナシでは経営者としてのCTOを優先した
『ユースケース実践ガイド』をもとにした品質向上への取り組み 全体像を見るテスターの視点はチームへの大きな貢献になる
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでウイングアーク１ｓｔ株式会社の伊藤氏が登壇。つづいて、ビックピクチャーを理解する重要性と、品質向上のために取り組んだ流れを紹介します。前回の記事はこちらから。 ビッグピクチャーとユースケース 伊藤潤平氏（以下、伊藤）：ビッグピクチャーとユースケースです。ジャネット先生と話していると、「ビッグピクチャーを理解しましょう」という話がよくあります。ビッグピクチャーは全体像という意味で、Agile Testing Daysのキーノートでもジグソーパズルの例を出して説明していました。 ジグソーパズルの1ピース1ピースがユーザーストーリーで、これを組み立てると全体像になる、というキーノートでした。あとRSG
「Retrospectives Antipatterns」を読んだ - 勘と経験と読経
先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみた。アンチパターン好きなもので。すごい有用な本だった。 Retrospectives Antipatterns 作者:Corry, Aino,Corry, Aino発売日: 2020/11/02メディア: ペーパーバック 著者サイトはこちらのようだ。https://metadeveloper.com/ 全体的な感想 えてして「ふりかえり」のファシリテーターは孤独だと思う。特にファシリテーションすること自体を主な仕事にしている場合、「より良い
世界規模のクラウド「中の人」の働き方 - メソッド屋のブログ
現在私は、世界規模のクラウドの中の人になって一か月が経過しました。グローバルで、クラウドプラットフォーム自体を作って運用する側はどんなスタイルで開発されているのか興味がある人もあるかもしれないと思ってブログを書くことにしました。これは自分のチームや周りのチームを観察しただけであって、私の所属会社全体がそういうスタイルではないかもしれませんが、何らかの参考になるかもと思い書いてみました。 スモールチーム 世界規模のグローバルなシステムなので、ものすごい大人数で、ものすごく厳密に開発されているイメージがあるかもしれませんが、実際のところ小さなチームの集まりです。自分がアジャイルコーチだったころに学んだことですが、開発は２５人ぐらいのチームがマックスで、Amazon でも two pizza team といわれているように、ソフトウェア開発は少人数でないとまわらないのでそうなっているようです。沢
はてな粕谷氏が実践する「プロダクトを10年運用するチームの作り方」
「以前は『動いているシステムは不必要に触るな』というのが主流だったが、それはもう昔の話。ソフトウェアを取り巻く周辺環境の変化は激しく『インターネットとつながり、さまざまなサービスと連携するソフトウェア』が当たり前に存在している。そうなればOSのバージョンアップやブラウザのアップデート、日々発見される新しい脆弱（ぜいじゃく）性など周辺環境の変更に追従するために、頻繁にシステム変更が発生する」 しかも、スマートフォンの自動アップデートのように、もはやソフトウェアの更新はユーザーが意識することなく実施されるものになっている。ユーザーに意識させずにソフトウェア更新をするためには、テストやデプロイを自動化する「CI/CD整備」「監視の整備」「DevOpsの構築」が必要だと粕谷氏は語る。 Mackerelの場合は管理ソフト「Jenkins」を利用してCIを実現し、サーバ監視にはMackerelを使って
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
積極性と強い問題意識を要求する「振り返り」は、もうたくさん - Qiita
「この人たちのために成長したい」といつも自分を駆り立ててくれる、大好きな職場のみなさんに本稿は捧げます。 はじめに これからの人生で、チームで「振り返り」をする可能性が1％でもある方々に本稿は贈らせていただきます。 皆さんの「振り返り」が行われる前にもう一度、読んでいただき、参考にしていただければ幸いです。 「振り返り」への違和感 「積極性」と「強い問題意識」を持ったメンバーがいることを前提とした方法論ばかりが叫ばれることに私は強い違和感を感じています。 その目的や背景は置いといて、「過去に起きた出来事をチームメンバーと共に目を向ける過程全般」を本稿では「振り返り」と呼びます。 業務改善、PDCA、KPT、スクラムのレトロスペクティブ、といった過程の一部に含まれており、「振り返り」は広く知られた活動と言えます。 しかし、これらの内容は、 「問題があれば主張し、必ず、議題にあげる」という個人
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
