貯金と投資のバランス

株式投資を始めてから大体2年くらいになった。その間収支はぎりプラスになってるはずである。現有資産的にもプラスなのだけど、あくまで「含み益」としてプラスになってるだけなのでそれは利益になってるとは言わないと思っている。だって何か市場経済に大きなダメージになることが起きたらその含み益は一瞬で消え去るもので、非常に不確定な数字だから。

おそらく株にしてもFXにしても「利益が出てるよ」といってる人の結構大きな割合で「含み益」が出てる状態を「利益が出てる」というように言ってる人多いんではなかろか。どこで利確するか、これが最も難しい。早く1億円くらいの株資産を持って悠々自適な生活を送れるようになりたい・・。

さて、実際に株式投資をしていると悩むのが「貯金と投資のバランス」だと思う。果たしてどれくらいのバランスであれば丁度いいのだろうか。

ちなみにうちの親は「投資なんて怖いから貯金をしろ」とうるさいが、本人はバブル期に不動産投資（マンションを買ってその賃貸料金で儲けるつもりだったらしいが、バブル崩壊で大失敗）、畜牛投資（数年前に運営会社が倒産）などで手痛いダメージを負っているからこそのアドバイスなのかもしれない。それと大きいのが親世代は定期預金などで今では考えられない利率をもらっていた世代なのもあると思う。

今では信じられない、ほぼノーリスクで年率5％増えた時代 | MonJa〈もんじゃ〉お金と暮らしの情報サイト

預金で年率6%とかいう時代があった

こんな利率を経験していれば、どうしても「投資より貯金」という考え方になるのも頷ける。だってノーリスクで元本割らずにお金がどんどん増えるんだから。それとは別に元本補償で利率5％とかを謳う勧誘は気をつけないといけないな、と感じる。絶対に破堤するだろ...

私が思う貯蓄と投資のバランス

例えば普通の会社員なら、毎月給料が振り込まれ夏冬とボーナスが出ることを考えたら貯金を目一杯保持しておくよりは投資に回す方がいいではないだろうか。もちろん結婚出産子供の進学等々の人生のステージにおける出費というのもあるのでまるっきり0とというのはありえないが、資産が500万円あるなら200万円を貯金として300万円を投資に回すというのも全く問題ないと思う。４：６の割合ということ。

フリーランスなどの場合、会社員と違って必ず給料が出る保証もないので、割合としたら半々くらいが安全圏なような気がする。とはいえ、継続的に仕事があるということであれば6ヶ月分の生活費程度を目安に貯金に回しあとは投資に回す、というのも十分ありだと思う。

何にしても、給料は全部貯金に回せばOKというような時代でもないので、何かしら（iDeCOとか）投資をしておくということが大事なことだと思う。なぜなら貯金をしているだけではお金の価値がいずれ下がるから、ということに他ならない。

物価の上昇は緩やかとはいえ今後も続いていくし、その分今貯金しているお金は相対的にどんどん価値が下がっている。卵くらいじゃないだろうか今後もワンパック200円くらいで買える商品というのは...

みんなも一緒に株やろうぜ！

10万円から始めて資産を200倍にする小型成長株投資

日本一カンタンな「投資」と「お金」の本

マンガでわかる最強の株入門

いまさら聞けない　ビットコインとブロックチェーン

【リーダー論】クソみたいなリーダーが実は自分自身だった

今参画しているSES先のQAチームで、プロジェクトのリーダーを任されることが増えた。プロジェクトといっても一つのプロジェクトは工数でいうと30人日とかそういう規模なので、小さいものなのだけど。

1人きりのプロジェクトを任されることもあるので、必ずしも「リーダー＝メンバーを抱える」ではないのだけど、メンバーを抱えた場合に非常に苦労している。特に以下の2点で苦労している。

1. テストケースの抜け・漏れのせいで、実施時にメンバーから質問がくる
2. 仕様を把握してない or 誤った把握でテストケースを作っていて質問がくる

改めて書き出してみると「全て自分のせい」であることがわかり頭を抱えている。こんなリーダーの元で作業をしなくていけないメンバーは苦労するだろう。じゃあ逆に良いリーダーってどんなリーダーなのか。実は今までよく考えてきたことがなかった。

