ITプロジェクトにおけるリスクマネジメントと人的資源の充足について（過去のプロジェクト振り返りその8）

今回はリスクマネージメント、および人的資源について述べる。
これでソフトウェアプロジェクトサバイバルガイドの一通りの設問の要点を述べたことになる。

"
リスクマネジメント
25.プロジェクト計画案には、プロジェクトが現在抱えているリスクの一覧を明示した資料が含まれているか、その一覧は最近更新されたか。
"

プロジェクトの初期段階でリスクを見通した一覧が作成されることはまずない。（日本人の特性なのか？）希望に満ち溢れたプロジェクトの初期段階でリスクを列挙し管理していくことは、はばかられるのではないかと考えている。

"
26.プロジェクトの管理責任者がいるか。その責任者は、プロジェクトに発生しているリスクを発見して特定する責任を持つ。
"

25.とも関連するが、大規模プロジェクトにおいてリスクを洗い出すことは通常ある。しかし洗い出すのは担当者レベルであり、客観的にリスクを評価し対策を考える管理責任者を置くことは稀である。よってプロジェクト全体にかかわるリスクは放置されがちとなる。

"
人的資源
30.そのプロジェクトを成功に導ける指導力を持った技術リーダーがいるか。
"

ITプロジェクトにおいて大切な要素の一つは、全体を一貫した技術的考え方（アーキテクチャ）で統一し、その考え方に沿って以降の工程を進めていくことにあると考えている。しかしながら、営業が提案するBUZZワードがアーキテクチャであると勘違いされ、それを深める技術リーダーが置かれることは少ない。よって工程が進むにつれ、当初の技術的考え方は忘れ去られ、（または最初から全くないか）各サブチームはばらばらの方向に進むことが多い。

以上でソフトウェアプロジェクトサバイバルガイドのチェックリストのうち個人的に重要だと思われるものを抜粋し説明をすることは終えた。次回以降は、実際に自分が関わった２つの大規模プロジェクトをチェックしてみたい。

大企業の基幹システム開発における進め方のポイント

大企業の基幹システム開発における開発方法論（は関係ない？）
を書いたので、どのように進めればよいか考えてみる。

個人の力では個々人の意識改善、組織のあり方を変えるのは、ほぼ不可能ではあるが、理想がなくてはギャップも埋められないので、理想であることを意識して書いてみる。

個々のプロジェクトの性質に依存する事項ではなく組織の（および個人）のあり方について書いてみる。

では、まずネタとしてCIAの前身であるOffice of Strategic Servicesの作ったスパイに命ずる相手組織の撹乱作戦（Simple Sabotage Field Manual ）の内訳を簡単に書く。（実際に第二次大戦時の機密文書として存在し近年公開されたらしい）　


・何をするにも「指揮系統」を主張し、意志決定を早めるためのいかなる抜け道も認めないようにせよ
・可能な限り物事は委員会で決定せよ。委員会は決して５人以下にしてはならない。
・できる限り本質的でない議題を持ち出せ。
・業務の承認手続きを複雑にせよ、どんなことでも３人以上の承認を得るようにせよ。

・ペーパーワークを増やせ。

・さほど重要でない仕事でも完璧さを求めよ。

・内容よりも手続きを重視せよ。

・やるべき重要な仕事をさておき会議を行え。

つまりこの逆張りをすればいいことになる。

1. 組織のフラット化。
2. 管理組織をコンパクトにする。
3. 会議の数を最小にする。
4. （正確さよりも）迅速な意思決定。

あと第二次大戦の時になかったのはITインフラであるが、使わない誰も見ない情報をITシステムに入力することを要求するということがよくある。そしてその情報の集計などの再加工させ報告を求められることがある。ペーパーワークを増やすことにも通ずるが報告書のなんと多いこと、またどんな状況報告であっても聞いて終わり、一緒に対応策を考えることはしない。

よって

• 情報は、必要な人がITシステムから「自分で」取り出して加工して分析すればよい。
• 報告を求め、問題点がある場合は一緒に考える。

も加えたい。

これらを心がけるだけで、プロジェクト開発はかなり円滑に進み、いたずらに巨大化しないのではないだろうか？

ubuntuへのnode.js、npm、expressのインストール手順（2016/08）

node.jsの練習のために多少調べたりして時間を食ったので、手順を記録として残す。
練習のためなので最新版は必要がないのでインストールの簡便さを優先した。

