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すると後半の手戻りも少なくより成功に近づくのではと考えた。

2016年9月16日金曜日

IoTについて勉強した

IoT(Internet on Thing)とは何か?を勉強した。
文字通り、あらゆるものがインターネットに接続されること(冷蔵庫とか家電)と最初は理解していた。で接続して情報を収集して何になるの?と考えていた。

IoTとは、以下のように定義されるらしい。

  1. モノからセンサーによっていろいろな情報をインターネット経由で収集する。
  2. 収集したデータを蓄積する。
  3. 蓄積されたデータを分析する。
  4. 分析に従って、必要に応じてモノにフィードバックする。(センサーついているモノに直接フィードバックすることもあれば、分析結果を社会や企業、の今後に生かすことも指すらしい)

センサーから収集し、蓄積したデータは膨大なものになるので、その分析には人工知能も関連してくる。(人知では分析しきれないほどのデータ量になりがちのため)

とすると応用領域は、例えば電力のスマートメーターによって電力の使用量の傾向の蓄積であるとか、自動車からの交通量の状況蓄積と対策とか、自動車事故を起こしやすい状況の分析とか。また医療分野についてもいろいろな応用が考えられる。介護分野についても同様。(しかし金融の投資動向とか分析されると一般人は、大手金融機関の思いのままになるんだろうなあ)

とするとその情報の管理が大変重要になる。各々のデータが個人情報と結びついた時、その個人の生活が赤裸々になってしまう可能性がある。(もうAmazonやGoogle、Appleにはかなりの個人情報を握られてしまっているが)

2016年9月現在、政府から情報銀行なる構想が提言されたが、個人の購買行動や医療情報などは国に握られたくはないとの思いがある。年金の管理のずさんさ、住基カードの有様をみるととても役所に自分の情報を預けたくはないと考える。(マイナンバーを利用したいのだろうけど、ビッグブラザーの影がチラチラ見えて来る)

2016年9月15日木曜日

とあるプロジェクトのPMOの1週間

9:30−18:30が定時
そんなにも忙しくない時

月曜日
9:30−10:00 メールチェック等
10:00−11:00 バグ報告会
11:00−12:00 午後の資料準備
13:00−14:00 資料準備の続き
14:00−15:30 定例会議(変更管理等)
15:30-16:00 ちょっとした隙間
16:00−17:00 バグ確認(現場からの報告)
17:00−19:30 いろいろ資料作成
帰宅

火曜日
9:30−10:00 メールチェック等
10:00−11:00 バグ報告会
11:00−12:00 リーダーミーティング
13:00−16:00 テスト状況の報告書作成
16:00−17:00 バグ確認(現場からの報告)
17:00−19:30 いろいろ資料作成&打ち合わせ
帰宅

水曜日
9:30−10:00 メールチェック等
10:00−11:00 バグ報告会
11:00−12:00 いろいろ資料作成&打ち合わせ
13:00−13:30 ちょっとした隙間
13:30-15:00 テスト進捗会議
15:00−16:00 全体進捗会議
16:00−17:00 バグ確認(現場からの報告)
17:00−19:30 変更管理等の打ち合わせ
帰宅

木曜日
9:30−10:00 マネージャーブリーフィング
10:00−11:00 バグ報告会
11:00−12:00 いろいろ資料作成&打ち合わせ
13:00−14:00 いろいろ資料作成&打ち合わせ
14:00-15:00 テスト報告会議
15:00−16:00 いろいろ資料作成
16:00−17:00 バグ確認(現場からの報告)
17:00−19:30 いろいろ資料作成(月曜日に向けて)
帰宅


金曜日
9:30−10:00 メールチェック等
10:00−12:00 いろいろ資料作成&打ち合わせ
13:00−14:00 いろいろ資料作成&打ち合わせ
14:00-15:00 テスト連絡会議
15:00−16:00 いろいろ資料作成&打ち合わせ
16:00−17:00 バグ確認(現場からの報告)
17:00−18:00 プロジェクト連絡会議
18:00−19:30 いろいろ資料作成(月曜日に向けて)
帰宅

テスト関連会議多すぎ〜 一番忙しい時はわすれました。
延々と会議と打ち合わせだったような気が。。

ITシステム開発プロセスについて(過去のプロジェクト振り返りその11)