このエントリーでは、あくまでのQAのプロジェクトに関してのリーダー論になるので、対象が非常に限定的になります。いわゆるシステム開発におけるリーダー論とも多少ずれてくる部分はあると思うし、あまり一般的な話にはならないかもと思っています。

良いリーダーとは

 実際メンバーとしてプロジェクトに参加しているとき、「なんかこのプロジェクトは嫌だな」と感じることが少ない時があるが、そういう場合「良いリーダーがプロジェクトを率いている時」なのだろうと思う。じゃあ具体的にはどういうことなのだろうか？

• 仕様の抜け漏れがない
• 仕様についてメンバーからの問い合わせにすぐ回答できる
• 把握できていない仕様についての問い合わせ先を把握している
• 必要な情報を社内ネットワークなどからすぐに取得できる
• 必要な情報を察知できる
• 質問をしやすい雰囲気を持つ
• 突発的なことに割と冷静に対応できる

仕様の抜け漏れがない

もちろん全てを完璧に把握しているわけではないが、抑えるべきところは抑えている。たとえ漏れや抜けがあったとしてもリカバリーできる程度にきちんと理解している。

仕様についてメンバーからの問い合わせにすぐ回答できる

Slackで問い合わせがあったときなど、レスポンスが早い。2時間とか放置しない。問い合わせへの回答があるまで作業が止まることもある。

把握できていない仕様についての問い合わせ先を把握している

完璧超人ではないので、ど忘れしてしまうこともあるがそういった時に、どのチームの誰に問い合わせをすればいいか、把握している。日頃からそういった人との信頼関係を築いていて聞きやすい確認しやすい人間関係を構築している。

必要な情報をすぐに取得できる

最近はConfluenceなどの社内ワークスペースを使うことが当たり前になってきているが、それらに格納されている情報に対して検索してすぐに情報の取得を行うことができる。またConfluenceに書かれている情報がシステム寄りだったり、英語だったりしても理解することができる。

必要な情報を察知できる

個人的にはこれが結構大事だと思ってるのだけど、仕様書などに書かれていないが、実は当たり前となっている機能や処理やまた単純に仕様書を記載した人が書き漏らしたことに対して「これも必要ですね？」と察知できる。当然ある程度業務や機能に対しての経験値が必要な部分ではあるがたとえ業務知識が浅くても「AだったらBも必要になる」という風に頭の中で紐付けがすぐに出来る人がいるが、そういう人に私はなりたい。

 質問をしやすい雰囲気を持つ

 質問を受け付けるのを嫌がる人、感情の波が激しい人（普段穏やかでも忙しくなってきてキャパシティを超えたら急に不機嫌になる人）、そういう人は割と多いが、そうではなく常に安定した態度で、質問そのものを受け付ける人。「これは前にも言いましたよね？」と言いつつちゃんと聞いてくれる人がいいですね。

突発的なことに割と冷静に対応できる

プロジェクトの最初から最後まで一つも例外が起きずに終わることはまずないが、実際に想定してないような事象が起きた際にどれだけ冷静に対応できるかというのはある程度リーダーの資質に必要なことじゃないだろうか。自分で対処できること、自分だけでは対処不可能なこと、今の段階では判断つかないこと、それぞれを的確に判断して対処できるようなリーダーにはどうやったらなれるのか...

ダメなリーダーとは

ほとんど自分のことなので、挙げるのはしんどいのだけど、多分こんな感じではなかろうか（あまり自己批判に終始するのも新興宗教とかセミナーぽいので嫌なのだけど）

• 対象のプロダクト、またはプロジェクトの概要・仕様を把握できてない
• テスト設計段階で抜け・漏れが発生する
• 作業の分担をうまく捌けない
• 作業を抱え込みすぎてパンクする
• 質問への回答レスポンスが遅い
• 作業進捗を把握してない
• 想定外の事象にうまく対応できない（パニックになる）

 対象のプロダクト、またはプロジェクトの概要・仕様を把握できてない

例えばいろんなプロジェクトを抱えるPMが関わるプロジェクトの全てのプロダクト仕様を把握できてないのは仕方ないが、プロジェクト専任のリーダーがプロダクトやプロジェクトの概要や仕様をきちんと把握できてないのはまずい（気がする）。

設計段階で抜け・漏れが発生する

