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割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな?書き直すのが面倒なので補足しておく。


2016年9月20日火曜日

IT開発プロジェクトと建築土木

もうIT関連の仕事に携わって20年ぐらいになるが、関係したプロジェクトは成功も失敗もある。自分自身がPMとして失敗してしまったプロジェクトもあるし、さまざまな担当して担当タスクを失敗してしまったこともあるし、自分は失敗しなかったがプロジェクトとしては、失敗だったこともある。

ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能(品質)が+30%の幅の中に収まることと考えている。(甘い見方かもしれないが)

ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。

ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。

  1. ものすごくざっくりというと作業工程が計画〜設計〜実装(建築土木ではなんと表現するのだろう)と工程の進み方が似ていると考えていた。※アジャイル開発においても基本これは変わらないと考えている。進め方の粒度の違いだけ。
  2. 何十〜何千という見知らぬ人間が集まって目標を完遂する。各工程でスペシャリストが集まり、ものを作り上げていく。釘を打つ人と壁紙を貼る人の間のコミュニケーションはどのようにとっていくのだろうとか。
  3. 予算、工期、品質の目標がある。
建築に失敗したビルというのは聞かないが、(実はあるのか??)、失敗したITプロジェクトはごろごろある。なぜなんだろうと考えた結果、計画局面の決定ぐあいが違うのでは?と思い至った。大きなビルならモックアップをつくって検証すると聞いたことがある。また設計図など共通認識を持つための情報ツールがもう枯れた技術となっていて実装時に迷うことがないのでは?(記法なども統一されているだろうし、A社の設計図は、全然別のB社が完全に読み取れるはず)

とするとITプロジェクトにおいても
  1. 計画、設計局面において、できるだけ決定できることは細かく決定しておくこと。
  2. 決定したことの共通理解を関係者がもつこと。また理解のための共通言語(設計図に相当するもの)もつこと。
  3. 上記とも関係するが、共通理解のためのイメージ合わせのためプロトタイプを利用すること(モックアップに相当。プロトタイプの再利用など考えず使い捨てにしたほうが良いと思う)
実装より計画を!(アジャイル宣言に反している気がしますが。。)
に重点をおくと現状が改善されるように思った。通常のウォーターフォール開発では計画〜要件定義までに予算の2割も使えば多いほうだが、(計画には1割も使っていないのでは?)これを少なくとも3割程度までUPすると後半の手戻りも少なくより成功に近づくのではと考えた。