ITプロジェクトのプロセス改善と標準化

ITプロジェクトをやっていると、よくお客様に対して「新規システムを導入するだけではダメで、プロセス改善も同時に行ってください！そうでないと効果がないです！！」と言う場面がある。
それは実際真実なのだが、振り返ってみるとプロジェクト内部でも色々とプロセスを改善したいことが良くある。ツールを導入して効率化してと言う場合もあれば、プロセスそのものを変更したらもっと効率的にプロジェクトを運用できるのにということもあった。

しかしお客様に向かっては厳しくいうくせに自身のプロジェクト運営は全然ダメだった。
一つは、プロジェクトの標準ツールが決まっていて、それ以外は導入してならぬとか。それは大体ExcelかPowerPointかWordか、一般的な企業なら大体あるはずのツールをしか使わせてもらえない。ガントチャートを引くのにMS Projectを使いたいと言ったら「高いからダメだ」とか。IT企業のくせに情報化投資を全然しない。Excel大活躍である。もっともお金がかかるのは人件費なのに、ツールにお金をかけることには極めて消極的だった。
もう一つはプロセスを変えたいとプロジェクト内部で提案した時に、決まり文句で「決まったことだから」「他のチームもプロセスを変えなければならないので無理」とか。

そんなIT企業が真にお客様のための業務効率化に寄与できるとは思わない。「つくることだけ」が目的になっているプロジェクトが多いのではないかと思う。
ちなみにMS Projectは最近しらべたらブラウザベースの簡易版で月に700円程度。実績入力と閲覧だけならこれで十分と思う。アプリをインストールするタイプでも月3600円ぐらい。計画立案をしたりカスタムレポートを使ったりするならば、こちらの方がいいと思うが、それでも3600円だ。
あとプロセスに関しては、お客様側のキーマンに直訴して俺様プロセスを作ったりしていた。本当は良くないのだが、非効率ゆえに仕事量に圧殺されて本当にやるべきことができなくなってしまうからだ。（レポートの為にコピペを繰り返すのに時間を割くのはもったいない）
よってそんな非効率プロジェクトは大体うまくはいかない。

IT開発プロジェクトにおける要件（または要求）定義と以降の局面の期間割合について

大体のベンダーさんにおいては、ウォーターフォールアプローチを取ることが多いのだけれども、すごく大雑把に言って各局面の期間割合は、
要件定義：1
基本設計：2
詳細設計・開発・単体テスト：3
結合テスト：2
総合テスト：2

ぐらいでは無いかと思う。

いつも思うのだが、テスト局面を手厚くして、要件定義及び基本設計にそれほど時間をかけていないのはどうかと思う。実際問題、要件は決め切れないことが多いし、細かい要件について引き出そうとするときりがなくなるというのはわかる気がする。
しかし、それにしても要件定義時の資料の陳腐化が激しくて、以降の局面でその資料が使い物にならないことが多すぎる。また忙しくて要件定義時の資料を直そうということ起こらない。
結果的に要件定義っぽい活動を延々と続けていることになる。テスト局面に入っても。テスト局面が比較的長くとってあるのは、要件が未決定のまま開発に突入してしまうことが多すぎて、経験則からテスト局面を長くとってしまうのではと考える。

ならばいっそ要件定義の局面をできるだけ長くとってはどうかと思う。自分の経験上はできる限り長く要件定義（あるいは要求、システム構想）の期間をとってじっくりユーザーさんと「やりたいこと」を煮詰めてから開発に突入した方が良い結果が生まれる気がする。開発することが明確であるならば期間は短くてもかなりのスピード感をもって開発を進めることができるはず（そうそう特殊なロジックを必要とするアプリケーションはない）

後続局面での手戻りほどオーバーヘッドが大きいのは周知の事実である。なので、できる限り不明なことは、事前に潰しておきたいというのが自分の方針になっている。

工数的にみても、最初プロジェクトの立ち上がりは、数人で始まり、だんだん人数が増えて、最盛期に数十人〜数百人に達するということが多いと思う。
数人で受け取った要件を数十人に展開するのはかなり難しいと思うし、数人では気づきが少ないことも多いと思う。

よって要件定義早期に多くの人間を投入し、それなりの期間を取ることができれば、品質も良く、開発・テスト期間も圧縮できると考える。

CI（継続的インテグレーション）を勉強した

CI(continuous integration:継続的インテグレーション)について勉強した。
CIとは、
プログラムの動作を毎日毎晩確認してバグを洗い出しながら開発を進める手法のこと。確認のために日々プログラムのコミット、コンパイル、テストを自動化する。その為ツールを用いて人がいない夜間にそれら確認を実行する。

そのメリットは

1. 日々少しづつ確認を行うことにより手戻りを最小限にする。（最悪でも1日分の手戻り）
2. それにより品質を高めることができる。
3. 自動化により作業工数の削減が可能。
4. 自動化により作業ミスを減らすことが可能。