プロダクト、プロジェクトにおける設計仕様を把握できていなければ当然そのテスト設計時に「抜け漏れ」が発生するのは当然といえる。テスト設計で抜けや漏れが発生すればテスト実行時に実際のプロダクトとの齟齬が発生する。

「テスト仕様書は正しく書かれている」前提にあるからテスターは「なぜか仕様書とプロダクトが一致した動作をしない。これはバグなのか、それとも仕様書の不備なのか」と本来不要である思考する時間が発生し、時間を取られることになる。そしてその疑問を解消するためにリーダーに質問し、リーダーが確認し回答するという二重三重の時間が取られることになる。これではテストが予定通りに進まない。

作業の分担をうまく捌けない

 作業分担は結構悩ましいもので、全員が同じ知識経験を持っていれば平均的に割り振ればいいだけの話だがそうもいかない。メンバーそれぞれの経験や知識をある程度把握した上で割り振らないといけないわけだが、これって決まった方法論があるのだろうか？例えば自分より後から参画したメンバーでもテスト経験という意味では何倍も知識量が上のメンバーがいたりするケースもあったりして（つまり業務経験が乏しいだけ）判断に迷う。

作業を抱え込みすぎてパンクする

作業の割り振りがうまくいかず、「だったら自分でやった方がいい」と抱え込んだ結果、週次のミーティングや割り込み作業・ミーティングにより時間が取られて想定のパフォーマンスを出せず潰れる。実際自分がメンバー時に作業の割り振りをされた時でも「割り振られたからには頑張る」という認識に立って作業を実施するのに、なぜか自分が作業を割り振る立場になった途端に「こんなに作業を押し付けていいのだろうか？」という「遠慮」のようなものが発生してうまくできなくなる現象。

質問への回答レスポンスが遅い

タイミングにもよるが、妙にレスポンスの遅い人がいる。特にリモートワークをしていると質問先の人がどのような状態にいるか把握できないのでレスポンスが遅いと「寝てるのか？」と思ってしまう。そうでないにしても質問者は今の作業を進めるために質問をしているので、素早いレスポンス（それが直接回答にならなくても、質問を受けたことを了解するレスポンスをするなど何らかのアクションを取らないと質問者の作業が止まる場合もある）が必要。

作業進捗を把握してない

作業を割り振ったはいいが、どこまで作業を進められているか把握できてない。これは「今日はここまでやる」というような目標がないことも要因にあると思う。つまりその日の作業目標を立てられていないか漠然としている。作業の進捗がよくわかってないといつまで作業を続けるべきなのか困惑するメンバーも出てくるだろう。

想定外の事象にうまく対応できない（パニックになる）

これはリーダー業務に関わらず、なのだけど想定外の事象があったときに思考が停止してしまうことが多い。近い過去に同じことが起きていればある程度対処する方法について考えられることもできるが、全く知らないことだったりするとその時点で何をすべきかが浮かばない。当然ボーッとするわけじゃなくて「誰か」に対処方法を聞いたりすることくらいはできるのだけど、マズイのは「どうしましょうか？」という質問などに対してあまり考えもせずに勘で「こうしましょう」などと回答してしまう場合がままあるということ。

はっきりいって自分自身を見つめ直すいい機会になったエントリー、というだけで果たしてこれが記事を読みにきた方の参考になるのかどうか・・・

リーダーの仮面――「いちプレーヤー」から「マネジャー」に頭を切り替える思考法

できるリーダーは、「これ」しかやらない メンバーが自ら動き出す「任せ方」のコツ

リーダーを目指す人の心得

面白いほど役に立つ　図解　人を動かすリーダー力

あっ、次の仕事はバケモノ退治です。（５） (サイコミ×裏少年サンデーコミックス)

仕事が速いのにミスしない人は、何をしているのか？

「いい人」をやめれば人生はうまくいく

設計書レビューが苦手な人が克服する方法

人前で話すことが苦手である。

大人数の前で何かを話さなくてはいけないとき、例えば新任の挨拶のように内容がなくても問題ないようなものから、事前に準備をして行う成果の発表を行うようなものまでほとんど全て、苦手である。

一般的な「対話」は苦手というよりはどちらかと好きな部類なので、あくまで1対多という状況で話をすることが苦手なのだと思う。

