(IT?)コンサルタントにプログラミンング知識は必要か？

この間古巣の元同僚と飲む機会があった。この春に入社したばかりの新人四人を連れてくるというので、「よろこんで！」と返事して飲み会に行った。

古巣は大手SIerで様々なことをやっている。同僚は偉くなってしまって主に管理とかプロジェクトのPMとかをやっている。同僚のもとに配属された新人はOJTでプロジェクトにアサインされているが、本来はコンサルティング部門なのだそうだ。コンサルティングと言っても様々で具体的になんのコンサルティングかはその場では聞かなかった。（自分もコンサルティング部門にいたが、その時は主としてIT技術のコンサル（導入技術のメリットデメリットとか）をやっていた。）

飲み会の場で、新人の一人から、「上司からJavaを覚えろと言われて本を買ったんですけど、プログラミング技術とかコンサルタントに必要なんですか？」と聞かれた。元同僚は、「必要ない！」と断言していたが、自分は、「完全に習得しておく必要はないけど、初歩を覚えておいて損はないんじゃない？」とやんわりと言った。

実際問題、同僚の所属するSI部門でも、WBSをかける人はいても、プログラミングのできる人はほとんどいない。（プログラミングは協力会社にやらせるから、いわゆるITゼネコンです。）自分も実務でプログラムを書いたのは、５年ぐらい前で、それも担当でプログラミングに秀でた人がいなくて仕方なく自分で書いたぐらい。

元同僚は、コンサル部門を営業サポート的に考えているようで、プロジェクトを取るまでがコンサルタントの役割と考えているようだった。実際は、ITに関するコンサルティングはいろいろな場面で必要で、プロジェクトの立ち上げからサービスイン、運用まで様々な場面でできることはあると思う。（言わなかったけど）

では、コンサルティングにプログラミング技術は必要かともし自分の後輩に聞かれたら真面目に「覚えなさい」と言うと思う。そのほうがコンサルタントとしての幅が広がると思うから。プログラミングのプロになる必要はないかもしれないが、「バグってなんなの？」とか「システム障害ってなんなの？」とか具体的に語れるようになるから。セキュリティのコンサルとかたまにあるが、このシステムはなぜセキュアなのかとかプログラミング（と関連技術）を知らないでどうやってコンサルするというのだろう。「このプロジェクトには問題があります」とか、「こうやってやるから弊社にお任せいただければ大丈夫です」とか具体的に語れないと思う。

あとプロジェクトは予定通り行けば１年後にサービスインだが、「サービスインに立ち会いたいです！」と言っていた。OJTは通常半年なので、普通なら立ち会えないが、自分はその新人に好感を持った。「コンサルタントとしてはそういうことに興味を持つのはだめなのかなあ」と言っていたが、そんなことはないと思う。その柔軟な考えを生かしてすごいコンサルになって欲しいと思った。

自分がサラリーマンをやめて、唯一残念なことがあるとするとこう言った新人を育てることができないことかな。

CoreOSを勉強した

遅ればせながらCoreOSを勉強した。

CoreOSとは、Linuxのディストリビューションの一つだが以下の特徴がある。

1. コンテナ（Dockerなど）を動かすために特化したLinux
2. そのため一般的な機能（コマンドとか）は最小限にされている。（ツールとか簡単に入れられない）
3. クラスタ機能を標準でもっている
4. 分散システムのためのツールを装備

なので、コンテナのためのOSなので、ここに巷に出回っているDockerイメージをぶちこめば、すぐに環境が構築できるはず。

ソフトウェア品質管理（変更管理とその発生源）について

現在、こういうことを聞く相手がいないためブログに書いてみる。

あるプロジェクトで、私は変更管理を担当していた。もともと変更がたくさん発生するのがわかっていたため、専任の変更管理の管理担当者としてアサインされた。実際担当をして変更管理プロセスを回してみると、もともと予想されていたより更に多く（おおよそ２倍）の変更要求が発生した。