となる。これは短期間でプロダクトのデリバリを行うアジャイル開発手法ともよくマッチする。

この考え方をさらに推し進めると継続的デリバリ≒DevOps、つまり本番環境へのプロダクトの投入まで自動化することも目指すことができる。

ちなみにスマホゲームなどは、毎日のようにイベントを行ってゲームを盛り上げようとしており、そのために毎日のようにプログラムの修正が発生していると思う。その場合にはこの継続的デリバリの考え方で開発を行わないとやっていけないはずだ。
一方自分が関わることが多いいわゆる「お堅い企業」においてもビジネスにおいて新しいサービスの早期投入を求められるようになってきており、この考え方の導入がだんだん進みつつある。

IT開発プロジェクトの個人個人の生産性について（過労死事件に寄せて）

電通で入社１年目の方が自死された事件について、労災認定されたことが話題になっている。その方のTwitterの投稿を見るとそれは凄まじく言い尽くせない悲しみを感じた。
また以前ワタミで自死された新入社員の過労死認定の訴訟を行った遺族の方が、和解金を使って「ブラック企業」との訴訟費用を援助する基金を設立されたとのニュースもみた。

自分自身を振り返ると、かつては自死された方ほどではないが、徹夜も辞さないとの姿勢で働いていたことがある（30代前半ぐらいまでだが）。また周囲に対してもそのような姿勢が望ましいとの考えを持っていたことがある。
結論から言うとそれは誤っていた。
自死された方との違いは、「頑張っている自分」に酔っていたのと、なんだかんだ（仮眠とか、ちょっとしたサボりで）休んでいたからだと思う。

毎日16時間からそれ以上働いていたが、客観的に見ると本当に生産的なことができたのは8時間以内で、もっというと最高の集中力を発揮できたのは5、6時間だったと思う。
残りの時間は、何かを待っていたり、無駄な会議（ほんとうなら自分は必要のない会議）に参加したり、実質的には何もしていなかったように思う。PCの画面をぼーっと眺めているだけの時間もあったように思う。無理に長時間何かをしようとしても思考力が低下しているので、ミスも多くなりミスをカバーするためにさらに時間を要するという悪循環に陥った。

ITの（あるいは日本の）世界では、何も生み出さなくても頑張っている姿勢を示すことが大事という風潮があるように思う。本来合理的な活動であるはずの会社（あるいはプロジェクト）において非合理的、非科学的な行動規範を求められるのは馬鹿げている。
（長時間労働を強要し、ましてや残業時間のごまかしなどが行なわれている。ブラック企業とか聞こえよくいうが、違法行為である）

なので30代後半からはなるべく長時間労働をしないようにしていたが、それでも周辺からのプレッシャーと自分への過信と（信頼されていることに対しての）自己満足で長時間労働してしまったことがある。結果的には体調を崩してしまった。崩した結果、プロジェクトを休んだりしてしまった。休みを含めた平均労働時間は、8時間を確実に切っている。ならば最初から長時間労働しないほうがよかったのではないかと思う。休めば急に人がいなくなるので、代わりの人を探したり、代替要員の新たな学習コストもバカにならない。
※補足すると思い返すと「信頼」とは聞こえが良いが、実際には「お前が働かないと俺が困る」という利己主義に基づくもの。

無能な管理職で「プレッシャーをあたえると生産性があがる」という奇妙な考えを持つ人がいる。そんなデータはどこにもない。
おそらく「火事場の馬鹿力」のような考えなのだとは思うが、ITプロジェクトは、日々続く普通の経済活動であり、「極限状況において、人間がごく稀に発揮する力」を期待するのは無能の極みである。※火事場の馬鹿力も客観的なデータがあるのかわからない。都市伝説ではないかと思う。自分自身は、高いプレッシャーの環境下でいつもより良いパフォーマンスを示せたことは無い。（低下するほうが多かったように思う）
オリンピックのトップアスリートは、いかにリラックスするかを常に考えている。

プロジェクトで生産性を向上させるには、いかにコミュケーションをとっていくかの創意工夫が必要と考える。いわゆるアジャイル方法論が注目されるのもコミュニケーションを重視する方法論であるからだと思う。

ITに関わる方で（それ以外の業種の方でも）、ぜひ読んでおいて欲しいのが、

人月の神話（フレデリック・ブルックス）
ピープルウェア（トム・デマルコ）
アジャイルソフトウェア開発宣言※最後の2行をちゃんと頭の隅に置いておくこと

である。いかに長時間労働が、クオリティを低下させるかが見えてくると思う。自分はこれらを勉強することによって間違った考えを修正することができたように思う。特にトム・デマルコは自分にとっての神様みたいな存在（会ったこと無いけど著作を通じて）。

最後にトム・デマルコの著作　デッドライン（これも名著）から引用しておく、
”プレッシャーをかけても思考は速くならない”

至言であると思う。

NoSQLを勉強した

ちょっとかじった程度で曖昧にNoSQLを理解していたので勉強した。
SQL（というかRDBMS）については、これまでそれなりに実務でもやっていたので理解しているつもりではあった。

