2016年12月4日日曜日

ExcelのCSVの取り扱いについて(苦労した)

テストデータを作っていて、苦労したので記録しておく。

バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて1万行くらいに増殖させようとしていた。CSVなので下記のような形。
(CSVにもいろいろ方言はあるが)

”ABC","¥123,456","XYZ"

みたいな形。

このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。

ABC,"¥123,456",XYZ

つまり

  1. 勝手にダブルクォートを削除する。
  2. 全部削除ならまだ統一感があるが、データ内にカンマ「,」が含まれているとその列のダブルクォートは残す。

テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。
小さな親切、大きなお世話だ。


2016年11月25日金曜日

MariaDBについて勉強した

久しぶりに勉強したシリーズ。
といっても前から存在は知っていて最近ちょっと使い始めたところ。MySQLは、オープンソースのデータベースとしてよく知られているが、サン・マイクロシステムズが、オラクルに買収されてしまったため、元々のMySQLの開発者が将来に懸念を抱き(オラクルは、オープンソースを潰すことで有名だ)、ソースコードをフォークして作ったRDBMSだ。

MySQLとAPIの互換性があり、ドライバなどはほぼそのまま使える。
オラクルだと有償の機能(スレッドプール)が、タダで使える。

互換性を意識しつつ、より良い機能という方針で開発が進んできたが、バージョンが上がるにつれて、だんだんと本家MySQLと機能差がでてきたようではある。

なぜMariaDBを勉強したかというと、再度RDBMSを勉強し直し、DOA(データオリエンテッドアプローチ)、データモデリングを勉強し直したいと思ったからだ。商用のデータベースにお金を払うほどお金持ちでは無いので、取りあえずオープンソースでと思った次第。取りあえずリレーショナルシップだけ実現できればと思って、調べ始めたが驚いた。

参照整合性制約
ストアドプロシージャ
トリガ
チェック制約
ドメイン(カラムに色々と制約を仕込むことができる)

などなど
普通に使いそうな機能は一通りあった。
20年前くらいにORACLE7.3を使っていたが、もうとっくにその機能は超えているのだろう。ガンガン使ってみてDOAを思い出してみたい。

2016年11月19日土曜日

IT開発におけるパフォーマンス問題について

最近また業務システムの設計をするようになった。
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか?それとも自分の考え方が間違っているのだろうか?確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか?

2016年11月13日日曜日

IT開発プロジェクにおける計画外のタスクについて

また、みずほ銀行の基幹システム開発が話題になっている。本当か嘘かわからないが、工数の9割が進捗会議についやされているという噂を見た。また進捗会議にむけての会議もあるらしい。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成(Excelのほうが作るのに便利だと思ったから)していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算(人かける期間)は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。

2016年11月11日金曜日

ITプロジェクトで失敗した時

当たり前のことだけれども人間だれしも失敗をする。その時どのような心持ちでいれば良かったかを書いてみたいと思う。なぜこのとこを書こうかと思ったかと言えば、最近自分はプロジェクトで小さな失敗をした。(正確に言うと失敗をしたかも知れないと思い込んでビクビクしていた)その時に冷静に考えて、なんで自分はこんなにビクビクするんだろうと振り返ってみた。
過去自分はプロジェクトの激務で体調を崩し、長期にわたって休んでしまったことがある。それは失敗をリカバリーしようとして激務に激務を重ねて結果的に体調を崩してしまった。
(もとからそのプロジェクトは失敗していたが、リカバリーせよとの指示を受けてプロジェクトに入った)
その時のトラウマがあるのだろうと思う。その時の自分は委任契約で大手ITベンダーに雇われていた。それなりに高給の契約ではあったが、契約上はプロジェクトの成否に一切責任のない立場のはずであった。
しかし実態はユーザーさんから毎日毎日「どうなっているんだ!怒」と責められ、どなられる毎日であった。しまいには「お前のせいでこれこれの金額分の損失を被った。どう賠償してくれるんだ!」と言われた。ベンダーのPMに相談したがなにもしてくれなかった。
また同じ立場であるはずの協力会社の人も責めてしまった。「なんでできないんだ!」とか「どうしてこうなった」と言ってしまった。
結局のところ「火中の栗を拾う」とは聞こえが良いが、「本当」の責任者は責任をとらず、委任契約である自分に便宜上責任を押し付けたのだった。
その時の自分は「プロジェクトを救う!」といった今考えると意味の無い義侠心にかられて、仲間を責め、自分を責め、プライベートもすてて頑張ったが、個人の力では限界もあり潰れてしまった。
委任契約で個人が受けるペナルティーは、契約を打ち切られる以外にはなく、責められるいわれもないはずである。
通常は契約の継続は生活の安定とリンクしているので、ついつい無理をしてしまいがちになる。とことん追い詰められると最後は「死」を意識してしまうまでになるが、サラリーマンと違って労災は降りない。残業代も契約上明記がなければ請求権はない。
なので心の安定を図る為、いつでも契約を打ち切られる(こちらから打ち切る)ことを念頭において仕事をしている。「信頼している」と言われてもその人は99%生涯の面倒は見てくれない。どころか半年先の約束でさえ平気で破る。なので戦国時代の武将では無いが、常に死地にあることを意識していれば、おのずと飄々と「責任逃れ」ができる。責任はないので責任逃れという言葉はおかしいが。
冒頭に書いたビクビクしてしまった理由は、昔の記憶が少し残っていたからだろうと思う。なので、何かあったらこのブログを見直して、これからも飄々とプロジェクトに関わることができればと思う。
委任契約の関係は、切るか切られるかしかないのだから。

2016年11月3日木曜日

システム要件の暗黙知化について(あるいは無知)

要件定義のポイントは、だれにでもその要件がわかるようにすることが必要と思う。文章でもいいし図表でもいいし確かにああそうだねと理解できることが必要。業務の流れ、データの流れ、インプットとアウトプットを明確に知りたいと思う。
しかし要件定義において良くあるのは、「現行通りにつくってください」ということがよくある。そのパターンが一番困る。現行を知るためには、無限のインプットのパターンとそのアウトプットを確認するか、何万行〜何百万行のソースコードをよむしかない。ソースコードの中にもマジックリテラルが仕込まれていて意味不明なことは普通にあり得る。