もともとはこのプロセスはお客様のため（つまり開発途中で要求が詳細化、具体化されて、それが設計変更につながると予測されたため）に作られた。しかし蓋を開けてみるとお客様からの変更も予測通り発生したが、開発側からの変更が多数発生した。

開発側からの変更って何？って思われるはずなのでプロジェクトの構造を簡単に説明すると。

お客（自分はお客様側PMOの立場）-元請けSIer-２次受けSIer

という構造となっていた。あと変更管理といっても予算管理は別にして、リソース管理（受容工数に対して、変更を受け入れることができるか？また優先順位をどのようにつけるか？）に特化して管理を行っていた。

お客からの変更は予想通り、しかし元請けSIerから「これこれを修正したいので変更させてくだい」という依頼が大量に来た。
※お客と元請けは請負契約ではないので、リソース余裕は丸見えになっていた。前のフェーズの反省からあえて余裕をもたせていた。

おかしいと思いなぜ発生したのか簡単に分析してみた。当初は課題やバグ（もうテストフェーズに入っていたため。ウォーターフォールでテストフェーズでなんで変更フリーズできないとか言わないで察してください）から派生して変更になっているのかと考えたが、課題管理のプロセスからではなく、いきなり変更管理に飛んできていた。
テストをやってて網羅的にテストポイントがカバーできているなら、バグ由来の変更になるんじゃないの？（元請けが２次受けにバグとして対応依頼をできないため、予算は持ち出しで、リソースを使わせてくださいとプロセスに乗っける）

変更管理担当としては、

1. お客様の変更を優先したいが、開発側の変更（実際はバグ）を認めないとそもそもプログラムが動かない。
2. 今発生している分はしょうがないが、将来のフェーズに向けて対策を立てたい。
• お客様の変更要求に対してのリソース余裕をもたせていたはずなのに、それを食い潰したくない。品質が悪いなら品質担保のためのタスクを設けリソースを確保するべき。

と考えたので、お客様、開発側に上記2の提案をしてみた。

とすると「これからもテストはまだまだ予定されており、前フェーズより網羅的にテストする予定であるので新たなタスクは必要ない」

いやいや、変更は、ちょっとした打ち合わせ、有識者の気づきから発生していて、仕様（設計書）レベルのバグと考えていた、設計書の総点検をしたいぐらいであるが、そのことを主張しても結局は受け入れられなかった。

テストシナリオ（ケース）の組み立てを経験値に頼り、間違った設計書をもとにしているので、抜け漏れが発生すると考えて提案をしたのだが、本当はもっとうまい提案の仕方があったのだろうか？過去のタスクを否定することはタブーなのだろうか？

ITプロジェクトにおいて目標設定が軽視されることについて（過去のプロジェクト振り返りその4）

前回は、目標設定の重要性について述べた。
振り返ってみると、過去自分は10以上のプロジェクトに関わってきたが、目標が明確に設定されているプロジェクトはなかった。（目標を窺い知ることのできないほどの末端担当者の場合もあったが、それでも末端担当者でも目標を胸に刻んでプロジェクトを推進できるようにするべきと思う。）
直近のプロジェクトでは、当初目標設定がなされていたが、やはり時間とともに忘れ去られていったように思う。または、頭の片隅に目標はあったが、達成できないことがわかってしまってきたため、口に出すのがはばかられるようになってきてしまっているのかもしれない。

企業におけるシステムの導入、または刷新の効果は、結局のところお金に換算できる。（システムを積極的に止める（撤廃する）という事例は聞いたことがない。対象事業そのものが無くなるためシステムが必要なくなったという例は聞いたことがあるが）

XX費用の削減、XXの収益の増大、利便性の向上や作業の効率化という目標も結局のところ費用削減につながっていく（具体的金額目標を設定しない場合も多いが）

かつて、官公庁で業務・システム最適化計画というIT戦略目標策定のプロジェクトに携わったが、システムをいくら効率化しても部門単位で見れば要員の削減にはなるかもしれないが、公務員をクビにできるはずもなく、虚しさを感じた覚えがある。

