2016年10月4日火曜日

ITプロジェクトを設計する

プロジェクトを設計するというと、少し変な感じがするがこの概念は勝手に自分が考えた。勝手にプロジェクト設計と名をつける。あるいはプロジェクトのためのプロジェクト(PfP:Project for Project)と名付ける。※商標登録しておこうかな。主に発注者側である企業さんに対してであるが、RFP(Request For Proposal)のさらに一段手前において
  • 何をプロジェクトの目的とするか
  • その手段として何を用いるか(ITなのか業務改善なのか、あるいはその両方なのか)
  • どうやって目的の達成具合を測定するか
  • おおよその規模感(1億円なら投資できるが、10億円は無理とか)
等々を明確化し、組み立てていく、要求をできるだけ定義していくのがこのフェーズの目的である。当然決まっていないこともあると思うが、それは「決まっていない」と明確化していく。(それによって提案も変わってくるから)成果物はプロジェクト計画書(設計書)となる。プロジェクト計画書の目次は、
  1. プロジェクト目的
  2. 対象業務・システム
    1. 対象業務・システム概要
    2. 主要課題
  3. 手段
    1. ITによる目的達成部分と達成手段の概要
    2. 業務改革による目的達成部分と達成手段の概要
  4. 効果
    1. 効果概要
    2. 効果の測定方法
  5. 意思決定者(組織)
  6. 実行組織
  7. 関連組織
  8. 要員規模
    1. 実行組織の要員規模
    2. 関連組織の要員規模
    3. 外部調達する要員規模
  9. プロジェクト終了に向けたスケジュール概要
    1. 内的主要マイルストーン(※プロジェクト自体のマイルストーン)
    2. 外的主要マイルストーン(※プロジェクト外で発生するマイルストーン、例えば法改正等)
  10. プロジェクト課題
    1. 主要課題
    2. 課題責任者
    3. 課題対策
  11. プロジェクトリスク
    1. 主要リスク
    2. リスク責任者
    3. リスク対策
ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。(血判状的な)※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。

これぐらいをまず検討していると、プロジェクトの成功確率がぐっと高くなるのではと考える。

2016年9月29日木曜日

IT開発プロジェクトと軍隊(戦争)について

前にITプロジェクトと建築土木について書いたので。今回は、ITプロジェクトと軍隊(戦争)の類似について考えてみる。
似ていると思うところ。
  1. 戦略と戦術がある。
    1. 戦略目標は超重要。戦術レベルでいくら勝利しても。戦略的には敗北はする。
  2. 大部隊を動かす。
    1. 戦争にも大小あるが、総力戦になると数百万の人が動く。
    2. ITプロジェクトは最大規模でも数万だと思うが、十分大人数。
  3. プロジェクトのあるいは戦闘の初期段階では、情報が足らない。
    1. ITプロジェクトの場合は、要求、要件が不明確。できないことも不明確。
    2. 戦闘の場合は、敵の全容が不明確。現代戦ではあまりないのかもしれないが、味方の別部隊の動きも不明確(フォークランド紛争の戦記を読んで思いました。またしばしば味方への誤爆もあるから現代においても完全には相互連携は実現されていないのだと思う。)
戦略目標が重要というのは、これまでにも書いてきたので省略する。
戦術というのは、ITプロジェクトにおける各種方法論だと考える。戦略が破綻していれば、戦術(方法論)がいかに優れていても敗北する。

大部隊を動かすというのは、ITプロジェクトも軍隊も同じだが、(かってな思いだが)各々の兵隊が任務を達成して、それが全体の目的の達成につながるというのは軍隊の方が優れているのではないかと思う。ITプロジェクトにおいては、数千の人間がいても、そのうち何割かは何もしていないか、あるいは無駄なことをしているのを見てきた。
軍隊においてはそれはないと信じたい。なぜなら、少なくとも何かしていないと「死ぬ」から。(想像だが)軍隊においては個々の行動規範が明確化、マニュアル化されており、それに従った訓練がなされているから。千変万化する戦場において、(できるだけ)的確な行動を個人がするためには、それがマニュアル化と訓練が必要だと思う。
※なんとなく行動する軍隊とか想像できない。

ITプロジェクトでは、そのマニュアル化と訓練ができていないと思う。
各々の役割に対する行動規範が不明確で、また日々の訓練も出来ていない。大した研修もなしにOJTと称して最前線に投入されるのは、よくあることと思う。プログラミング研修などは、兵隊がライフルの撃ち方を教わるレベルであって体系立てた訓練とは言えないと思う。
ただし、ITプロジェクトは日々立ち上がるのに対して、戦争はそう滅多に起こらない。なので訓練の余裕がないのかもしれない。