ではお客様はどのようにシステムを使って仕事をしているのだろうか?仕事のひとつひとつの意味を理解している人は少ないのかもしれない。企業は、一人一人の仕事の総体でお金を稼いでいるはずなのだけれでも、自分の担務の意味(特にシステムを使う意味)を理解している人は少ないのかもしれない。画面の文字の位置、帳票の文字の大きさには異常にこだわるのに、なぜその位置に文字がないと困るのか答えられる人はいない。

当初この文章を書き始めたのは、要件が属人化していてプロジェクト全体に共有化されにくいということを書こうと思った。その仕事のある領域では達人みたいなひとがいて、またそれを聞き取ったエンジニアも共有できる形に要件をまとめきれず、結果的に設計をするにあたって「聞き直す」しかない。「なんでそんなこともわからないのか?」「まえに話したはずなんだけれども」と怪訝な顔をされる場面が過去によくあったからだ。

しかし、よくよく考えてみると上段で書いたように実は「本当に要件を知っている」人はいないのかもしれない。細部にわたってこだわりがあり、何かを知っているように見えて、なぜそのような仕事の仕方なのかを理解している人はいない気がする。
したがって要件が不明なプロジェクトは失敗する。

※最後に「プロジェクトは失敗する」でしめるのが多くなってきた気がする。失敗シリーズとでも名付けようかな。

2016年11月2日水曜日

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

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

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

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

2016年10月30日日曜日

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

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

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

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

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

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

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

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

2016年10月21日金曜日

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

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

そのメリットは

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

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

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

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

2016年10月10日月曜日

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

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

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

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

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

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

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

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

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

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

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

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

至言であると思う。






2016年10月9日日曜日

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も大別すると4種類くらいのタイプがありそれぞれ得意不得意がある。
  1. キーバリュー型:とにかく早い
  2. カラム型:列単位でのデータ操作が得意
  3. グラフ型:グラフというのは、関係性の意味で、複雑な関係性の検索・分析などリレーショナルデータベースで表現できないぐらいの関連付けをデータに紐づけられる(例としては道路網における最短ルート探索とか)
  4. ドキュメント型:定型的な構造を持たないデータベース(Row毎にデータ構造を変えることができる)
なので要件によってNoSQLを使用していくことも十分考えられるが、既存のRDBMSがNoSQLの機能をどんどん取り込んでいっているので、先行き不透明という印象を持った。

しかしながら、調べていくうちに例えば、Radis(キーバリュー型にちょっとドキュメント型風味)、Cassandra(カラム型)、CouchDB(ドキュメント型)とかに興味を持った。
あとMongoDB(ドキュメント型)も人気があるようだ。

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




2016年10月5日水曜日

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

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

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

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

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

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


  1. コア機能の要件と理解
  2. コア機能の開発・テスト
  3. コア機能を踏まえた上での追加機能の要件の検討
  4. 追加機能の開発・テスト
  5. 繰り返し
  6. リリースタイミングは、ユーザーが追加機能の充足度から判断して決めれば良い。
    • 永遠に開発し続ける可能性もあるが、どこかで割り切ってリリースするはず。
おお!アジャイルっぽいとも思ったが、ちょっと違う気もする。アジャイルは早期リリースを重視するんじゃないんだっけ??


2016年10月4日火曜日

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. リスク対策
ぐらいかなと思います。重要なのは、この計画書に意思決定者、実行組織、関連組織が内容に同意し、ハンコを押すこと。(血判状的な)※未決事項があるならそれはそれで良い。未決であることが明確であることに意義がある。

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

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という考え方が生まれてきたのだと考える。


2016年8月31日水曜日

ITプロジェクトにおけるリスクマネジメントと人的資源の充足について(過去のプロジェクト振り返りその8)

今回はリスクマネージメント、および人的資源について述べる。
これでソフトウェアプロジェクトサバイバルガイドの一通りの設問の要点を述べたことになる。

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

プロジェクトの初期段階でリスクを見通した一覧が作成されることはまずない。(日本人の特性なのか?)希望に満ち溢れたプロジェクトの初期段階でリスクを列挙し管理していくことは、はばかられるのではないかと考えている。

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

25.とも関連するが、大規模プロジェクトにおいてリスクを洗い出すことは通常ある。しかし洗い出すのは担当者レベルであり、客観的にリスクを評価し対策を考える管理責任者を置くことは稀である。よってプロジェクト全体にかかわるリスクは放置されがちとなる。

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

ITプロジェクトにおいて大切な要素の一つは、全体を一貫した技術的考え方(アーキテクチャ)で統一し、その考え方に沿って以降の工程を進めていくことにあると考えている。しかしながら、営業が提案するBUZZワードがアーキテクチャであると勘違いされ、それを深める技術リーダーが置かれることは少ない。よって工程が進むにつれ、当初の技術的考え方は忘れ去られ、(または最初から全くないか)各サブチームはばらばらの方向に進むことが多い。

以上でソフトウェアプロジェクトサバイバルガイドのチェックリストのうち個人的に重要だと思われるものを抜粋し説明をすることは終えた。次回以降は、実際に自分が関わった2つの大規模プロジェクトをチェックしてみたい。

2016年8月30日火曜日

大企業の基幹システム開発における進め方のポイント

大企業の基幹システム開発における開発方法論(は関係ない?)
を書いたので、どのように進めればよいか考えてみる。

個人の力では個々人の意識改善、組織のあり方を変えるのは、ほぼ不可能ではあるが、理想がなくてはギャップも埋められないので、理想であることを意識して書いてみる。

個々のプロジェクトの性質に依存する事項ではなく組織の(および個人)のあり方について書いてみる。

では、まずネタとしてCIAの前身であるOffice of Strategic Servicesの作ったスパイに命ずる相手組織の撹乱作戦(Simple Sabotage Field Manual )の内訳を簡単に書く。(実際に第二次大戦時の機密文書として存在し近年公開されたらしい) 


・何をするにも「指揮系統」を主張し、意志決定を早めるためのいかなる抜け道も認めないようにせよ
・可能な限り物事は委員会で決定せよ。委員会は決して5人以下にしてはならない。
・できる限り本質的でない議題を持ち出せ。
・業務の承認手続きを複雑にせよ、どんなことでも3人以上の承認を得るようにせよ。