これまでのイメージでは、NoSQLとは、

1. ACIDを保証しない。
2. リレーショナルな関連付けとデータの最適な保持（正規化）ができない。
3. 便利なSQLを使えない。
4. ただし高速らしい。

とわりとマイナスのイメージから理解していた。当初は、Hadoopあたりから発展した技術と勝手に考えていた。すなわち巨大データを（ペタバイトとか）をつかって分析を行うためによみ出しを重視して、ACIDを保証しないという理解をしていた。

今回勉強してもその理解は、あまり変わっていなくて「本当ならRDBMS(SQL)で間に合わせたいが、データが巨大すぎ、そのうえで高速な処理を求められるため泣く泣くRDBMSの利点をすてて、要件を満たす技術を作り出した。」

という理解です。

近年、クラウド技術が発展して、かつRDBMSもインメモリで動くようになっています。1クライアント（トランザクションといったほうがいいのかな）が1データ（ROW）を読み書きするだけならば、そして、蓄積された巨大データは別途分析するという要件ならば、

NoSQLという選択になるのかもしれませんが、上記のようなクラウドやRDBMS自体の発展に伴い、使用する局面は少なくなってくるのではないかと考えました。（複雑に絡み合うデータを取り扱うケースのほうが圧倒的に多いと考える）

ちなみにポケモンGoはGoogle Cloud Platformで動いているとので、選択したデータベースは、MySQLの派生DB(Google Cloud SQL)かなあと想像する（カスタムで全然別のデータベースも導入できるとは思うがスケールさせるのが大変そう）

NoSQLも大別すると４種類くらいのタイプがありそれぞれ得意不得意がある。

1. キーバリュー型：とにかく早い
2. カラム型：列単位でのデータ操作が得意
3. グラフ型：グラフというのは、関係性の意味で、複雑な関係性の検索・分析などリレーショナルデータベースで表現できないぐらいの関連付けをデータに紐づけられる（例としては道路網における最短ルート探索とか）
4. ドキュメント型：定型的な構造を持たないデータベース（Row毎にデータ構造を変えることができる）

なので要件によってNoSQLを使用していくことも十分考えられるが、既存のRDBMSがNoSQLの機能をどんどん取り込んでいっているので、先行き不透明という印象を持った。

しかしながら、調べていくうちに例えば、Radis（キーバリュー型にちょっとドキュメント型風味）、Cassandra（カラム型）、CouchDB（ドキュメント型）とかに興味を持った。

あとMongoDB（ドキュメント型）も人気があるようだ。

自分は元々オラクルやサイベース（懐かしい）を使ってたのでやはりSQLに親しみがあるが、上記のDBたちも少しづつ触ってみて評価できるようになりたいと思う。

ITシステム開発のミニマリズムとリリース（過去のプロジェクト振り返りその12）

今回は、ITシステム開発におけるミニマリズムについて書く。

ソフトウェアプロジェクトサバイバルガイドによると
"ソフトウェアプロジェクトで開発に成功するためには、ソフトゥアコンポーネントとその機能の複雑さという点について、要求定義時からリリースまで「単純なほど良い」という方針が必要である。"
とある。

自分は、古い業務システムをリプレースするプロジェクトが多かったが、古いシステムとなると過去のいろいろな経緯（機能追加の蓄積等）によって、どうしても置き換える新しいシステムは複雑になりがちである。その場合、自分はシステムの断捨離を推奨する。過去に組み込まれた多くの追加機能のほとんどは、ちょっと便利な機能であり、システムの根幹を左右するほどの機能はほとんどない。
いまだ人間は非常に優秀なシステムの一部であり、追加機能に100人月かけるならば、2人の人間の手作業でしのげないかどうかを検討するべきであると考える。

ただプロジェクトを実際にやっていると、そうは言ってもということがよくある。しかし最終的にリリースするソフトウエアが複雑であっても。最初のフェーズは単純に作り、その後、機能追加していくフォーズを設ければ良いと思う。つまり最終的なリリースとコア機能の構築フェーズ、追加機能の構築フェーズを切り離し、何段階にも分けて開発・テストを繰り返せば良い。

特にウォーターフォール開発では最初に（しかも短い期間で）、すべての機能要件の詳細をつまびらかにしなければ、次のフェーズに移れないという考えがあるが、そんなことは人間には無理である。

1. コア機能の要件と理解
2. コア機能の開発・テスト
3. コア機能を踏まえた上での追加機能の要件の検討
4. 追加機能の開発・テスト
5. 繰り返し
6. リリースタイミングは、ユーザーが追加機能の充足度から判断して決めれば良い。
• 永遠に開発し続ける可能性もあるが、どこかで割り切ってリリースするはず。

おお！アジャイルっぽいとも思ったが、ちょっと違う気もする。アジャイルは早期リリースを重視するんじゃないんだっけ？？

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. リスク対策

ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。（血判状的な）※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。

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