自分のレビュー下手に気づかない（気づかないようにしていた）

実はエンジニアとして働き始めてすぐに、設計書やテストケースのレビュー時に、なんとなく「なんかおかしい」とは感じてはいた。 ただ、あまり頻繁に実施することもなかったので、その時の違和感は時間の経過とともに風化してしまっていた。ただ、しこりとして残っていたのは確かだと思う。

そして今になってテストケースの設計レビューを頻繁に行うようになって、「なんか変だな」という違和感というか心の引っ掛かりというかそういうものが時間の経過で風化する前に、また別の設計レビューがあり、違和感が確信に変わった。

自分のレビューって「グダグダになること多いな・・・」ということに。

それまでも違和感としてずっとあったはあったが、普段の会話とかでは問題ないし、人前で何かスピーチする機会もないので、気づかないというか気づかないようにしていたのだと思うけど、さすがに2週間に1回の頻度でレビューを実施していれば嫌でも気づかざるを得ない。

どうしてグダグダになるのか

ドキュメントは揃っているし、完璧ではないにしろ仕様は頭に入っている。それでもいざレビューとなるとなぜか話がぐちゃぐちゃになって、結果としてレビューがグダグダになる。

今まで特にグダグダになった時のレビューを振り返ってみる

1. やたら早口
2. レビュー対象が広範囲にわたる場合に、要点を説明しない
3. 「〜と思う」「〜はず」などの曖昧な表現を多用する
4. 特にレビュー時に確認しておきたい箇所と、サラッと流してもいいような箇所を同じレベルで話してしまう
5. 周りの沈黙が恐ろしくなって、余計なことを言ってしまう

これらが混ざり合った感じのレビューになっている気がする。もし自分がレビュアーなら「聞きにくいし理解しにくいレビューだなぁ」と感じると思う。特に早口になるのは一種の精神的な防御態勢に入っていると思う。早口で話すことで、要点をボカすというか「なんとなく合っているだろう」と思ってもらいたい、というか...そんな姿勢でレビューしても意味ないのに。

また、レビュー時に概要を説明しないでいきなり本題というかドキュメントの内容を説明しようとしている。例えば「今回のシステム改修の要件は○○なので、確認観点としては□□と△△です。」というような説明をしないで「□□と△△と■■をチェックして、▲▲の確認もします」というようにレビューを進めてしまう。確かに確認する個所ではあるので間違いではないが、主語がない長台詞のようで何をするためのものなのか理解を妨げる。

「〜と思います」などの曖昧な表現それ自体は会話として別にNGということでもないが、「〜なので、こうです」という断定口調に比べるとやはり印象が良くない。というか口癖になってるので、それが悪影響を及ぼしているのだと思う。

１〜１０まで全ての内容を一通り説明しようとするので、その中で重要なものがぼやける。例えばログイン画面とログイン成功画面があるシステムにおいて、重要なのはログインのID項目とパスワード入力項目、ログインするボタンと認証成功時に表示されるログイン成功画面、ログインNGの時のメッセージなどだと思うが入力エリアの表示位置やサイズ、色、などまで全部説明しているようなもの。

元営業してた癖が抜けないのか、対面相手が無言でいる「間」に弱い。どうしてもその間を埋めたくて余計なことを喋ってしまったりする。レビューの場で必要ないのに「〜ですよね？」とつい質問してしまったり（レビュアーが複数いる場合に誰に質問しているのか不明な場合も多い）。

どうしたら改善できるか

とりあえず、今の自分のやってる失敗を逆にしてレビューしてみたらいいんじゃないだろうか。

1. 早口　→　ある程度ゆっくり喋る
2. 要点を説明しないで始める　→　　レビューのポイントとなる要点を説明する
3. 曖昧な表現を多用する　→　断定口調＆「〜ですね」という話し方にしてみる
4. 全部同じレベルで話す　→　飛ばしてもいいところは「〜なので飛ばします」と説明する。必要なら指摘が入るはず。
5. 沈黙に耐えきれず余計なことを言う　→　沈黙は「同意状態にある」「特に指摘が見つからない」ということだと認識する

そもそも仕様が頭に入りきれてないとか、不明点がある場合は失敗の可能性が高いので、事前に確認しておくとかすることも大事。