・ペーパーワークを増やせ。
・さほど重要でない仕事でも完璧さを求めよ。
・内容よりも手続きを重視せよ。
・やるべき重要な仕事をさておき会議を行え。



つまりこの逆張りをすればいいことになる。

  1. 組織のフラット化。
  2. 管理組織をコンパクトにする。
  3. 会議の数を最小にする。
  4. (正確さよりも)迅速な意思決定。

あと第二次大戦の時になかったのはITインフラであるが、使わない誰も見ない情報をITシステムに入力することを要求するということがよくある。そしてその情報の集計などの再加工させ報告を求められることがある。ペーパーワークを増やすことにも通ずるが報告書のなんと多いこと、またどんな状況報告であっても聞いて終わり、一緒に対応策を考えることはしない。

よって
  • 情報は、必要な人がITシステムから「自分で」取り出して加工して分析すればよい。
  • 報告を求め、問題点がある場合は一緒に考える。
も加えたい。

これらを心がけるだけで、プロジェクト開発はかなり円滑に進み、いたずらに巨大化しないのではないだろうか?





2016年8月25日木曜日

ubuntuへのnode.js、npm、expressのインストール手順(2016/08)

node.jsの練習のために多少調べたりして時間を食ったので、手順を記録として残す。
練習のためなので最新版は必要がないのでインストールの簡便さを優先した。

1.node,jsのインストール

sudo apt-get install nodejs

2.おまじない(nodejsをnodeにリンク)

sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10

3.npm(パッケージマネージャ)のインストール

sudo apt-get install npm

4.express(フレームワーク本体)のインストール

sudo npm install express -g

5.express-generator(スケルトンの自動生成機能と思う)

sudo npm install express-generator -g

以上で準備は整ったはず。

2016年8月24日水曜日

ITプロジェクトのコントロールや運用(過去のプロジェクト振り返りその7)

今回は、プロジェクトのコントロール(するための組織や運用)について述べる。

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

巨大プロジェクトにおいて役員が最高責任者となっていない場合は、少ない。しかしながら方向性や自身の意思を示すことは少なく、実質的には下から上がってきた方針を追認するするだけの場合は多い。神輿としての役員は置かれるが、意思決定の役目を果たすだけの見識を持つ役員は少ない。


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

プロジェクトの要所要所にチェックポイントが設けられることは多いが、上記のように明確なマイルストーンが置かれることもやはり少ない。また2択ではなく、3択(◯×△とか)が多い。チェックポイントも「XXの計画書が作成されていること」などと、中身は問われない。問題がある場合も「改善点はあるものの概ねOK」として△でお茶を濁す。そして最後の最後で大爆発する。

二者択一の明確なチェックポイントリストを一度見てみたい。。
(かなり細かく作りこむのかな?)

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

この制度が設けられているプロジェクトは残念ながら見たことがない。いわゆる「目安箱」制度だが、より現場の状況を把握するために良い仕組みと思う。過去一度だけ似たような制度が設けられようとしたが、組織階層外からの報告は良しとされず、結局お流れになった。

2016年8月23日火曜日

大企業の基幹システム開発における開発方法論(は関係ない?)

カンバン方式を勉強して、数百人から数千人及ぶ大企業の基幹システム開発に最新の方法論と言われるやり方が(部分的にでも)導入して、失敗しがちなプロジェクトの成功率を上げることはできないかと考えた。

しかし問題は方法論ではなく以下の点にあるのでは?と考えた。ウォーターフォールよりアジャイルがより良いかとかそういう問題ではないと考えた。

大規模プロジェクトの特性

  1. ミッションクリティカル(業務を止められない、止めるとしても時間を最小にすることが求められる。)
  2. 基幹システムなので、関連(連携している)システムが非常に多い。(数十〜)
  3. 関連システムが密結合で連携している。
  4. システムが多いので利害関係者が多い。
  5. 利害関係者は、システム部門間だけではなく、ユーザー部門も巻き込んで複雑な関係になる。
  6. (日本人の特性なのか?)失敗したくない。(評価方法が減点方式なのか?)

1.は方法論に関係なく、移行の仕方の難しさの話。
2,3.は密結合から近年の考え方である疎結合への移行の難しさの話。アーキテクチャをどう考えるかという技術の話ではあるが、プロジェクトの進め方の方法論とは直接関係ない。
※ここまで書いて考えたのが、作る対象のシステムが密結合から疎結合に変わっていくように方法論やプロジェクトマネジメントツールも密結合から疎結合へという流れになるのかな。依存関係は少ない方がもちろん難易度は低くなる。
4,5.は、アーキテクチャや方法論を超えて、もはや政治の世界になる。全員がハッピーになる方向などありえない。(PMにはその企業1番の実力者、といわれるのはそのためであろう。)
6.は(個人は、あるいは自チームは)失敗したくないのに、(全体としては)結果的には失敗する流れになってしまうという相反する結果を生み出してしまう。これも方法論とは関係ない。個人が成功するため(失敗しないため)には、他の人は知ったこっちゃないという考え方が生まれがちと考える。

よって方法論の良し悪しに関わらず大規模プロジェクトは失敗の確率が高いのでは?


ITプロジェクトにおけるカンバン方式について勉強した。

「カンバン」というと「トヨタ」しか連想されなくて、生産管理の手法と思いこんていたので改めて勉強した。

カンバンのポイントは以下のとおり
※ちなみにWikipediaは、難しすぎてよくわからなかった。

  1. この方式の導入の大きな目的は、プロジェクトの見える化。
  2. 何(タスク)を、いつまでに、誰が、今どこまで、を見える化する手法。
  3. 最低限、ホワイトボードと付箋紙があれば実行できる。
  4. (おそらく一番単純な書き方では)ホワイトボードに縦に3本線を引く。
  5. 左の列は「ToDo」何をするのかを付箋紙で貼っていく。
  6. 真ん中の列は「Doing」仕掛り中の付箋紙を「ToDo」から移動させる。
  7. 右の列は「Done」終わったタスクを「Doing」から移動させる。
  8. 付箋紙にはだれが、いつまでに、どんなことをするのかを書く。(はず)
  9. ホワイトボードではなく、コンピューターのツールを使ってももちろんいい。
    • チームの人数がすこし多くなるとその方が良いのだろうと思う。
