単体テスト、結合テスト、総合テストのそれぞれのテストで、障害（バグ）が発生したときは、プログラムを修正し、再テストを行うと思います。
このとき、あなたは、どのような再テストを行っていますか？
まず考えられることとして、障害（バグ）が発生した箇所がちゃんと正しくなっているかを見るということが挙げられます。このテストは必ず行うとは思います。
ですが、この障害（バグ）を修正したことによる影響の確認はどうでしょうか？
今回は、単体テスト、結合テスト、総合テスト、障害（バグ）発生時に、必ずやるべきテストとして、リグレッションテストが必須であることを学んでください。
カテゴリ：問題管理
設計や実装、テストなどにおいて、その成果が正しいのかどうかを確認する作業がレビューです。
このレビューは、悪の根源とも呼ばれるほど、非常にやっかいな存在であることは、あなたもご存知だと思います。
本来レビューは、思い込みによる誤りや漏れなどを事前に見つけ、ユーザーの目的を達成させるために軌道修正を行うべき作業です。
しかし、そのほとんどが、軌道修正することなく、さらなる脱線を助長しているのです。
今回は、品質向上のためにはかかせないと思われている「レビュー」がいかに悪なのかについて考えてみたいと思います。また、どのような思考であれば、本来の役割を果たすことができるのかも考えてみましょう。
カテゴリ：品質管理
システム開発のテストは、障害（バグ）をつぶす作業とも言えます。
しかし、システムが納品（リリース）され、運用が始まったあとも障害（バグ）は発生することがあります。
障害（バグ）には、２つの原因が存在します。
それは、「直接原因」と「根本原因」です。
この２つの原因は、因果関係にあります。
根本的なミス（根本原因）によって表面化された（直接原因）不具合が障害（バグ）となるのです。
通常、障害が発生すると、直接的に障害が引き起こされた「直接原因」を究明することに力が注がれることが多いです。
しかし、「根本原因」を知り、分析することで、多くの直接原因を減らすことができるのです。
今回は、この２つの原因の違いを理解し、品質を高めるための思考を学んでください。
カテゴリ：問題管理
プロジェクトに参画する条件に、必ず、「コミュニケーション能力の高い人」という項目があります。
また、就活で頑張っている大学生や専門学校生、高校生などが面接をする企業なども、決まって、採用条件に「コミュニケーション能力のある人」というのがあります。
あなたは、コミュニケーション能力は高いですか？
それとも、低いほうですか？
実は、ほとんどの人が、このコミュニケーション能力を間違って解釈しています。
今回は、このコミュニケーション能力について考えてみたいと思います。
カテゴリ：コミュニケーション
システム開発に限らず、仕事をする上で、作業を効率的に行うことが推奨されます。
ムダや間違いを極力なくすためにも、単純な作業は効率化すべきです。
ですが、効率化しないほうがよい場合も多々あります。
今回は、作業を行う上で、効率化すべき場合としないほうがよい場合について、その見極め方を考えてみましょう。
カテゴリ：作業効率