システム開発プロセスについては様々な方法論があるが、ここでは個々の方法論については述べない。
過去のプロジェクトにおいてよく体験してしてきたことだが、開発方法論の大枠(ウォーターフォールでいくとか)は、計画段階で決めるものの、方法論を実際に実行するための細部にわたるプロセスは、必要性が見えてきたときに初めて検討され始める傾向がある。

初期段階において、開発プロセスの「実際の」運用を決めておかないと、必要性が高まってきたときに、決め始めるのではオーバーヘッドが大きいとよく感じる。

スティーブマコネルの「ソフトゥエアプロジェクトサバイバルガイド」には、計画段階でのプロセスの決定を推奨している。例としては以下のプロセスを事前に決定する必要があると述べている。

  • 変更管理
  • 品質保証
  • 欠陥追跡
  • システム統合(システム間インターフェースの考え方)
  • ソースコードのバージョン管理
  • スケジュール(見積含め)
例えば、変更管理を例にとると「変更を誰がどのように評価し、受け入れるのか」が実際に変更が大量に積みあがるまで管理プロセスが決定していないことがよくあった。

またスケジュールに関しても、当初のスケジュール(ドンブリ勘定でとりあえず置いてみたもの)が、やはりうまくいかないので3ヶ月から2週間ごとに再見積もりとスケジュールの引き直しを求められたことが、よくあった。
ちなみに当初スケジュールを自分で見積もらせてもらったことは、ほとんどない。どこかの誰かが適当に引いたものの順守を求められるという理不尽なことがよくある。

プロセスの実際の運用が遅れれば遅れるほど、プロセス運用の試行錯誤(突貫工事で作らなければならなくなるため)と本来の作業が重なり合い非効率な、場合によっては本来の作業を阻害するような事態が引き起こされる。








2016年9月8日木曜日

あるプロジェクトで「チームメンバーがプロジェクトを達成不可能と信じていること」を深堀ってみる

とあるプロジェクトでチームのメンバーは、口々にプロジェクトを達成不可能といっていた。その理由大きくいうと以下の3つに集約されるのではないかと思う。

  1. 仕事量がものすごく多い。やってもやっても終わらない。
  2. 優秀な人とそうでない人の差が大きくフォローしきれない。
  3. プロジェクトとして現場レベルで決めたことを実際に現業をやっている部門に持っていくと簡単にひっくり返される。

1.について。自分のチームは要件定義を行うチームであった。要件としてはパワーポイント1ページに集約されることであっても、主管部門との調整、他の業務との整合性をとることに多くの時間を割かれた。日中の時間帯のほぼ7、8割が会議であった。必然的に自分の中で考えをまとめたり、資料を作ったりというのは残業時間で行うことしかできないことになった。コミュニケーションパスが多すぎて一つのことを決めるために小さなことから大きなことまで会議会議の連続であった。

2.について。優秀な人はまあいいとして、ソフトウェア開発プロジェクトには向き不向きがあると思う。向いている人というのは、

  1. 積極的にコミュニケーションを取れる人。(単なる会話ではなく交渉能力、調整能力に長けた人)
  2. 論理立てて物事を考えられる人。(なぜそれをするのかを突き詰めて考えることができる人)
の2点のうちどちらかでもできる人でないと辛いのではと思う。人間性はすごくいい人なのだけれどもプロジェクトにおいてつらい毎日を送っている人が何人かいた。マネージャーは適性を見抜いて人を配置することがすごく重要だと思う。不向きの人がいた場合、3人いて3人分の仕事があるのに、2.5人分の仕事しかこなせない体制になっている場合がしばしばある。その場合優秀な人がフォローに回ることになる。

3.について。プロジェクトと主管部門との力関係で、決めたことが左右される。また長期にわたるプロジェクトの場合、主管部門の担当者の異動があったりすると方針が180度がらっと変わったりもする。それは担当者レベルでもマネージャーレベルでもあった。

上記のことが重なり合い、毎日のように起こっているとチームメンバーの士気はさがっていく。決めるべきことがいつまでたっても決まらない。度々の方向転換があり、右往左往する。仕事時間は増える。

なので「このプロジェクトの目標は達成不可能」と思い込むとなる。

2016年9月7日水曜日

プロジェクト開発に関する見積について過去の振り返り

IT開発プロジェクトにおける規模見積について考えてみた。

