Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

「kubernetes」を含む日記 RSS

はてなキーワード: kubernetesとは

2024-10-17

はてなスターの★数字

★100★は100個のスターが付いていることを示しているのではなく、★と★の間に100個あることを意味する。

まり両端の2個と合わせて102個のスターが付いている。

i18n(internationalization)やK8s(Kubernetes)のようなIT業界オサレ表記って奴か。

空と君とのあいだにある地上の星の数ともいえる。

上の表記PCはてブで見られる。はてブアプリの★100は数字通り100個。

2023-12-16

Kubernetes

火にくべるねってす(クベルネテス)ごい思想が強い

なんつって

ちょっと苦しいか

ふふ

2023-12-09

GoogleのGeminiはジェミニで確定だが

日本人にとっては「ジェミナイ」より「ジェミニ」のほうが言いやすいからってだけで、ジェミニ言語的に正しいからとかではないよね。経緯はよくわからん複数音写がそれぞれ正解として採用された外来語はたくさんある。

逆に日本人認識しづらい外来語というのもあって、「ユグドラシル」「タイコンデロガ」あたりは昭和オタク達を大層悩ませたと聞く。往年の人気シリーズ「それゆけ宇宙戦艦ヤマモト・ヨーコシリーズに「聖夜のユグドシラル」という本があるくらいだ。インターネットがなかった当時は資料集めも大変だったということなんだろうが、じゃあ現代は手軽に英語動画発音確認できるから表記揺れ問題もなくなったかと言えば全然そんなことはなく、たとえばこないだのOpenAIお家騒動話題になったIlya Sutskever氏は「サツキバー」「サッツケーヴァー」「スツケヴェル」など6パターンくらいの表記をされていた。ポッと出のマイナーキャラだし表記が定着してないんでしょという意見もあろうがまあその通りである。じゃあいずれ正しい表記に落ち着くのかといえばそうはならないのが面白いところで、たとえば10年来エンジニアを悩ませてきたKubernetes英語圏では明らかに「クーバネーティス」なのだ日本語では「クベルネテス」「クベ」に落ち着いている。だからGeminiはジェミニに決まってるのだが、しかあらためて見てみると「ルクソール」と「ラクソー」、「アテナ」と「アシーナ」のようなアクセント位置が変わるやつにくらべれば、「ジェミニ」と「ジェミナイ」の発音には然程の差がないようにも感じる。根本的には発音が難しいというより「巻き舌とか恥ずかしいし・・・」というのが理由なのかもしれない。

2023-07-31

anond:20230731104947

最近最前線から離れててあんまり追えてないけど、現役のとき2008年くらいか10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。

分野にもよるし、調査して試作した結果自分業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。

あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応テスト手法進化もけっこうカロリー高いけどここには書いてない。

自分フロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからいか普通リスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要

ソーシャルコーディング(GitHub)

スマホアプリ(iOS, Android)

NoSQL(memcached, Redis, Cassandra)

暗号通貨

クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)

CI/CD(Travis CI, CircleCI, Jenkins)

トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)

システム(Rust, TypeScript, Haskell)

テスト自動化(xUnitSelenium)

クリーンアーキテクチャ

コンテナDocker

オーケストレーション(Ansible, Kubernetes, Terraform)

機械学習(Python, MATLAB, 線形代数数学知識)

HTML5(WebGL, WebAudio他)

SPA(React, AngularJS, Ember.js, Vue.js)

マイクロサービスアーキテクチャ

3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及

GraphQL

機械学習ライブラリ(Tensorflow, PyTorch, Chainer)

Jupyter Notebook

NFT

モバイルアプリフレームワーク(React Native, Flutter/Dart)

シングルサインオン

多要素認証生体認証

メタバース

2023-07-08

金曜日オフラインイベント参加して勉強なるわぁって気持ちよくなってた裏で、自分が先月まで担当してた機能バグ問い合わせ。

しかリリース1週間前。

リリース担当者がめっちゃ頼りになる人だったから、担当関係ない機能なのにサクッと突き止めてなんとかなってたけど(後でSlack見て経緯を知った)、こういうの自他共にしんいね月曜日には謝罪行脚やな。。。

