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. をツールを使い分析していく。

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

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

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