MariaDBについて勉強した

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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