上記は、単純なパターンだが列を増やしプロセスを細かくすることも可能。
上記をみて巷でいうチケット駆動では?と思ったがそちらも詳しくないので後日調べてみる。

しかしこれは自分が関わったような大規模プロジェクトでは、導入しにくいのではと思った。やり方に問題があるのではなく「見える化」を良しとしない人がいるためだ。表向きは、「プロジェクトなので見える化は推進されるべき」となるが、実際は見えると困る人達がいる。プロジェクトの進捗状況は、その人自身の評判や人事考課に関わってきたりする。なにしろ一目で「できない人」がわかってしまうので、日本人の性質なのか赤裸々にそれを明確にすることは難色を示されることがあるのではと感じた。

個人的には、ITプロジェクトにおける「できる」「できない」は、向き不向きの問題なので、赤裸々になっても恥じることはないと考えているが。


2016年8月22日月曜日

SEOの勉強会にいってきた

最初にSEO(Search Engine Optimization 検索エンジン最適化)の勉強会にいってきたので記録として残しておく。

全体は2部構成で
1.Webマーケティングの考え方
2.Google Analysticsの概要について
となっていた。2部はツールの簡単な紹介だったので省略する。

1部のWebマーケティングの考え方が非常に面白かった。
例えば、自分が有料自習室(最近は図書館で受験勉強とかしづらい)を経営しているとして、その宣伝のWebサイトにどのように誘導するのか?

カスタマージャーニー(顧客行動と訳すのかな?)という考え方で誘導の方法論をかんがえる。

  1. まず顧客像を定義する(ペルソナというそうだ)
    1. 例えば浪人生で集中して勉強する為の施設を探している(毎日喫茶店は高すぎる。また長時間いるのは気がひける)という人が顧客像
  2. 次にそのペルソナがとる行動を定義する(フェーズとタッチポイントという、行動の際に顧客がどのように思考するかも仮説を立てる。)
    1. フェーズ1 浪人生が自習施設を探す。
      • タッチポイント1 Webで、「自習室」「無料」「有料」「最寄の駅名」などで検索をかける。
    2. フェーズ2 浪人生がヒットした中でHPを開いて中身を確認する。
      • タッチポイント2 ヒットした中で上位のサイトを開き、自分の予算、駅近か?どうか、設備などを確認する。
    3. フェーズ3 実際に一度行ってみる。
      • 条件に合致していた場合、見学の申し込みをする。
  3. 上記は非常に簡単な例だが、フェーズ1、2においてどれぐらい顧客に訴求するか?また検索上位に位置するかがWebマーケティングのポイントとなる。
  4. 上記の例だと
    1. 自分が想定する顧客の検索にヒットしているか?
    2. 自分が想定する顧客が求める情報が自身のWebサイトに盛り込まれているか?
    3. をツールを使い分析していく。
なのでブログタイトル、副題、記事タイトルなどが非常に重要であるとわかった。
これまで記事タイトルは、漠然と書いていたところがあるので改善していきたいと思う。

※勉強会では触れられなかったが、どれだけ他サイトからリンクされているかも重要じゃなかったかな?


2016年8月19日金曜日

ITプロジェクトにおける計画立案(アーキテクチャとリソース計画)について(過去のプロジェクト振り返りその6)

今回は、計画立案の設問について述べる。

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

アーキテクチャをプロジェクト全体として共有することは重要である。しかし計画段階でそれを設定することができるプロジェクトは多くない。また実現可能性の高いアーキテクチャ(本を丸写ししたようなアーキテクチャではなく)を設計できる人も少ない。


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

20年前ならいざ知らず、近年は人的リソースについては、上記のことを考慮して計画することが多い。しかしながらそもそも「計画時におけるプロジェクト規模の見積もりの難しさ」という問題があり、余裕をもってリソース計画を立てたつもりであっても、結局工程が進むにつれリソースを食いつぶしてしまうことが多い。計画と実際の規模の間に借りが大きい場合は、そのプロジェクトはデスマーチとなる。

2016年8月16日火曜日

JSONを勉強した

Web越しのデータの受け渡しにJSON(JavaScript Object Notation)という形式が使われると聞いたので勉強してみた。かつてはXMLが主流とおもっていたのが、必ずしもそうではなくなったらしいので勉強しておかねばと思った。(特にJavasScriptを勉強するにあたって)

XMLは構造をあらわすのに便利な形式ではあるが、ちょっと冗長なところがあるとは思っていた。入れ子構造をあらわすには便利だと思う。しかし可読性はそれほど良くないところもあり、単純なデータ構造をあらわすためにJSONという形式ができたのではないかと思う。単純な設定ファイルなどのためには、XMLは大仰なのかもしれない。

JSONの簡単な記載例を以下に示す。

{
    "年齢":50,
    "住所":"東京都杉並区",
    "ペット":["犬","猫","猿","雉"],
    "既婚":false
}

左側にデータ名、コロンで挟んで右側にデータ値。超簡単ですね。
ペットの記載例のように配列も取り扱い可能。記載例には書かなかったが入れ子構造も可能な様子。(オブジェクトというものを使うのかな?今回は割愛)

確かにXMLよりは可読性に優れているように思います。
RDBMSでJSONをサポートしたというニュースを聞くのもなんだかわかる気がします。

2016年8月15日月曜日

SOAについて考えてみた

これまで関わった2つのプロジェクトで基本的なアーキテクチャにSOA(Service Oriented Architecture)を採用していた(とされていた)。

まずSOAとは、概念であり、技術や製品ではないと記述をあるところで読んで、ひっくり返りそうになった。

SOAの概念、利点は以下とおり。

  • 業務(領収書を発行する等)単位でプログラムを部品化し再利用できるようにして、システム単位のみならず企業単位で最適化を図る。(例えば組織変更によるワークフロー変更への柔軟な対応とか)もうすこし詳しく書くと、
      1. 業務の部品化する。
      2. 部品を組み合わせてアプリケーションを構成する。
      3. オープンな技術による(SOAP等)標準的なインターフェースを備える。
と理解した。