目標は「金！」というのは、企業にとって至極あたりまえだが、「使って楽しい」システムも目標にできればと思う。AIに仕事を奪われると戦々恐々とするのではなくて、ともに素晴らしいサービスを提供できるような世界になればと思う。

まだ続く。。

開発環境構築でハマる（いきなり高い目標を掲げるのは悪い癖）

勉強のため、ちょっとしたプログラムを作りたいと思い取り掛かったが、ハマる。

やりたいこと

1. どこからでも環境にアクセスできるようにクラウド上に環境を作る。
2. ブラウザさえあれば作業できるようにWebベースのIDEを導入する。

やろうとしていること

1. クラウドは、Vultrを選択。これまでは、DegitalOcianを使ってきたが新たに使ってみることにした。理由は、Tokyoリージョンがあるため、アジアはシンガポールリージョンしかないDegitalOcianよりレスポンスが良いかなと考えた。（ただし出来合いのアプリケーションを一発で入れることができるのはDegitalOcian、インスタンスの作成とかスナップショットからのレストアもDegitalOcianのほうが気持ち早いかな）
2. ディストリはubuntuを選択。理由は使い慣れているから、CoreOSも使ってみたいけど。そこから覚え直すのかなあ。。
3. IDEはCloud9を選択。Amazonに買収されて話題だし、使い勝手が良いと評判。

１、２は超簡単。幾つか選択をしてボタン一発。SSHで接続する。useraddでユーザーを作ろうとするが、デフォルトで/homeにディレクトリ作ってくれなかったっけ？ディレクトリを作成。

３で、必要なもの。

1. node.js
2. python（2.7系列？）

node.jsのインストールはうまくいった。ubuntu16.04はpython3系列しかない？←いまここ

--追記--
やはり16.04からpythonは3系列がデフォルト。

-2016/7/26追記　ubuntu16.04にpython2.7を導入。
node.js + expressまで導入。

-2016/08/09追記
やはり思い直すし上記の環境は破棄することにする。

大規模プロジェクトは、なぜ大規模になるのか？

今回は、タイトルをテーマに書いてみたいと思います。

私は、大規模プロジェクトに参画することがおおかったのですが、たいていの場合数十億〜数百億というプロジェクト規模のことが多いです。半端ない金額ですがなぜこんな金額になってしまうのでしょうか？
人月換算はあまり好きでは有りませんが、10億円で一人月単価100万円（高い方と思います）で1000人月（本当は、HWやSWのライセンス費用等も含まれるので、こうはなりませんが）です。一人の人が83年間かけて達成するプロジェクトです。

以下に理由を列挙してみたいと思います。

1. 古いプロジェクトの刷新が多い（新しくて10年、古ければ数十年前のシステム）
2. よって当初シンプルだったシステムもその年数分の機能追加がなされ、複雑化している。
3. そのシステムを刷新する場合、その機能追加も含めたシステムの置き換えを図ろうとする。
4. よって旧システムの当初開発の費用＋経た年数分の機能の費用がかかってしまう。と考えます。（昔のシステムは、柔軟な機能追加を考慮して開発などしていない場合が多いので、システムが複雑化しやすい。）

では、どのように解決していくか？

1. 機能の８割はレアケースの処理のはずなので、バッサリと切り捨てる。
2. 切り捨てられない場合でも、機能の優先順位をつけ、当初サービスインのスコープから外し、その後速やかに随時機能を追加していく。

と考えます。一緒にプロジェクトをした外国人に言われたのですが、曰く「日本人はマニアックスすぎる」とのことでした。上記に示した解決方法は日本人の美徳と言われる丁寧さ、繊細さからは抵抗感があるとは思いますが、グローバル化の進むIT業界では、スピードがなにより重要です。

割り切る覚悟がIT開発プロジェクトに必要と考えます。

サーバレスアーキテクチャについて勉強した

最初にの言葉を知った時なんだろうと、？マークが３つぐらい頭に浮かんだ。

いろいろ調べていくにつれ以下のことがわかった。
※クラウドサービスを使う前提。

