ある過去の開発プロジェクトの要求、開発立案、プロジェクトのコントロール、リスクマネジメント、人的資源をチェックしてみた（過去のプロジェクト振り返りその9）

今回から過去関わったプロジェクトの２つについて、スティーブマコネル著のソフトウェアサバイバルチェックリストに沿ってチェックしてみる。サバイバルテストの詳細は英文だが以下のURLにある。

http://www.construx.com/Thought_Leadership/Books/Survival_Guide/Resources_by_Subject/Survival_Test/

プロジェクトのチェックを早速始める。
完全に「はい」と言える場合は、3点。おそらく「そのとおり」の場合は2点。
そう言えなくもないという場合は1点。そうではない場合は、0点。
全体的に厳し目に採点することにする。

要求
6項目で、7点であった。満点が18点なので半分以下。
自分が以前に言及した。

”
要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか？
"

は両方とも1点であった。

計画立案
８項目で、7点であった。

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

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

は、やはり両方1点であった。

プロジェクトのコントロール
10項目で、10点であった。

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

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

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

設問15は2点、17、19は0点であった。

リスクマネジメント
3項目で、3点であった。

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

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

設問25は1点、26は0点であった。

人的資源
6項目で、7点であった。（実際の人物を顔を思い出して甘く点数をつけてしまったかも）

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

設問30は0点であった。

合計は、25点。

サバイバルガイドによると、40〜59点が普通のプロジェクトで、40点未満は危険と言及している。引用すると、

"
この範囲の得点しか獲得できなかったプロジェクトは、要求、計画立案、プロジェクトのコントロール、リスクマネジメント、人的資源という主要な領域において重大な弱点を持っている。このレベルのプロジェクトにとって最大の懸念は、そもそもプロジェクトそのものを完了できるかどうかということである。
"

実際にどうであったかというと、何を持って完了とするかによるが、結果的にサービスを提供することはできた。ただし予算は当初のおそらく3倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って（当然ある程度のブレ幅は許容するとして）成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。

DevOpsについて勉強した。

DevOpsといえば高速な開発と本番環境へのプロダクトの投入と思い込んでいた。まちがっていないが、もっと広く深い概念と理解した。

2016年現在確立した定義はないが、自分の理解を列挙してみる。

1. Dev（開発）とOps（運用）の協力体制をより密にすること。
2. これまでは、開発の立場としては、開発したプロダクトをより早く本番環境に載せたい。
3. 一方運用側は、安定稼働を望むため変化を好まない。
4. そのような利害関係があるので、企業体として求められる「早くサービスを提供すること」に対応しきれない部分があった。※上記の書き方だと運用側が抵抗勢力のように読めてしまうが、低品質のプロダクトをもってくる開発側にも問題がある。あと本番環境と開発環境の差異などで障害は発生しがちである。なのでコンテナ技術が発達してきたのかな？
5. そのための考え方がDevOpsという言葉に集約される。
6. より密に協力していこうという考え方の背景は、ITをコストカットのためのツールとしてではなく、ITを使って競争に打ち勝つという考え方がある。そのためより便利で安定性のあるソフトウエアプロダクトが求められている。
7. また協力の考え方だけでなく、それを実現するためのツール群も近年現れてきた。
• ツール群によるプロダクト開発（と投入）のレベルに段階があるので少し解説する。さっき覚えた（笑
1. 第1段階　バージョン管理（本番のソースコードと開発中のソースコードの差異管理。）
2. 第2段階　継続的インテグレーション（テストとOKであれば開発系ソースコードへのコミットの自動化）
3. 第3段階　継続的デプロイ（第２段階の結果、問題がなければプロダクトのビルドと本番環境への適用の自動化）
4. 第4段階　継続的デリバリ（本番環境へのデプロイタイミングをビジネス要求に沿って決定する。※第3段階までくるといつでも本番環境にプロダクトを投入できる状態になる）
• 上記の段階を実現するための便利なツール群が近年登場してきた。
8. 欧米ではここ7,8年前ぐらいからこの考え方はあって、日本では自分の見聞きする限りせいぜい第2段階どまり。（スマホゲームだと第4段階まで行っていないとだめだろうけども、毎日のように何かイベントがあるから）

一番重要なのは6.の考え方だと思う、その方法としてDevOpsという考え方が生まれてきたのだと考える。

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

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