1.node,jsのインストール

sudo apt-get install nodejs

2.おまじない（nodejsをnodeにリンク）

sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10

3.npm（パッケージマネージャ）のインストール

sudo apt-get install npm

4.express（フレームワーク本体）のインストール

sudo npm install express -g

5.express-generator（スケルトンの自動生成機能と思う）

sudo npm install express-generator -g

以上で準備は整ったはず。

ITプロジェクトのコントロールや運用（過去のプロジェクト振り返りその7）

今回は、プロジェクトのコントロール（するための組織や運用）について述べる。

"
15.意思決定権を持つ特定の役員が、プロジェクトの責任者として選任されているか、さらに、その人物は積極的にプロジェクトを支持しているか。
"

巨大プロジェクトにおいて役員が最高責任者となっていない場合は、少ない。しかしながら方向性や自身の意思を示すことは少なく、実質的には下から上がってきた方針を追認するするだけの場合は多い。神輿としての役員は置かれるが、意思決定の役目を果たすだけの見識を持つ役員は少ない。

”
17.完全に達成されたか、あるいはまったく達成されていないかを判定できる「二者択一型」の明確なマイルストーンが、プロジェクトの要所に設定されているか。
"

プロジェクトの要所要所にチェックポイントが設けられることは多いが、上記のように明確なマイルストーンが置かれることもやはり少ない。また２択ではなく、３択（◯×△とか）が多い。チェックポイントも「XXの計画書が作成されていること」などと、中身は問われない。問題がある場合も「改善点はあるものの概ねOK」として△でお茶を濁す。そして最後の最後で大爆発する。

二者択一の明確なチェックポイントリストを一度見てみたい。。
（かなり細かく作りこむのかな？）

"
19.フィードバックするための制度が設けられているか。この制度は、プロジェクトのメンバーが直属の上司や経営上層部に対して匿名で問題を報告できる必要がある。
"

この制度が設けられているプロジェクトは残念ながら見たことがない。いわゆる「目安箱」制度だが、より現場の状況を把握するために良い仕組みと思う。過去一度だけ似たような制度が設けられようとしたが、組織階層外からの報告は良しとされず、結局お流れになった。

大企業の基幹システム開発における開発方法論（は関係ない？）

カンバン方式を勉強して、数百人から数千人及ぶ大企業の基幹システム開発に最新の方法論と言われるやり方が（部分的にでも）導入して、失敗しがちなプロジェクトの成功率を上げることはできないかと考えた。

しかし問題は方法論ではなく以下の点にあるのでは？と考えた。ウォーターフォールよりアジャイルがより良いかとかそういう問題ではないと考えた。

大規模プロジェクトの特性

1. ミッションクリティカル（業務を止められない、止めるとしても時間を最小にすることが求められる。）
2. 基幹システムなので、関連（連携している）システムが非常に多い。（数十〜）
3. 関連システムが密結合で連携している。
4. システムが多いので利害関係者が多い。
5. 利害関係者は、システム部門間だけではなく、ユーザー部門も巻き込んで複雑な関係になる。
6. （日本人の特性なのか？）失敗したくない。（評価方法が減点方式なのか？）

1.は方法論に関係なく、移行の仕方の難しさの話。

2,3.は密結合から近年の考え方である疎結合への移行の難しさの話。アーキテクチャをどう考えるかという技術の話ではあるが、プロジェクトの進め方の方法論とは直接関係ない。

※ここまで書いて考えたのが、作る対象のシステムが密結合から疎結合に変わっていくように方法論やプロジェクトマネジメントツールも密結合から疎結合へという流れになるのかな。依存関係は少ない方がもちろん難易度は低くなる。

4,5.は、アーキテクチャや方法論を超えて、もはや政治の世界になる。全員がハッピーになる方向などありえない。（PMにはその企業１番の実力者、といわれるのはそのためであろう。）

6.は（個人は、あるいは自チームは）失敗したくないのに、（全体としては）結果的には失敗する流れになってしまうという相反する結果を生み出してしまう。これも方法論とは関係ない。個人が成功するため（失敗しないため）には、他の人は知ったこっちゃないという考え方が生まれがちと考える。

よって方法論の良し悪しに関わらず大規模プロジェクトは失敗の確率が高いのでは？