IPA情報処理推進機構によると、見積の要素としては、以下の要素が挙げられている。

"
規模
 ファンクションポイント
 コード行数
  機能数、画面数、テーブル数
その他見積りに影響を与えるもの(工数の変動要因)
 プラットフォーム/環境
 ハードウェア、オペレーティングシステム
  言語、ツール、ユーティリティ
  開発環境
プロダクト
 アプリケーション種別
 複雑度、要求される信頼性
 ライフサイクル
人材
 能力と経験
 総労働時間
"

見積は当初の計画時からどんどん増える方向に乖離していくものである。(残念ながら少なくなる方向に乖離していくことは経験したことがない。そういう事例はあるのだろうか?)多くの場合、計画(提案)時には、上記の要素の大部分はわからないことが多い。そこで、経験者、あるいはひどい場合は開発未経験の営業さんがエィっとドンブリ勘定で出すことが多い。さらには、「予算はこれぐらいと決まっているから。この範囲内でよろしく!」とどんなことをするのかも決まっていないのに型にはめられてしまうこともある。

自分が経験した中で一番優れた見積は、ある中規模SIベンダーさんで、上記のような要素を入力すると自動的にブレ幅も示した上で、開発規模を算出してくれるツールをもっていた。しかも過去の多数のプロジェクトの実績を加味しながら、そのツールは常に進化し続けていて、かなり精度の高い見積を出すことができたことがある。またそのプロジェクト独自の要素(今までに使ったことのない言語であるとか)も加味することができて非常に良くできたツールであった。

大規模SIベンダーさんであれば、過去事例も山ほどあるはずとおもうがそういったツールは、後にも先にも1度しか経験していない。(過去事例の要素を洗い出してみて、実績と突き合わせて分析すればかなり精度の高い見積が出せそうと思うのだけれども)

仮説に仮説を重ねて何らかの数字を出していってもほとんど意味のない数字になってしまう。が要件定義の具体的な個別タスクの工数の積算などそんなことをよくやった記憶がある。

成果物に対しての作業工数が測りにくい作業に対しては、作業の積み上げによる積算よりも、全体から俯瞰して算出したほうが良いような気がする。「考える」作業に対しての見積は一筋縄ではいかない。最終的には1ページの要件定義書であっても、それを作り上げる過程ではたくさんの会議があって、うんうんうなりながら考える時間がある。また会議で説得するための資料作りなどの作業もあまり目には見えない。なので細かい作業の一つ一つを洗い出して積み上げると、とんでもない工数となる。(それぐらいかかるのが現実に近いのだけれども)

大体のプロジェクトにおいては、もう「やりたいこと」がほとんど決まっていることが、前提になっている気がする。しかし実態は「やりたいことがわからない」ほうが多いと思う。「古いシステムと同じで!」というのも「やりたいことがわからない」に等しいと思っている。そういった場合には、要件定義の工数は際限なくかかっていく。そしてデスマーチへとつながっていく。

2016年9月5日月曜日

別のプロジェクトも健全度具合をチェックしてみた(過去のプロジェクト振り返りその10)

別のプロジェクトについてもチェックリストにそってチェックしてみた。サバイバルテストの詳細は、以下のURLにある。

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

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

要求
6項目で、8点であった。


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

は設問1は2点、設問2は1点であった。

計画立案
8項目で、9点であった。

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

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

は、設問10は2点、13は0点であった。

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

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

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

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

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

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

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

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

設問25、26ともに1点であった。

人的資源
6項目で、6点であった。

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

設問30は0点であった。

合計は、39点。先のプロジェクトよりは点数は良いが、やはり危険領域である。
サバイバルガイドによると、40〜59点が普通のプロジェクトで、40点未満は危険と言及している。引用すると、

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

実際にはまだこのプロジェクトは、現在進行形である。(自分はプロジェクトを離れてしまったが)現在のところ重大な問題を抱えていることがわかる。

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

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

計画立案
8項目で、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倍に膨れ上がった。またサービス提供後の運用にも大変な苦労をしていると伝え聞く。
個人的には、当初の計画の予算、期間、品質を守って(当然ある程度のブレ幅は許容するとして)成功と考える。このプロジェクトの場合、予算、品質は失敗プロジェクトと言えるのかもしれない。




2016年9月1日木曜日

DevOpsについて勉強した。

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

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

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