2016年振り返りと2017年目標と予測

久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。

2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。

さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。

人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。

2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）

とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）

自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？

IT開発におけるパフォーマンス問題について

最近また業務システムの設計をするようになった。
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか？それとも自分の考え方が間違っているのだろうか？確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか？

自動運転の自動車がする判断について

近年の技術の発展はめざましく、自動車の自動運転技術が競って開発されて実用化間近で、本当の路上での実証実験や運転者のアシスト機能として自動車にその機能が搭載されたりしている。最近、自動車の自動運転での死亡事故（テスラ）が海外であり、ちょっと思うところがあるので書いてみる。

自分も昔、自動車を運転していたためわかるのだが、自動車を運転していると色々な場面で色々な判断、選択をせまられることがある。前に割と早い速度でカーブを曲がるときに、急な土砂降りでできた水たまりの上に乗って制御不能になりそうな場面があったりした。

上の例は、単に自分のドライブテクニックの問題かもしれないが、自動車運転においてどうしようもない場面（急な飛び出しとか）は起こりうると思う。どうしようもない場面でそのときにとる行動は、人間の場合それぞれだ。

子供が急に飛び出してきた。そのときに取りうる選択肢の例としては、

1. そのままブレーキは最大限かけるだろうが、まっすぐ進む
2. 自分を犠牲にして横の壁に向かって激突しに行く
3. 逆方向にハンドルを切る（ただしそっち側には老人がいる）

人間で自分のようにドライブテクニックもない場合は、だいたい1.しかできないのではないかと思う。テクニックのある人は2.を選択するかもしれない。さらにテクニックのある人は、1.2.3.のうち最大限人命を損なわない可能性にかけるかもしれない。（1.の場合は前方不注意になるんだろうなあ）

自動運転にすると、人身事故はすごく減るんでないかという話をきいた。スピードは必要以上に出さないし、パニックにならないし、蓄積された膨大なデータから最善の運転方法をとるだろうし。（ここで思いついたのが、自動運転ばかりだと、自動運転プログラムは自然と連携して動けるが、人間の運転者が一人でもいるとそれがノイズとなって、事故の確率が上がるというジレンマが。。）

しかし自動運転でもどうしようもないケースはあるだろうし、その場合上記も1.2.3.のどの選択肢をどのようにとるか、どうゆう風にプログラムされているのかは気になった。

確率で一番安全策をとるのだろうか？完全に同確率の場合、命の選択をせまられるが、命の重み付けをしたりしているのだろうか？老人は轢いてもよしとか。。道交法上は、運転者の命が一番軽い設定のような気がするが、そういうプログラムになっているのだろうか？

仮に誰が亡くなったとしてもその責任は運転者に帰すのだろうか？（テスラの事例は、自損で運転者の死亡だった）プログラムの判断ミスに対する責任は問われないだろうか？とすると自分でハンドルを握りたいなあと思った。

まあ飛行機はすでに離陸はほぼ全自動らしいけど。着陸は難易度が高くてまだプログラムには任せられないらしい。

--追記--

テスラモータースの事故は、横切っていたトレーラーに直進して追突ということののようだ。しかも制限速度違反で。自動追突防止装置は付いていたらしいのだが、まず制限速度も認識できない自動運転て怖いとおもった。

コマンドラインとGUIの狭間

当たり前なのかもしれないが、熟練者にとってはコマンドラインの方が圧倒的に早い。
最近は、ツールの入力補完も充実しているのでタイプミスも少ない。

しかし自分のような初学者だったり、手っ取り早くポチポチOKボタンを連打して環境を作り上げたい場合にはGUIがあればなあと思うことも多い。

自分は元々コンピューターの世界に入ったのはNECの汎用機からだったし、その後オフコンを使っていたりしたので、コマンドをタイプすることに大きな抵抗はない。