次回以降のレビューでは以上のことを気をつけて、レビューに臨みたいと思います。

なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書）

いちばんやさしい資料作成&プレゼンの教本 人気講師が教える「人の心をつかむプレゼン」のすべて (「いちばんやさしい教本」シリーズ)

今まで誰も教えてくれなかった人前で話す極意 〜年間330講演 プロの講演家が語るスピーチのコツ〜

スピーチや会話の「えーっと」がなくなる本

ポストモーテムやってみた

今までプロジェクトの終わりにプロジェクトメンバーで集まって、KPTという作業をまれに行ってきた。KPTとは、KEEP・PROBLEM・TRYの頭文字から取った言葉で要はプロジェクトを終えての振り返り作業のこと。

KEEP・・・継続していきたいこと

PROBLEM・・・問題など改善したいこと

TRY・・・取り組むべきこと

これらをそれぞれチームメンバーが出せるだけ出して、リストに書き出して残すという作業を行なってきた。チームメンバーが揃って1時間程度時間を使ってリストを残すのだけど、そのリストの寿命は、「Google Driveに格納された時点」で尽きてしまう。つまり、誰もそのリストを後から読み返すことがないのだ。全く意味がない。

それを知ってか知らずかわからないが、PMから「ポストモーテムを今後やります」という周知があり、今回からやることになった。

ポストモーテムとは

正直、KPTもここの現場に来るまで知らなかったがポストモーテムも単語として全く耳馴染みのない言葉で、最初は何を指示されているのかわからなかった。

本来、ポストモーテム（post-mortem）とは「検死」という意味で、転じて終わったプロジェクトの実施報告・振り返りのこと。「じゃあKPTと変わらないじゃないか」という声が聞こえてきそうだが、KPTはチームメンバーがプロジェクトに対してそれぞれ意見を提出するのに対して、ポストモーテムはリードメンバーが一人で振り返りを行い、ドキュメントを作成する。関わる人数が複数人か一人かという違いが大きい。またKPTでは理路整然としたドキュメントは作成しないが、ポストモーテムではドキュメントを作成する。

※というのはここの現場だけのルールで、他でどのようにしてるかわからない

単純にKPTだとコストがかかる割に成果物として意味をなさないので、ポストモーテムとして作業名目を変えてコスト削減と成果物の両方を得ようというのが目的かもしれない。そのあたりはわからない。

どんなドキュメントを作成すれば良いか

 例えば今かかってる工数について改善を考えてる状況とか、業務のやり方（例えばソフトウェアテスト工程）の改善を考えてるとか、人やチームでポストモーテムを実施するのはなんのために？というのがあるので目的に合わせた内容を作成する、というのが最初にあると思う。

個人的にはドキュメント自体のボリュームはそんなに多くない方がいい、つまりポストモーテムそれ自体に時間をかけるのはなんか違うのでは？という感覚。コンサルティングじゃないんだから、そんなに大量にページがあってもしょうがないだろう、という感覚なんですけども。

具体的には、

1. 目次
2. 案件やプロジェクトの概要
3. 案件やプロジェクトの実施見積もり、工数見積もり
4. 案件やプロジェクトの実施状況、工数状況
5. 見積もり時点と実際の状況との差分、乖離の割合比較
6. 乖離原因
7. 継続すること、改善したいこと
8. 作業評価、感想
9. 当該ポストモーテム自体への第三者からの評価メモ

上記のように、多くても10ページといったところじゃないだろうか。これでもページ数的には多い感じもするし、不要と判断できる箇所はページを作成せず、まとめられるところはまとめてしまう方が良いと思う。というのも、ドキュメントを作ることが目的ではなくて、あくまでも振り返り・今後の改善や今実施していることの継続とかそういうことを検討するというか、確認することがポストモーテムをする意味・意義なので。

あと、一つの項目に対してあまりダラダラと長い文章を書くのもよくないのではないかと思う。できるだけ端的に（短くできるなら1行レベルでもいいと思う）すべきかな。

ポストモーテムを実施した、その後

せっかく共有された知見というか振り返りなので、それをチーム内で共有したい。失敗ならその失敗はなるべく繰り返さないように、成功したことなら、みんなでやっていく。まだ始まったばかりなので、どう活かされたか、については後日報告したい。

