(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. まだこれからの技術なのであまり複雑な処理には向かないかもしれない。

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