プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
概要 本書を通して、ソフトウェアテストの知識・技術を体系的に学びます。そしてその中でテストによって次の課題にどのように対応していくか学び、現代的なソフトウェア開発に対応するため総合力・基礎力を強化します。 開発成功や顧客満足実現をどう支えるか 開発の高品質と高スピードの両立を支えるアプローチとは アジャイルや継続的デリバリー、DevOpsの導入にどう対応するか テスト自動化といったテスト技術導入を成功させるには チーム全体でテストを推進していくためには 定番のテスト失敗要因に対しマネジメントでどう対策すべきか こんな方にオススメ テストエンジニアやQAエンジニアにこれからなる人 テストに疎いが、テストに関わることになった開発者やマネージャ 旧来のテストと、モダンな開発現場で求められるテスト技術のギャップに悩んでいる人 個々の担当ごとのテストの遂行はできているが、それらを連携させた、チーム全
この記事を読むたびに学びがあるなぁと感じていたが読むたびに忘れている気がするので現時点での理解を書き留めることで今後の学びの糧にしたい。本記事は元記事の全体を和訳する事や内容の全てを解説する事を目的としておらず、僕自身の学んだ事や振り返った事や噛み砕いた解釈を大いに含むので、本記事に書かれている内容は元記事の主張と一致している保証は全くない事を念頭においてほしい。 apenwarr.ca To paraphrase the book, the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions. この本を言い換えると、幹部の仕事とは文化と価値を定義して強制し、良い決定を承認する事です。 元記事で言
FOSSology is a open source license compliance software system and toolkit. As a toolkit you can run license, copyright and export control scans from the command line. As a system, a database and web ui are provided to give you a compliance workflow. License, copyright and export scanners are tools available to help with your compliance activities.
An open source license protects contributors and users. Businesses and savvy developers won’t touch a project without this protection. { Which of the following best describes your situation? } I need to work in a community. Use the license preferred by the community you’re contributing to or depending on. Your project will fit right in. If you have a dependency that doesn’t have a license, ask its
参考文献 オープンソースソフトウェアとは - Weblio辞書 プロプライエタリソフトウェアとは - Weblio辞書 派生プログラムとは - Weblio辞書 フリーウェア - Wikipedia ソフトの配布とライセンス - 可知豊 OSSをライセンス的に正しく使う／プロプラだけの製品とするための11のチェックポイント - NEC GitHubを利用する際に注意したいOSSライセンスのポイントとは - Think IT オープンソースとは - 日本ユニシス 著作権審議会マルチメディア小委員会ワーキング・グループ中間まとめ - 公益社団法人著作権情報センター CRIC 企業技術者のためのOSSライセンス入門（1）：訴訟が増えている!? OSSライセンス違反 - ＠IT 2.「オープンソースの定義」を理解する OSSを規定する上で重要となる「オープンソースの定義」を知っておくと、主要ライセ
この記事は、ソフトウェア工学が専門のMITのDaniel Jackson教授が書いたブログ記事 "How software succeeds"を、本人の許可の元翻訳するものです。 なおこの記事と同じトピックを扱っている、彼のTEDx Talkもあります。 ソフトウェアが成功する仕組み 優れたソフトウェアへの第一歩は「成功のシナリオ」である ソフトウェアの成功を診断する 成功するソフトウェアを作りたいなら、まず成功例を調べることから始めるとよい。この記事では、よく知られた1つの事例を取り上げ、それが成功した理由、その秘訣を特定し、同じ戦略が同様の成功例にどう適用できるかを示す。 あるアプリが大成功した理由を理解しようとして、ユーザーにそのアプリが好きな理由を尋ねると「とにかくちゃんと動くから」という答えが返ってくることがよくある。これが何なのか、つまり「とにかくちゃんと動く」とは実際に何を意
先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン
株式会社いづなのホームページです。デジタルなんでも屋として、スマートフォンアプリやWebアプリケーション開発、デザイン制作を行っています。
参考 プリンシプル オブ プログラミング - 3年目までに身につけたい一生役立つ101の原理原則 発行: 2016/3/23 著者: 上田 勲 まえがき プログラマーの世界で語り継がれる原則や格言を知ることは、その共通の言語や道徳を理解する手助けとなります。 『プリンシプル オブ プログラミング』（以下、プリプロ）は、統一された語句と形式により、先人のプログラマーたちが重要視していた思考法やアプローチを、微妙な概念の違いに気を使うことなく理解できるよう構築されています。この記事では、この本を読む上で役立つ101の原則マップと原則から抽出した価値観をまとめます。プリプロを読む際のガイドになればと思います。 一方で、プリプロに収録されていないウィットに富んだ原則や格言も多く存在します。この記事では、主に私の現場で重要視しているプリプロの101の原則以外の原則・格言も追加で紹介します。 プログラ
2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