LEADER's KPT

トヨタに学ぶ　カイゼンのヒント71（新潮新書）

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

ポストモーテム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

【工数】ソフトウェアテストのコスト

最近QAチーム内でテスト実施前に「見積もり」を提出し、その見積もりが妥当かどうか検証するステップが作業として盛り込まれた。正確にはこれまでも実施にかかる工数は提出していたが、手計算による簡易すぎるものだったので工数の妥当性についてある程度正確性を出そう、ということでプロジェクト単位でシートを作成し始めたという感じ。

実はこれまで「見積もり」という作業に関わったことが一度もなかった。大体「この日から作業を開始して、この日までに終わらせてください」という作業指示のもとプログラミングやテストなどを実施してきていて、プロジェクトの全体像を把握することがなかった（下流工程エンジニアかつ底辺SESエンジニアならではです）。

そして、実際に見積もり作業を実施して

「大体設計に1人日かかるなぁ。設計のバッファに0.3人日として、実施に3人日、バグ修正確認も必要なのと何かしら作業の停滞があることも考慮して0.5人日を実施バッファに取りましょう。設計バッファの0.3を0.5として計算して、合わせて5.0人日がこのプロジェクトにおけるQA工数です」

というような報告をドキュメントで提出している。大体提出した通りに見積もりが通るのだけど、後から要件追加などがあったりして再提出することもある。実際に見積もり作業（小さなプロジェクト単位で見積もりしてるので、計算対象が多くないというのもかなりあるが）をしてみて、そこまでヘヴィな作業ではないのかもしれないというのが実感だ。

あくまで自社プロダクトに対する見積もりなので、例え見積もりと実績に乖離があっても実施者に何かペナルティがあるわけではない。これが対外的な見積もりになるとまた話は違ってくるのだろうが・・・（1億でシステム受注して、実際かかったコストが受注費用を超えてしまい大赤字になった、とかIT業界の悲しい話とかでたまに聞く）

タイトルから逸脱した話が延々続いているが、何が言いたいかというと、見積もりって結局「このプロジェクトに対してQAするとこのくらいコストがかかりますよ」ということを明示していく作業のことなのだ。

例えばWEBページのデザイン改修プロジェクトで、そのデザイン改修されたものがリリースされたとしてもそれ自体は何も収益をあげるものではないのに見積もりしてみたら工数がとんでもなくかかった、とかいうのが割とあるなと傍目に感じていたが、よく考えたらとんでもないことになっているということにさっき気づいた。

複数ページにまたがってデザイン修正が入ったとして、それぞれのページに対してテストを実施するとなると案外工数がかかるものだが、例えばそのテストに対してQAから「トータルで10人日かかります」というような見積もりが出たとして、10人日という数字自体にインパクトはあまり感じないが、月に80万円の予算で外注としてQAエンジニアを雇っていた場合、そのエンジニアの1ヶ月の稼働が20日程度として10人日なので丁度半分。つまり80万円の半分40万円がそのプロジェクトのQAにかかるコストになるということである。

40万円...これを大きいコスト捉えるか妥当と捉えるかは正直なんとも言い難い。

じゃあ、コストがかかり過ぎているのでテスト実施を半分にしましょう、というのは品質担保とのトレードオフになるのでそれはまた別の判断が必要になる（まさに予算との兼ね合い）。

かかる工数を実際のお金に換算してみるとちょっと怖くなる。大体今のQAチームには10名弱人員がいるので、月に800万円くらいコストがかかっている計算になる。年間で1億円である。1億！それだけコストをかけてしっかり品質の検証することを期待されてるわけですので、頑張らないとダメだと改めて思った。

というのも、あまりコストがかかりすぎる、ということになれば自社でQAチームを持たずに外注でええやんという話になりなりかねないためだ。それだけはなんとしても避けたい。

それから直接のテスト業務だけでコストがかかるわけではない、というのは理解すべきことだと思う。ミーティングだって工数だと理解しないとだめ。時給換算して1H5000円の社員が10人が1時間ミーティングしたらそれだけで5万円かかる。5万円のミーティングだぞ！

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

テストから見えてくるグーグルのソフトウェア開発

マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1

ザ・ゴール

ソフトウェア見積り　人月の暗黙知を解き明かす

人月の神話