node.js練習用開発環境を作成した

目的：できるだけ早く、お試しで単純なwebサービスを作ること。（内容はまだ秘密）

手段：開発言語は、node.js+express+HTML+javascriptでやりたい。

方針：なるべく手間をかけずに早くサービスを立ち上げる。

環境作成

1. クラウドを使いそこにWebサービスを置く
2. 開発は、ローカルでやるが仮想環境上に構築したい
3. プログラムは、クラウドにファイル転送（SFTP）する。（ゆくゆくはrktとか使うか）

手順

1. MacにVirtualBox（仮想化ソフト）をインストール。（手順は省略。）
2. VirtualBoxにXubuntu（ubuntuの派生ディストリビューション。ISOが1G超えてる。。もうCDROMには収まらないのか。）をインストール。（手順は省略。理由は慣れているから。）
3. Xubuntuにnode.jsをインストール（練習なので最新版でなくお手軽インストールを重視）
1. sudo apt-get install nodejs
2. sudo apt-get install npm 
3. sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
4. node -v　（v4.2.6　20160809現在。練習なので最新でなくて良い）
5. sudo npm install express
4. XubuntuにVisual Studio Codeをインストール（新進気鋭のMicrosoft製エディタでコード補完機能も充実してそうだから）
5. 続いてクラウドの設定、Vultrを選択（お手軽、東京リージョンがあるから。こちらからサインインしてもらえると。とてもとてもありがたいです。）
6. クラウドにubuntu serverをインストール（慣れているから、インスタンスの維持は最低価格で月5ドル。インスタンスを破棄すれば課金されません。）
7. rootしかないので、useradd -m hogehoge
8. 上記の3.の手順でnode.jsをインストール
9. XubuntuからSSHでクラウドに接続。

一応一通り環境ができたので、練習開始。

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

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

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

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

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

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

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

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

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

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

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

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

--追記--

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

node.jsで’Hello World’してみた

初めてnode.jsを触ってみた。参考書に従ってインストールをしてHello worldしてみた。
node.jsの特徴は、

1. サーバーサイドで動くJavaScript
2. 非同期処理（I/Oの結果を待たずに並列で処理を行う）
3. シングルスレッド（マルチスレッドよりメモリ消費が少ない）
4. イベントドリブン（リクエストがあったときだけ処理を行う）
• ちょっとよくわからない常時起動してないってこと？
• あとで掘り下げて勉強する

それにより得られるメリットは、

1. 大量のリクエストをさばくことが可能
2. リアルタイム処理に向いている（イベントドリブンのため）
1. なんで？

node.jsのプログラムサンプル

"

//Webサーバーの定義

var http = require('http');

var server = http.createServer();

server.on('request',doRequest);

server.listen(1234);

console.log('Server running!');

//リクエスト処理

function doRequest(req,res){

 res.writeHead(200,{'Contnt-Type':'test/plain'});

 res.write('Hello World\n');

 res.end();

}

"

簡単すぎる。。上の10行でブラウザでhttp://localahot:1234/ でHello World!が表示される。

ITプロジェクトにおけるプロジェクトビジョンとビジネス要求について（過去のプロジェクト振り返りその5）

第２章のソフトウェアサバイバルテストにおいては、具体的な設問に答えていき、採点をしてプロジェクトの成熟度を図るようになっている。自分の経験したプロジェクトを採点するのは、「その12」ぐらいを予定している。

ここではテストの設問を引用しながら、内容について述べていきたい。

”
要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。
”
これまで述べた通り、この設問に「はい」と答えられるプロジェクトは少ない。単にシステムが古くなり関連ソフトウェア、ハードウェアのサポート切れという場合も多いのではないかと思う。

"
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか？
"