コマンド書いてバッチ処理は、いろいろメリットがあることもわかっている。しかし若い時はコマンドを（プログラミング言語も）覚えることは苦ではなかったが、もうおじさんになってきたので、コマンドの意味を覚えるのも一苦労。コマンドを意味を覚えるに当たって、マニュアルをにらみながらポチポチ打っていく根気が無くなってきたと思う。

一方GUIは、Windows3.1が最初に触ったGUIとなる。しかも昔でいう4GL開発（ボタンとかウィンドウをペタペタ画面上にはって、それぞれの部品（オブジェクト）に対してコードを書いていく。ちょっとしたカルチャーショックだった。

プログラムを書いていくのは仕方がないが、環境構築についてはもうちょっと楽にならないかなあと思う。思うような環境を作るためには、コマンドを何回も叩き、インストールを繰り返し、うまくいけばいいがトラブルが発生すると何が悪かったんだろうと、原因究明にすごく時間がかかったりする。ソフトゥエア間の依存関係が複雑になってきているからかなと思う。

またそれぞれのソフトゥエアのお作法というものがあり、それを覚えるのが大変だったりする。昔のようにCOBOL、JCL以上！という世界にちょっとだけ、戻りたい気もする。オールインワンでポチポチインストールすれば以上終わり、という商用製品に目がいったりする。当然今の方が断然自由度が高いが。今ではCOBOLでWEBアプリとか作れるのかな？明らかに向いてない気もするが。。

環境構築がうまくいかないのでちょっと愚痴ってみた。乗り越えなければならないハードルだけれども。

古いITシステムを捨てるということ

あるITシステムがある。
もう30年前にできたシステムだ。それを置き換えようと大きなプロジェクトが立ち上がる。大抵は失敗してしまう。失敗とは当初想定していた予算、期間をオーバーすることだ。

しかし機能が削られることは滅多にない。（品質が悪いことは、また別の話）

一戸建てに例えて考えてみる。

何十年か前、一戸建てを買ったとする。その後車庫に屋根をつけたり、壁を塗り替えたり、物置をつけたり、家庭菜園のための小さな畑を作ったり、時間をかけて住みやすいようにしてきた。

その後、家も古くなり買い換えることにした。次の家は最初から車庫に屋根は欲しいし、物置は大きいものが付いていて欲しいし、（あるのか知らないが）畑つきのより広い庭が欲しい。

一戸建てだと、お金を出すのは個人なのでお財布に合わせて我慢をするしかないことがある。しかしITシステムは、何十年かの間に積み重なった機能を捨てることができない。システム刷新をする場合にほんの小さな機能をあきらめることもできない。時代も変わり変化した業界についていくためには、その業界にあった、何十年か前とは違ったコンセプトでシステムの根幹を考え直さなければいけない。そのためには従来の機能の大部分を捨てるしかない。

「それでは困る」という人がいる。あの機能も、この機能もこういう理由で必要だ。いや困るなら人間が合わせればいいのだと思う。人間は超柔軟なシステムである。今までのやり方を変えればいいだけだと思う。あるいは我慢すればいいのだと思う。

ここまで書いてみて思ったのが。あれがないと困るという意見は、常に企業の局所的な部門、部署から発信されている。全体をみて判断をする見識、力をもつ情報システム部門（とCIO）は日本はほとんどないのではと思う。

よって「情報システムは企業にとっての力の源である」という考えを持たない限り、日本は企業内の情報化において常に遅れを取るんだろうなと考えた。

仕事を辞めました！その2

今回は、仕事を辞めた理由を書きたいと思います。

自分は、大規模プロジェクト（予算X億円以上）に関わることが多かったのですが、もしかしたら中小規模にも当てはまるかもしれません。多くのプロジェクトで以下のことを経験しました。（繰り返しになりますが、み◯ほには関わっていません笑）