1. 一般的なWebのシステム構成としては、2層構造となる（アプリケーションサーバー（Webサーバー含む）、データストレージ）
2. しかしサーバーレスアーキテクチャでは、このうちのアプリケーションサーバー層が存在しない。
3. もう少し厳密にいうとアプリケーションサーバーは、（あたりまえだが）サーバーとして常駐し、リクエストを待ち続けている。よって常にCPU、メモリ等のリソースを消費し続けている。
4. サーバレスアーキテクチャによると、プログラムは常には起動していない。リクエストがあった時に起動され、リソースを消費する。
5. 代表的なサービスは、Amazon Lambda

※ただしサーバーがなくなったというよりは、サーバーの存在を意識する必要がなくなったという方がより正確らしい。

メリットは、以下のとおり

1. サーバーとして常に動いていないのでリソースを使わない（コストの削減）
2. スケーリングが楽（サーバレスを実現する仕組みのたまものだとも思うが、サーバー自体をリクエスト量に応じてスケールさせるにはそれなりの仕掛けを構築する必要がある）
3. サーバーがないのでサーバーの運用管理が不要（サーバーが死んでいないかを機にする必要はない）

デメリットは、

1. まだこれからの技術なのであまり複雑な処理には向かないかもしれない。

比較的、静的なリクエストの大量処理に向いているかもしれない。

ITプロジェクトにおいての顧客とプロジェクトチームの関係と成功の為の目標設定（過去のプロジェクト振り返りその3）

プロジェクト計画について引き続き書いてみます。

プロジェクトの立ち上げ時において、プロジェクトサバイバルガイドには

”顧客の権利章典

顧客は次の権利を持つものとする。

1.プロジェクトの目標を設定し、その目標に従ってプロジェクトを進めさせる。

一方

"プロジェクトチームの権利章典

プロジェクトチームは次の権利を持つものとする。

1.プロジェクトの目標を把握し、優先事項を明確にする。

と顧客側とプロジェクトチームを対にして述べ目標設定の重要性を説いています。

しかし自分が関わったプロジェクトは多くの場合、目標は曖昧で、かつプロジェクトの進行とともに目標は忘れ去られ、プロジェクトが終わること（プロダクトの完成）が目的になっていきます。

プロジェクトの目標設定は顧客側の責任ではありますが、「具体的」目標値とその計測方法はプロジェクトチームも共に考え決めていくべきと考えます。例えばシステムの導入によりXX億円の営業利益の増収とか。そして本当にそうなるかの検証も合わせて行わなければならないと思います。

例　コールセンター　プロジェクト予算1億円　期間１年　機能追加により応答率が30%向上する。これにより人件費が20%削減よってシステム導入後３年間で費用を回収し、その後は会社に利益をもたらす。　とか。

例としてはものすごく簡単に書きましたがこれを、決め、予測し、計測することは非常に難しい。プロジェクトは、常に変化し当初の予測値とずれていくため、例えば途中で予算が1.2億になり、期間が15ヶ月になった時には、本来目標も修正していかなければなりません。

続く。。

ブロックチェーンについて勉強した。

話題のBitcoinと関連技術のブロックチェーンについて勉強した。
主としてブロックチェーン技術について記載する。

ブロックチェーンとは、

1. ネットワークを利用した改ざんが困難かつ、堅牢性（システム的に非常に障害に強い）の高い「台帳の仕組み」
2. なぜ改ざんが難しいか？データの変更の履歴をすべて保持するから（単純に変更履歴を持つと膨大なデータ量になるが、最新技術により過去履歴をそのまま保持するわけではないと理解（ハッシュデータとして保持））
3. 一回のデータ変更と一つ前のデータ変更履歴のかたまりをブロックと呼ぶ。
4. ブロックが連続してつながる（チェーン）ことによりデータの一貫性を保つ、よってブロックチェーンと呼ばれる。
5. なぜ改ざんが困難なのか2？改ざんを行うためには、チェーンのつながり全てを改ざんしなければならないから。
6. また各ブロックは、ネットワーク上に分散して保持されている為（いわゆるP2P）中央サーバー型のデータ保持が一つのサーバーをクラックし、改ざんすれば良いのに比べ、データの改ざんが非常に困難。
7. 各ダータ変更は分散されたコンピューター上で検証され（つまり複数の検証）正当性を担保する。
8. また各ブロックは公開鍵秘密鍵方式による暗号化技術をもって署名される。

