品質とは何か
品質という言葉の意味 測定との関係と視点 品質の種類 基本的な考え方 ソフトウェア品質特性 機能性品質特性の品質副特性 信頼性品質特性の品質副特性 使用性品質特性の品質副特性 効率性品質特性の品質副特性 保守性品質特性の品質副特性 移植性品質特性の品質副特性 利用時の品質とは 俯瞰 まとめ 品質という言葉の意味 「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い／悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。 人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
「電子立国は、なぜ凋落したか」の感想～日本の技術者は減価償却のコスト意識が低い - プログラマの思索
「電子立国は、なぜ凋落したか」の感想をメモ。 理解できた部分だけラフなメモ書き。 あくまでもメモなので、時々論理は飛んでいる。 【元ネタ】 日本の製造業もアジャイルの概念が必要ではないか: プログラマの思索 ユーザの力を利用するアジャイル開発: プログラマの思索 【1】「電子立国は、なぜ凋落したか」では、特に日本における半導体、電子電気の業界の栄枯盛衰を多角的に記載している。 そこで興味深い文言だけ拾っておく。 「日本の技術者は減価償却のコスト意識が低い。なぜなら、技術ではなく経営の問題だから。」 【2】日本の技術者は減価償却のコスト意識が低いのではないか 日本の半導体は世界を席巻していたが、諸外国に負けた時の言い分は「経営、戦略、コスト競争力で負けた」「技術では負けていなかった」とよく言う。 しかし、著者は、製造コストを考える時に、日本の技術者は減価償却のコスト意識が低いのではないか、と
LINE iOSアプリ開発についてのご紹介 LINE Engineers' Blog
[English version] はじめまして、LINE技術戦略室のhayaishiです。 趣味は自転車と言っていますが最近は全く乗っていません。 この記事では、LINEのiOSアプリ開発に関することをいくつかご紹介させていただこうと思います。 LINEのiOSアプリ開発環境 ソースコード管理 ソースコードはgitで管理しています。gitのリポジトリブラウザとしてGithub Enterpriseを利用しており、Githubでお馴染みのPull Requestなどを活用して開発を進めています。 また、LINEのiOSアプリのタスクについてはGithub Enterpriseとは別のチケット管理システムを利用しておりそちらのステータスと連携して開発者、QA、プランナー間の開発状況の共有を行っています。 Gitでの開発フローについて LINEのiOSアプリはgithub-flowの様に
プロダクトマネージャー宣言 - 小さなごちそう
プロダクトマネージャーを目指す人にとって指針となるようなマニフェストを、日本語で作りたいと思っている。 僕自身も修行中の身だが、僕がプロダクトマネジメントを行う際に気をつけていることをマニフェスト風にざっと書き出してみた。 まだ粗々なのでここからブラッシュアップして行きたい。 私たちは、ユーザーに愛されるプロダクトによって利益を生み出すことに情熱を持っています 私たちは、プロダクトの力で難しい問題を解決できると信じています 私たちは、問題の定義が最初の仕事であることを知っています。 私たちは、ターゲットとその課題を定義すること無しに良いプロダクトを作れないことを知っています 私たちは、要件定義はゴールではなく出発点であることを知っています 実現可能性のあるアイデアを選定するのは私たちの仕事です。 私たちは、自分の考察に盲点があることを知っています。 私たちは、多数決ではイノベーションが生ま
プロジェクトマネージャへのお勧めの本 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ソフトウェアエンジニアを目指す人へのコードに関するアドバイス | POSTD
この短い記事で私は、ある素晴らしいアイデアを提案します。それは、製品品質のコードは、下記リストに挙げた特性で説明することができるということです。それぞれ、重要性の高いものから順番に記述しています。もしあなたが、学校もしくは独学でプログラミングを学ぶ、真面目な学生なのであれば、製品品質のシステムを構成するコードの特性を学びたいと思うのではないでしょうか。 是非、 ご意見・ご感想 をお寄せください。 読みやすさ 言うまでもなく、読みやすいコードである。 読みやすいコードは、必要に応じて簡単に変更できる。 読みやすいコードは、他の人も理解することができ、共有することができる。
チーム開発においてGit初心者が踏みがちな地雷まとめ｜TechRacho by BPS株式会社
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 - 肉とビールとパンケーキ by @sotarok
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい！あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
あるＳＥのつぶやき: フリーで使えるプロジェクト管理ツールまとめ
フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートでプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートでプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートでプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール（saramiさん情報） Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある
できる開発者になるための7つの習慣 - builder by ZDNet Japan
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
第1回 連載を始めるにあたって | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人（わだ たくと）といいます。 このたびgihyo.jpにて、テスト駆動開発（TDD）の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演！ リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演！ テスト駆動開発」と「実演！ リファクタリング」は、本誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方
設計文書のうまい書き方 steps to phantasien t(2007-09-24)
訳して YukiWiki に置きました. 元は "How to Write an Effective Design Document". 友達が "最近, プロジェクトで設計仕様書を作ろうって話が..." と悩んでいた. そりゃ大変だねえと相槌をうち, 相槌ついでにぐぐっていたらみつけた記事. <design document> や <designdoc> と検索すれば ガイドラインだけでなく実物もじゃんじゃかみつかる. 玉石混交で面白い. 設計仕様書と聞くと, 設計する人と実装する人が異るような大規模開発をまず連想する. そっちの世界で文書が必要なのはわかるが, 一方で私は大規模開発をしたいと思わないし, 興味も湧かない. 元の記事も私の友達もそんな大規模開発を想定していない. 文書化した本人が実装も行う. それでもこの記事からは (訳しておいてなんだけれど) いまいち違和感が拭えない.
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
古橋貞之の日記 - 開発環境としてのMac OS Xカスタマイズ
Mac OS Xを使っていないプログラマは、時間の80％を無駄にしている、かどうかは知りませんが、堅いGUIとUNIX系のコマンドラインツールを使えるMac OS Xは、開発環境として使いやすいことは確か。 が、デフォルトのままでは、Terminal.appで日本語が表示できないとか、lsやfindがGNU系じゃなくてBSD系だとか、要するにOSだってカスタマイズしてなんぼというわけであります。 というわけで、私のMac OS Xのカスタマイズをこのあたりに書いておきます。 ※2008/2/3追記: Leopard版書きました > 開発環境としてのMac OS X Leopard Terminal.app Mac OS Xにはデフォルトで「ターミナル」（/Applications/Utilities/Terminal.app）が付いてきますが、これがデフォルトではまったくイケてない。主要な
ウノウラボ Unoh Labs: WEBアプリテストのチェック項目リスト
こんにちは！やまもと＠テスト番長です。 TestingGeekという耳障りの良い名前のサイトをご存知でしょうか？ 総合的にテストの話を取り扱っており、それでいて読みやすいサイトです。 そこのTemplatesのコーナーにWeb Application Testing Checklist という便利そうなものがありましたので、日本語にしてみました。 ちょっとそのままだと物足りない感がありますが、テストポリシー作成の叩き台に使ってみるのも良さそうですね。 この手のリストを他にもご存知の方がいらっしゃれば、是非ご一報ください。 1. 機能テスト 1.1 リンク 1.1.1 記載された通りの先に遷移するか 1.1.2 どこからもリンクされないページは存在しないか 1.1.3 全ての外部リンク 1.1.4 参照しているサイトおよびメールアドレスはハイパーリンクになっているか？ 1.1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの話
レガシーコード改善の戦略と戦術
All-In-One-Trac - All-In-One Project