ITプロジェクトにおけるカンバン方式について勉強した。

「カンバン」というと「トヨタ」しか連想されなくて、生産管理の手法と思いこんていたので改めて勉強した。

カンバンのポイントは以下のとおり
※ちなみにWikipediaは、難しすぎてよくわからなかった。

1. この方式の導入の大きな目的は、プロジェクトの見える化。
2. 何（タスク）を、いつまでに、誰が、今どこまで、を見える化する手法。
3. 最低限、ホワイトボードと付箋紙があれば実行できる。
4. （おそらく一番単純な書き方では）ホワイトボードに縦に３本線を引く。
5. 左の列は「ToDo」何をするのかを付箋紙で貼っていく。
6. 真ん中の列は「Doing」仕掛り中の付箋紙を「ToDo」から移動させる。
7. 右の列は「Done」終わったタスクを「Doing」から移動させる。
8. 付箋紙にはだれが、いつまでに、どんなことをするのかを書く。（はず）
9. ホワイトボードではなく、コンピューターのツールを使ってももちろんいい。
• チームの人数がすこし多くなるとその方が良いのだろうと思う。

上記は、単純なパターンだが列を増やしプロセスを細かくすることも可能。

上記をみて巷でいうチケット駆動では？と思ったがそちらも詳しくないので後日調べてみる。

しかしこれは自分が関わったような大規模プロジェクトでは、導入しにくいのではと思った。やり方に問題があるのではなく「見える化」を良しとしない人がいるためだ。表向きは、「プロジェクトなので見える化は推進されるべき」となるが、実際は見えると困る人達がいる。プロジェクトの進捗状況は、その人自身の評判や人事考課に関わってきたりする。なにしろ一目で「できない人」がわかってしまうので、日本人の性質なのか赤裸々にそれを明確にすることは難色を示されることがあるのではと感じた。

個人的には、ITプロジェクトにおける「できる」「できない」は、向き不向きの問題なので、赤裸々になっても恥じることはないと考えているが。

SEOの勉強会にいってきた

最初にSEO(Search Engine Optimization 検索エンジン最適化)の勉強会にいってきたので記録として残しておく。

全体は２部構成で
1.Webマーケティングの考え方
2.Google Analysticsの概要について
となっていた。２部はツールの簡単な紹介だったので省略する。

１部のWebマーケティングの考え方が非常に面白かった。
例えば、自分が有料自習室（最近は図書館で受験勉強とかしづらい）を経営しているとして、その宣伝のWebサイトにどのように誘導するのか？

カスタマージャーニー（顧客行動と訳すのかな？）という考え方で誘導の方法論をかんがえる。

1. まず顧客像を定義する（ペルソナというそうだ）
1. 例えば浪人生で集中して勉強する為の施設を探している（毎日喫茶店は高すぎる。また長時間いるのは気がひける）という人が顧客像
2. 次にそのペルソナがとる行動を定義する（フェーズとタッチポイントという、行動の際に顧客がどのように思考するかも仮説を立てる。）
1. フェーズ１　浪人生が自習施設を探す。
• タッチポイント１　Webで、「自習室」「無料」「有料」「最寄の駅名」などで検索をかける。
2. フェーズ２　浪人生がヒットした中でHPを開いて中身を確認する。
• タッチポイント２　ヒットした中で上位のサイトを開き、自分の予算、駅近か？どうか、設備などを確認する。
3. フェーズ３　実際に一度行ってみる。
• 条件に合致していた場合、見学の申し込みをする。
3. 上記は非常に簡単な例だが、フェーズ１、２においてどれぐらい顧客に訴求するか？また検索上位に位置するかがWebマーケティングのポイントとなる。
4. 上記の例だと
1. 自分が想定する顧客の検索にヒットしているか？
2. 自分が想定する顧客が求める情報が自身のWebサイトに盛り込まれているか？
3. をツールを使い分析していく。

なのでブログタイトル、副題、記事タイトルなどが非常に重要であるとわかった。

これまで記事タイトルは、漠然と書いていたところがあるので改善していきたいと思う。

※勉強会では触れられなかったが、どれだけ他サイトからリンクされているかも重要じゃなかったかな？

ITプロジェクトにおける計画立案（アーキテクチャとリソース計画）について（過去のプロジェクト振り返りその6）

今回は、計画立案の設問について述べる。