とすると、関わった2つのプロジェクトは、いずれも(かなり有名な)パッケージ製品を利用することが決まっており、外部からアクセスする為のAPIも当然備わっていた。それぞれのプロジェクトは、別途アプリケーションサーバーを立て、APIにかぶせる形でSOAサーバーを立てていた。(SOAは概念であるとするとSOAサーバーって変な感じ)
パッケージ製品のAPIは、部品化され標準にのっとったインターフェースを備えており、さらにSOAサーバーが必要な理由がよくわからなくなってくる。

真に企業においてSOAの概念が必要なケースは、全く新規にシステムを一から再構築する場合のように感じる。

つまりバズワードであるSOAを営業的に使って、SIerから余計にサーバーを買わされただけなのが真実なのだろうか?

Visual Studio Codeを使ってみた。

node.jsを練習するために、入力補完のあるEditorを使いたいと思った。
クラウド開発環境のCloud9は、結局インストールがめんどくさく諦めて、練習のための環境整備の為に労力を割くのもバカバカしいと思い、割り切ってローカルでIDE(Integrated Development Environment))を使うことにした。いろいろなIDEがあるが今回は新進気鋭のVisual Studio Code(2016/08/15 v1.4 Microsoft製OSS)を使ってみようとインストールしてみた。インストールは凄く簡単でだった。

余談だが商用のIDEも検討してみたが、だいたい300、400ドルもするので断念した。これだけの価格差の価値のある機能なのかわからずチュートリアルのためにそれだけの出費をすることは納得できなかったので諦めた。(グループワーク機能や各種フレームワークへの対応が充実しているように感じたが、チュートリアルそこまでの機能は必要としていない)

node.jsの入門本のチュートリアルをやってみるだけなので、とりあえず20行〜30行ぐらい編集できれば良い。なのでエクステンションはまったくインストールせずにそのままとりあえず使ってみた。4、5年前にはEclipceをPythonの為につかったことがあるが、そのときよりもかなり進化しているように感じた。(Pydevってエクステンションをインストールした記憶がある)

まずチュートリアルの為の簡単なhtmlを作成しておおっと思ったことは。

  1. 入力補完がずっと進化しているような気がする。
    1. カッコ(){}の補完が便利。
    2. タグの候補が2,3文字入力するだけで表示される。(タグ以外の文字列も補完してくれるのかな)
    3. Tabの段落下げをかなり自動でやってくれる。
  2. Terminalが内蔵されているので、エディタ内で完結できるので良い。
  3. ファイルブラウザ(エクスプローラー)がデフォルトで内蔵されている。
  4. 思ったよりずっと軽かった(Eclipceはかなり重かった気がする。昔いた現場では現場ではプログラマーは、ロースペックのPCでEclipceでJava開発をしていた。機能はともかく重くてしんどかっただろうなあ。)
まだまだ使いこなしていないが、いろいろ便利なんだろうな。手慣れたプログラマーにとっては基本的な機能でも、おじさんの手習いとして使うには凄く感動した。

2016年8月9日火曜日

Macにおける仮想化環境(VirtualBoxとParallels Desktopの簡単な比較)

最近Macを買い換えたので、移行アシスタントを使わずに新しいMacに一からソフトウェアをインストールすることにした。

旧Macでは、ちょこっとした仕事にOfficeを使う為、Parallels Desktopを買ってその仮想環境にWindowsをインストールして使っていた。ソフトウェアの見直しに当たってParallels Desktopを使い続けて課金するのもなあと思い始めた。よってかつて使い慣れたVirtualBoxに戻ることにした。そこでとことん使い倒しているとはいえないものの、両者を簡単に比較してみる。

Parallels Desktopの良いところ。
  1. (おそらく)パフォーマンスが良い。Macbook Airの1.7GHzで32bitWindows7および10がキビキビ動いていた。バリバリ3Dとかでなければ上記スペックでもゲームで遊べていた。Officeももちろん普通に動く。
  2. Guest OS(特にWindows)への対応が早い。
  3. 設定とか全然考えずにファイル共有とかクリップボード共有とかが出来ていた。

Parallels Desktopの良くないところ。
  1. メジャーバージョンアップ(MacOSのメジャーバージョンアップとタイミングはほぼ同じ。)ごとにバージョンアップの費用が五千円くらいいる。(バージョンアップをしないという選択肢もあるが、最新OSにだんだん対応しなくなっていく)
  2. なんか自社製品の広告が時々出てうざったい。(たまにだが)
  3. 設定は至れり尽くせりなのだが不要なエイリアスとか勝手に作ってくれたりする。
  4. クロスプラットフォームじゃない。(これは結構大きいかも)
VirtualBoxの良いところ
  1. ただ(USBまわりの機能拡張を入れると完全OSSではないが無料)
  2. クロスプラットフォーム(作った仮想環境を別のPCに持っていける)
VirtualBoxの良くないところ
  1. 新しいMacbook Proでは試していないが、過去の記憶ではゲームとか描画系が厳しかったのでゲームとか無理(と思う)
  2. 一時期オラクルがサボっていてアップデートが滞っていた気がするので、将来的に不安。
  3. 細かいところまでの設定が厳しい(Xubuntu16.04のインストールでは結局サウンドドライバ周りは切った)。HOSTとの共有フォルダとかは自分で設定が必要(その方が良いケースもあるが)
よって今回は、お金とクロスプラットフォームを取ってVirtualBoxにした。
あとOffice365を使っているので、Mac版の最新Officeをインストールできたのも大きい。
余談だがOffice365マジおすすめ。昔は互換性が悪いという話も聞いたが、今のところ問題ない。


node.js練習用開発環境を作成した

目的:できるだけ早く、お試しで単純なwebサービスを作ること。(内容はまだ秘密)

手段:開発言語は、node.js+express+HTML+javascriptでやりたい。

方針:なるべく手間をかけずに早くサービスを立ち上げる。

環境作成

  1. クラウドを使いそこにWebサービスを置く
  2. 開発は、ローカルでやるが仮想環境上に構築したい
  3. プログラムは、クラウドにファイル転送(SFTP)する。(ゆくゆくはrktとか使うか)
