｢全員に経営者目線を持て｣ と何が違うのか､ソフトウェアエンジニアのビジネスと市場価値と説明責任
｢なぜこんなに必要？｣ にうまく答えられなかった当時 当時の役員から組織の頭数に対して、そんな旨の問いを投げかけられたことがありました。ポジションの内訳や開発規模に対する"必要性"を中心に話したはずですが、わざわざ内製で安くない人件費を投じている文脈で期待される +α の成果に対して十分な説明を行うことはできなかったように思います。 技術畑でない役員と話すにあたっては当たり前ですが自社の経営目標とビジネス一般の理屈にチャネルを合わせて話をする必要があり、当時は自身にそれが求められていたことを改めて意識するタイミングでした。 相応の学習や技術の乗換をしていれば Tier 2 ソフトウェアエンジニアの価値が直ちに崩壊する可能性は今のところなさそうですが、作れます！使えます！以外で説明可能な「自身のバリューのテーマ性とキャリア」の獲得が市場価値の持続的な向上に不可欠であることの確信が深まります。
Online CSS Code Quality Analyzer - Project Wallace
The best way to analyze your CSS is to use the CSS analyzer, but if you’re in a hurry or if you want an opinionated tool, then you can use this CSS Code Quality analyzer. It will use the output of the CSS analyzer to run a couple of checks and turn that into a set of recommendations for your CSS. It will focus on Performance, Maintainability and Complexity and score each one of them between 0 and
より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発副本部長の okady です。 サイボウズ開発本部では2019年に組織変更を実施し、当時のインタビュー記事で私はこんなことを言っていました。 「マネージャー、いないと無理なら、またつくればいい」 サイボウズの開発本部がマネジャーをなくしてみた「いないと無理なら、またつくればいい」 | サイボウズ式 そして今回の記事は、当時の私自身の言葉に応えるタイトルにしました。 「マネージャー、いないと無理だったので、またつくりました」 2019年の組織変更から3年が経ち、目的は概ね達成できました。しかし、思い通りにいかなかったことや当初想定していなかった問題もたくさんありました。そして2022年5月、開発本部の組織力をさらに強化すべく再び大きな組織変更に取り組むことを決断しました。 この記事では、2019年の組織変更とその後を振り返った上で、2022年に実施した新たな組織変更についてご
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
150 分で学ぶ高校数学の基礎
[重要なお知らせ (2023/8/12)] 現在，スライドの p.10 に不十分な記述があります．ルートの答えは 0 以上の数に限定することに注意してください (たとえば -3 を 2 乗しても 9 ですが，ルート 9 は -3 ではありません)．なお，現在筆者のパソコンが修理中でデータがないので，修正は 1 週間後となります． [目次] 第1章 数学の基礎知識（p.5～） 第2章 場合の数（p.31～） 第3章 確率と期待値（p.56～） 第4章 統計的な解析（p.69～） 第5章 いろいろな関数（p.103～） 第6章 三角比と三角関数（p.141～） 第7章 証明のやり方（p.160～） 第8章 ベクトル（p.187～） 第9章 微分法と積分法（p.205～） 第10章 その他のトピック（p.240～） スライドのまとめ（p.254～）
Ryuzee氏に学ぶ『エンジニアリングマネージャーのしごと』 #Forkwell_Library | DevelopersIO
近年は、エンジニアを束ねるエンジニアリングマネージャー(EM)を採用する組織が増えています。 デリバリーに軸足を置くプロダクトマネージャーに対して、EMはエンジニアのピープルマネージメントに軸足を置いています。 そんなEM渇望の一冊が、先月末にオライリーから出版されました。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 : James Stanier 社内でも、今週月曜から部門横断の読書会が始まったばかりです。 その翌日に、Forkwell のイベントで同書の翻訳に関わった 吉羽龍太郎/@ryuzee 氏によるエンジニアリングマネージャーに関する講演を視聴する機会がありましたので、かんたんにレポートを共有します。 Forkwell イベント概要 エンジニアリングマネージャーのしごと - Forkwell Library #5 - connpass 公式レ
英作文する際に気を付けるポイント5選
自分は英語・日本語ネイティブ話者であり、英語に関しては高等教育中に少なくとも基本的な文章の書き方・プレゼンテーションの仕方は体形的に学んでいます。大学では技術方面の専攻だったせいでいわゆるテクニカルライティング的な授業も基本的なところから学んでいます。 そういう背景もあるため、仕事で英語のドキュメントを添削する機会がこれまでたくさんありました。 この記事ではこれまで色々見てきたドキュメントの中で「これだけ気を付ければ英文を書くのが得意じゃなくてもぐっとよくなるのに…」という点を書き出してみました。 期待している読者層としてはこれから英語を習うというレベルではなく、すでになんらかの形で仕事向けの報告書、プレゼンテーション、公開記事等でまとまった英語を書く必要があって、翻訳サービスや辞書を使いながらある一定レベルで一応英語書けるつもりの人です。 英作文をしてみたものの、「なんか書くときに迷う…
ラクマiOSアプリのフルSwift化を約4年かけてやり遂げた話 | Rakuten Rakuma Tech Blog
こんにちは。楽天ラクマ モバイルアプリケーション開発グループのdarquroです。 今回はラクマiOSアプリのフルSwift化を、約4年かけてやり遂げた話を書きたいと思います。 ことの始まり私は2018年10月1日に楽天グループに入社しました。 当時採用面接で驚いたのは、アプリエンジニアのチーム体制を聞いたところ、iOS1名、Android1名という状態だったことでした。 なので、私がiOSエンジニアとして入社し、やっとiOSアプリは2人体制になったというわけです。 2018年はラクマの前身である「フリル」を運営する株式会社Fablicを吸収合併し、それに伴い開発組織としても再構築していく時期でした。 そういったチャレンジングなタイミングに入社を決めたわけではありますが、iOSアプリのコードの状況はというと、Objective-Cという大きい技術的負債を抱えており、なかなかメンテナンスをし
英語が苦手だったエンジニアが本当に必要だったもの｜Nishimura Yukari
こんにちは、マネーフォワード CTO室グローバル部の nishimura.yukari です。 いまはGo言語でクラウド会計ソフトのバックエンド開発を行っています。 グローバル部は東京勤務ではあるものの、チーム内公用語は英語かつ多国籍なメンバーで構成されている、非常にエキサイティングな環境です。 いまでこそ仕事上のやりとりは大半が英語ですが、もともと英語が得意だったわけではありません。 学生時代は英語が苦手科目でしたし、社会人になったあとも英語でしか情報が存在しない技術情報を業務上の必要に迫られて収集する程度。 ですが、グローバル部への異動から遡ってちょうど3年前にあたる2018年の秋。 私は転職活動を通じてマネーフォワードへの内定を頂いたと同時に、 「10年後には、自分には英語が必要だ」と強く考えるようになり、本格的に英語勉強のやり直しを決意した経緯があります。 結果としては、3年後に英
GitHub - astral-sh/ruff: An extremely fast Python linter and code formatter, written in Rust.
Docs | Playground An extremely fast Python linter and code formatter, written in Rust. Linting the CPython codebase from scratch. ⚡️ 10-100x faster than existing linters (like Flake8) and formatters (like Black) 🐍 Installable via pip 🛠️ pyproject.toml support 🤝 Python 3.12 compatibility ⚖️ Drop-in parity with Flake8, isort, and Black 📦 Built-in caching, to avoid re-analyzing unchanged files 🔧
READYFORのOSSポリシーを公開しました - READYFOR Tech Blog
こんにちは、READYFORでVP of Engineeringをしております、いとひろです。 この度、めでたくREADYFORのOSSポリシーをGitHub上で公開しましたので、共有いたします 👏👏👏 github.com OSSポリシー策定の背景 READYFORでは、息をするようにOSSにコントリビュートをしている @kotarella1110（React Hook Formコアコントリビュータ）や @yuji_developer（自作gem多数、OSSにPRやissueで貢献）や @ksss（CRubyやmrubyに貢献、最近はRBS関連の活動多し）をはじめとする多くのエンジニアがOSS活動を行なっています。 かくいう私自身も、かつてはEclipse CollectionsというJavaのOSSライブラリのリード・コミッターをしていたこともあり、OSS活動に対しては非常に前向
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームでおこなうDevRel活動
テックブログを分析して分かった始めるコツ・続けるコツ
カンファレンス主催者から見た プロポーザルを通すコツ / How to hack the CfP
Text to diagram
About `npm:` support of Deno
事業会社におけるプロジェクトマネジメントの基礎
The False Trade-off Between Quality and Speed
「時間がない」症候群、その傾向と対策
