エンジニアリングマネージャーになって1年がたった
私は，あるスタートアップ企業でエンジニアリングマネージャー（の，1人）をしている。toB向けSaaSを提供している数百名規模の会社で，社名が少しずつ世の中に知られるようになってきたくらいのフェーズ。会社からはDirectorという肩書をもらっていて，トラディショナルな日本企業だといわゆる部門長の層にあたる。中間管理職の中では上のほうで，執行役員の下あたり，というと伝わりやすいだろうか。 様々な事情（会社が大きくなった，比較的社歴が長い，そこそこの業界経験値がある，自分の専門領域(*1)に社内のフォーカスがあたるようになり，チームをスケールする必要が出てきた，etc.）から，半ば必要にかられて，重い腰を上げてエンジニアリングマネージャーとして活動を始めたのがちょうど1年ほど前。 決してマネージャーとして早咲きのほうではなく，IT業界でのキャリアは15年くらいで，これまではずっとプレイヤー，ま
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
ミルクボーイがアジャイルを説明したら
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
Holacracy と Scrum は共存できるのか
LAPRAS株式会社では全社的にHolacracy(ホラクラシー)という組織体系を導入しています。一方で開発チームではアジャイル開発のフレームワークであるスクラムを導入して開発を進めています。ホラクラシーの思想は個々人が別々の役割を持って、各人が優先順位を決めて主体的に動いていくものである一方、スクラムはだれもがどんなバックログアイテムでもできるのが理想で、プロダクトオーナーが決めた優先順位に従って開発をしていきます。根本的に違う思想を持っているように見える2つのフレームワークが同居できるのか、運用して1年ぐらい経つのでまとめてみることにしました。 ホラクラシー組織のおさらいホラクラシー組織とはティール組織の一種です。より詳細な話は 代表の島田 がいくつか記事を書いているので、それを参考にしてもらうと良いです。参考になりそうなものをピックアップしてみました。 - ホラクラシー組織への誤解と
Redisを使って出入り自由・リアルタイム・日次平均・グループ対抗ランキングを作ろう
こんにちは、FiNCで法人向けサービスを作っているエンジニアのyoshikenです。 今回、グループ対抗の歩数ランキングのシステムを作りました。 リアルタイム更新かつ 出入り自由かつ 日次平均かつ グループ対抗 上記のランキングシステムという少し複雑な要件で実装したので、その際のパターンを各要件のステップごとに分けて説明します！ 写真右の枠で囲った部分が実際のランキング部分目次 Lv.0 日次平均歩数ランキングを作ろう!Lv.1リアルタイム歩数ランキングを作ろう！Lv.2リアルタイム日次平均グループ対抗歩数ランキングを作ろう！Lv.3 出入り自由リアルタイム日次平均グループ対抗歩数ランキングを作ろう！まとめLv.0 日次平均歩数ランキングを作ろう!要件 毎日定時にユーザーごとの歩数が集計されること 実装方法 RDBを使います テーブルはこんな感じ 単純ですね！ Lv.1 リアルタイム歩数ラ
コンテナ技術を捨て、 WASIを試す
こんにちは、NTTの藤田です。 Dockerfileを書くのに疲れた？イメージサイズの縮小で1日が終わった？コンテナの起動が遅すぎる？コンテナ技術と悪戦苦闘する皆様のための新技術、アーキテクチャに依存しないポータブルなバイナリフォーマットと数十μsで起動するsandbox環境を実現する、WebAssembly System Interface（WASI）を試してみました。 WebAssembly System InterfaceとはWASIは、 WebAssembly（WASM）をウェブブラウザ以外の環境で実行するため、 ホストのファイルやネットワークなどの資源に安全にアクセスさせるための仕様です。 具体的には、POSIXに似たAPIが定義されており、WASMのバイナリが、OSが管理する資源にアクセスできるようになります。 WASMは、ネイティブコードなみの速度で動作する、ポータブルなバイ
MIT Scientists prove adults learn language to fluency nearly as well as children
Scott Chacon is CEO of the online language learning company Chatterbug. This week a new paper was published in the journal Cognition titled “A Critical Period for Second Language Acquisition” that used a new, viral Facebook-quiz-powered method of gathering a huge linguistic dataset to provide new insights into how human beings learn language and what effect age has on that process. In a nutshell,
不確実性と道標としてのコンセプト
DMMに転職して以降、キャリアについて話してほしいという登壇依頼が多く似た話をする機会が数回あったのですが、その中でもコンセプチュアルスキルというか不確実性との立ち向かい方について先日社内に投稿していた内容をベースにこちらにも記事化しておきます。（ちなみにペパボのあんちぽさんからのリクエストが記事化のきっかけです。） コンセプチュアルスキルキャリアや長期の目標を検討するとき、そこには 資産（現状自分が持っているスキル・知識・ツールなどのリソース）スコープ環境要素が制約条件として存在しています。 自分の持ち物については理解しやすいですね。今自分が置かれている状況で使えるものを考えてみると、そこにはスキルや資本、時間、知識など様々な自分の資産が存在しています。「今ここ」を検討する上で自分の資産を知るということは分かりやすい要素です。資産を無視した状態で目標を検討しても、その目標を達成することは
コミュニケーションで大事な推論のはしごについて
Amazonでピーター・センゲ, 柴田 昌治, スコラ・コンサルタント, 牧野 元三のフィールドブック 学習する組織「5つの能力」 企業変革をチームで進める最強ツール。アマゾンならポイント還元本が多数。ピーター・センゲ, 柴田 昌治… 端的にいうと「事実を元に、観察者が、選び、意味付け、推測し、結論づけ、情報とし、行動する」という段階をへて推論をはしごを登るように行うということ。人は、このはしごを一気に登って行くことで「自分の解釈を前提とした行動」を行う。 例えば、 「会議中にあくびをしていたAさん」という事実を元に、それを見た人が あくびをしていた（事実）→会議に集中できていない→やる気がない→叱責する、という行動を引き起こすということだ。 ここで、事実は「あくびをしていた」というものだけであり、「会議に集中できていない」や「やる気がない」というのは、観察者が意味づけし推測した結果である
Progressive Web App Progress in iOS 12.2 Beta 1 (Build 16E5181f)
As a regular (and passionate) iOS user with a strong belief in the Web, I beta-test any and all new iOS builds as soon as I can get my hands on them. My main motivation is to see how they do when it comes to Progressive Web App features. Each new iOS version comes with a new version of Safari, yet changes in Safari tend to almost never get highlighted in the iOS release notes (and the 12.2 beta 1
Monorepos: Please don’t!
Here we are at the beginning of 2019 and I’m engaged in yet another discussion on the merits (or lack thereof) of keeping all of an organization’s code in a “monorepo.” For those of you not familiar with this concept, the idea behind a monorepo is to store all code in a single version control system (VCS) repository. The alternative, of course, is to store code split into many different VCS reposi
スクラムチームのためのカンバンガイド by Scrum.org
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。 この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。 目的カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。 この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受
Engineering Managerの難しさTOP3
この記事はEngineering Manager Advent Calendar 2018の14日目の記事です。 株式会社FiNC Technologiesにてエンジニアリングマネージャーやっております清水 @takayuki_shmz です。今は自分の担当の日が回ってしまいそうで焦っております。 今日はEngineering Managerをそこそこやってみて、特に難しかったなぁという点を書きたいと思います。TOP3とか偉そうに書いてますが気をつけてください、n=1の主観100%です。異論は余裕をもって認めます。 まぁ「この世のすべての不利益は当人の能力不足」とのことなので、以後でる話題はすべて自分がマネージャーを始める際の勉強不足が原因なのですが、Engineering Manager界隈も徐々に盛り上がっていますので、僕のただの後悔を書き綴ることで、誰かの役に立てばと思います。 では
101 ideas for agile teams – Medium
a collection of ideas on how to improve team work in an agile team.
海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium
こんにちは。阿部と申します。とある渋谷のIT企業でエンジニアのお仕事をしています。普段はブログを書いていないのですが、お勤め先の社内ブログ用に以前執筆した記事をlean-agile podcastで紹介していただく事になり、当時の記事を今回こちらのプラットフォームでも公開する事にしました。長文になりますが、ご興味を持たれた方は是非ご覧ください。 「海外と日本でのソフトウェア開発職の文化を振り返ってみた」という記事のタイトルにしているのですが、この話のモチベーション・裏付けとしてまず自分のバックグラウンドを簡単に説明しておきます。私は名前によらず外国籍・海外育ちで、今までヨーロッパと日本それぞれでベンチャー・中小企業・大手の仕事環境を６社ほど転々とし、色々な国のエンジニアと仕事をしてきました。 （＊ちなみに、日本語で記事を書くのはあまり得意でないので、言葉遣いがおかしいところは大目に見ていた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PIN Translation
Medium