手順
  1. MacにVirtualBox(仮想化ソフト)をインストール。(手順は省略。)
  2. VirtualBoxにXubuntu(ubuntuの派生ディストリビューション。ISOが1G超えてる。。もうCDROMには収まらないのか。)をインストール。(手順は省略。理由は慣れているから。)
  3. Xubuntuにnode.jsをインストール(練習なので最新版でなくお手軽インストールを重視)
    1. sudo apt-get install nodejs
    2. sudo apt-get install npm 
    3. sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
    4. node -v (v4.2.6 20160809現在。練習なので最新でなくて良い)
    5. sudo npm install express
  4. XubuntuにVisual Studio Codeをインストール(新進気鋭のMicrosoft製エディタでコード補完機能も充実してそうだから)
  5. 続いてクラウドの設定、Vultrを選択(お手軽、東京リージョンがあるから。こちらからサインインしてもらえると。とてもとてもありがたいです。)
  6. クラウドにubuntu serverをインストール(慣れているから、インスタンスの維持は最低価格で月5ドル。インスタンスを破棄すれば課金されません。)
  7. rootしかないので、useradd -m hogehoge
  8. 上記の3.の手順でnode.jsをインストール
  9. XubuntuからSSHでクラウドに接続。

一応一通り環境ができたので、練習開始。

2016年8月8日月曜日

自動運転の自動車がする判断について

近年の技術の発展はめざましく、自動車の自動運転技術が競って開発されて実用化間近で、本当の路上での実証実験や運転者のアシスト機能として自動車にその機能が搭載されたりしている。最近、自動車の自動運転での死亡事故(テスラ)が海外であり、ちょっと思うところがあるので書いてみる。

自分も昔、自動車を運転していたためわかるのだが、自動車を運転していると色々な場面で色々な判断、選択をせまられることがある。前に割と早い速度でカーブを曲がるときに、急な土砂降りでできた水たまりの上に乗って制御不能になりそうな場面があったりした。

上の例は、単に自分のドライブテクニックの問題かもしれないが、自動車運転においてどうしようもない場面(急な飛び出しとか)は起こりうると思う。どうしようもない場面でそのときにとる行動は、人間の場合それぞれだ。

子供が急に飛び出してきた。そのときに取りうる選択肢の例としては、

  1. そのままブレーキは最大限かけるだろうが、まっすぐ進む
  2. 自分を犠牲にして横の壁に向かって激突しに行く
  3. 逆方向にハンドルを切る(ただしそっち側には老人がいる)
人間で自分のようにドライブテクニックもない場合は、だいたい1.しかできないのではないかと思う。テクニックのある人は2.を選択するかもしれない。さらにテクニックのある人は、1.2.3.のうち最大限人命を損なわない可能性にかけるかもしれない。(1.の場合は前方不注意になるんだろうなあ)

自動運転にすると、人身事故はすごく減るんでないかという話をきいた。スピードは必要以上に出さないし、パニックにならないし、蓄積された膨大なデータから最善の運転方法をとるだろうし。(ここで思いついたのが、自動運転ばかりだと、自動運転プログラムは自然と連携して動けるが、人間の運転者が一人でもいるとそれがノイズとなって、事故の確率が上がるというジレンマが。。)

しかし自動運転でもどうしようもないケースはあるだろうし、その場合上記も1.2.3.のどの選択肢をどのようにとるか、どうゆう風にプログラムされているのかは気になった。
確率で一番安全策をとるのだろうか?完全に同確率の場合、命の選択をせまられるが、命の重み付けをしたりしているのだろうか?老人は轢いてもよしとか。。道交法上は、運転者の命が一番軽い設定のような気がするが、そういうプログラムになっているのだろうか?

仮に誰が亡くなったとしてもその責任は運転者に帰すのだろうか?(テスラの事例は、自損で運転者の死亡だった)プログラムの判断ミスに対する責任は問われないだろうか?とすると自分でハンドルを握りたいなあと思った。

まあ飛行機はすでに離陸はほぼ全自動らしいけど。着陸は難易度が高くてまだプログラムには任せられないらしい。

--追記--
テスラモータースの事故は、横切っていたトレーラーに直進して追突ということののようだ。しかも制限速度違反で。自動追突防止装置は付いていたらしいのだが、まず制限速度も認識できない自動運転て怖いとおもった。


2016年8月5日金曜日

node.jsで’Hello World’してみた

初めてnode.jsを触ってみた。参考書に従ってインストールをしてHello worldしてみた。
node.jsの特徴は、

  1. サーバーサイドで動くJavaScript
  2. 非同期処理(I/Oの結果を待たずに並列で処理を行う)
  3. シングルスレッド(マルチスレッドよりメモリ消費が少ない)
  4. イベントドリブン(リクエストがあったときだけ処理を行う)
    • ちょっとよくわからない常時起動してないってこと?
      • あとで掘り下げて勉強する

それにより得られるメリットは、
  1. 大量のリクエストをさばくことが可能
  2. リアルタイム処理に向いている(イベントドリブンのため)
    1. なんで?

node.jsのプログラムサンプル

"
//Webサーバーの定義
var http = require('http');

var server = http.createServer();
server.on('request',doRequest);
server.listen(1234);
console.log('Server running!');

//リクエスト処理
function doRequest(req,res){
 res.writeHead(200,{'Contnt-Type':'test/plain'});
 res.write('Hello World\n');
 res.end();
}
"

簡単すぎる。。上の10行でブラウザでhttp://localahot:1234/ でHello World!が表示される。

2016年8月4日木曜日

ITプロジェクトにおけるプロジェクトビジョンとビジネス要求について(過去のプロジェクト振り返りその5)

第2章のソフトウェアサバイバルテストにおいては、具体的な設問に答えていき、採点をしてプロジェクトの成熟度を図るようになっている。自分の経験したプロジェクトを採点するのは、「その12」ぐらいを予定している。

ここではテストの設問を引用しながら、内容について述べていきたい。


要求
1.明確なビジョンステートメントまたはミッションステートメントがプロジェクトで制定されているか。

これまで述べた通り、この設問に「はい」と答えられるプロジェクトは少ない。単にシステムが古くなり関連ソフトウェア、ハードウェアのサポート切れという場合も多いのではないかと思う。

"
2.すべてのチームメンバーが、ビジョンを達成可能であると信じているか?
"

