コンピュータに関連した業務では、
インターネット、または書籍から知識を得る場合が多くあります。

インターネットで検索して簡単に得られる知識もありますが、
複数の書籍を読み体系的に覚えなければならない知識もあります。

その知識を形にしやすいか、形にしにくいかで大別して
確かな物と不確かな物に分けて考えてみます。

確かな物は、問題が決まっていてゴールが見えているものです。
「プログラム動作に一つの問題がありました。解決できませんか？」
これは解決の判断がしやすく、方法も確立しやすいものです。
コードを追っていけばすぐに見つけられる場合が多いです。

対して不確かな物は、問題が決まっておらずゴールがあやふやなものです。
「プログラム動作に問題はありませんか？」
こう言った場合、100%問題が無いことを立証するのは難しいと思います。
誰かが判を押したから問題ないという意味ではなく論理的にです。

プロジェクトが進行すると多数のソースコードを抱えることになるため、
このように不確かな問題を追求する事は労力のかかる作業になります。
数値にするのが難しく地味で面白みのない作業と思うかもしれません。

ただ、不確かなものを確かなものにする方法はいくつかあります。
今回はコードレビューを挙げます。

書いたソースコードを誰かに見せたり、説明したりしたことはあるでしょうか？
ソースコードを人に見せて説明をすると、
意外と基礎的な点で言葉が詰まってしまうものです。

「これはこういう物だから」
「他の人がこうしてたから」
「コピー＆ペーストしただけ」

このような言い方が出てしまったら基礎的な学習が不足しているのかもしれません。

レビュアーからは、
「この処理はこのようにしてみたら？」と提案を受けたり、
時には
「この処理はダメだ！」と頭ごなしに指摘を受けることもあります。
その場合も上記のような反論をせず、論理的に考えるといいでしょう。

また、他のメンバーが書いたソースコードをレビューしましょう。

レビューでどう見られるかを考えながらソースコードを書けば、
不確かなものが形になってくると思います。

コードレビューの細かな説明は省きますが、
書籍などに詳しい情報を見つけられると思います。

開発チームを運営する上で組み入れたい効果のある工程です。