よって、非常に堅牢かつ安全な台帳を構築することが可能となる。

ただし、欠点もありデータの検証には多大な計算が必要となる。その為の分散技術でもある。

ブロックチェーンの具体的な実装はBitcoinであるが、仮想通貨を安全に運用する為には、上記の技術がバックグラウンドとなっている。（チートによって、仮想通貨が無限増殖したりすると、信用を毀損する）

そしてこの技術が注目されている理由は、ありとあらゆる「台帳」にこの技術を用いることが可能な為である。ちょっと想像するだけでも在庫管理、株の取引、会計管理もろもろありそうである。特に金融機関からこの技術が注目されているらしい。

今日の疑問1 個々のデータの正当性は担保できるとして、データ全体の統計はどのようにとるのか？（例えば今日現在の全世界でのBitcoinの総額）

ITプロジェクトの成功率（過去のプロジェクト振り返りその2）

第1章の冒頭に以下のように書かれている。

/*
ソフトウェアプロジェクトが完了段階まで存続できる確率は、多くの場合、低い。
*/

Yes!そのとおり、プロジェクトの完了をどう定義するかによってその確率は変わってくるが、自分はプロジェクトの開始当初の予算、期間、効果（期待されている機能、それにともなう事業目標）が+-30%の誤差で達成できれば完了（成功）と考える。

※1 予算と期間については、マイナスの誤差は、経験したことがない。また効果についてもプラスの誤差は経験したことがない。この経験を覆す事例を知りたい。（雑誌取材とかに話している効果は大体盛ってますからね。）

※2 本の中では+-10%で成功と書かれていますが、そんな難しいこと無理ですと言いたい。これも事例があったら知りたい。

/*
しかし、この確率の低さは必然ではない。ソフトウェアプロジェクトを完了させるための第1歩は、プロジェクトを正しい手順を踏んで開始することにある。きちんとした形で開始できれば、単に完了できるという以上の単に完了できるという以上のメリットが得られる
*/

これもYes!そのとおり、プロジェクトの困難さの大部分は開始時にあると考える。開始時の条件が間違っていると以降の工程でいくら努力改善しようとも、そのプロジェクトは、よれていく、最後には何のためにプロジェクトを推進しているのかわからない状態に陥る。（責任を取りたくない人がいる。間違いを道めたくない人がいる。そしてなんとプロジェクトが混乱した方が儲かる人がいる。）

※ここにビジネスチャンスがあると自分は考える。具体的には、別途述べる。

Dockerを勉強した（その2）

昨日書いたことに間違いがあったので、まずは訂正。


3．コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）

→といった使い方は、あまりしないらしい。Webサーバーで1コンテナ、アプリケーションサーバーで1コンテナというふうに分割して運用するのが普通らしい。

そして昨日の疑問、

疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか

→独立したプロセス空間、ネットワーク空間を提供する。（アプリケーション側からは一見１つのOSとして見える。OSより下位レベルのシステムコールとかはできないんでしょうね）

疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？

→仮想ブリッジと仮想ネットワークインターフェースによってネットワーク差異を吸収する。（すごいぜ！）

その他
コンテナ自体の冗長化（クラスタリング）技術は、まだ発展途上にあるらしい（ほんのつい最近そういった技術が発表されつつある）
とすれば、大規模サービス（ブラウザゲームとか）は、OSレベルで冗長化して、その上にコンテナをいくつも載せていく構成になっていくのか？
自分は、これまでレガシーシステムの刷新を多く手がけてきたので、これら技術の基幹システムへの導入例は不勉強にして知らない。このような技術によって大企業の多くが悩んでいる迅速なサービスの提供が可能になる気がします。