1番目の設問とも関連するが、この質問に明確に「はい」と答えられる人も少ないはずだ。明確に決まってないからだ。「いいえ」または「しらない」という答えが多いのではないかと思う。
また日本人の特性かもしれないが、表向きは「はい」答える人も多いのではと思う。かっこいい錦の御旗に逆らえる人はそうはいないからだ。大本営に逆らえる人はそうはいない。実現可能なビジョンを考えるという点が、できているプロジェクトにはなかなか出会えない。外国のプロジェクトではどうなんだろうか?実現可能なビジョンがとてつもなく難しいように思える。

"
3.事業における便益を詳細に示し、メリットの測定方法を明らかにするビジネスケースを策定しているか。
"

これもこれまで述べてきた通り設定できているケースは少ない。

2016年8月2日火曜日

コマンドラインとGUIの狭間

当たり前なのかもしれないが、熟練者にとってはコマンドラインの方が圧倒的に早い。
最近は、ツールの入力補完も充実しているのでタイプミスも少ない。

しかし自分のような初学者だったり、手っ取り早くポチポチOKボタンを連打して環境を作り上げたい場合にはGUIがあればなあと思うことも多い。

自分は元々コンピューターの世界に入ったのはNECの汎用機からだったし、その後オフコンを使っていたりしたので、コマンドをタイプすることに大きな抵抗はない。

コマンド書いてバッチ処理は、いろいろメリットがあることもわかっている。しかし若い時はコマンドを(プログラミング言語も)覚えることは苦ではなかったが、もうおじさんになってきたので、コマンドの意味を覚えるのも一苦労。コマンドを意味を覚えるに当たって、マニュアルをにらみながらポチポチ打っていく根気が無くなってきたと思う。

