1.はじめに
前回の記事で、あるデータを取り扱う歳の認識の仕方の違いについて述べました。モダンなプログラミング言語のエンジニアと違い、データを配列として認識するのに対し、COBOLエンジニアは一度に一行のデータを認識し、それを繰り返すと述べました。
今回の記事では、プロジェクトチームの中でCOBOLエンジニアとモダンなエンジニアが共同作業を行う場合に想定される課題について述べます。
2.データの認識の仕方の違い
前回の記事でCOBOLエンジニアの頭の中について説明しました。
COBOL脳を解説する（１）
これを元に、あるデータを見た時に、それぞれのエンジニアが頭のなかでどのように認識しているかを図にしてみました。
例えばRDBの結果セットや、テキストファイルを取り扱う際には必ずこのような認識が各エンジニアの中で行われます。こんな基本的なことですら考え方が異なるエンジニアたちが、１つのチームでうまく強調して働くことはできるのでしょうか。実際のところ、うまくいっていないケースはある程度存在するようです。先日、社内の勉強会でもこのような事例が報告されていました。また、ツイッターやブログをみると、COBOLに対する不満が書かれているのをしばしば目にします。いわゆるStaticおじさんも、実はこの認識の違いが遠因なのかもしれません。
3.問題が発生するチーム編成
すべてのチームで、COBOLやCOBOLエンジニアに起因する問題が発生するわけではありません。問題が発生するのは、チームのリーダーとメンバーで、プログラミング・パラダイムについて考え方の差異がある場合だと考えます。 チームにおけるリーダーの役割は様々ですが、ここではガイド＆レビューという作業に着目して議論を進めます。
チームリーダーは、プロジェクトのゴールヘ向かうための作業を定義し、メンバーへ指示を出します。この際、暗黙であれ明示的であれ、なんらかのメソドロジーを念頭に置いていると思います。これは、プロジェクト全体の方針による場合もあるでしょうし、リーダーの知見に基づく場合もあるでしょう。そして、メンバーが作った成果物（ドキュメントやソースコード）をレビューするというのも１つの役割です。
一方、メンバーの方はリーダーのガイドに基づき作業を始め、成果物を提出するわけですが、リーダーの指示が理解できない場合もあるでしょうし、自分なりに作業して提出したら、理解できない理由でレビューがNGになる場合もあるでしょう。この時リーダーは恐らく、うちのメンバーは理解が悪いだとか、なぜ私の言っていることが理解してもらえないのだろうか、とか、そういう不満を持っています。このようなコンフリクトがなぜ発生するのか、次の節でもう少し詳しく書きます。
4.プログラミング・パラダイムの違いがどのようにチームに影響するか
例えば、次のような要件があったとしましょう。一般に、要件は必ずしもスペシフィックに記述されている訳ではありません。例えば上記2.で
（要件）
ファイルに含まれるすべてのデータに10を掛ける
これは、2.で書いた図のようなデータに対して、なんらかの処理を行うことを想定してください。この要件を読んで設計書を書くとしましょう（設計書をどのレベルまで詳細化すべきかという議論は置いておいて）。恐らく次のように書くと思います。
（COBOLエンジニアによる設計）
入力ファイルをオープンする
出力ファイルをオープンする
最初の１行を読む
項目１に１０を掛け、ワークレコードにセットする
項目２に１０を掛け、ワークレコードにセットする
項目３に１０を掛け、ワークレコードにセットする
項目４に１０を掛け、ワークレコードにセットする
ワークレコードを出力ファイルに書き出す
最後の行まで同じ処理を繰り返す
出力ファイルをクローズする
入力ファイルをクローズする
一方、モダンなエンジニアは次のように書くでしょう。
(モダンなエンジニアの場合)
入力ファイルオブジェクトのすべての要素に１０を掛け、結果を出力ファイルオブジェクトに代入する
上記は誇張した表現になっていますが、リーダーとメンバーの頭の中がこんなに違っていたら、ガイド＆レビューが上手くいくわけがないと、私は思います。リーダーがCOBOLエンジニアだとすると恐らくは要件とのトレーサビリティを理由にレビューNGにするでしょう。モダンなエンジニアがリーダーの場合は、冗長な記述だということでNGにすると思います。NGにされた方は不満に思いますよね。特に、モダンなエンジニアの場合、こんなにエレガントに記述しているのに何故だ、と思うでしょう。
5.ではどうすれば良いか
しっかりしたガイドが提供できていれば、コンフリクトはかなり減ると思います。あらかじめ、逐次処理で書きなさいとか、可能な限り配列を想定しなさいとか、そういったことを、リーダーの頭の中でなく文書にしたものがあれば良いのです。さらに、今行っている設計という作業のゴールがどこなのかを示めせれば、なお良い。要件をスペシフィックにするものなのか、このあとすぐコーディングに入るのか、設計書はユーザー部門のレビューを得る必要があるのかどうか、といったようなことがガイドに書かれていれば、メンバーの不満がかなり減ると思います。書き方そのものより、ゴールを示す方が重要かもしれないですね。
6.最後に
最近、社内の事例紹介として、若いリーダーがCOBOLプロジェクトで苦労しているというプレゼンテーションを見る機会がありました。それをきっかけに私なりに考察した結果が今回の記事です。どうもCOBOLの言語仕様というよりは、メソドロジーとか、リーダーの役割だとか、そういった部分がCOBOL問題の原因のようです。
特に今回は設計という作業に力点をおきました。設計という作業を考える時、よく言われるのが、「プログラミング言語に依存しない設計」という言葉です。私はこのようなものが実在するとは思えない。しかし事務計算の領域に限って言うと、もし存在するとしたら、それは結局のところCOBOL向けの設計になっているのではないかと思います。COBOLにアドバンテージがあるとすれば、その点だと私は思います。