また情報の不明確さに対しては、軍隊は情報をを重視する(どこに敵がいるかがわからないとお話にならない)ため、あらゆる手段を講じて情報を得ようとする。現代戦においては、「情報戦が勝敗を決める」とまで言われているようである。
ITプロジェクトにおいては、その情報を得て分析する努力が足りていないように思える。「見える化」が声高に言われて久しいが、見えた後の分析と行動ができていないように思う。事前に見えるようにもしない。(プロジェクト企画は常にバラ色の未来で、問題やリスクがあることを明記してあるのを見たことがない)

戦争においては、できるだけ本格的な戦闘の前に情報を得ようと、偵察を重視する。ITプロジェクトにおいても本格的なプロジェクト開始の前に「偵察」行動が必要なのではないか?それは、プロトタイピングかもしれないし、要求の分析、RFPをちゃんと書くことかもしれない。プロジェクト企画の段階で、「偵察」のプロが偵察行動を行うだけで、戦争に負ける=プロジェクトが失敗することを防げるように考える。

2016年9月28日水曜日

ubuntuで新規ユーザーにsudoの権限を与えるコマンド

新規ユーザーを作成した後、sudoの権限を与えるコマンド。
(基本的にrootで作業したくないため)

一行だが
gpasswd -a username sudo
※usernameは任意のユーザーID

2016年9月27日火曜日

ubuntuでファイヤーウォールを導入してポートを制限する

Vultrでクラウドサーバーを本格的に使い始めたのでファイヤーウォールを導入して一応セキュリティ対策。
  1. ファイヤーウォールを導入
    • sudo apt-get install ufw
  2. Port設定(SSHとTCPのみ許可する)
    • sudo ufw allow 22
    • sudo ufw allow 8888
  3. 有効化
    • sudo uff enable
  4. 確認
    • sudo ufw status

ubuntuで自分のサーバーの空いているportを調べる

こちらをそのまんま実行。


  1. nmapというportスキャンのアプリケーションをインストール
    • sudo apt-get install nmap
  2. 自分のサーバーの空いているportを調べる。
    • sudo nmap -sTU localhost


2016年9月26日月曜日

node.js開発環境を構築したfor Mac(Macは結果的に関係なかった)

自分で使いやすい環境は何かなと、試行錯誤してきた結果、やっと何となく落ち着くやり方が見えてきたので、記録しておく。


  1. サーバーを立てることにした。Vultrにした。東京リージョンがある。なんとなくAWSとかは敷居が高い気がした。慣れたubuntuを速攻インストールできる。後発なので管理コンソールが洗練されている気がする。最低月5ドルなので、お小遣いも減らない。ここから登録してもらえるとさらにお小遣いが減らないので嬉しい。
  2. ubuntu16.04で環境整備
    1. adduserでユーザー追加(useraddをいままで使ってた。こっちのほうが便利)
    2. apt-getでnode.jsをインストール
    3. 同じくnpmをインストール
    4. npmでexpressをインストール
    5. 同じくexpress-generatorをインストール
    6. 同じくpug(旧jade)をインストール
  3. Visual Studio Codeをエディタとして使う。プラグインを導入。
    1. ftp-simpleプラグインを導入して直接サーバーのファイルを編集することにした。
    2. あとはHTML、Jade関連のプラグインをインストール。
これで最低限のことができる。Gitとかはおいおい。とりあえずRCSでいいかな。

これまでやったこと。
  1. node.jsのチュートリアルでWebサーバーをつくってjavascriptを基本を学習。
  2. サンプルHTML(CSSフレームワークbootstrapの学習)ファイルを作成
  3. もう一歩進んでテンプレートエンジンJadeの学習<今ここ
これからやりたいこと
    1. expressをつかってチュートリアルアプリの再作成。
    2. socket.ioを使ったチャットプログラムの作成。

IT開発プロジェクトの見積

今回は、見積について少し書いてみたいと思う。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり(アジャイル系アプローチ等)の提案についてはいろいろな人が別に述べていると思うので割愛する。

プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか?
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。(定まっていないなら必ずプロジェクトは崩壊する)
※このへんのところは名著 失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。

見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。

しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
8:2の法則から考えると8割ぐらいの要求は決まっていて、またプロジェクトコストに対する8:2の法則から考えると8割の決まっていることは、最終コストの2割で実現できるのでは?と考える。

じゃあ残りの2割の要求は?と考えるとそれは、レアケースに対する要求ではないか?

とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは?と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは?残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか?

最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。

※「決まっていること、わかっていること」の数だけでいうと、8割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな?書き直すのが面倒なので補足しておく。