Dockerを勉強した（その1）

Dockerについて全然わかっていないので、まずガバッと勉強することにした。
有識者の方には何言ってんだこいつと思われることもあるかもしれませんがご容赦を。

まず今日理解したこと。

1. Dockerとは、コンピューターの仮想環境を構築する仕組みの１種である。
2. Docker（という仕組み）の環境の一つ一つをコンテナと呼ぶ。
3. コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）
4. コンテナとは、OSを仮想化するわけではなく、アプリケーション実行環境の仮想化である。（今日の疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか）
5. コンテナは環境依存しないので、開発環境で作成したアプリケーションをそのままデプロイすればそのまま動く（今日の疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？）

Dockerの利点

1. 上記と重複する部分があるが、開発環境と本番環境の差異（CPU、メモリ量、ディスク量などは当然差異がある。しかしそれらはスケーラブルであることを前提にした作りにしておけば良い？）がないはずなので、開発環境のアプリケーションを本番環境にそのままおけば動く（はず）

その他（感想とか）

1. コンテナ技術は、Docker以外にもあるが現在はDockerが主流。
2. 仮想化技術の進歩は目覚ましい。コンテナ以外にも新しい技術がたくさん生まれては消えていっている。過去に確かSun Microsystemsが夢見ていた、どこでもなんでも同じように動く世界がだんだん実現しようとしてきているのか？

ソフトウェアプロジェクトサバイバルガイドというITプロジェクトにおけるバイブル（過去のプロジェクト振り返りその1）

これまでの仕事を振り返るにあたって、なんの軸もなしに書いてしまった場合、ただの愚痴の垂れ流しになるので、
我がバイブルであるスティーブ マコネル著作「新訳ソフトウエアプロジェクトサバイバルガイド」にそって過去を振り返っていきたいと思います。

章立ては以下のとおり

出展　著者Steve McConnell　「新訳　ソフトウェアプロジェクトサバイバルガイド」
ISBN4−89100−476−2

"
第１部サバイバルの心得
ソフトウェアサバイバルテスト
サバイバルの概念
サバイバルのためのスキル
成功するプロジェクトの条件
第２部サバイバルの準備
変化する目標への対応
暫定計画
要求開発
品質保証
アーキテクチャ設計
最終準備
第３部ステージ別納品の効用
ステージ開始時の計画
詳細設計
構築
システムテスト
ソフトウェアのリリース
ステージ完了時の確認事項
第４部プロジェクト終結後の作業
プロジェクト履歴
サバイバルメモ
"

プロジェクトの始まりから終わりまでのプロセスのチェック項目が網羅されています。
この軸にそって、ポイントを引用しながら、自分が経験したプロジェクトで過去何が問題だったか、どうすればよかったを振り返っていきたいと思います。

※2016/7/14　追記　著作権との関連でblogで引用する場合のルールを調べた。
基本的なルールは以下のとおり

1. 出典を明確にすること。
2. 引用する必然性があること。（長々と引用して、一言これってすごいですよね！というのはアウト。自分の考えを述べるために引用する。）
3. 自分の著述部分との主従関係（あくまでも自分の著述が主）
4. 引用部分を明示すること。

よって出典と引用部分を明確するようにした。

疑問点：blogは公開日記帳みたいなものであるため、必然性と主従関係をどう見るかが難しいように思う。日々積み重ねたblog全体としての必然性、主従関係と見るか、ある日の1postだけで必然性と主従関係を見るか？前者と考えるがどうか？

仕事を辞めました！その2

今回は、仕事を辞めた理由を書きたいと思います。

自分は、大規模プロジェクト（予算X億円以上）に関わることが多かったのですが、もしかしたら中小規模にも当てはまるかもしれません。多くのプロジェクトで以下のことを経験しました。（繰り返しになりますが、み◯ほには関わっていません笑）

