年金の支払記録システムやその運用方法が問題化したことに対して、ITにかかわる人間として考えました。
これからの情報技術(IT)が考えなければならないことは、10年先、20年先、50年先を考えるような長期的な視野に立った計画や教育、運用ではないかと。
小手先の技術スキルは、一般的なパソコンの使い方、データの入力や検索の仕方、文書や表計算の作成にかかわる操作を覚えれば何とかなります。WindowsになってからはＰＣのオペレーションをする分にはとても使いやすくなりました。
経験上、ある程度普及した技術スキルは10年から20年は使えます。例えば、 しかし、開発やシステム運用の分野についても、UNIX、MS-DOSといったCUIのスキルは今でも使えます。Windowsも同様でしょう。プログラミング言語ではC言語あたりは今でも十分使えますし、使っています。Javaは歴史が浅いですが、きっとこれも相当な年数使えるでしょう。私はWebページの記述言語であるHTML、データ記録形式のCSVやXMLもかなり後世まで使われると予想します。
しかし、中・上級技術スキルを習得するための学習機会はあまり多くはありません。形式的なテキストや講習よりも、自らが工夫し習得する、獲得するといった段階だからでしょう。しかし、このような段階でいろいろなことにチャレンジして、試行錯誤をするという段階の経験を日本の義務教育では知ることができません。芸術やスポーツの世界では支障に弟子入りしたりして高度な技を見る機会があり、考え方も直接伝わっていくように思います。
学問の世界では、高度な専門書で学んだあと、研究室や研究所での活動があります。
学問色の強い情報処理技術に関しては研究も広く行なわれていて、学会などを通じて発表したり、発表を聞いたりする機会が比較的多くあります。しかし、プロジェクトをうまく進めていく方法、意思決定をスムースに進めていく方法、クレーム・トラブル・問題の解決の方法などは学ぶ機会が少ないのが実情です。おそらく原因には、人の経験や感覚に頼っている部分が多く、客観的なデータが集まりにくい。それに同じ方法でも、顧客やプロジェクトのメンバの違いによって、成功と失敗の場合があったりして研究しにくいのでしょう。
プロジェクトの成功と失敗について掘り下げていきます。
後で周りから失敗といわれるプロジェクトであっても、途中で内部のメンバは失敗することに気付いていたり、対処しようとしていることが少なくありません。それでもなぜ失敗してしまうのか・・・そこには人間性、つまり感情による部分が大きいです。例えば、プロジェクト管理のベテランでカリスマ性のあるプロジェクトリーダーに、中堅、若手とそれぞれに相応のスキルや適正があるメンバーから構成される理想的な体制を整えたとします。中堅メンバの一人がある勘違いから仕様ミスしていたことに自ら気付きます。そうしたときにこの後どのような行動を取れば失敗への転落の道ではなく成功の道に戻れるか考えてみてください。
分かれ道：
A、リーダーや上位メンバに自分の勘違いによる仕様ミスがあることを報告する。後の判断を仰ぐ。
B、自分の配下のメンバにのみ自分の勘違いによる仕様ミスがあることを報告する。修正の協力を頼む。
Ｃ、レビューや進捗会議の場で発表する。後の対処は成り行きに任せる。
Ｄ、仕様変更があったとウソをついて、勝手に仕様書を書き換えたり、自分の配下のメンバに修正作業をさせたりする。
Ｅ、自分のミスは自分で取り戻すために、他の仕事を止めてでも自ら修正作業を行なう。
Ｆ、仕様ミスとは言わずに改良ポイントとして内部レビューで修正内容の指示をメンバにする。
Ｇ、仕様ミスが含まれた仕様書だが、内部レビューも済んでいるし、客先にも仕様書は収めてあるので他の人から指摘があるまで気付かないふりを決め込む。
さて、どうでしょう。自分の失敗は上にも下にも言いにくいですよね。できれば隠したいとか、ごまかしたいとか思いますよね。正直に言って、問題として指摘されたり、能力がないと思われたりしたら損だと思うこともあるかもしれません。ここで、誠実な対応を速やかに取っていれば大きな問題にはならないはずです。上に報告して、リーダーが再発防止策を取れれば同種の問題が防げます。
Ａ～Ｇの分かれ道はどれが正解かとコメントでいわれそうなので、先に断っておきますが、どれが正解かとはいえません。他のメンバーや客との相互作用によってプロジェクトの結果は決まります。気付いた本人が言わなくても、他のメンバが気付けば問題は修正されます。本人が正直に言ったとしても問題になることを恐れて修正しなければ問題は残ってしまいます。他人によって修正されるケースはまれなケースですから、楽観視はできません。この仕様ミスが最悪な結果を招く可能性について考えると怖いことはいくつも思いつきます。このミスの修正が他のモジュールや関連システムへ波及して、とても大きな後戻り作業が発生、ミスが修正されずに開発プロジェクトが終了、リリースされて運用中に問題が発覚し、損害が発生なんてこともありえます。
年金保険料の記録問題は、まさに分かれ道のＧ的な発想で気付かないふりをし続けてきたツケがいよいよまわってきたのではないでしょうか？ そして今さらながらＦ的発想で追加の開発を行なう・・・
ここでタイトルの「10年先、20年先、50年先を考えたIT」についてもう一度よく考えます。習得したスキルは10年や20年は使えることは先に述べました。プロジェクトの成功と失敗について言及したのかというと、プロジェクトを取り巻く周囲状況を把握し、適切に行動できるメンバをいかに育てるのかという点、プロジェクトを進める上での心構えと問題が起きたときの対処が重要だという点を言いたかったからです。特定のスキル一辺倒でもとりあえず10年や20年はなんとかなっても、50年は持ちません。状況を分析して適切に判断できる人間になり、後に続く人間を育てることによって、50年先のITの未来を明るくできると信じています。
法人向けパソコン・サーバ・周辺機器
ナビ得 Link
グループサイト：ＮＥＣ特選街情報 NX-Station Blog (ウェブリブログ→Seesaa版)、VersaPro MATEブログ、NEC Express5800 PCサーバ購入