"
計画立案
10.アーキテクチャと設計についての詳細な文書を作成してあるか。
"

アーキテクチャをプロジェクト全体として共有することは重要である。しかし計画段階でそれを設定することができるプロジェクトは多くない。また実現可能性の高いアーキテクチャ（本を丸写ししたようなアーキテクチャではなく）を設計できる人も少ない。


"
13.プロジェクト計画には休日、休暇、病欠、教育などの時間が見込まれているか。さらに、リソースの使用率が100%未満で計画されているか。
"

20年前ならいざ知らず、近年は人的リソースについては、上記のことを考慮して計画することが多い。しかしながらそもそも「計画時におけるプロジェクト規模の見積もりの難しさ」という問題があり、余裕をもってリソース計画を立てたつもりであっても、結局工程が進むにつれリソースを食いつぶしてしまうことが多い。計画と実際の規模の間に借りが大きい場合は、そのプロジェクトはデスマーチとなる。

JSONを勉強した

Web越しのデータの受け渡しにJSON(JavaScript Object Notation)という形式が使われると聞いたので勉強してみた。かつてはXMLが主流とおもっていたのが、必ずしもそうではなくなったらしいので勉強しておかねばと思った。（特にJavasScriptを勉強するにあたって）

XMLは構造をあらわすのに便利な形式ではあるが、ちょっと冗長なところがあるとは思っていた。入れ子構造をあらわすには便利だと思う。しかし可読性はそれほど良くないところもあり、単純なデータ構造をあらわすためにJSONという形式ができたのではないかと思う。単純な設定ファイルなどのためには、XMLは大仰なのかもしれない。

JSONの簡単な記載例を以下に示す。

{
    "年齢":50,
    "住所":"東京都杉並区",
    "ペット":["犬","猫","猿","雉"],
    "既婚":false
}

左側にデータ名、コロンで挟んで右側にデータ値。超簡単ですね。
ペットの記載例のように配列も取り扱い可能。記載例には書かなかったが入れ子構造も可能な様子。（オブジェクトというものを使うのかな？今回は割愛）

確かにXMLよりは可読性に優れているように思います。
RDBMSでJSONをサポートしたというニュースを聞くのもなんだかわかる気がします。

SOAについて考えてみた

これまで関わった２つのプロジェクトで基本的なアーキテクチャにSOA(Service Oriented Architecture)を採用していた（とされていた）。

まずSOAとは、概念であり、技術や製品ではないと記述をあるところで読んで、ひっくり返りそうになった。

SOAの概念、利点は以下とおり。

• 業務（領収書を発行する等）単位でプログラムを部品化し再利用できるようにして、システム単位のみならず企業単位で最適化を図る。（例えば組織変更によるワークフロー変更への柔軟な対応とか）もうすこし詳しく書くと、
1. 業務の部品化する。
2. 部品を組み合わせてアプリケーションを構成する。
3. オープンな技術による（SOAP等）標準的なインターフェースを備える。

と理解した。

とすると、関わった２つのプロジェクトは、いずれも（かなり有名な）パッケージ製品を利用することが決まっており、外部からアクセスする為のAPIも当然備わっていた。それぞれのプロジェクトは、別途アプリケーションサーバーを立て、APIにかぶせる形でSOAサーバーを立てていた。（SOAは概念であるとするとSOAサーバーって変な感じ）

パッケージ製品のAPIは、部品化され標準にのっとったインターフェースを備えており、さらにSOAサーバーが必要な理由がよくわからなくなってくる。

真に企業においてSOAの概念が必要なケースは、全く新規にシステムを一から再構築する場合のように感じる。

つまりバズワードであるSOAを営業的に使って、SIerから余計にサーバーを買わされただけなのが真実なのだろうか？

Visual Studio Codeを使ってみた。

node.jsを練習するために、入力補完のあるEditorを使いたいと思った。
クラウド開発環境のCloud9は、結局インストールがめんどくさく諦めて、練習のための環境整備の為に労力を割くのもバカバカしいと思い、割り切ってローカルでIDE(Integrated Development Environment))を使うことにした。いろいろなIDEがあるが今回は新進気鋭のVisual Studio Code(2016/08/15 v1.4 Microsoft製OSS)を使ってみようとインストールしてみた。インストールは凄く簡単でだった。

