プロジェクトオーガナイザの吉田聖書です。
プログラムを書いたことがない人には
ピンとこない話かもしれません。
ですが、部下や外部のパートナーに
プログラムを書かせているのであれば、
是非一度考えてみてもらえたらと思います。
初めにお断りしておきます。
私自身はプログラムを書きますが、
言語や技術の作者や研究者ではないので
全く的を外しているかもしれません。
しかしプログラミング言語を利用する立場で
私がこの数年何となく感じていることです。
データ構造（コンテナ）の一つに
「連想配列」というものがあります。
言語によってハッシュ（Hash）と言ったり
マップ（Map）や辞書（Dictionary）
と言ったりすることがあります。
分かりやすく言うと、データ一つ一つに
ラベルを付けられるようなものです。
データをVALUE（値）、ラベルをKEY（キー）と呼びます。
とても便利で、扱いやすいデータ構造ではあるのですが、
一方で懸念していることがあります。
それは、言語によって制約はあるものの
KEY＝VALUE という形式であれば
何でも放り込めるため、
設計フェーズで行うモデリングという作業が
おざなりになっているのではないかということです。
昔、C++やJavaという言語が流行りましたが、
これらはどちらかというと硬派で、
データの入れ物をクラスや構造体という形で定義していました。
逆に、そのクラスや構造体の定義を見れば
そのモデルが理解できます。
ところがコンテナのクラスや構造体を定義せず、
ほとんどのコンテナを連想配列で済ませることもできます。
そうすると、連想配列では見るべき定義が存在しない為、
モデルの全体像が掴みにくいのです。
もちろん、きちんとやっているチームでは
設計段階でモデリングをきちんと行い、
ドキュメントに残しておきます。
しかし、そうではないチームは、
行き当たりばったりで、
とりあえず値を連想配列に放り込みがちです。
するとその連想配列はいつの間にか成長していて
ますます全体が把握できなくなります。
これは分散オブジェクトから
Web API（REST API）へ主流が移ったことと
関係があるのではないかと考えています。
分散オブジェクトとREST APIの関係は
リレーショナルDB（RDB）とNoSQLの関係や
XMLとJSONの関係に似てないと言えなくもないです。
分散オブジェクトやRDBは
カチッとしたモデリングが必要で
変更に弱い（変更の負荷が高い）です。
だから変更が頻繁に発生するシステムでは
REST APIやNoSQLが選ばれるのでしょう。
これはどちらのタイプの言語や技術が
優れているという話ではありませんし、
どちらのタイプを採用すべきだという話でもありません。
設計と実装は別です。
気になっているのは次の点です。
モデリングは、データの羅列に意味や秩序を与えます。
連想配列は大変便利ですが、
モデリングがなければプログラムが散らかり、
結局のところ変更に弱くなって
メンテナンスコストが上がってしまうのではないかということです。
これが「あるある」なのか、
私が見ている範囲での話なのか分かりませんが、
設計としてモデリングをきちっとやり、
その上で実装を連想配列で行うというのであれば
全くその心配はないのかなと思います。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。