一方GUIは、Windows3.1が最初に触ったGUIとなる。しかも昔でいう4GL開発(ボタンとかウィンドウをペタペタ画面上にはって、それぞれの部品(オブジェクト)に対してコードを書いていく。ちょっとしたカルチャーショックだった。

プログラムを書いていくのは仕方がないが、環境構築についてはもうちょっと楽にならないかなあと思う。思うような環境を作るためには、コマンドを何回も叩き、インストールを繰り返し、うまくいけばいいがトラブルが発生すると何が悪かったんだろうと、原因究明にすごく時間がかかったりする。ソフトゥエア間の依存関係が複雑になってきているからかなと思う。

またそれぞれのソフトゥエアのお作法というものがあり、それを覚えるのが大変だったりする。昔のようにCOBOL、JCL以上!という世界にちょっとだけ、戻りたい気もする。オールインワンでポチポチインストールすれば以上終わり、という商用製品に目がいったりする。当然今の方が断然自由度が高いが。今ではCOBOLでWEBアプリとか作れるのかな?明らかに向いてない気もするが。。

環境構築がうまくいかないのでちょっと愚痴ってみた。乗り越えなければならないハードルだけれども。

2016年8月1日月曜日

古いITシステムを捨てるということ

あるITシステムがある。
もう30年前にできたシステムだ。それを置き換えようと大きなプロジェクトが立ち上がる。大抵は失敗してしまう。失敗とは当初想定していた予算、期間をオーバーすることだ。

しかし機能が削られることは滅多にない。(品質が悪いことは、また別の話)

一戸建てに例えて考えてみる。

何十年か前、一戸建てを買ったとする。その後車庫に屋根をつけたり、壁を塗り替えたり、物置をつけたり、家庭菜園のための小さな畑を作ったり、時間をかけて住みやすいようにしてきた。

その後、家も古くなり買い換えることにした。次の家は最初から車庫に屋根は欲しいし、物置は大きいものが付いていて欲しいし、(あるのか知らないが)畑つきのより広い庭が欲しい。

一戸建てだと、お金を出すのは個人なのでお財布に合わせて我慢をするしかないことがある。しかしITシステムは、何十年かの間に積み重なった機能を捨てることができない。システム刷新をする場合にほんの小さな機能をあきらめることもできない。時代も変わり変化した業界についていくためには、その業界にあった、何十年か前とは違ったコンセプトでシステムの根幹を考え直さなければいけない。そのためには従来の機能の大部分を捨てるしかない。

「それでは困る」という人がいる。あの機能も、この機能もこういう理由で必要だ。いや困るなら人間が合わせればいいのだと思う。人間は超柔軟なシステムである。今までのやり方を変えればいいだけだと思う。あるいは我慢すればいいのだと思う。

ここまで書いてみて思ったのが。あれがないと困るという意見は、常に企業の局所的な部門、部署から発信されている。全体をみて判断をする見識、力をもつ情報システム部門(とCIO)は日本はほとんどないのではと思う。

よって「情報システムは企業にとっての力の源である」という考えを持たない限り、日本は企業内の情報化において常に遅れを取るんだろうなと考えた。

大規模プロジェクトにおけるPMというお仕事

ここではSIer側のPMOの仕事を語りたいと思います。
自分自身の経験では、大規模といってもせいぜい10億円ぐらいの規模のPMしかやったことはなくて、その時は導入するHWやSWが馬鹿高くて、プロジェクトメンバーはMAX20名といった具合の中規模プロジェクトでした(ORACLEがすんごく高かった気がする)

ですので、自分の経験としては語ることはできないのですが、予算規模数百億のプロジェククトにPMOとして参画したことは何度かあります。なので端から見ていた感想として述べるのですが。

小〜中規模プロジェクトだとPMはなんでもやらなければなりません。
(上記のPMの時は最初期のプロジェクトのコンセプトデザインの時から関わって、導入プロダクトを決めて、カスタマイズを行い、運用を決め、デリバリするというまさに上流から最下流までやらせてもらえた幸せなプロジェクトでした。それなりにしんどかったけど。)管理、設計、はてはプログラミングまで、をやることになります。

しかし大規模プロジェクトのPMとなると、全然別次元の世界で管理、管理、管理、報告、報告 & 報告といった仕事が中心になります。(そんななかでもプロジェクトの中に入り込んでいくPMもいるとは思いますが超大変と思います。)

管理と一口にいっても実際どんなタスクがどれぐらい進んでいるかさえ、超ざっくりとしか掴めなくて(細かく掴む暇がない。下からの報告が正しいのか検証する暇さえない。)
主としてお金の出入りの管理になります。(予算がどれぐらいあって、今どれぐらい使ってるのか。)また報告もそれだけ大きなプロジェクトになると大手SIerしか受けることができません。大きな企業となるとその内部も超複雑な官僚機構が存在していて、そこへの報告作業がとてつもなく大変になってきます。これは本当に膨大な資料作成を要求されます。資料作成の過程で、バックデータとして進捗資料とか細かいデータも入手するのですが、実際のプロジェクト運営のための進捗把握とは乖離していて、資料作成のためのデータという何をやっているんだかという作業になります。でもそれだけの資料を官僚機構は要求しておきながら何かを判断するわけではない。(プロジェクトの状態が悪くなった時の訴訟対策だったりするのでしょうが。。)
お客様むけには逆にざっくり資料で済んでしまうことが多い気もしますが。(金融とかだとちょっと違うのかな?)



書いていて昔のプロジェクトでリーダーをやっていたのにリーダー本業はそっちのけで、PMのため、本社官僚機構のための、「これからこれだけプロジェクト全体が悪くなっていくから、これだけ追加の費用が必要!」という資料を一生懸命作ったことを思い出しました。本来の仕事は、担当チームのプロジェクト実行のはずだったのに。。

また報告作業ともかぶりますが、調整作業も大変です。お客様からのクレーム対応、社内官僚機構からの突き上げ(もっと利益を!)、現場からの悲鳴(悲鳴の原因をキャッチアップする暇もないのに)

それだけ大変な担務であるにもかかわらず、サラリーマンである限りすごい報酬をもらえるわけでもない。(失敗してもペナルティもないけど)

端から見ていて思うのは、純粋なITプロジェクトとしての楽しみは少なく、大企業の中間管理職であることは変わらず。権限も少なく。個人的にはやりたくないなあというお仕事の一つです。




2016年7月28日木曜日

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

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

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

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

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

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

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

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

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



2016年7月26日火曜日

CoreOSを勉強した

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

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

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

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

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

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

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

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

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

お客(自分はお客様側PMOの立場)-元請けSIer-2次受けSIer

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

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

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

変更管理担当としては、

  1. お客様の変更を優先したいが、開発側の変更(実際はバグ)を認めないとそもそもプログラムが動かない。
  2. 今発生している分はしょうがないが、将来のフェーズに向けて対策を立てたい。
    • お客様の変更要求に対してのリソース余裕をもたせていたはずなのに、それを食い潰したくない。品質が悪いなら品質担保のためのタスクを設けリソースを確保するべき。
と考えたので、お客様、開発側に上記2の提案をしてみた。
とすると「これからもテストはまだまだ予定されており、前フェーズより網羅的にテストする予定であるので新たなタスクは必要ない」

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

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

2016年7月25日月曜日

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

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

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

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

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

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

まだ続く。。

2016年7月22日金曜日

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

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

やりたいこと

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

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

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

3で、必要なもの。
  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追記
やはり思い直すし上記の環境は破棄することにする。

2016年7月21日木曜日

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

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

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

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

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

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

  1. 機能の8割はレアケースの処理のはずなので、バッサリと切り捨てる。
  2. 切り捨てられない場合でも、機能の優先順位をつけ、当初サービスインのスコープから外し、その後速やかに随時機能を追加していく。
と考えます。一緒にプロジェクトをした外国人に言われたのですが、曰く「日本人はマニアックスすぎる」とのことでした。上記に示した解決方法は日本人の美徳と言われる丁寧さ、繊細さからは抵抗感があるとは思いますが、グローバル化の進むIT業界では、スピードがなにより重要です。

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


2016年7月19日火曜日

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

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

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


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


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

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

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


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

プロジェクト計画について引き続き書いてみます。
プロジェクトの立ち上げ時において、プロジェクトサバイバルガイドには

”顧客の権利章典
顧客は次の権利を持つものとする。
1.プロジェクトの目標を設定し、その目標に従ってプロジェクトを進めさせる。

一方

"プロジェクトチームの権利章典
プロジェクトチームは次の権利を持つものとする。
1.プロジェクトの目標を把握し、優先事項を明確にする。

と顧客側とプロジェクトチームを対にして述べ目標設定の重要性を説いています。
しかし自分が関わったプロジェクトは多くの場合、目標は曖昧で、かつプロジェクトの進行とともに目標は忘れ去られ、プロジェクトが終わること(プロダクトの完成)が目的になっていきます。

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

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

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

続く。。

2016年7月15日金曜日

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

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

ブロックチェーンとは、


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

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

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

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

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

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


2016年7月14日木曜日

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

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

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

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

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

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

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

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

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


2016年7月13日水曜日

Dockerを勉強した(その2)

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


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

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

そして昨日の疑問、

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

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

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

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

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


2016年7月12日火曜日

Dockerを勉強した(その1)

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

まず今日理解したこと。


  1. Dockerとは、コンピューターの仮想環境を構築する仕組みの1種である。
  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

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

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

※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. プロダクトを実現する力を身に付けたい。
ので従来の仕事の片手間で勉強していては、世の中の進歩についていけない。退路を絶って真剣に取り組みたいとプータローになった次第です。

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


2016年7月11日月曜日

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

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

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

30過ぎまでは、プログラミング(COBOLer。。Java)や設計(DB設計得意です!多分いまでも!)を中心にやっていました。
27の時に初めてPMとして小さなプロジェクトを任され、大赤字を出したことも今ではいい思い出です。コンサルタント時代は、お客様のIT戦略の立案、アーキテクチャ検討などを行っていました。また大規模プロジェクトのPMOとして参画することも多くなってきました。
そして、2008年に独立してからは、雇われPM、PMOとしての仕事が中心になってきました。

で、2016年6月よりロングバケーションに入ることにしました。
プロジェクトを抜けた理由は、プライベートな理由が主たる理由なのですが、しばらく仕事をしないと決めた理由は、
現在の大手企業さんにおける大規模プロジェクトの現状(あ、み◯ほには関わっていません笑)、PMOというお仕事(見てるだけ〜手を出してはならぬ)に嫌気がさして、「あ、こんなことしてていいんだっけ?」とちょっとカッコよく言えば自分を見直したいと思ったからです。

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

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