組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
最近は個人開発は自分のOSSのメンテで手がいっぱいになってしまったのでサービス開発のようなものは普段あまりやらないのだが、大学院*1で今学期、何作ってもよいという感じの授業を取ってWeb/iOS/Androidアプリ*2を全て作るという体験をする中で、たまたま個人開発のコストを抑える活動をしたので、その時に調べたり考えたりしたことを書いておく。 Herokuで無料にする Herokuでは毎月550時間free dynoが使え、クレジットカードを登録しておくと更に450時間、合計1000時間無料で使える。Herokuは30分アクセスがないと一旦停止するが、今回授業で作ったサービスでこれを使い切らないことは明らかだったので最初はこれでセットアップした。セットアップも簡単だし、PostgreSQLも無料でついてくる。 ただ、コールドスタートに10秒くらいかかり、これがこのサービスではUX的に致命
ホーム > 「マネージャー不要」という人いますけど、大抵の人はマネージャーが管理してくれないと仕事ができないんです。 こんな記事を拝読しました。 どう考えてもマネージャなんて不要だからそれで上手くいくなんて期待しない方がいい 色んなマネージャがいる。何をやる仕事だろうか？役に立ってる？要らないだろ？って話をまとめたい。 別段批判という訳ではないんですが、思ったことを書きます。 私はシステム関係の仕事をしておりますので、この話を「一般的なシステム開発におけるマネージャーの仕事」の話として解釈してみます。 数人から十数人程度のメンバーが、それぞれ細分化されたタスクを割り振られて、当該タスクの達成を日々のミッションとして働いている現場と、その現場をまとめているマネージャーを想定しましょう。 で、そのマネージャーが不要かどうか、と考えます。 web上で「マネージャー不要論」というものを目にする機会
この記事は私が過去 3 年ほど Kubernetes に携わる中で学んだ、ちょっと見つけにくい知識をまとめたものです。 特にカスタムコントローラーを開発するような人に必要となる知識群です。 感想とか指摘とかあれば Twitter までお寄せください。 更新履歴 2021-03-05: "コンテナの resources.limits と resources.requests の違いについて" の項を補足しました (thanks to @superbrothers) API コントローラー実装 プログラムと連携動作 資源管理 ネットワーク モニタリング アクセスコントロール API kube-apiserver が備える拡張機構を列挙しなさい 回答例 Custom resources: OpenAPI スキーマで独自のリソース型を追加できる Aggregation layer: kube-ap
個人でWEB開発を１５年くらいやってる者ですが
この記事を見てびっくりした。 https://laiso.hatenablog.com/entry/nope-sql 「個人開発のコストはDB次第」 まずビックリしたのは「DBってそんなにお金かかる？」という点。 もちろんDBがストレージ、CPU、メモリを食うのは分かる。 でもVPSならそんなにコストかからんだろう？ 俺は１日100万PVほどのエロサイトを運営しているが、WEBサーバ1台、DBサーバ1台、画像サーバ2台で動いているぞ？ VPS4台で月額6000円くらい。 次にビックリしたのは、個人開発なのに難しそうなDBサーバを使っている事。 「Cloud Firestore」「Amazon DynamoDB」「MongoDB Atlas」 ↑俺、全部知らない。。。 もちろん、こうしたDBサーバの必要性は分かるのよ。 稼働率、安定性、拡張性などなど。 でもそれって、大規模サイト向けじゃない
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして
Rustの勉強に良さげな学習リソースをまとめます。 はじめに Rust学習リソースまとめ The Rust Programming Language Tour of Rust Rust by Example The Rust Reference The Cargo Book Crate docs Rust API Guidelines Rust Design Patterns The Rustonomicon Secure Rust Guidelines Command line apps in Rust おわりに 参考 はじめに こんにちは、@bioerrorlogです。 最近、Rustを触り始めました。 多様な領域で盛り上がりを見せているRustですが、私は最近ハマっているブロックチェーンのエコシステムでRustが使われることが直接の理由となり、Rustに入門しました。 Rustは学習
プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
大規模システムでの Linux のメモリ管理
(This post is also available in English.) この記事は Linux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 cgroup2 プロジェクトでの私の仕事の一部として Linux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、 Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。 昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、 なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。 SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。 といった話題にフォーカスしました。 今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Co
前々からこの手のことを書きたいとは思ってたけど id:k0kubun さんの下記エントリに触発されて書きました。 k0kubun.hatenablog.com tl;dr; 個人アプリ開発歴 前提 Heroku GCP Google App Engine Cloud Run Firebase Cloud Functions GitHub Pages 2022/8/14追記 GitLab Pages 2022/5/7 17:00追記：ブコメレス tl;dr; HerokuやFirebaseを駆使すれば割と無料でいける 若干お金を払えばもっと選択肢は増える 個人アプリ開発歴 2001～2002年あたりから個人HPでアプリを公開。後にVectorにも公開 アカウントは残ってるのでいまだにVectorからのレポートメールが毎月届いてます 2009年くらいから色々ウェブアプリを開発 Google A
７月に水泳の授業を３年ぶりに再開する仙台二高（仙台市青葉区）の複数の生徒から、再開を疑問視する声が「読者とともに 特別報道室」に寄せられた。生徒らは男女が一緒に同じプールに入ることへの違和感を訴える。 【写真】３年ぶりに水泳の授業が再開される仙台二高のプール 同校で水泳は各学年の必修授業だが、新型コロナウイルスの感染拡大が始まった２０２０年度に中断し、球技で代替してきた。宮城県内の感染状況が落ち着きつつあることなどを踏まえ再開を決めた。 県内の高校で唯一、５０メートルの競技用プールがあり、女子は全体の３分の１のエリアを使う。女子は更衣室、男子はプールサイドのテントで着替え、準備運動までは男女ともジャージーを着る。水着の指定はない。 声を寄せたのは、２０年度に入学した現３年生の男女３人。共通するのは「男女混合の水泳授業はおかしい」という点だ。 女子生徒は「男子の視線が気になり、プールに一緒に
AWSの開発環境の利用時間をGoogleカレンダー連動させたら開発チームが自由に使えてコスト70%削減！！ - Uzabase for Engineers
こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発
「教員不足」一刻も早い改善を 専門家が緊急会見 | NHK
今年度も各地の学校で「教員不足」が起きているとして、教育の専門家らが緊急の会見を開き、正規教員の採用増加に向けた予算の確保など、一刻も早い改善を国や自治体に求めました。 9日、文部科学省で会見したのは教育の専門家ら4人です。 会見では、この春も、教員や保護者から、教員不足を訴える声が相次いでいることを受け、先月下旬から緊急調査を実施しているとし、全国公立学校教頭会を通じて、8日までにインターネット上で回答した教頭179人のうち、2割が先月の始業式の時点で「教員不足が起きている」と答えたことを明らかにしました。 会見した日本大学の末冨芳教授は、調査は今月22日まで実施する予定のため、今後の推移を見る必要があるとしたうえで「昨年度の国の調査では、教員不足は2558人だったが、実感としてはもっと多い。『担任の先生がいない』などという状況は、子どもに不安と不利益を生じさせるため、一刻も早い改善が必
社内に投下したポエムを一部修正してリポスト。 「リソース」っていう表現が嫌い 表題の通りなんですが、僕は人間をリソースと呼ばないほうがいいと思っていて、何ならとても嫌いな表現なんです。 文脈上使わざるを得ないときもありますが。 よく聞くような使われ方だと、「開発リソースが足りない」とかですね。 言葉狩りか？と言われるとそうかもしれないですが、日常的に使う言葉というのは結構大事だと思っていて、連想される思考になっていく（あるいはもうなっている）と考えているからです。 「代替可能」を連想させる じゃあどういうことを連想するかというと、リソースという言葉は「代替可能な資源」をイメージしやすいと思うんです。 そうすると、表面上のスキルとかスペックで人間を捉えて、例えば組織編成とか要員計画だとか、なんだかパズルみたいに組み合わせるとうまくいくような気がしちゃうんですよね。 エモい話ってわけじゃない
最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。 前提としてはこんな感じ。 仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない 技術スタックは技術的な実験とか学習を兼ねているので多少オーバースペックになるのはいい お金はなるべくかけたくない 移行前のスタック フロントエンドはNuxt.js、Netlify バックエンドはRailsでgRPC、envoyを噛ませてフロントエンドからはgRPC-Webで呼んでる VPS上にバックエンドのアプリケーションとDB（postgres）を動かしてる バックエンドは普通のRailsアプリにしてHerokuにするのが一番楽でお金もかからないんだけど、gRPC-Webを試してみたくて、そうするとproxyが必要にな
Kubernetesは自分にとって必要なのか
この記事は、著者の許可を得て配信しています。 https://mbird.biz/writing/do-i-need-kubernetes.html 私がチームからよく聞かれる質問がこれです。「スタックをKubernetesでホストすべきか」というものです。技術の世界でKubernetesが話題になっていることを考えると、多くの人がそうすべきだと思い込んでいます。 私は数年間k8s（Kubernetes） を使って仕事をしてきました。非常に強力で複雑なプラットフォームを使うことも多々ありました。 ただ真実はもっと微妙だと思っています。 ここでは、その判断をした経緯を紐解いてみたいと思います。スタートアップや、自社製品のホスティングに責任を持つ、より広い組織内の自給自足のチームを対象とした記事となっています。また、大規模な組織の従来のIT部門の人々にも役に立つ記事になっていると思います。 何
そのトラフィック、NATゲートウェイを通す必要ありますか？適切な経路で不要なデータ処理料金は削減しましょう | DevelopersIO
コスト最適化のご相談をいただくなかで、NAT Gateway に不要なコストが掛かっているパターンが多くみられます。また、そのような環境に限って NAT Gateway にかなりのコストが掛かっていることを把握されていないケースも少なくありません。 今回は見落としがちな NAT Gateway で無駄なコストが発生してしまうケース、何処へのアクセスで NAT Gateway を浪費してるかを確認する方法、そしてどのような改善パターンがあるかをご紹介します。 （本記事中で記載の価格はいずれも、執筆時点の東京リージョン価格を参考にしています） 目次 よくある構成 NAT Gateway に関わる料金のおさらい NAT Gateway 料金 AWS データ転送料金 実際の料金例 何が NAT Gateway を使ってるのか見当がつかない データ通信の方向を確認 VPC フローログから NAT G
第2回 AWS Fargate かんたんデプロイ選手権 #AWSDevDay - Speaker Deck
Find your best for ECS/Fargate 🙌 Talked at "AWS Dev Day Online Japan" 2020.
https://yuru-sre.connpass.com/event/317749/ の LT 資料です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
個人開発を黒字にする技術 - k0kubun's blog
「マネージャー不要」という人いますけど、大抵の人はマネージャーが管理してくれないと仕事ができないんです。
Kubernetes 専門家として知るべき 47 のこと - 誰かの役に立てばいいブログ
Rustの良質な学習リソースをまとめる - BioErrorLog Tech Blog
プラットフォームの上でものを作るということ
インフラにかかるコストを正しく「説明」するための取り組み - クックパッド開発者ブログ
なるべくお金をかけずに個人アプリを運用したい - くりにっき
男女一緒のプールに生徒ら疑問の声 仙台二高、水泳授業３年ぶり再開（河北新報） - Yahoo!ニュース
人間をリソースと呼ばない方がいいと思う - ジムには乗りたい
個人開発のサービスをVPSからVercelとCloud Runに移行した話
不要な DNS リソースレコードは消そう / Delete unused DNS records