ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
カナリアリリースとは - IT用語辞典
概要 カナリアリリース（canary release）とは、ソフトウェアやネットサービスの最新版を配布・提供する手法の一つで、公開当初は一部の利用者のみに限定して提供し、反応を見ながら提供範囲を拡大していく方式。 ソフトウェアの最新版を公開したり、サービスの機能を更新する際、いきなり利用者全体を対象に更新を試みるのではなく、最初は全体の数%など限られた利用者のみに最新版を提供する。 Webサービスなどでは自動的に一部のアクセスを振り分けて最新版への切り替えを行うことが多いが、オープンソースソフトウェアの配布などの場合は「カナリア版」などと明示して利用者が自ら選択して入手・導入できるように提供する場合もある。 最新版に切り替わった利用者が実際の本番環境で使用するのを確かめ、致命的な問題が発生していないことが確認できたら、段階的に提供する範囲を広げていく。初期の利用者の状況を見て修正が必要な場
『Joel on Software』を読んだ - 30歳からのプログラミング
Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い（長いものでも 20 ページくらい、短いものだと 4 ページほど）ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので
おわりに - なぜ機械学習はうさん臭く感じられるのか? / 真面目なプログラマのためのディープラーニング入門
本講座では計8回にわたり、ディープニューラルネットワークの原理と実装について 説明してきた。ニューラルネットワークの原理は基本的には 勾配降下法であり、その基盤となっているのが関数の微分可能性である。 ニューラルネットワークにはさまざまな形態が存在するが、 画像処理・画像認識の場合は畳み込みニューラルネットワークが非常に 有効であることがわかっている。また、ニューラルネットワークの 出力形式や損失関数を変えることにより、ニューラルネットワークが 物体検出や奥行き推定など、さまざまなタスクに利用可能であることを紹介した。 さて、本講座は「真面目なプログラマのための」ディープラーニング入門、 と銘打っている。真面目なプログラマとは何か? 諸説いろいろあるだろうが、 多くのプログラマは、ソフトウェア開発において 仕様の明確さや、 システムの効率・堅牢性、そして 保守のしやすさといったものを 追求
変化し続けるキャリアと変わらない原体験
YAPC::Japan::Online 開催めでたい キーノート光栄 オンライン開催 id:onishi さんに先んじてしまった YAPC::Kyoto 中止残念でした (延期とのことです) 今後のオフライン開催に期待 新しいハイブリッドな形にも Discord活用いいですね Me id:Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 Launchable / プリンシパルソフトウェアエンジニア おそらくはそれさえも平凡な日々 https://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 60+ CPAN Modules / 200+ GitHub repositories 3 Times ISUCON Winner Using Perl 「みんなのGo言語」共著者 ghqメンテナ 認定スクラムマス
開発速度が速い #とは（LayerX社内資料）
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで10年の軌跡 - Findy Engineer Lab
ソフトウェアエンジニアの藤吾郎（@__gfx__）と申します。最近、IC（Individual Contributor / 個人貢献者†）という言葉でキャリアが語られることも増えてきたように思います。この記事では、ソフトウェアエンジニアにおけるICというキャリアパスについて、自分の認識と経験を交えて次の点から解説していきます。 ICというキャリアパスがあることを、ソフトウェアエンジニアに知ってもらいたい 私が39歳という年齢でIC一本でいくと決意するに至った経緯は？ 「IC」とはどういったキャリアなのか？ 管理職ではないキャリアとしてのIC これからICを定義する企業は増えるか 私がICというキャリアパスを選ぶことになるまで ソフトウェアエンジニアになるつもりはなかった 27歳で選択したソフトウェアエンジニアをウロウロする10年 Fastlyに入社して初めて明示的にICとなる ソフトウェア
スクラム開発の現場にJoinして失敗した俺が悪い話 - Qiita
ほぼノー知識でスクラム開発の現場に乗り込んで失敗した話を書き記します。 「なぜスクラムは上手くいかないのか」「スクラム開発のアンチパターン」などチームにフォーカスした記事はあれど、個人にフォーカスした失敗談が見当たらなかったので書こうと思いました。 はじめに 大前提として、その現場が悪かったとかスクラム開発が悪いとかそういったネガティブキャンペーンをするつもりではありません。 ウォーターフォールと比較して、継続的にプロダクトを作って完成に近づけていくスクラムのメリットは十分理解しているつもりです。 その中で自分が「あ、無理かも」と感じてしまった理由を記して同じ立場に立ってしまった人の救いになれればいいなと思い記します。 概要 AWSを基盤とするインフラ開発の現場Joinし、スクラムメンバーとしてプロダクトを開発する役目を受けました。 結論から言うと2週間のスプリントでベロシティを上げること
ネットワークスペシャリスト平成29年秋期問24 使用性を向上させる施策
アオンラインヘルプを充実させ，利用方法を理解しやすくする。イ外部インタフェースを見直し，連携できる他システムを増やす。ウ機能を追加し，業務においてシステムが利用できる範囲を拡大する。エファイルを分散して配置し，障害によるシステム停止のリスクを減らす。 使用性とは、ISO/IEC 9126(JIS X 0129)として定義されているソフトウェア品質特性の1つで「分かりやすさ、使いやすさの度合い」をいいます。 ISO/IEC9126(JIS X 0129)では、ソフトウェアの品質特性として使用性を含んだ次の6つと、品質特性をブレークダウンした21の品質副特性を定めています。機能性(Functionality)目的から求められる必要な機能の実装の度合い 副特性として合目的性，正確性，相互運用性，標準適合性，セキュリティが含まれる。信頼性(Reliability)機能が正常動作し続ける度合い，障害
アプリケーション・エンジニア職位ガイドライン
2021/9/23プロジェクトリードにおける考察について取り入れた2021/10/11職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート2021/12/10プロフェッショナルの年収を520~550万を520~570万に変更チーフプロフェッショナルの年収を550~600万を570~620万に変更マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニアの年収上限を950万から1000万に変更アーキテクト、リードアーキテクトの職位ガイドラインの詳細（暫定）を追加2022/4/11リードエンジニアの年収レンジを650-700万についてを、650-720万に変更チーフリードエンジニアの年収レンジを超える700-800万から、720-800万に変更2023/3/13 プロフェッショナルのチームコラボレーション（主体性）に追加
中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
日本の古き良きIT企業を退職して3年がたった
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。 客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、 会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。 これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。 Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、 手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできない
Code Reading ――― 他人のコードを読む！ - やねうらおブログ(移転しました)
自分ではソースがすらすら書けるのに他人のソースをほとんど理解できないという人が居る。 他人のソースを理解できないという傾向は仕事でしかプログラムに関わっていないという人に顕著だ。仕事の過程であまり他人のソースを読むことはないから（他人のソースを読む作業は直接的な生産作業ではないから）、そういう能力が養われない。おまけに資料(ハウツー本)は会社のお金で買ってもらえたり、理解の及ばない部分を前任者に説明を求めたり、あまつさえフローを書いてもらったりできる。はっきり言って生ぬるい。そういうことをする限り、コードを読む力が養われるはずがない。そういった環境に自分の身を投じること自体が、技術者としての自分をダメにしているというのに多くの人はそれがわかっていないのだ。 この、他人のソースを読む力というのは、うちの会社でやっているような移植作業だと特に重要視されるものである。今回のアルバイト募集でそのへ
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
競合アプリを不正に攻撃する犯人の告発と対処│Miraku
私が開発したアプリが半年以上もの間、競合叩きに合いダウンロード数が大きく低下しました。あまりにも不自然だと思い、調査を行なった所、競合叩きによるものでGoogleからスパム認定されました。 今回はその被害の調査方法から対処方法まで記載しました。 星1の総件数は100件超え。複数のデベロッパーが同一タイミングで攻撃をうけていました。 アプリリリース直後に星1を13件つけられて、アプリがダウンロードされなくなっていると嘆いていた開発者もいます。今は更に被害者が増えていると思います。 狙いはGooglePlayでキーワード「文字数カウント」のトップを取る事のようで、このワードに関連するアプリは7ヶ月前と比べ、評価が軒並み落とされています。 このワードだけでなく、該当開発者がアプリをリリースした直後、それに関連するアプリが被害をうけてるというつぶやきもTwitterで目にしました。 大量に星1を書
SIerが作ったパッケージが“さっぱり売れない”理由 | ノヤン先生のマーケティング講座 | 講座 | マーケティングキャンパス
パッケージベンダーとシステムインテグレーター（以下、SIer）は、同じようにコンピュータシステムを扱うビジネスでも、まったく違うビジネスモデルです。それを忘れた結果、リリースはしたもののさっぱり売れず、また売り方も分からずに放置され、利益が出た年に特損で処理されるパッケージが無数に存在しています。 そのメカニズムと対応をノヤン先生が解説します。 今日はパッケージの完成度とソリューション、それを踏まえたマーケティングの基本設計の話を、SIerの例で説明しようかの。 ある日、SIerと呼ばれるコンピュータシステムの開発を業務とする企業でマーケティングに携わっている人から、こんな質問を受けたんじゃ。まぁ質問というより愚痴じゃがの。 「新しく作ったパッケージがさっぱり売れなくて困っています。業務系のシステムなのでコンシューマ系のアプリのようにダウンロードで勝手に売れる訳もないし、でも経営者は『パッ
ジュンク堂書店池袋本店の長田さん！ いま、どんなコンピュータ書が売れているんですか？ - GeekOutコラム
ジュンク堂池袋本店の2017年販売冊数ランキング（太字が2017年内の刊行） ── 今でも『リーダブルコード』がランキングの上位に入っているあたりは、さすがですね*1。8年連続でCPU大賞を受賞された売り場だけあって、顧客はやはりコアなエンジニアの方が多いのでしょうか。 長田 ありがとうございます。ジュンク堂の売り場では、年間ランキングのような数字で追える売上だけでなく、ロングテールの部分をより重視しています。端的にいえば、「ほかの書店では品切れしていても、ジュンク堂に行けば置いている」という状態を目指して売り場づくりをしています。 これはコンピュータ書に限ったことではなく、ジュンク堂は経営理念に「愚直なまでに”本と文具”の品揃えにこだわります」ということや「“図書館よりも図書館らしい”店づくり」を掲げていて、ジュンク堂でしか買えない本を置くことを意識しています。 とくに池袋の場合、駅近の
ここ最近の客先常駐の実情
今、IT業界は人手不足だ。 それでもIT業界の大部分を占めるSI業界が体質を改めるどころか更に姑息になっているので、これから就職活動をする学生さんには気を付けてもらいたい。 その姑息さが目立つのが客先常駐をメイン事業とした企業の存在である。 社員数200人以上の規模を誇る独立系企業でも客のセキュリティの都合上、社員を客先に常駐させている事が多く「自社開発」と言っても「客先での開発」になる事がほとんど。 SI業界のユーザー子会社・メーカー系・独立系は共に客の都合で客先常駐にならざる負えないのが現実である。 それぐらいは業界研究してる人には既にわかりきったことかもしれないただ求人広告に記載する内容が詐欺に近いデタラメを載せる企業が多いので自分が見た事実を元に警告しておきたい。 まず、１回でも名刺交換したら取引企業として扱う会社が存在するため規模が小さい割に名だたる大企業をたくさん載せてる会社は
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
100日後に退職する47歳 非公式 まとめ
