プログラムの作成が終わった段階で行うテストが単体テストになります。
単体テストは、軽視されがちですが、実はとても重要な工程になります。
軽視されている理由は、プログラム作成と単体テストを一緒に「実装」工程としているプロジェクトが多いことが挙げられます。単体テストを一つの工程にしていないということです。
そのような状況のプロジェクトでは、単体テストの項目は非常に意味のないものができあがります。
その場しのぎの、どうでもいい、バグの出ないテストしかしないということです。
これでは、結合テスト以降に大量に障害（バグ）が出るのは当たり前なのです。
今回は、品質を上げるための、単体テストに必要な観点について、学んでください。
カテゴリ：テスト
システム開発の現場では、言われたことしかしない人あるいはできない人がいます。
前者を動かない人、後者を動けない人と定義します。
それぞれのタイプの人の心理を考えたことがありますか？
なぜ、この人は動かないんだろうか？動けないんだろうか？と。
今回は、一般的には役に立たない人と言われている、これら動かない人と動けない人の考えていることについて考えてみたいと思います。
彼らの心理を理解できれば、次は我が身だということが理解できるでしょう。
カテゴリ：コミュニケーション
単体テスト、結合テスト、総合テストのそれぞれのテストで、障害（バグ）が発生したときは、プログラムを修正し、再テストを行うと思います。
このとき、あなたは、どのような再テストを行っていますか？
まず考えられることとして、障害（バグ）が発生した箇所がちゃんと正しくなっているかを見るということが挙げられます。このテストは必ず行うとは思います。
ですが、この障害（バグ）を修正したことによる影響の確認はどうでしょうか？
今回は、単体テスト、結合テスト、総合テスト、障害（バグ）発生時に、必ずやるべきテストとして、リグレッションテストが必須であることを学んでください。
カテゴリ：問題管理
設計や実装、テストなどにおいて、その成果が正しいのかどうかを確認する作業がレビューです。
このレビューは、悪の根源とも呼ばれるほど、非常にやっかいな存在であることは、あなたもご存知だと思います。
本来レビューは、思い込みによる誤りや漏れなどを事前に見つけ、ユーザーの目的を達成させるために軌道修正を行うべき作業です。
しかし、そのほとんどが、軌道修正することなく、さらなる脱線を助長しているのです。
今回は、品質向上のためにはかかせないと思われている「レビュー」がいかに悪なのかについて考えてみたいと思います。また、どのような思考であれば、本来の役割を果たすことができるのかも考えてみましょう。
カテゴリ：品質管理
システム開発のテストは、障害（バグ）をつぶす作業とも言えます。
しかし、システムが納品（リリース）され、運用が始まったあとも障害（バグ）は発生することがあります。
障害（バグ）には、２つの原因が存在します。
それは、「直接原因」と「根本原因」です。
この２つの原因は、因果関係にあります。
根本的なミス（根本原因）によって表面化された（直接原因）不具合が障害（バグ）となるのです。
通常、障害が発生すると、直接的に障害が引き起こされた「直接原因」を究明することに力が注がれることが多いです。
しかし、「根本原因」を知り、分析することで、多くの直接原因を減らすことができるのです。
今回は、この２つの原因の違いを理解し、品質を高めるための思考を学んでください。
カテゴリ：問題管理
プロジェクトに参画する条件に、必ず、「コミュニケーション能力の高い人」という項目があります。
また、就活で頑張っている大学生や専門学校生、高校生などが面接をする企業なども、決まって、採用条件に「コミュニケーション能力のある人」というのがあります。
あなたは、コミュニケーション能力は高いですか？
それとも、低いほうですか？
実は、ほとんどの人が、このコミュニケーション能力を間違って解釈しています。
今回は、このコミュニケーション能力について考えてみたいと思います。
カテゴリ：コミュニケーション
システム開発に限らず、仕事をする上で、作業を効率的に行うことが推奨されます。
ムダや間違いを極力なくすためにも、単純な作業は効率化すべきです。
ですが、効率化しないほうがよい場合も多々あります。
今回は、作業を行う上で、効率化すべき場合としないほうがよい場合について、その見極め方を考えてみましょう。
カテゴリ：作業効率
システム開発が進むにつれ、進捗の遅れが発生することはよくあることです。
遅れが発生する原因は様々考えられますが、もっとも多いものに、見積が甘かった、不測の事態が発生し、工数が足りなくなったというように、見込んでいた時間をオーバーするというものでしょう。
そもそも、なぜ進捗管理をする必要があるのでしょうか？
逆に言えば、進捗管理をしているにも関わらず、ほとんどのプロジェクトで遅れが問題になります。管理してもしなくて、遅れが出るのであれば、管理する必要などないのではないでしょうか？
ここでは、進捗管理とはいったい何なのかを整理し、本当の進捗管理とは何かを考えてみたいと思います。
カテゴリ：進捗管理
あなたのプロジェクトのメンバーでこの人はなんでここにいるのだろう？と思える人はいませんか？
設計もプログラミングも出来ず、言われたことしかやらない、もしくは、言われたこともやらない、やれない人がシステム開発の現場には必ずといっていいほどいます。
なぜなのでしょう？
しっかり要員計画のもと確保されたメンバーではなかったのでしょうか？
カテゴリ：要員計画
よくシステムエンジニア（SE）とプログラマーの仕事内容を聞かれることがあります。
あなたはどうお考えですか？
はっきりと明確に説明出来る人は少ないのではないでしょうか？
私は、この二つの職種を明確に分けて説明することができません。なぜなら、その仕事の境界線があまりにも曖昧で、かつ、経験年数や年齢にも依存している場合も多いからです。
説明できないというより、分ける意味がないと思うのです。分けることにより、技術者が成長しないということにもつながっている気がしてならないのです。
また、システムエンジニア（SE）やプログラマーに向いている人、向いていない人はどういう人ですか？という問いも同じく、明確に説明することができません。
これは、その人の置かれている環境や考え方に大きく左右されることだからです。
カテゴリ：システム開発の本質