1. お客様の社内の偉い人の政治的な力関係で物事が決まってしまう。（自分ではどうにもできない領域。特に雇われPMOとしては助言できる立場にない）
2. お客様のITリテラシーがあまりにも低い（情報システム部門なのに）
3. プロジェクト推進チームとしての一体感がなく、あくまで顧客とベンダーという立場（よって、やはり助言はあまり聞いてもらえない、お客の言う通り動け！）
4. 最初に書きましたが、政治的（というと大げさかもしれないですが）な力関係が、チーム内の担当者レベルにまで影響する。（上司の意向に沿うように動く人もいれば、反発して動く人もいる。いずれにしてもプロジェクトとして最適な行動とは別の論理でプロジェクトを推進する）
5. ベンダー側も責任回避の為（訴訟もありましたよね。ベンダー側が敗訴していましたが）、極力、意思決定をお客様に投げる（現在の状況を握りつぶすこともまあまあある。）よってプロジェクトとしての最適な判断ができないケースが多い（1〜4の理由により）
6. 実は、人月で仕事をもらっている限り、トラブルが発生すればするほど、ベンダーは儲かる（担当は疲弊しますが）
7. プロジェクトの進め方が少なくとも15年前から変わっていない。（自分が億円単位のプロジェクトに関わるようになったのが2000年ぐらいからなので、もしかするとそれ以前からかも）アジャイルが絶対いいとは言いませんが、WFでこの15年同じ失敗を繰り返しているのはどうなの？（一部CIとかは導入されつつありますが）※自分はアジャイル絶対主義には懐疑的です。
8. EXCEL絶対主義は、もういやだ。。（一部は、BTSとか導入されつつはありますが）

愚痴を垂れ流すときりがないですが、この辺で。上記のようなフラストレーションにより、上記のない世界へ旅立ちたいと考え、

1. 具体的なプロダクト（サービス）を提供する側になりたい。
2. プロダクトを構想する力を身に付けたい。
3. プロダクトを実現する力を身に付けたい。

ので従来の仕事の片手間で勉強していては、世の中の進歩についていけない。退路を絶って真剣に取り組みたいとプータローになった次第です。

※壮大なことを書きましたが、お試しでエロサイト作りたいんですよねぇ。

仕事を辞めました！その1

よく世間でブログネタになっている「転職しました」ではなく、しばらく仕事をしないことに決めました。ニートになります。

プロフィールを少々。1968年生まれ。

24の時に上京してきて、最初の会社はITとはあまり関係のない会社でした。

いわゆる総合職（人事部だった）だったのですが、そこで「これからはコンピューターの時代だから勉強してこい」と言われ社内情報システムに配属されたのが運の尽き。コンピューターに魅せられて、転職、転職、なぜかコンサルティングファームにヘッドハンティングされたり、そのときの上司に引っ張られ、また転職したり、上司とケンカをして独立したり。。。

30過ぎまでは、プログラミング（COBOLer。。Java）や設計（DB設計得意です！多分いまでも！）を中心にやっていました。

27の時に初めてPMとして小さなプロジェクトを任され、大赤字を出したことも今ではいい思い出です。コンサルタント時代は、お客様のIT戦略の立案、アーキテクチャ検討などを行っていました。また大規模プロジェクトのPMOとして参画することも多くなってきました。

そして、2008年に独立してからは、雇われPM、PMOとしての仕事が中心になってきました。

で、2016年6月よりロングバケーションに入ることにしました。

プロジェクトを抜けた理由は、プライベートな理由が主たる理由なのですが、しばらく仕事をしないと決めた理由は、

現在の大手企業さんにおける大規模プロジェクトの現状（あ、み◯ほには関わっていません笑）、PMOというお仕事（見てるだけ〜手を出してはならぬ）に嫌気がさして、「あ、こんなことしてていいんだっけ？」とちょっとカッコよく言えば自分を見直したいと思ったからです。

で、このブログをはじめた動機は、いい機会なのでこれまで自分が経験したこと、本当はこうすればよかったと振り返ったことを記録に残したいと考えたからです。

次回からは、その振り返りを中心に、これから勉強していきたい新しい技術を書いていきたいと思います。