ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
ソフトウェアの資産計上〜減価償却編〜
事業の成果や開発組織のリソースを最終的なアウトプット先である管理会計や財務会計に、私達が日頃から作っているソフトウェアどういった風に計上されているか。前提としては、自社開発でのソフトウェア資産計上とする。 まずは、なぜ資産計上をするべきかなのか、ひいてはプロダクト開発にどう関わってくるかを考えていく。 なんでソフトウェアを資産計上しないといけないのか私達が作ったソフトウェアというを資産計上しなければいけないかというと、端的に言えば、正しい財務諸表（B/S : 貸借対照表）のためです。あと普通に資産計上しないと脱税になるはず。（実際には、色々な資産巡りでのあれこれでの対策防止があるらしい） B/Sの中で、固定資産という枠があり、ソフトウェアはその中の「無形固定資産」にあたります。細かいですが、ソフトウェアで計上できるものは確実に将来の収益や費用削減が見込まれるものになります。それ以外は、費用
ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
ソフトウェアアーキテクトが知るべき97のこと
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
ZOZOテクノロジーズのオープンソースソフトウェアポリシーを策定しました - ZOZO TECH BLOG
こんにちは。MLOpsチームリーダー兼プラットフォームSREチームリーダーのsonotsです。今年の4月からZOZOTOWNリプレイスプロジェクトにも関わるようになりました。Zoomの背景画像を「進め！電波少年」にしてみても、チームの若者に伝わらないのが最近の悩みです。 今回の記事は、昨年度にタスクフォースとして発足したOSSポリシー策定委員会を代表して、今年の4月に弊社で策定したOSSポリシーについて紹介します。 OSSポリシー策定の背景と目的 弊社でもOSSを利用・貢献・公開しているメンバーが増えてきています。また、会社としても業界貢献、技術アピールの側面からOSS活動を奨励したいという想いがあります。 しかし、弊社にはOSSポリシーが存在しなかったため、相談を受けた際にCTO室が都度判断するという状況がしばらく続いていました。都度判断ではスケールしないため、「社員がOSS活動しやすい
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
要件？要求？揺れる用語を整理する
要求なのか、要件なのか？「要件を詰めましょう」「要件定義をしましょう」「要求管理どうしてる？」といったようにソフトウェア開発の現場では要件や要求が飛び交います。 現場では関係者間での共通認識を持つことが非常に大切ですが、それでも要求なんだか要件なんだかわからないことや、これらの言葉を混同していてそれによって後々のコミュニケーションや問題に発展することも少なくありません。 まずは、用語の共通認識が大切だということです。これだけを気を付けるだけでも多くの「言った、言わない」や「文脈を読んでくれよ」問題は快方に向かうのではないでしょうか。 用語を整理する私はこの要件なのか、要求なのかの問題に直面した際には、英語に置き換えてもらうように働きかけます。 「今の『要求』とは英語だとなんですか？」「今の『要件』とは英語だとなんですか？」という具合にです。すると、多くの場合で、「要求」も「要件」もどちらも
ISO/IEC 9126 - Wikipedia
ISO/IEC 9126 は、ソフトウェア品質の評価に関する国際規格である。同じ概念についての新たな規格策定事業 SQuaRE(Software Quality and Evaluation) により、ISO/IEC 25000:2005 に置換した。 ISO/IEC 9126は、「品質モデル; quality model」、「外部測定法; external metrics」、「内部測定法; internal metrics」、「利用時品質測定法; quality in use metrics」の4つの部分から成る。 品質モデルは ISO/IEC 9126-1で規定しており、ソフトウェア品質を次のように構造的に定義した。 JISでは、ソフトウェア製品の品質に関わるJIS X 0129群と、ソフトウェア製品の評価に関わるJIS X 0133群とに分かれている。 JIS X 0133-1は、J
契約による設計の紹介 - Hatena Developer Blog
こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で
支援者としてのリーダー - 「リーダーシップ3.0」を読んで - - ソフトウェアさかば
年末にサーバントリーダーシップ私論を書いたばかりですが、サーバントリーダーシップにも触れている書籍「 リーダーシップ3.0」の感想を書きます。 サーバントは革命の言葉。ビジョンを示せ！ - サーバントリーダシップ私論 - [#benkyoenkai] 古くて新しいサーバントリーダシップ サーバントリーダーシップを否定すると嫌な上司になっちゃう件 書籍「 リーダーシップ3.0」は、日本人がサーバントリーダーシップと聞いた際のイメージよりも、私の期待するサーバントリーダーシップのイメージに近いと思いました。 支援者としてのリーダーが求められている リーダーシップはその時代に応じて求められることが変化してきました。かつては中央集権的な強い権力者が求められ、やがて限界に達して分権され、さらに変化に対応できなくなったので調整者が求められました。しかし、従業員に優しい企業はスタッフ部門の肥大化や内向き
第7章 周りの人と協力しあおう―報告・相談に欠かせない3つの情報 | gihyo.jp
さて、最後はほかのチームメンバーとの関わり方だね。開発の場面においても、チームで1つの課題に取り組む以上は、メンバーどうしでうまく連携し合えないといけないよ 僕、まだまだみなさんのお荷物ですよね…… そんなことはないさ。チームの人間関係ってのは、「私作る人、僕食べる人」みたいな一方的なものじゃないんだ。お互いに影響し合って、各自が1人でやる以上のことをできるようにするのが、チームプレイなんだよ 問題を報告しよう 開発したソフトウェアが期待どおりに動かないときに、問題の伝え方が良くないと、解決までに余計な時間や手間がかかってしまいます。 問題の報告で重要なのは、聞き手に過剰な負担をかけないことです。背景やコンテキストを共有していない聞き手が、報告者の状況を想像して報告内容を補わなくてはならない場合、聞き手にとってはたいへんな負担となります。逆に、そのようなことをしなくて済む良い報告は、より
ソフトウェアのスケーラビリティについてスターバックスが教えてくれること | POSTD
2004年に Gregor Hohphe が「 スターバックスでは2相コミットを使わない（Starbucks Does Not Use Two-Phase Commit） 」という優れた投稿を発表しました。それを読んでいたら、学生時代にスターバックスでアルバイトをした頃がいきなり関わってきました。何年もの間に次第に分かってきたのは、プログラマでさえ有名なコーヒーショップのチェーンから学べることが思った以上にあるということです。 多くの人はスケーラビリティのあるソフトウェアを作ろうしますが、最初に考えていたよりも非常に難しいことがあります。個々のタスクをこなしているうちに「あらゆるものの重要性は等しく、同じリソースを必要とし、決まった順序で同期的に進行する」と考えてしまう罠に陥ってしまうのです。 実際には、少なくともスケーラビリティのあるシステムでは、当てはまりません。もちろんスターバックス
GPLv3とソフトウェア特許
GPLv3にはソフトウェア特許についての言及（GPLv3 第11条）がなされているが、どうもこの点については誤解が多く人々がGPLv3の利用を躊躇する理由になっているように思う。GPLv3の特許条項はGPLv3に対するFUDの元凶になっているように思う。実は筆者は最近「GPLv3を適用したソフトウェアを公開するとあなたの持っている特許は全て無効になる」という（如何にもGPLv3を適用すると不利益を被るような）誤った説明がなされているのを目の当たりにしたところであり、筆をとる必要があると感じた次第である。そこで、今日はGPLv3における特許の取り扱いについて説明しようと思う。 GPLv3の要求事項GPLv3が定めるのは、簡単にいうと「あなたがGPLv3が適用をしたソフトウェアに特許が含まれる場合、GPLv3でライセンスされたそのソフトウェアを利用／使用するユーザーを特許侵害で訴えませんよ！」
UNIXという考え方 The UNIX philosophy · GitHub
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. 定理 1. Small is beautiful. 小さいものは美しい 小さいものは、大きい物にない利点がいくつもある。小さいもの同士なら簡単に独特の便利な方法で組み合わせることができる 小さなプログラムという発想 小さなプログラムはわかりやすい 小さなプログラムは保守しやすい 小さなプログラムはシステムリソースに優しい 小さなプログラムは他のツールと組み合わせやすい 一般にソフトウェアの開発者は、巨大なプログラムを書いてしまう。 これは「あらゆる不測の事態に対応できるように」という誤った考えに基づくものだ。 巨大で複雑なプログラムの開発者は、「将来が予測可能で、そして現在とそう大きくは変わらない」 という勝手な思い
ソースコード・リーディングしよう！[GemJam][ActiveSupport]
@h5y1m141さんに誘っていただいて、 @hitomi_twさんや shiro615さんと一緒に、RubyGemsのソースコードリーディング勉強会『GemJam』を行いました。 今回は最近仕事でソースコードを読む時間が増えてきて、苦労していたのでソースコード・リーディングのモチベーションアップやコツを調べつつ、いつもRailsでお世話になっていた『ActiveSupport』 のソースコードリーディングに挑戦してみました。 (12/28 12:10) 勉強会のアウトプットを更新しました。全員アウトプットしたのはすばらしいです 🎉 プログラムのモチベーションこれは経験談からくる話ですので、これが正解ということでないッス。どちらかというと、今までエンジニアとして経験してきた中で、僕個人はこう思っていますという観点で書きました！ プログラミングは継続することが一番大切プログラミング経験ゼロ
![ソースコード・リーディングしよう！[GemJam][ActiveSupport]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers
YouTubeへの動画アップロードも可能！ 無料で多機能の動画編集ソフト「DaVinci Resolve」／タイムラインで動画や音声を編集。テロップの追加も可能【レビュー】
リファクタリング（第2版） 既存のコードを安全に改善する | Ohmsha