PRレビューしたの自分からって上長は言うけど、そうじゃねーよおおおおおおお。

昔、前にいた会社で、コミュニティイベントで著名な人がKubernetesアプリモダナイゼーションの普及のために自分会社にも支援で来たけど、ニーズと違ってたらしく、「意味ねー」「そうじゃねーんだわ」ってボロカスに陰口言われてたのが記憶にあって。

自分プロジェクト兼任のCCoEメンバーとして、新技術導入だったり、開発基盤の保守だったりって活動従事してるのだけど、日常的に「そういう布教活動は足元安定して初めてしていい仕事」だとひしひし感じてる。端的に言えば、あの人は仕事ができると見なされないと誰も聞いてくれない。

そういうこと込みで今回のはまずかった。

今までもワイもそういう部類じゃね?とか一瞬でも過ぎることが1ヶ月ぐらいに1回はあって、頭ハゲそうになってるのに。

から今回みたいなのはホントダメだわ。

どうしてトラブルになったんだっけ、から見直さないとな、(´Д`)ハァ…

2023-05-27

はてな退職エントリを書いています

私は約3年間、はてなエンジニアとして働いていました。

この期間に、様々なプロジェクトに関わり、多くのことを学びました。

今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います

 

## RailsでのWebアプリケーション開発

はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。

はてなログはてなブックマークなどの有名なサービスはもちろん、社内向けのツール新規事業プロトタイプRailsで作っていました。

Railsは、高速に開発できるというメリットがありますが、それと同時にコード品質パフォーマンスにも気を配る必要があります

私は、テストリファクタリングコードレビューなどの技術的なプラクティス積極的に取り入れることで、Railsの開発をより効率的安全に行う方法を学びました。

例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。

また、Pull RequestやPair Programmingといった方法を使ってコードレビューを行い、バグ改善点を見つけたり、知識ノウハウを共有したりしました。

 

## クラウドサービスでのインフラ構築

また、はてなでは、AWSGCPなどのクラウドサービス活用してインフラを構築していました。

私は、DockerKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーションインフラストラクチャ・アズ・コードなどの技術実践しました。

これらの技術は、開発環境と本番環境差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。

私は、モニタリングロギングアラートなどの技術的な仕組みを整備することで、インフラ運用をより安定的信頼性の高いものにする方法を学びました。

例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステム状態パフォーマンス監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。

また、ElasticsearchやFluentdといったツールを使ってログ収集分析を行い、原因究明や改善策の検討に役立てました。

 

## チームでの協働

はてなエンジニアとして働くことで、私は多くの技術的なスキル知識を身につけることができました。

しかし、それ以上に大切だったのは、チームで協力して問題解決することでした。

はてなでは、エンジニアだけでなくデザイナープロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。

私は、コミュニケーションフィードバックドキュメンテーションなどの技術的ではないスキル重要だと感じました。

私は、自分意見提案積極的に発信することで、プロダクトやサービス品質価値を高める方法を学びました。

例えば、私が参加したプロジェクトでは、SlackZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。

また、FigmaMiroといったツールを使ってデザインアイデアの共有やフィードバックを行いました。

 

## 退職への決断

私は、はてなエンジニアとして働くことがとても楽しく充実していました。

しかし、私は自分キャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。

私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。

そこで、私はこの度、はてな退職することにしました。

私は今後、別の会社エンジニアとして働く予定です。

 

## おわりに

はてなで働いた3年間は私にとってかけがえのない財産です。

私は、はてな出会ったすべての人に感謝しています

に私が所属したチームのメンバーには大変お世話になりました。

彼らから学んだことや刺激されたことは数え切れません。

彼らと一緒に仕事ができたことを誇りに思います

彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います

 

以上、AIによるフェイ記事です。

どの程度、真実味がありましたか

2023-04-29

29歳正社員Webエンジニア副業のためエージェント登録したけど壊滅だった

基本はPHPer歴長め CakeとかLaravelとか触ってて、フロントエンドVueが一番長かった

最近はTerraformでGCP/AWSインフラ構築したらKubernetes触ったりGoとかScalaを触ってる

現在年収は650万で、年収を更にあげたく副業のためにエージェント登録してみた

ただ、8~18時が基本本業で埋まってるということで、なかなか厳しい世界になるのは予想していた 一応フレックス制で間1~2時間とか抜けれることは抜けれる

言われたことはこんな感じ


いやーやっぱ厳しいなぁ、副業やりたいってバイタリティだけじゃどうしようもない世界だったわ

そらググっても出なかったもんなぁ土日だけでOKみたいな案件

なんか知り合いの話聞いてるとコネかこっちから制作会社営業かけてるような人多かったから、そういう方向で頑張るしかないのかな

意欲だけはあるんだけど、ぶつける場所がねえわ

2023-01-12

anond:20230112221133

・色んなこと満遍なくやりたい

・やべー案件に何年も磔にされたくない

これが多様なサービスアプリ作ってみたいという話なら高単価SESに行くしかない。

かなりの経験を積んだベテランじゃないと入れない世界出身学部も見られるから相当に厳しいと思う。

フロントバックエンドインフラなどもやってみたいという話なら自社でウェブサービス運用している上場企業正社員で入るのがいいだろう。

ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。

派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。

ここでは俺の経験を踏まえて「自社でウェブサービス運用している上場企業正社員で入る」という前提で話す。

アピールすると良いのは使える言語インフラの知見、構築と運用経験

全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。

使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身コード書いてたなら当然できるよね、というレベル

今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。

分かってると思うが言語が使えるというのは、まっさらPCを与えられて主要なウェブフレームワークセットアップしてローカルホストを立てるとこまでを含む。

JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjangotypescriptならNode+React+knex、あとJestかDreddも入るかな。

インフラ知識では、クラウドオンプレ両方のメリットデメリットを把握しているとよい。

AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人GCP契約してkubernetesVM、LBを使っている。

ネットワーク知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか?レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。

LetsSSL証明書を作ってopenssl検証してnginx適用してHTTPS化ができるならアピールになる。

dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。

構築と運用では、予算内に収まるような構築と運用サービスインした後のトラブルシューティング経験があるとよい。

常にコスト意識を持っていることが必要クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。

トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。

サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識必要

CI/CD、PrometheusやDatadogによる監視アラートについて語れるとよい。

CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsコンフィグもできるということである


どうだろう、かなり雑に書いたが雰囲気は伝わると思う。

あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。

2022-10-13

anond:20221013190032

CCNAは受けたことないし、インフラ系は実務経験あるだけで体系的な勉強してきてないから自信ない。

というわけで、ちょっと調べたのと観測範囲での印象だけの話になっちゃうんだけど、ネットワークエンジニアじゃなくてインフラ系を名乗るんであればCCNAだけだと足りない気がする。

あと、今からインフラ系を目指すんであれば、Kubernetesみたいなコンテナ使って大きめサイズなことやるときに多少プログラミング(と言っていいか微妙だけど)することからは逃れられないんじゃないかと。

そうでなくてもサーバーいじりは多少シェル書けないと始まらないみたいな雰囲気はある。

そうではなく、ネットワーク専門の、特にセキュリティに強いエンジニアはそれだけで十分需要あるから、そっち方面スペシャリストになるのもありなのかなと思う。

セキュリティ理解攻撃したりされたりっていうのを実践してみたり観測するのが近道だと思うから、とっかかりとしてはそういうハンズオンを探すか、YouTube漁ってみるか、あるいはCCNA取った時点でネットワークエンジニアとして実務経験積みながら学ぶのがいいんじゃないかな。

ふわっとしててごめんよ。

anond:20221013145402

ほいノ

学歴

中学ん時の偏差値は60くらい。

高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。

もう全然馴染めなくてさっさと中退

17歳までニート

18歳までフリーター

18歳〜21歳まで定時制に通った。

英語個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルバカ校。

大検で足りない単位取って3年で卒業した。

職歴

21歳〜24歳まで契約社員

この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。

24歳でうつになって、30歳くらいまで日雇い派遣無職を半々くらいでリピートしてた。

30歳で製造業正社員になった。

これが人生初めての正社員だった。

やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。

この時にプログラミングを始めた。

33歳で正社員社内SE転職

年収めっちゃ下がった。

34歳でWebスタートアップ転職

ここで年収どんどん上がった。

36歳でうつが再発して辞めて今に至る。

プログラミング遍歴

略歴・技術スタック

基本は、仕事で使えそうなもの必要ものをその都度吸収していった感じ。

Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。

言語的なやーつ
Excel VBA 1年
VB.NET半年
JavaScriptNode.js 4年
HTML 1年
SQL 4年
GAS 3年
C# 1年半
TypeScript 2年
Java半年
C++半年
ラダーFB三菱シーメンス 1年

実務経験があるって胸張って言えるのはこれくらい。

大体習得順。

他には、Python、Julia、R、Fortran、Rust、GoDart、Shell、Deno、CSSなんかは少しずつかじってる。

最近Webに関してはほとんどJSTS)で済む感じになったので楽。

なんでPLC最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。

それ以外のなんかなやーつ

RDBPostgreSQLSQL Server、MySQLSQLiteの順で実務経験あり。

NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。

PaaSGCP(Firebase)、AWSの順で実務経験あり。AzureADVM周りをちょっと触った程度。

Dockerはよく使うけどKubernetesとかまでは行ってない。

後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本ドイツアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。

閑話休題

俺のキャリア形成方法と、簡単アドバイス

まずはカイゼンをしよう

フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん?

から、その時間をまず有効に使う。

以下、俺の場合ね。

次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない?」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。

作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るからイラッとして仕事用のPC勝手Excel業務日報を付けるようにして、イントラファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。

それだけでめちゃくちゃ喜ばれる。

で、今度はその次長が「この製造番号どれくらいの時間作業終わった?」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。

それでまた、めちゃくちゃ喜ばれる。

俺のプログラミングの始まりは、ひたすらそれの繰り返し。

最初プライベート時間結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分スキルアップに直結する時間を作れるようになる。

自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって?てのを考える。

これがカイゼン英語Kaizenって言っても通じる。

ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。

大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。

https://ifttt.com

これはiPaaSっていうサービス一種で、まあ言葉意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス

例えば、あなた日雇い会社にいて、毎日違う現場に働きに行くとする。

で、出勤前、現場到着時、勤務終了の時にLINE毎日報告しなきゃいけないとする。

で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。

面倒くさいし、お金がかかる。

そこで、「特定グループLINEを受信したら(イベントA)、特定Googleスプレッドシート情報を記録せよ(イベントB)」っていうのをIFTTT登録すると、少なくとも事務員入力の手間は省けるってえ寸法だ。

IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。

プログラミングを学ぶならN予備校

月1000円で学べる。コスパは圧倒的。

テキストベースだけど、Web講義とかチャット質問できる。

入門コース学習に180時間と公称してる)がしっかり理解できていれば、Webで大抵のものは作れる。

ただし、大筋は問題ないんだけど、細かい部分で最新技術キャッチアップできてない可能性があるので、そこは注意した方が良いかも。

https://www.nnn.ed.nico/pages/programming/

安定志向なら中小企業社内SE転職する

N予備校の入門コース終わらせたら、基本情報技術者応用情報技術者を取る。

そしたら、職歴書の作り方次第で中小企業社内SEにはまず転職できる。

中小企業社内SEは、ITリテラシーの低い社員が多い中で「Excelセルの色が変わらなくなっちゃったんだけど!」とか「複合機が紙詰まりって言ってるけどその紙が見つからない!」とかクソイージークエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。

ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。

けど安定なのは間違いない。

上昇志向なら中小製造業生産技術転職する

N予備校の入門コース終わらせたら、基本情報技術者応用情報技術者を取る。ここは社内SEと同じ。

生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。

あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。

で、中小企業生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。

IoT最近セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。

そこに滑り込むのはアリだと思う。

まとめ

よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。

ま、橋渡しって自然プロマネとか任されがちで、裁量大きくて大変なんだけどね。

質問あればどうぞ。頑張って。

2022-09-19

anond:20220919145347

TerraformとかKubernetesとか

Rustとか

なんちゃらJSとか

かいがくしゅーとか

2022-07-27

anond:20220726084330

雑魚エンジニアがよく使う言葉ももはや禁止されとるやろ

2022-05-21

零細Saasベンチャーから競合のSaasメガベンチャー転職した

表題の通り。当方エンジニア

前職と比較すると平均技術レベルマジで変わったように感じる。

前職だとクリーンアーキテクチャやらCI/CDやらは言葉意味すら知らない人も多かったけど、

今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。

FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、

凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値めっちゃ上がるんだろうなって感じもある

コード品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル

命名として若干ニュアンス違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し!」みたいなのは容赦なく潰される。

ペアプロモブプロしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。

会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらはいる。

開発手法アジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんセオリーに則ってる形で管理されている。



ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね?」っていうのもまた感じた。

そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値提供できてんのかなこのサービス?っていう感じというか……

前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。

動いてるものが同じなら採用技術オンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、

NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん?

難易度の高いイケてる技術スタックを使う=必然的エンジニアのお賃金が高くなるってことだから経営者視点から見てもこういう選択って果たして正しいのかなぁって。

なんならエンジニア賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。

どう思うよ。

2022-04-22

広告業界転職したエンジニアなんだが

パフォーマンス求められて言語GoやらRustやらScalaやら使ってて

大規模分散処理やストリーム処理、BigQueryやらKubernetesでの環境構築やら、俺はやってないけどやろうと思えば機械学習での最適化とか、

まあ今の仕事続けてたら将来独立したときかに割りと単価上がるんだろうな―、って感じはあるんだけど、

仕事自体社会の役に立ってるかって言われると、まあない方がWeb全体の居心地はよくなるんだろうなっていうのも薄々感じてる

お仕事ってそんなもんかな

2022-03-08

AWS大先生質問なんだけど

インフラほとんど未経験

転職先がどうやらKubernetes構成管理してる会社で俺もその管理に関わる立場になるっぽいのよね

で、正式入社までの間にAWSのEKSにKubernetesで構築したWebアプリデプロイして軽くロードバランサ設定とかそういうの実際に触ってデプロイしながら勉強したいと思うんだけど、

ただそもそも大規模システム向けなサービスだしこれ金額面とか大丈夫かなって心配してる

想定はnuxtサーバ+バックエンドサーバ+DBサーバ適当アプリ作ってバックエンドサーバ辺りを分散構成かにしようかなと思ってる

実際の運用目的じゃないから使わないときはすぐ消すしそんな超スペックみたいな構成じゃないと思うけど、個人ポケットマネー(できれば1万円以内とか)とかでも行えるものかね?

2022-03-05

弱者男性今日の出来事

起きた時点で13時過ぎ。最近平日あんまり寝れてなかったからかスマートウォッチアプリ開くと8時間以上寝てたみたい。

起きてすぐ卵入り袋麺とか素麺とか食べながらTVer座王脱力タイムズ、dアニメからかい上手の高木さん最新話を視聴。

終わると洗濯掃除をぱぱっとやって外出。徒歩で近所の大型ダイソーへ。

麻婆豆腐用のちょうどいい深さと広さがある皿、和洋折衷デザインスープ容器(300円もした)、金色スプーン無印パクリっぽいティーカップとかを買う。

買う予定だった充電池が全部売り切れててどうせ転売ヤーのせいだろと軽くムカつく。

その足で大型書店へ。最近転職決まったのでそこで必要になるKubernetes関係の本を立ち読みして続きはKindleで買うことにして帰宅

家に帰ると先日Steamセールで買った大逆転裁判を1時間くらい遊んで丁度いい時間になったので夕飯へ。

昨日作って余った麻婆豆腐カレールーをぶち混んだだけの雑料理。麻婆ならもう少し戦えると思ったがカレーが強すぎて8割くらいカレーになった。スープサラダ今日買ったオシャレ食器を使った。

転職先はgo言語使うらしいので勉強用にはてなブックマークRSSから記事情報を読み取ってDBに保存・表示するWebアプリを開発。

昨日でORマッパーの検証作業まで終わらせたので取得バッチ実装まで終わらせたい。

いつもやってるLAMP環境なら半日もかかんなそうな簡単アプリだけど勉強用にgo+Kubernetes+gRPC+nuxt+AWS実装する予定なのでWeb部分はかなり時間かかりそう。

あとはYoutubeで何個かインフラクラウド関係技術動画を見るのと、さらば青春の光佐久間宣行の土曜更新分のYoutube動画を視聴。時間が余ったらアマプラの新恐竜も見たい。

時間が足りないので動画系は全部CMカット+2倍速。

あとは今日立ち読みしたKubernetes関係の本を購入して第1章くらいは読み終わりたい。

ゲームとか動画視聴はいろいろやってるけど今日は寝るの遅くなりそうだし勉強検証作業で6時間くらいは費やすことになりそう。まあそこそこ忙しい。

なにげに勉強予定あると酒飲めないのがよくないね

これが弱者男性日常だ、恐ろしいか

2022-03-04

ヤバい間違えてめちゃくちゃレベル高い会社内定決まっちゃった

年収は250万くらいアップするんだけど流石にヤバい

メンバー高学歴ばっかだし技術スタック難易度高いのばっかでヤバい

アプリ実装に加えてTeraformとかkubernetes構成管理とか現職のインフラエンジニアでもこんなややこしそうなことしてなかったわってことやらされるらしい

しか評価基準説明だと悪かったら容赦なく給料下がるんだって

偏差値40の高校中退してるようなアホやぞ

ヤバいどうしよう、ついていける気がしない

2022-03-03

クラウドに詳しい人に質問なんだが

当方Webアプリエンジニアで、転職先はアプリに加えてある程度インフラも触らないといけない会社なんだけど、

自主的勉強として

Terraform + Kubernetes +grpc(grpc-web) + nuxt.js簡単Webサービス作って

コンテナ環境AWSデプロイ、みたいなのって入社までの1ヶ月くらいで完了できる内容だと思う?

経験的にアプリレイヤはわかるけど↑みたいなコンテナ構築みたいなのはあんまりやったことない感じ

2022-02-18

VMWare苦しい戦いしてるなー

まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ

お疲れさん

マルチクラウド環境における5つの課題とは

VMware提案する、DRにも対応するマルチクラウドソリューション

昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数クラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題解決するVMwareソリューションを紹介する。

マルチクラウド環境における5つの課題

COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。

多くの企業が、「ビジネススピード対応できるモダンアプリケーション」や、「あらゆるクラウドデータセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスレジリエンスセキュリティ運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境活用が前提になってきている。

具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数パブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決必要課題存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想現実ギャップとなっており、これらを意識して進めていく必要がある。

マルチクラウド環境における5つの課題

特にマルチクラウド環境適材適所で使う場合クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキル重要になる。

VMware Cloud on AWSの特長とメリット

こうしたマルチクラウド環境における課題解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービス重要ポイントとなる。例えばVMwareは、複数パブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理運用を一元化している。

VMware Cloud on AWSは、VMwareAWSが共同で開発したもので、AWSベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。

VMware Cloud on AWSの特長

その特長は3つある。1点目は「VMware製品ベースとしたクラウドであること。VMware製品仮想化されているため、AWS世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキル習得する必要がない。

2点目は「シームレスクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間コストリスクを大幅に削減することが可能だ。

3点目は「VMware管理を行う」こと。ハードウェアソフトウェアトラブル対応運用管理メンテナンス対応など、すべてサービスの中でVMware実施する。3カ月に一回の頻度で新しいリリース提供しており、ユーザー要件を反映しながら新たな機能を追加している。

最近アップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区データセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症流行地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョン活用度が高いといえる。

大阪リージョンサービス提供開始

VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存ノウハウ運用管理手法をそのまま踏襲できるという点。VMware製品ベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキル運用ノウハウなど、既存資産をそのままクラウド上でも活用でき、新たなスキル習得や、運用管理手法の大きな変更の必要もない。クラウドオンプレミス環境をvCenterから一元管理できる。

VMware Cloud on AWSが選ばれる理由

2点目が、規模に依存しないシンプルクラウド移行を実現できる点。ワークロードをそのままクラウド簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスデータセンタークラウド間のネットワークをL2延伸する。ネットワークがつながった環境仮想環境VMをそのままマイグレーションできる。アプリケーションIPアドレスを変更することなく、無停止でワークロードを移行することができる。

3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。

また、リソース最適化する機能提供される。ユーザーリソース使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWS提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSサービスシームレス連携することができる。この面も同サービスの大きな強みとなっている。

クラウドスケールインフラストラクチャ

最近では、VMware提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間コンテナKubernetes環境が導入できるようになる一方で、ハードウェアソフトウェア管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。

VMware Tanzuの概要

高まるDR環境へのニーズ安価に実現

VMware Cloud on AWSユースケースには、主に「オンプレミス環境クラウド移行」、「データセンター拡張」、「災害対策サイト」、「次世代アプリケーションプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。

VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトデータクラウド上のストレージ領域レプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想環境フェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資不要となる。

VMware Cloud Disaster Recoveryの特長

このタイプオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングリカバリサイトに対する課金が開始される。復旧後に仮想環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される

また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境データバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。

マルチクラウド環境可視化するVMware vRealize Cloud

マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしま可能性がある。クラウドごとに管理ツールや必要とされるスキルノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクコストが増加してしまう。そこで有効解決策となるのが、クラウド環境をまたがって一貫性のある運用管理を実現できるVMware vRealize Cloudである

まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウド環境にまたがってデータ収集分析評価を行うことで、例えば常にパワーオフ状態仮想環境や、実体がない状態ディスクなどを検知された場合最適化していくことが可能。これにより、最終的にコスト最適化も図ることができる。

コスト運用最適化できるVMware vRealize Cloud

また、VMware vRealize Log Insight Cloudによって、複数クラウドを横断してログ管理できる。例えば、監視対象イベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査対応を行うことができる。セキュリティコンプライアンスの強化にも有効だ。

さらに、クラウド間のネットワーク可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審通信を洗い出すこともできる。また、アプリケーション通信も把握できるため、アプリケーションの移行計画にも活用できる。

今後、DXの推進を加速していく上で、必ずしもひとつ環境ひとつクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用課題解決するだけでなく将来への有効投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。

2022-02-15

anond:20220214201911

kubernetesのいいところは、無駄雇用が発生するところじゃないか

anond:20220214201806

バズワードだったのはその通りだと思うけどコンテナ動かすなら検討はするぐらい当たり前のポジションにはなってる気がする。

未だにコンテナ化してないサービスが数多にあると思うのでこれ以上流行る感じはしないけど。

Kubernetes本体機能と事例、エコシステムはだいたい出揃った感があって、最近追ってても全然おもしろくない問題

2022-02-14

anond:20220214201431

kubernetesってすげー流行って一気に消えたよな

俺は使わない方面技術屋だったけどはてブとかでもめっちゃ見かけたから覚えてる

 

2022-02-11

anond:20220211220608

Kubernetesって、イマイチなんて読むのか自身がなくて、何となくモゴモゴ言ってごまかしてる

2022-01-25

アメリカガチシステム開発現場を行動観察

アメリカガチシステム開発現場を行動観察

ここから今日の本題です。

アジャイルコーチとして、アメリカガチの、ガチシステム開発現場に、言うたらエスノグラフィ(行動観察調査)をしてるようなもんです。三流プログラマながら。

そういうリファレンスみたいなことをお伝えしたら、皆さん(Regional Scrum Gathering Tokyo 2022の参加者)が喜んでくれるかなとか思って、内容を構成しています

ただ、僕が知っているのはマイクロソフトだけですし、自分職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから(笑)

そういうのを踏まえて聞いてください(笑)。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分経験したことのみで構成します。

ウォーターフォールは使われていない

まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。

fig

からといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア成熟)かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン(開発前の仕様策定)を大量に時間をかけてやってるというのもない。

デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。

何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たとき日本のお客さんに「ウォーターフォールアジャイルメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。

僕が当時そのことをブログに書いたらすごい炎上しましたけど。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります

開発者それぞれが責任を持って設計実装する

次は、僕のチームがどんな感じで運用されてるかっていうお話します。

マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います

基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。

自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者

fig

マネージャからアサインされるバックログ基本的にはふわっとしているので、ICがそれを明確にします。

IC仕様自分明確化して、自分デザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。

ただ、同じマイクロサービスメンテする役割の人みたいなのがいて、それは「Buddy」(バディ)みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。

他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。

多分このチームの単位マネージャ管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分レスポンシビリティを持って自分でやる。それは新人であっても一緒です。

司会)ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。

(右下の点線で囲われたところ)このチームはスケールコントローラをやっていて、(右上の3つのICを指して)このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。

でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。

司会)隣のチームと、このチームを分けているのは、マネージャが違うだけ?

ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイム担当してるんですよ。

給料を上げるのは他人との競争ではなく自分との戦い

さて、エンジニア評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログGAFA給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。

参考:GAFA米国本社エンジニア年収ジョブレベル別に比較してみた【GoogleAmazonFacebookApple

この図がまさに僕が言いたいことなので、この図を使います

fig

こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフト給料の額とかも調べられるんですよ。

どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフト場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。

このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。

から自分給料を上げたかったらどうするかっていうと、プロモート(ランク上げ)してもらえるように頑張るって感じです。他の人との戦いじゃないんです。

いまより一つ上のランク仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパル仕事してるからプロモートしよう」とノミネートしてくれる。

そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。

ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。

給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくま自分との戦いって感じになります

マネージャ自分仕事キャリアを助けてくれる

マネージャ存在っていうのは僕的にはすごい(日本と)違ってるように感じています

日本にいるときマネージャって進捗管理課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。

アメリカ場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリア成功するかっていうのをすごい重視してくれるんです。

fig

これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます

マネージャ大事仕事アンブロック」

マネージャのすごく大事仕事に「アンブロック」というのがありますIC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものアンブロックしてくれるんです。

fig

例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。

そういうブロックをされる状況が一番生産性を阻害すると思うんですね。

そういうときマネージャアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。

マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。

基本的納期の設定はない。マネージャも急かさな

あと結構面白いのは、少なくとも今の僕の職場では、納期基本的にない感じです。

fig

あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。

基本的納期的なものはなくて、できたときが終了なんです。

マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。

これは多分いろんな意味合いがあるんですよね。多分クラウドプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。

例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。

僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。

やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃん理解して、より良いアーキテクチャを作らないとひどい目にあう。

から多分マネージャ絶対に急かさないんだと思いますちゃん理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます

バックログはあり予定もあるが、達成されないこともしょっちゅう

司会)すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね(笑)納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。

バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。

だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICアサインするんです。

でも、それが今期に達成されないということはしょっちゅう起こります

思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。

変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。

司会)お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか?

僕らの場合プロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略(ストラテジ-)とカスタマフィードバックですね。

あとはハッカソンエンジニアがなにかプロポーズするときもあります

そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものピックアップされます

で、それが達成されてリリースされるまでの期間は本当にピンキリです。

僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります

僕の上司で僕よりもプログラミングができない人はいない

ではマネージャ技術力の話に進みたいと思います

僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。

彼らの技術力はどんな感じか。

僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。

その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります

何でかと言うと、どんなテッキー話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧理解してアーキテクチャの深い話をするんです。

給料が高くて当然だと思いますね。

fig

で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。

まり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。

そしてこういう人が僕の仕事サポートをしてくれる、応援をしてくれるわけです。

からこんな上司に何かを説得する必要なんてないんです。彼らがテッキーミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。

皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。

へーOutlookぽちぽちけがスキルのクソ雑魚ポンコツ年功序列PMになってるようなケースがないのねアメリカ

ログイン ユーザー登録
ようこそ ゲスト さん