若者の希望を摘み取ってはいけない①
2017年10月26日 お仕事日 本 生 涯 現 役 推 進 協 議 会 ＆
NPO法人 ラ イ フ ・ ベ ン チ ャ ー ・ ク ラ ブ 活 動 で
ご 支 援 く だ さ る 会 員 皆 様
IT proご参考URL＝http://itpro.nikkeibp.co.jp/atcl/column/15/112000266/101200019/?rt=nocnt
どんづまりから見上げた空 ～ 我がITサバイバル年代
「私はコボラー」、 若 者 の 希 望 を 摘 み 取 っ て は い け な い ①
新卒社員にCOBOLを習得させて現場に投入していいのか
日本で稼働していたシステムの中で一番使われてきたプログラミング言語は「COBOL」であろう。今でも汎用機では現役のプログラミング言語である。ただ、最新の言語でないことは確かだ。
私の派遣SE・プログラマ時代は汎用機が主流であり、プログラミング言語として当たり前のようにCOBOLが使われていた。仕事としてもCOBOLの需要が多かったので、私も「コボラー」として現場に投入された。これに関して別に不満はなかった。
ただ、今は時代が違う。様々なアーキテクチャー、プログラミング言語、開発手法があり、ITの世界はすさまじいまでの広がりを見せている。そんな時代なのに、希望に満ちて新卒で入社した社員にCOBOLを習得させ、売り上げを確保できるという理由だけで、汎用機がまだ動いている現場に投入している会社があるという。
断っておくがCOBOLが悪いと言っているわけではない。私自身COBOLは大好きな言語だし、過去に習得したことは自分にとって間違いなくプラスになったと思っている。もちろんCOBOLを習得することはマイナスではない。ただ、これからITの世界で活躍する人材が習得すべきスキルは他にいくらでもあるのではないか、と思ってしまうのだ。
COBOLを使う現場で金融系の業務知識を得て、次に生かすといった将来のキャリアプランが描かれているのであれば問題はない。先のことを考えず、目先の売り上げ欲しさに若手をCOBOLの世界に放り込んでいるならば問題である。目先の金欲しさに若者の希望を摘み取ることなりかねない。先につながらない仕事をしなくてはならないのは、とても苦しいことだ。
レガシーは日本のITを支えてきたベテランが担う
もし読者が、そんなビジョンが見えない会社でCOBOLを嫌々やらされているなら、今すぐ辞めたほうがいい。そのまま続けても未来はたぶんその先にはない。今、IT業界には限りない可能性があるし、もしIT自体に嫌気がさしたのならばIT業界から足を洗うという選択肢もある。いいかげんなことはいえないが、未経験の分野に飛び込んでみるのもいいかもしれない。少なくとも、先が見えない暗闇でもがき続けるより余程良い。
こんなことを書くと、「日本には汎用機のシステムがたくさん稼働しており、COBOLで書かれたアプリケーションが動いている。そこにビジネスチャンスを見いだして何が悪い」というお叱りを受けそうだ。その指摘は間違ってはいない。レガシーシステムだろうと、保守しなければシステムを稼働させ続けることはできない。そのための人員は企業組織にとっても、社会にとっても必要だ。
ただ、それが若者でなくてもよいのではないか、と思うのだ。どうしても人手が足りないのであれば、リタイアした元COBOL技術者を再雇用すればいい。リタイアした人間を雇用することは最近の「生涯現役」時代の風潮にも合っている。一部にはそういった流れになりつつあるとは聞くが、まだまだだ。
最新技術に近い分野は若い者が担い、レガシーは今まで日本のITを支えてきたベテランが担う。そんな仕組みが出来上がれば、もっともっと日本のIT業界が活性化するような気がしている。
最悪のサイクルで業界が回っている
少し意地悪な書き方かもしれないが、日本の情報システム（特に業務システム）を巡る状況をこう考えている。
（1）品質が悪いがとりあえずユーザーに検品OKもらう。
（2）SIerは保守契約を結ぶ。出来が悪いシステムは手がかかる（＝もうかる）。
（3）ユーザー企業は保守費用の負担が重く、新規開発に予算を回せない。
（4）新規案件が減る。
（5）若手に新規開発を経験させる機会が減少する。
（6）ITエンジニアの技術力が低下する。
（7）日本のIT業界は弱体化する。
最近は「攻めのIT投資」の重要性が叫ばれ、ユーザー企業もコンシューマー向けシステムを中心に投資を行うようになったらしく、状況は変わりつつあるようだが、根本は変わっていない。
最悪のサイクルで業界全体が回っているように見受けられる。こんな現状について、ベンダーとユーザーの立場の違いについて書いておこう。
ベンダーは本番のプロジェクトで技術者を育てるしかない。失敗から学ぶことも多々ある。コスト面では許されない場合もあるが、それはそれで仕方ないのかもしれない。経験しなければ体得できないこともある。
ただし、「失敗」をユーザーから見ると、景色が一変する。ベンダーの技術者の中には失敗したことを武勇伝のごとく自慢げに話す人がいるが、IT以外のビジネスの現場において、失敗をひけらかす人はいない。IT業界の七不思議の一つといってもいい。
私はベンダーからユーザー企業に転身し、強く感じていることがある。ユーザー企業にとっては、失敗は許されないのだ。ベンダーの技術者が武勇伝として吹聴している「失敗」システムが基幹系だとしたら、そのシステムのユーザーは「失敗」システムを受け取った後、10年ほどはその失敗を引きずらなくてはならない。
失敗したシステムを稼働させ続けた結果、利用者であるエンドユーザーがコンピュータ（システム）に不信感を持ってしまえばおしまいだ。ユーザー企業は新しいシステム投資に積極的になるはずがない。
無駄なドキュメントが多過ぎる
もう一つ、ユーザー企業に移って時間がたった頃、改めて気になったことがあった。システムのドキュメントである。システム開発には「無駄」なドキュメントが多過ぎる。
ユーザー企業に移って、初めて納品受領という「儀式」に参加したときのことを今でも覚えている。ベンダーとユーザーの担当者が机を挟んで座っていた。机には分厚いファイルが何冊も並べられ、それらは「捧げもの」のように見えた。しかし、捧げもののように見えたファイルの大群は、すぐに陳腐化して無用の長物になった。
さらに言えば、ユーザーに納品しないドキュメントも山のように作っている。システム開発プロジェクトにおいては、余計なドキュメント、内容が重複しているドキュメントが多過ぎるように感じる。無駄なドキュメントは作らないほうがよい。何の役にも立たない。
例えば、打ち合わせで使用するエンドユーザーを説明するためのドキュメントと、オーナーへのプレゼンテーション用のドキュメントを別々に作ることは、どう考えても無駄だ。相手が違うので体裁を整えるのは必要不可欠であるとしても、別々に作る意味はない。また、最終系が納品物になるならば作成する意味はあるが、打ち合わせ用のみにしか使えないドキュメントは無駄ではないか。
システムをどのように作るかを具体的に考える工程（下流工程）において、開発者（主にプログラマ）に“思い”を伝えなければならないとき、何を作るかを明確にする工程（上流工程）で作成したドキュメントとまったく別モノをわざわざ作るのはばかげている。もちろん、工程において必要とされるドキュメントは違うが、前工程の「魂」を継承せずに、少し切り口を変えただけのようなドキュメントは無駄である。
ドキュメント作成自体が目的になっているようにすら感じる。無駄を省いてその分のリソースを他のことに回すべきだ。
さらに納品の際、すでに整合性が失われたプログラムとドキュメントの辻褄を合わせるために、プログラムに基づいてドキュメントを書くのもやめたほうがいい。
私が派遣SE・プログラマ時代に作成したドキュメントは詳細設計書が多かった。これは「必要なドキュメントだ」と感じていたが、たまに何のために必要なのか分からないまま、ただ作成を余儀なくされたドキュメントがあった。それについて何らかのレビューを受けた覚えはあるが、何かの役に立ったかと言われれば疑問符がつく。私が苦労して作成したドキュメントのほとんどはすぐにゴミ箱行きになっていたのだろうか。むなしい話だ。 つづく
NPO法人 ラ イ フ ・ ベ ン チ ャ ー ・ ク ラ ブ 活 動 で
ご 支 援 く だ さ る 会 員 皆 様
IT proご参考URL＝http://itpro.nikkeibp.co.jp/atcl/column/15/112000266/101200019/?rt=nocnt
どんづまりから見上げた空 ～ 我がITサバイバル年代
「私はコボラー」、 若 者 の 希 望 を 摘 み 取 っ て は い け な い ①
新卒社員にCOBOLを習得させて現場に投入していいのか
日本で稼働していたシステムの中で一番使われてきたプログラミング言語は「COBOL」であろう。今でも汎用機では現役のプログラミング言語である。ただ、最新の言語でないことは確かだ。
私の派遣SE・プログラマ時代は汎用機が主流であり、プログラミング言語として当たり前のようにCOBOLが使われていた。仕事としてもCOBOLの需要が多かったので、私も「コボラー」として現場に投入された。これに関して別に不満はなかった。
ただ、今は時代が違う。様々なアーキテクチャー、プログラミング言語、開発手法があり、ITの世界はすさまじいまでの広がりを見せている。そんな時代なのに、希望に満ちて新卒で入社した社員にCOBOLを習得させ、売り上げを確保できるという理由だけで、汎用機がまだ動いている現場に投入している会社があるという。
断っておくがCOBOLが悪いと言っているわけではない。私自身COBOLは大好きな言語だし、過去に習得したことは自分にとって間違いなくプラスになったと思っている。もちろんCOBOLを習得することはマイナスではない。ただ、これからITの世界で活躍する人材が習得すべきスキルは他にいくらでもあるのではないか、と思ってしまうのだ。
COBOLを使う現場で金融系の業務知識を得て、次に生かすといった将来のキャリアプランが描かれているのであれば問題はない。先のことを考えず、目先の売り上げ欲しさに若手をCOBOLの世界に放り込んでいるならば問題である。目先の金欲しさに若者の希望を摘み取ることなりかねない。先につながらない仕事をしなくてはならないのは、とても苦しいことだ。
レガシーは日本のITを支えてきたベテランが担う
もし読者が、そんなビジョンが見えない会社でCOBOLを嫌々やらされているなら、今すぐ辞めたほうがいい。そのまま続けても未来はたぶんその先にはない。今、IT業界には限りない可能性があるし、もしIT自体に嫌気がさしたのならばIT業界から足を洗うという選択肢もある。いいかげんなことはいえないが、未経験の分野に飛び込んでみるのもいいかもしれない。少なくとも、先が見えない暗闇でもがき続けるより余程良い。
こんなことを書くと、「日本には汎用機のシステムがたくさん稼働しており、COBOLで書かれたアプリケーションが動いている。そこにビジネスチャンスを見いだして何が悪い」というお叱りを受けそうだ。その指摘は間違ってはいない。レガシーシステムだろうと、保守しなければシステムを稼働させ続けることはできない。そのための人員は企業組織にとっても、社会にとっても必要だ。
ただ、それが若者でなくてもよいのではないか、と思うのだ。どうしても人手が足りないのであれば、リタイアした元COBOL技術者を再雇用すればいい。リタイアした人間を雇用することは最近の「生涯現役」時代の風潮にも合っている。一部にはそういった流れになりつつあるとは聞くが、まだまだだ。
最新技術に近い分野は若い者が担い、レガシーは今まで日本のITを支えてきたベテランが担う。そんな仕組みが出来上がれば、もっともっと日本のIT業界が活性化するような気がしている。
最悪のサイクルで業界が回っている
少し意地悪な書き方かもしれないが、日本の情報システム（特に業務システム）を巡る状況をこう考えている。
（1）品質が悪いがとりあえずユーザーに検品OKもらう。
（2）SIerは保守契約を結ぶ。出来が悪いシステムは手がかかる（＝もうかる）。
（3）ユーザー企業は保守費用の負担が重く、新規開発に予算を回せない。
（4）新規案件が減る。
（5）若手に新規開発を経験させる機会が減少する。
（6）ITエンジニアの技術力が低下する。
（7）日本のIT業界は弱体化する。
最近は「攻めのIT投資」の重要性が叫ばれ、ユーザー企業もコンシューマー向けシステムを中心に投資を行うようになったらしく、状況は変わりつつあるようだが、根本は変わっていない。
最悪のサイクルで業界全体が回っているように見受けられる。こんな現状について、ベンダーとユーザーの立場の違いについて書いておこう。
ベンダーは本番のプロジェクトで技術者を育てるしかない。失敗から学ぶことも多々ある。コスト面では許されない場合もあるが、それはそれで仕方ないのかもしれない。経験しなければ体得できないこともある。
ただし、「失敗」をユーザーから見ると、景色が一変する。ベンダーの技術者の中には失敗したことを武勇伝のごとく自慢げに話す人がいるが、IT以外のビジネスの現場において、失敗をひけらかす人はいない。IT業界の七不思議の一つといってもいい。
私はベンダーからユーザー企業に転身し、強く感じていることがある。ユーザー企業にとっては、失敗は許されないのだ。ベンダーの技術者が武勇伝として吹聴している「失敗」システムが基幹系だとしたら、そのシステムのユーザーは「失敗」システムを受け取った後、10年ほどはその失敗を引きずらなくてはならない。
失敗したシステムを稼働させ続けた結果、利用者であるエンドユーザーがコンピュータ（システム）に不信感を持ってしまえばおしまいだ。ユーザー企業は新しいシステム投資に積極的になるはずがない。
無駄なドキュメントが多過ぎる
もう一つ、ユーザー企業に移って時間がたった頃、改めて気になったことがあった。システムのドキュメントである。システム開発には「無駄」なドキュメントが多過ぎる。
ユーザー企業に移って、初めて納品受領という「儀式」に参加したときのことを今でも覚えている。ベンダーとユーザーの担当者が机を挟んで座っていた。机には分厚いファイルが何冊も並べられ、それらは「捧げもの」のように見えた。しかし、捧げもののように見えたファイルの大群は、すぐに陳腐化して無用の長物になった。
さらに言えば、ユーザーに納品しないドキュメントも山のように作っている。システム開発プロジェクトにおいては、余計なドキュメント、内容が重複しているドキュメントが多過ぎるように感じる。無駄なドキュメントは作らないほうがよい。何の役にも立たない。
例えば、打ち合わせで使用するエンドユーザーを説明するためのドキュメントと、オーナーへのプレゼンテーション用のドキュメントを別々に作ることは、どう考えても無駄だ。相手が違うので体裁を整えるのは必要不可欠であるとしても、別々に作る意味はない。また、最終系が納品物になるならば作成する意味はあるが、打ち合わせ用のみにしか使えないドキュメントは無駄ではないか。
システムをどのように作るかを具体的に考える工程（下流工程）において、開発者（主にプログラマ）に“思い”を伝えなければならないとき、何を作るかを明確にする工程（上流工程）で作成したドキュメントとまったく別モノをわざわざ作るのはばかげている。もちろん、工程において必要とされるドキュメントは違うが、前工程の「魂」を継承せずに、少し切り口を変えただけのようなドキュメントは無駄である。
ドキュメント作成自体が目的になっているようにすら感じる。無駄を省いてその分のリソースを他のことに回すべきだ。
さらに納品の際、すでに整合性が失われたプログラムとドキュメントの辻褄を合わせるために、プログラムに基づいてドキュメントを書くのもやめたほうがいい。
私が派遣SE・プログラマ時代に作成したドキュメントは詳細設計書が多かった。これは「必要なドキュメントだ」と感じていたが、たまに何のために必要なのか分からないまま、ただ作成を余儀なくされたドキュメントがあった。それについて何らかのレビューを受けた覚えはあるが、何かの役に立ったかと言われれば疑問符がつく。私が苦労して作成したドキュメントのほとんどはすぐにゴミ箱行きになっていたのだろうか。むなしい話だ。 つづく
