学びたいことは何ですか？
優れた研修計画を作成して新人のRPGプログラマを最大限に活用する
新人のRPG開発者は貴重な赤色ダイアモンドと同じように大切にしなければなりません。幸いなことに、求人市場にはいつでもRPGプログラマが控えています。しかしこの供給も無期限に続くわけではありません。RPGを学ぼうという意欲は業界内で若干高まってきていますが、企業およびIT業界全体としては明らかに不足しています。RPGの研修コースがなくなっていくにつれて、新人たちにこの言語を習得してもらう機会があればITマネージャはそれを最大限に活用しなければなりません。新人の開発者はダイアモンドと同じように、見つけた後にどのように磨き上げるかでマネージャにとってそして市場一般にとっての価値が決まります。
ではRPGプログラマとしての秘訣を学ぼうと心から興味を持っている人に幸運にも巡り会えたらどうすればよいでしょうか。その答はまったく「場合によりけり」です。どういう意味での初心者なのか、すなわちダイアモンドのたとえで言えば、原石がどれくらい自然のままであるかによります。プログラミングが格好良いと思っていてRPGが新しいオンライン・ゲームのようなものではないという感覚を持っている経理出身の若者なのか。仕事の幅を広げたいと思っているオペレータなのか、IT学科の新卒なのか、基本をかじったことのある人なのか、熟練プログラマなのか。本稿ではこうした志望者たちを宝石に変えるにはどうしたらよいかについてお話します。それぞれの場合においてどこからはじめたら良いかを知ることが、期待通りの結果を得るための鍵を握っています。
何を期待するか
まず、最初のタイプのプログラマ、経理出身の若者から始めましょう。私自身もこのような経験は一度だけしかありません。しかしその経験があったため、そういう人たちが現れた時のためにプログラミングを深く学ぶ前に読んでもらいたいプログラミングやロジックの基本に関する書籍を1～2冊備えています。プログラミングはしばしばメディアで美化されますが、プログラミングを真面目に考えていない人がロジックと批判的思考法に関する良い本を数冊めくれば、すぐに逃げ出すことになるでしょう。
次のタイプの候補者はIT学科の新卒者ですが、この人たちはプログラミングの方法についてかなりの考えを持っているはずです。この人たちはプログラムの設計とその実装についての基礎を学んでおり、実際にプログラミングをしてみたくてうずうずしているのです。今日のIT学科の卒業生のほとんどはRPGのプログラミング経験は持っていないでしょう。今どきの大学でRPGを教えてくれるところはわずかながらありますが、実際にインストラクターが教えてくれる講義の数はここ数年で激減しています。たとえば私の母校では基本的なRPGのコースでさえももはやありません。しかしRPGのことを全く知らなくても、IT学科の新卒者はRPGをかなりすばやく習得できるだけの知識のベースを持ち合わせています。
オペレータは長年に渡ってAS/400システムを現場でサポートしてきたという人が一般的ですが、静かに(場合によってはそれほど静かではないかもしれませんが)システム管理の一部始終を学んできています。オペレータ出身の人たちはさまざまなレベルでプログラミングへの興味を示します。オペレータ出身で優秀なプログラマになった人を私はかなり目にしてきました。彼らはユーザーが何を望み必要としているかを理解する力があり、酷い設計のプログラムがシステムとユーザーにどのような影響を与えるのかを十分経験してきています。
RPG II/IIIを少しかじったことのある人も財産となりえます。私はかつてとある企業に勤務していましたが、そこではプログラマが年代物のERPシステムを修正していて、それをとある女性に渡していました。その女性は自身で曰く「その昔(プログラムの設計を)少しかじったことがある」とのことでした。彼女は何時間もかけてプログラムを調べ、プログラマが入れ込んでしまったバグを一つ一つ摘み、見事なまでにバグのないシステムに仕上げました。当時その企業では文字の置き違え以上のバグを実運用システム上でみたことはありません。その女性はのちに(当時の)COBOLの補講をいくつか受講した後、同社のシニアプログラマの一人となりました。
熟練プログラマは即戦力となります。ただしIT部門のライブラリ構造やビジネス習慣、ジョブ･ストリームなどを一から十まで学ぶまでは100％というわけにはいかないでしょう。これは新規採用したプログラマ全員に当てはまることでもありますが、熟練プログラマはこうしたことをより速く学習することができます。
どこから始めるか
前節でお話したプログラマのほとんどは少なくとも何らかの研修が必要で、その研修の多くが各人の既存のスキルと新しいことを学びたいという欲求が起点となります。ここがIT管理者やCIOの出番です。なぜならIT管理者やCIOは、新しいプログラマが日常の仕事の中で必要とするスキルについてかなり正しく理解しているからです。さらに、IT管理者は何を差し置いてもまず、RPGのロジック・サイクルという地に足の着いたプログラミング・スキルを蓄えるための電池を作って欲しいと新しいプログラマに期待しています。このサイクルはモダン･プログラムの中で脇に追いやられがちなのですが、多くのIT部門でRPG II/IIIのプログラムが実運用環境で完璧に稼動しています。新しいプログラマがこうした古いRPGプログラムの一部を保守することができるようになるには、RPGのロジック･サイクルを理解することしか方法はありません。現在のIT部門を私が2011年終わりに引き継いだとき、突合せレコード、ADDROUT処理が多数あることがわかり、しかも元となっていたERPに対する修正に関するドキュメントはほとんどないということがわかったときの私の驚きようはご想像の通りです。こうしたテクニックはもう何年も使っていませんでしたので、参考のために数冊の書籍に頼らなければなりませんでした。この経験により、基本をしっかり理解しておくことが、たとえそれが大いに活用されようがほとんど活用されずに終わろうが、全てのIT部門にとって恩恵をもたらすのだという信念がいっそう強くなりました。
初心者プログラマに必要なもうひとつの重要な基礎的スキルがサブファイルの処理です。サブファイルについては正式な研修コースをいくつか受ければなんとかカバーできますが、プログラマによってはツールの蓄えにかなりの差ができます。新しいプログラマを社内から見つけようとしていてその人物のスキル・セットがわかっている場合は、IT部門でどのようにサブファイルを処理しているのかを教える準備ができているといえるかもしれません。見込みのあるプログラマがサブファイルの処理方法をまったく知らないのであれば、この重要なツールの基礎をまず教えてください。ほとんどのIT部門では、RPGを使用して単にレポートを印刷していたという時代はもうとっくに終わっています。新しいプログラマがサブファイル(あるいはすくなくともデータをユーザーに表示するレコード)を使用しているプログラムに出会うのは避けられず、それを処理する方法を知っておく必要が生じるでしょう。プリンタ・ファイルは、モダン・プログラミングにおいて知っておく必要のあるもう一つの概念です。プリンタ・ファイルについてはもう長い間正式な研修からはずされていますが、新人プログラマ向けの研修には組み入れるべきでしょう。
ここまでの私のアドバイスは、新規で採用したプログラマがプログラミング一般についてはほとんど知らず、ここで紹介したツールの使用経験がないということを前提にしています。もちろんロジック・サイクル、ディスプレイ、プリンタ・ファイルを何年も使ったことがあり、これらについて復習する必要がない「新しい」プログラマに出会うこともあるかもしれません。しかし部門のルールについてそれがどのようなもので、どのように適用されているのかについては忘れずに教えておいてください。たとえば私はかつてあるIT部門に勤務していて、そこではフリー・フォームの使用は一切禁止されていてCL、RPGやディスプレイ・ファイルにおいてとても特殊な名前付けの習慣がありました。その習慣を身に付け、新しいプログラムを/freeで無意識のうちに始めるという習慣を忘れ、ほとんどのループを処理するのに使用されていたleaveオプコードやiterオプコードに適応するのに時間がかかりました。使用させたい習慣やスキルを新しいプログラマに身につけてもらって実践してもらうには、その経験レベルにかかわらず研修セッションをいくつか実施するのが有効です。
プログラミングについてもう一つ重要な基本的側面は、コードに関するドキュメント(社内向けと社外向けの両方)の管理です。ドキュメントを作成するのは習慣であると主張する人もいますが、一部のプログラマにとっては習慣というよりは訓練です。今日どこでも見られるぎりぎりの体制のプログラミング・スタッフは、大急ぎでバグの修正を加えた後に、そのプログラムに対して行ったことすべてについてのドキュメントを作成する時間がほとんどありません。ですから良いドキュメントを残しておくことが、後で問題を引き起こすかもしれないコードを書いた人がそれを書いたときに何を考えていたのかを保守プログラマに理解してもらう鍵を握っています。またドキュメントはプログラムを書いた人がそれをのちに変更する必要が生じたときにも時間の節約につながります。大量のコメントはコードを読みづらくしますが、コメントがないコードを読むのは困難です。
新しいプログラマたちに対してコメントの重要性を強調しておくことは重要ですし、コメントに関する自IT部門の標準を説明することも重要です。これらはともにプログラムのコードに関してもそうですし、コードの外に記述するドキュメントについても言えることです。プログラム自体とは別に作成するドキュメントもコード中に記述するコメントと同じくらい重要です。外部ドキュメントでは、新人のプログラマに対してできるだけたくさん記述するように促し、どのような機能についてコードを作成しているのか、システム全体に(または古いコードを保守している場合はプログラム全体として)どのような影響を与えるプログラムにしようとしているのかを伝えられるようにします。ドキュメントの作成について初めの訓練が良いとその後の習慣が良くなります。
これは次の話題、フォーマッティングと文法につながります。プログラムのコードはきちんと機能するだけでなく、IT部門の標準に準拠していなければなりません。多くのIT部門にはなんらかのコーディング標準があり、プログラマはそれに従ってコードを読みやすく統一した形にしています。(きちんとした標準がないのであれば、新しいプログラマが作成するコードが読みやすくなるように時間をかけてください。) 新しいプログラマたちにはガイドラインのドキュメントと標準に沿って記述されたコードの例を渡すか、あるいはコーディングするときにどんなことが期待されているのかを誰かが一対一で説明することが必要です。まったくの未経験者のプログラマ(たとえば経理出身の若者)に教えるときは優位な立場にあります。あなたが教えることを学ぶしかないからです。そのためプログラマをIT部門にぴったり合うように育てることができます。RPGを学ぼうとしているプログラマについても熟練であろうがなかろうが同じことが当てはまります。演算仕様書(もし使用していれば)でフィールドを宣言するとかハード・コーディング、モジュールに対する古い呼び出し方(CALLBやCALLP)などといった悪習慣から抜け出すことができるように導いてあげてください。
新しいテクニックや習慣を学びたいと思っているプログラマたちがいるかと思えば、そうしたことを学ぼうという気持ちが全くないプログラマたちもいます。長年に渡るコーディングによって染み込んでしまった悪習慣に対処する方法を突き止めるのはなかなか難しいものです。コードをプロシージャ化したりサービス・プログラム化したりせずに、そのコードをプログラムから別のプログラムにコピー&ペーストしているプログラマをよく見かけます。またその反対に、サービス・プログラムやプロシージャを多用しすぎてコントロールが利かなくなり、プログラマがほとんど管理不可能となってしまったドキュメントのない蜘蛛の巣状の使用中のサービス・プログラムを作ってしまったのも見かけます。新しいプログラマたちに正しい訓練と研修を実施すればこうした悪夢を避けることができます。
仕事に取り掛かる
新しいプログラマに期待することを一通り説明し、コーディング標準やドキュメント標準についてプログラマたちがきちんと理解できれば、次の段階はいくつかプログラムを作成させてみて、IT部門のコードの中での環境がどのようなものか感じてもらうことです。これにはいくつかの方法があります。「実践で学ぶ」方法と(プログラマの面倒をしばらく見てもよいという人がいれば)メンターをつける方法です。
実践で学ぶ方法は、新しいプログラマに小さなプロジェクトを与えることです。おそらくレポートか対話型のクエリのプログラムを作ってもらうのが良いでしょう。プロジェクトを通じて今まで学んだスキルを適用させるのです。そうすることで、作業を進めるうちに生じてくる質問に答えてあげてください。メンターを活用する方法は私がプログラミングを始めたときに私のマネージャが採用した方法です。私は同じIT部門の他のプログラマ3人とそれぞれ一週間過ごしました。この3人がそれぞれ異なった方法でコーディングの方法を教えてくれました。「新卒者」として私は異なるプログラミング・スタイルを目にし、部門がどのように運営されているのかについても詳しく学ぶことができました。新しいプログラマに教えるためのこうしたスタイルは、プログラマたちの視野を広げ、一つのタスクを完成させる方法はプログラマの数だけあるのだということを示すことができるので、とても有用です。
部門に入ってきた経験のあるプログラマは部門の標準に慣れるのに時間がかかるかもしれません。これに対処するにはいくつかの方法があります。経験のあるプログラマはRPGを知っている可能性が高く、またプログラミング保守の需要は常にあるので、いくつかのプログラムの保守をさせるところから経験を積ませると良いでしょう。こうすることで部門の標準についての一般的な感覚を掴んでもらうことができますし、そしておそらく詳細なドキュメントの助けを借りてこうした標準をプログラムの保守に適用できるでしょう。
プログラミングの学習には視覚的、触覚的(運動感覚的とも言います)、そして聴覚的の3つのスタイルがあります。新しいプログラマと一緒に座ってどうするのかを示しながら画面上に表示されていることの理論について話すことで、視覚的あるいは聴覚的な刺激を与えて学習しているプログラマの心を惹きつけることができます。実践で学ぶ方法は触覚的な入力で学ぶ人に一番適した方法です。視覚的、聴覚的、あるいは運動感覚的のどれで学ぶのが良いかは本人に聞けばわかることがほとんどです。ただしごく一部の人はそれを自分からは言えないかもしれませんので、それぞれの方法を少しずつ試すことでそのプログラマを効率的に教えることができます。
最終的には、新しいプログラマはまったく新しいプログラムを書く機会を得ることになります。ここで今まで実施してきた全ての研修やドキュメントが威力を発揮します。研修講師が十分な教育をしていれば、そしてドキュメントが明快で簡潔なものであれば、新しいプログラマはコードをどのように書かなければならないか、どのような流れにならなければならないかをよく理解できているはずです。これで、コードが正しく機能するようにするために重要なあらゆる側面にプログラマが集中できるのです。
プログラマにはあらゆるタイプの人間がいて、あらゆるタイプの興味を持っています。したがって、プログラムをゼロから書くのも本当に楽しいことではあるのですが、既存のコードを保守することにまったく満足する人もいるのです。新しく来たプログラマがいまだに言語を学習しているのであれば、シニアのプログラマに見てもらってコードが正しく機能しているか、ごちゃごちゃの偽ロジックや当て推量でコンパイルもできないものになっていないかを確認してもらってください。
古いコードの保守と新しいコードの作成を交代でやってみて、古い標準と新しい標準の両方を実践していることを確認するのが一番良いと思います。このような方法により若いプログラマに無理強いすることなく古いコードを保守させることができます。それでも若い人たちは新しいものに腕試しを挑むからです。現状維持で満足している年配のプログラマに対しては、/freeと最新の部門標準で一度ゼロからプログラムを書いてもらえば切れ味を保ってもらうことができるでしょう。(もちろん熟練したプログラマで、IBMが提供する新しいツールを使って新しいプログラムを書くのが大好きなプログラマたちをたくさん目にもしてきました。
次の宝石を見つける
プログラマに部門の標準を教えることや新しくてより効率的なオプコードを教えることではなく、そもそもプログラマを見つけることが最大の課題であることがよくあります。コンピュータ科学の学位を取得した若い新卒者はRPGでプログラムを書いた機会がなかったかもしれませんし、経験のあるプロのプログラマは大学で少しかじったけれどそれ以後は全く使わなかったという人もいます。RPGを最初から学びたいと思っている人を見つけるのはかなり困難です。正式な研修コースがないこと、人口統計的そして地域経済的な要素もプログラマの相対的な不足に関係しています。こうした課題一つ一つについて記事が書けるほどです。
私は皆さんが新しいスキルを学んでそれを適用している現場を見るのが好きです。くる日もくる日も仲間と仕事をし、コードが何をするものなのか、どのように動作するのかを理解しているか確認し、最後には彼らが書いたプログラムを起動する瞬間を見ることほどの楽しみはありません。レポートが生成され、画面のプロンプトが入力を求め、ファイルに正しいデータが詰まっているのを見たときの彼らの表情は明るいものです。「新人」を研修し始める際の方法についていくつかの考え方と、新人たちをゆっくりではあるけれど確実に荒削りの石から輝くような素晴らしいカットの10カラット・プログラマに変えていく方法をご紹介できたのではないかと思っています。