1. お客様の社内の偉い人の政治的な力関係で物事が決まってしまう。（自分ではどうにもできない領域。特に雇われPMOとしては助言できる立場にない）
2. お客様のITリテラシーがあまりにも低い（情報システム部門なのに）
3. プロジェクト推進チームとしての一体感がなく、あくまで顧客とベンダーという立場（よって、やはり助言はあまり聞いてもらえない、お客の言う通り動け！）
4. 最初に書きましたが、政治的（というと大げさかもしれないですが）な力関係が、チーム内の担当者レベルにまで影響する。（上司の意向に沿うように動く人もいれば、反発して動く人もいる。いずれにしてもプロジェクトとして最適な行動とは別の論理でプロジェクトを推進する）
5. ベンダー側も責任回避の為（訴訟もありましたよね。ベンダー側が敗訴していましたが）、極力、意思決定をお客様に投げる（現在の状況を握りつぶすこともまあまあある。）よってプロジェクトとしての最適な判断ができないケースが多い（1〜4の理由により）
6. 実は、人月で仕事をもらっている限り、トラブルが発生すればするほど、ベンダーは儲かる（担当は疲弊しますが）
7. プロジェクトの進め方が少なくとも15年前から変わっていない。（自分が億円単位のプロジェクトに関わるようになったのが2000年ぐらいからなので、もしかするとそれ以前からかも）アジャイルが絶対いいとは言いませんが、WFでこの15年同じ失敗を繰り返しているのはどうなの？（一部CIとかは導入されつつありますが）※自分はアジャイル絶対主義には懐疑的です。
8. EXCEL絶対主義は、もういやだ。。（一部は、BTSとか導入されつつはありますが）

愚痴を垂れ流すときりがないですが、この辺で。上記のようなフラストレーションにより、上記のない世界へ旅立ちたいと考え、

1. 具体的なプロダクト（サービス）を提供する側になりたい。
2. プロダクトを構想する力を身に付けたい。
3. プロダクトを実現する力を身に付けたい。

ので従来の仕事の片手間で勉強していては、世の中の進歩についていけない。退路を絶って真剣に取り組みたいとプータローになった次第です。

※壮大なことを書きましたが、お試しでエロサイト作りたいんですよねぇ。

仕事を辞めました！その1

よく世間でブログネタになっている「転職しました」ではなく、しばらく仕事をしないことに決めました。ニートになります。

プロフィールを少々。1968年生まれ。

24の時に上京してきて、最初の会社はITとはあまり関係のない会社でした。

いわゆる総合職（人事部だった）だったのですが、そこで「これからはコンピューターの時代だから勉強してこい」と言われ社内情報システムに配属されたのが運の尽き。コンピューターに魅せられて、転職、転職、なぜかコンサルティングファームにヘッドハンティングされたり、そのときの上司に引っ張られ、また転職したり、上司とケンカをして独立したり。。。

30過ぎまでは、プログラミング（COBOLer。。Java）や設計（DB設計得意です！多分いまでも！）を中心にやっていました。

27の時に初めてPMとして小さなプロジェクトを任され、大赤字を出したことも今ではいい思い出です。コンサルタント時代は、お客様のIT戦略の立案、アーキテクチャ検討などを行っていました。また大規模プロジェクトのPMOとして参画することも多くなってきました。

そして、2008年に独立してからは、雇われPM、PMOとしての仕事が中心になってきました。

で、2016年6月よりロングバケーションに入ることにしました。

プロジェクトを抜けた理由は、プライベートな理由が主たる理由なのですが、しばらく仕事をしないと決めた理由は、

現在の大手企業さんにおける大規模プロジェクトの現状（あ、み◯ほには関わっていません笑）、PMOというお仕事（見てるだけ〜手を出してはならぬ）に嫌気がさして、「あ、こんなことしてていいんだっけ？」とちょっとカッコよく言えば自分を見直したいと思ったからです。

で、このブログをはじめた動機は、いい機会なのでこれまで自分が経験したこと、本当はこうすればよかったと振り返ったことを記録に残したいと考えたからです。

次回からは、その振り返りを中心に、これから勉強していきたい新しい技術を書いていきたいと思います。