余談だが商用のIDEも検討してみたが、だいたい300、400ドルもするので断念した。これだけの価格差の価値のある機能なのかわからずチュートリアルのためにそれだけの出費をすることは納得できなかったので諦めた。（グループワーク機能や各種フレームワークへの対応が充実しているように感じたが、チュートリアルそこまでの機能は必要としていない）

node.jsの入門本のチュートリアルをやってみるだけなので、とりあえず20行〜30行ぐらい編集できれば良い。なのでエクステンションはまったくインストールせずにそのままとりあえず使ってみた。４、５年前にはEclipceをPythonの為につかったことがあるが、そのときよりもかなり進化しているように感じた。（Pydevってエクステンションをインストールした記憶がある）

まずチュートリアルの為の簡単なhtmlを作成しておおっと思ったことは。

1. 入力補完がずっと進化しているような気がする。
1. カッコ(){}の補完が便利。
2. タグの候補が2,3文字入力するだけで表示される。（タグ以外の文字列も補完してくれるのかな）
3. Tabの段落下げをかなり自動でやってくれる。
2. Terminalが内蔵されているので、エディタ内で完結できるので良い。
3. ファイルブラウザ（エクスプローラー）がデフォルトで内蔵されている。
4. 思ったよりずっと軽かった（Eclipceはかなり重かった気がする。昔いた現場では現場ではプログラマーは、ロースペックのPCでEclipceでJava開発をしていた。機能はともかく重くてしんどかっただろうなあ。）

まだまだ使いこなしていないが、いろいろ便利なんだろうな。手慣れたプログラマーにとっては基本的な機能でも、おじさんの手習いとして使うには凄く感動した。

Macにおける仮想化環境（VirtualBoxとParallels Desktopの簡単な比較）

最近Macを買い換えたので、移行アシスタントを使わずに新しいMacに一からソフトウェアをインストールすることにした。

旧Macでは、ちょこっとした仕事にOfficeを使う為、Parallels Desktopを買ってその仮想環境にWindowsをインストールして使っていた。ソフトウェアの見直しに当たってParallels Desktopを使い続けて課金するのもなあと思い始めた。よってかつて使い慣れたVirtualBoxに戻ることにした。そこでとことん使い倒しているとはいえないものの、両者を簡単に比較してみる。

Parallels Desktopの良いところ。

1. （おそらく）パフォーマンスが良い。Macbook Airの1.7GHzで32bitWindows7および10がキビキビ動いていた。バリバリ3Dとかでなければ上記スペックでもゲームで遊べていた。Officeももちろん普通に動く。
2. Guest OS（特にWindows）への対応が早い。
3. 設定とか全然考えずにファイル共有とかクリップボード共有とかが出来ていた。

Parallels Desktopの良くないところ。

1. メジャーバージョンアップ（MacOSのメジャーバージョンアップとタイミングはほぼ同じ。）ごとにバージョンアップの費用が五千円くらいいる。（バージョンアップをしないという選択肢もあるが、最新OSにだんだん対応しなくなっていく）
2. なんか自社製品の広告が時々出てうざったい。（たまにだが）
3. 設定は至れり尽くせりなのだが不要なエイリアスとか勝手に作ってくれたりする。
4. クロスプラットフォームじゃない。（これは結構大きいかも）

VirtualBoxの良いところ

1. ただ（USBまわりの機能拡張を入れると完全OSSではないが無料）
2. クロスプラットフォーム（作った仮想環境を別のPCに持っていける）

VirtualBoxの良くないところ

1. 新しいMacbook Proでは試していないが、過去の記憶ではゲームとか描画系が厳しかったのでゲームとか無理（と思う）
2. 一時期オラクルがサボっていてアップデートが滞っていた気がするので、将来的に不安。
3. 細かいところまでの設定が厳しい（Xubuntu16.04のインストールでは結局サウンドドライバ周りは切った）。HOSTとの共有フォルダとかは自分で設定が必要（その方が良いケースもあるが）

よって今回は、お金とクロスプラットフォームを取ってVirtualBoxにした。

あとOffice365を使っているので、Mac版の最新Officeをインストールできたのも大きい。

余談だがOffice365マジおすすめ。昔は互換性が悪いという話も聞いたが、今のところ問題ない。

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プロジェクトとしての楽しみは少なく、大企業の中間管理職であることは変わらず。権限も少なく。個人的にはやりたくないなあというお仕事の一つです。