今日学んだこと

分かっていることは書かない。分かっていないから書いて学ぶ。だから「今日学んだこと」なのです。

モジュールの使い方

(写真:水彩画展 その1)

《モジュールとは》

少し専門的な話になります。
モジュールとは、一定の目的で作られた機能を、再利用可能なように切り離したものです。
私たちIT業界では関数とも言います。

数学で言う関数は、例えば三角関数のように、値を適切に与えると中の仕組みを知らなくても、自動で知りたい値を返してくれます。
同じようにプログラミングで言うところの関数も、条件を引数(パラメーターとも言います)で渡せば、自動で自分の望むことを実行してくれたり、値を返してくれたりします。
分かりやすい例をあげれば、曜日算出関数を作成した場合、1995/03/10と日付を渡せば、その日の曜日を返してくれます。曜日計算は非常に複雑ですが、中でどうなっているかを知らなくても、値だけ渡せば自動で結果が返るので、プログラマは難しいことを考える必要がありません。

世の中にプログラミング言語はたくさん存在しますが、この関数をうまく利用すれば、言語の知識がさほど深くなくても、それなりのものを作れるようになります。
そして、この関数、つまりモジュールは、会社独自で整備する部分が大きいので、IT系の会社の実力の差とは整備しているモジュールの差という事ができます。

《プロジェクトにおけるモジュール》

私たちは、ときおりプロジェクトに参加するメンバーについても、モジュールの考え方を適用します。
とくに、製作の一部を外部委託している場合には、モジュールとして正しく機能してくれることを期待します。

外注先に与える値とは、設計書と、そしてそれに対する対価です。
期待する値とは、設計書に対する完成品と、それに付随して発生するドキュメントを指します。
もし、それがこちらの期待通りの仕上がりであれば、その間の工程に要する時間はお金で買うことができます。
委託側として、スケジュール管理の面でも、予算管理の面でもこんな楽なことはありません。

しかし、実際はそんな上手い話ばかりではありません。
同じ社内で製作していても品質に差が出るのに、ましてや社外相手では伝え漏れや、伝え間違い、さらに聞き間違いが発生します。一旦この行き違いが発生すると、お互い悪気がなかった分、自分の正当性を主張して譲らず調整には苦労します。
また、相手の高い技術力を期待して任せたはずが、実は担当者にそこまでのスキルはなく、やり直さなければならない場合もあります。

《モジュールの正しい使い方》

モジュールを正しく使う場合に大切なことは、モジュールの機能や性能を正しく知ることです。

私たちは、時に社外の人が立派に見えるので、外部委託先として過度に期待する傾向があります。
ですが、その期待値の分だけ、モジュールとしての性能を見誤っているので、後々期待値とアウトプットのギャップに苦しまなくてはなりません。

実績や触れ込みが立派でも、どんな担当者がアサインされるか分かりませんし、先方がどの程度こちらの求めている精度を理解しているかも分かりません。
まずは、少しだけ値を投げて、アウトプットを確認する必要があります。
そして、アウトプットが出たら、その精度に応じて使い方も変えなくては失敗します。

相手が人間だった場合や、会社だった場合、こんな道具を扱うような感覚は馴染まないも知れませんが、そこは割り切って客観的にインプットとアウトプットの関係を見極めることが大切だと思います。