１番目の設問とも関連するが、この質問に明確に「はい」と答えられる人も少ないはずだ。明確に決まってないからだ。「いいえ」または「しらない」という答えが多いのではないかと思う。
また日本人の特性かもしれないが、表向きは「はい」答える人も多いのではと思う。かっこいい錦の御旗に逆らえる人はそうはいないからだ。大本営に逆らえる人はそうはいない。実現可能なビジョンを考えるという点が、できているプロジェクトにはなかなか出会えない。外国のプロジェクトではどうなんだろうか？実現可能なビジョンがとてつもなく難しいように思える。

"
3.事業における便益を詳細に示し、メリットの測定方法を明らかにするビジネスケースを策定しているか。
"

これもこれまで述べてきた通り設定できているケースは少ない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大規模プロジェクトにおけるPMというお仕事

ここではSIer側のPMOの仕事を語りたいと思います。
自分自身の経験では、大規模といってもせいぜい10億円ぐらいの規模のPMしかやったことはなくて、その時は導入するHWやSWが馬鹿高くて、プロジェクトメンバーはMAX20名といった具合の中規模プロジェクトでした（ORACLEがすんごく高かった気がする）

ですので、自分の経験としては語ることはできないのですが、予算規模数百億のプロジェククトにPMOとして参画したことは何度かあります。なので端から見ていた感想として述べるのですが。

小〜中規模プロジェクトだとPMはなんでもやらなければなりません。
（上記のPMの時は最初期のプロジェクトのコンセプトデザインの時から関わって、導入プロダクトを決めて、カスタマイズを行い、運用を決め、デリバリするというまさに上流から最下流までやらせてもらえた幸せなプロジェクトでした。それなりにしんどかったけど。）管理、設計、はてはプログラミングまで、をやることになります。

しかし大規模プロジェクトのPMとなると、全然別次元の世界で管理、管理、管理、報告、報告　&　報告といった仕事が中心になります。（そんななかでもプロジェクトの中に入り込んでいくPMもいるとは思いますが超大変と思います。）

管理と一口にいっても実際どんなタスクがどれぐらい進んでいるかさえ、超ざっくりとしか掴めなくて（細かく掴む暇がない。下からの報告が正しいのか検証する暇さえない。）
主としてお金の出入りの管理になります。（予算がどれぐらいあって、今どれぐらい使ってるのか。）また報告もそれだけ大きなプロジェクトになると大手SIerしか受けることができません。大きな企業となるとその内部も超複雑な官僚機構が存在していて、そこへの報告作業がとてつもなく大変になってきます。これは本当に膨大な資料作成を要求されます。資料作成の過程で、バックデータとして進捗資料とか細かいデータも入手するのですが、実際のプロジェクト運営のための進捗把握とは乖離していて、資料作成のためのデータという何をやっているんだかという作業になります。でもそれだけの資料を官僚機構は要求しておきながら何かを判断するわけではない。（プロジェクトの状態が悪くなった時の訴訟対策だったりするのでしょうが。。）
お客様むけには逆にざっくり資料で済んでしまうことが多い気もしますが。（金融とかだとちょっと違うのかな？）



書いていて昔のプロジェクトでリーダーをやっていたのにリーダー本業はそっちのけで、PMのため、本社官僚機構のための、「これからこれだけプロジェクト全体が悪くなっていくから、これだけ追加の費用が必要！」という資料を一生懸命作ったことを思い出しました。本来の仕事は、担当チームのプロジェクト実行のはずだったのに。。

また報告作業ともかぶりますが、調整作業も大変です。お客様からのクレーム対応、社内官僚機構からの突き上げ（もっと利益を！）、現場からの悲鳴（悲鳴の原因をキャッチアップする暇もないのに）

それだけ大変な担務であるにもかかわらず、サラリーマンである限りすごい報酬をもらえるわけでもない。（失敗してもペナルティもないけど）

端から見ていて思うのは、純粋なITプロジェクトとしての楽しみは少なく、大企業の中間管理職であることは変わらず。権限も少なく。個人的にはやりたくないなあというお仕事の一つです。