久しぶり

 久しぶりにブログを更新する。色々あったけど、Microsoft365を解約してドメインの退避先がなくなって一旦こちらに。

退避するにあたってDNSの設定を変えたけどムームードメインのDNSせっていが非常にわかりにくかったのでこちらに記録。

・MXレコード などで「@アットマーク」が使えなくて空白でいいことがわかるまで時間がかかった。

・SPFレコードで「"ダブルクォート」が不要だった。

 

結局、ヘルプデスクに聞いたけど、今やAIが返答してくれる。正確だし親切だしそういう時代なんだなあ。

クラウド時代のミドルウェア構成について（考え方の転換）

プロジェクトで色々経験して、最近思うことがあったので記録する。
また親しい人にもアドバイスを受けた。

今やっているプロジェクトは基幹系システムを刷新して、クラウド上に載せ替えるというものである。基本的には業務要件はAS ISのままで、それをクラウドに載せ替えるというものである。むろん汎用機からオープン系のシステムかわるので、言語が変わったり、アプリケーションサーバーとDBサーバーという今時の構成への変更はある。

自分の担当は、夜間バッチの部分で基本的にはJavaで作ることになる。

この夜間バッチが相当曲者で、これをJavaでやるとなると

1. DBからデータを持ってくる
2. データを加工する
3. データをDBにもどす

という順番の処理になる。汎用機時代はフラットファイルなので、夜間バッチには相当強くて、100万件だろうが200万件だろうが平気で処理を行う。一方オンライン処理には、それほど強く無いのではと想像する（今の時代のオンラインのトランザクション量は半端ないので、まえの現場は秒間200トランとか、、SNSとかスマホゲームはもっと多いだろう）

夜間バッチだと、30万件でもいま結構苦労している。（計算上で）

本当ならストアドプロシージャでやりたいのだが諸般の事情でそれはできない。

記録しておきたいことは、そんなことではなくて（関係なくはないが）、今まで自分はマイクロサービスというものに否定的であった。しかし現プロジェクトでいろいろ経験することで考えを改めることに至った。またアーキテクチャについても思うところがあった。

今のプロジェクトは、クラウドに乗せるといっても、基本的にはクラウド前のオープン系のアーキテクチャをそのまま踏襲している。

よってサーバーのインスタンスをクラウド上にいくつか立てて、それぞれをアプリケーションサーバーにしたり、DBサーバーにしたりしている。なので詳しいことは聞いていいが、アプリケーションサーバー間のロードバランスの仕組みを導入したり、DBサーバーをHOT-COLD構成にしたりしている。

当初はこれに疑問を持っていなかった。

しかしクラウドの利点の一つは、「スケーラブル」なことである。ロードバランスの仕組みや、DBの対障害性もクラウド側が機能としてもっている。

またクラウドの課金は、CPUの動いた時間である。（認識間違っていないかな？）

いまのお客様は、オンライン処理はそれほどでもなくて、夜間処理が非常にきつい。

しかしアプリケーションサーバーは、24時間動いている。すかすかの昼間も着実に課金されている。DBもHOT-COLD構成だが、COLD側もOSレベルでは動いているはずなので課金されることになる。

よって、クラウドにシステムを乗せるときは、できるだけ夜間バッチという考え方を捨てるべきとの考えに至った（そういうアドバイスを先輩にも受けた）

つまりできる限りCPUを効率的に使うため、

夜間バッチで行う処理は、マイクロ（でなくてもいいが）サービスで、バックグラウンドで個々のトランザクションで処理する。（集計できる形にまで、一気にオンラインで持っていって、集計とかだけ夜にする）

また少なくともDBサーバーを個々に立てるという考えも捨てるべきとおもったCOLD分のリソースがもったいない。クラウド側が持っているDBのサービス（Amazon RDSとか分散処理や、スケーラビリティもクラウド側が保証してくれる）を使うべきと思う。

本当にミッションクリティカルなシステムだけクラウド側の保証を超えて、独自の耐障害性の仕組みをADDするべきと考えた。

以上が記録したいことになる。過去の経験だけにすがって考え方の転換を図らないとすぐに知識は陳腐化するといういい経験になったと思う。

※ちなみに単純に仕組みを考えると単一の処理で200万回インサート文を投げることになるので、うまいこと考えないとと騒いでいたら。汎用機しか知らない人に、「200万件レコード追加するだけでしょ。そんなのなんでしんどいの？」と言われた。

レコード数６億件（RDBMS）

とあるシステムの設計をしていて、毎日30万件以上、月1000万件、年間１億２千万件、と試算した。少なくは無いがものすごく多いとも思わない。
５年分くらいはデータを保持したいので、６億件１テーブルに保持したいといったら、基盤チームからやめてくれと懇願されました。1レコードはそんなに大きくはないので1kバイトないくらい。仮に1kバイトとして、5年で大体600Gくらいかな。別にかまわないと思うのだけど。
6億件全体をこねこねすることもないのでパフォーマンスも問題ない。Insertもパーティショニングをつかえば問題ないと思います。
世の中的には、どうなんでしょうか？

AIの活用が今後増えていくと思いますが、そういった素データの保持が重要な気がします。今回のケースは本当に保持が必要か再検討しますが、600Gぐらいでうろたえるなと思いました。

RDBMSの機能と活用について

自分は、とある場所で勉強会を月１回主催しています。毎回色々なテーマで勉強をするのですが、その中で思ったことがあります。

アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。

今自分が直面している課題は、

何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。

要件はたったそれだけなのですが、実現にはいくつかのやり方があります。

パターン１　データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）

パターン２　データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）

パターン３　SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）

パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。

現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）

今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）

また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。

それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。

よって、今年の目標は、RDBMSを極めることとした。

2016年振り返りと2017年目標と予測

久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。

2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。

さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。

人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。

2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）

とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）

自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？

ExcelのCSVの取り扱いについて（苦労した）

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

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

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

みたいな形。

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

ABC,"¥123,456",XYZ

つまり

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

テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。

小さな親切、大きなお世話だ。

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

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

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

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

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

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

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

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

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

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

IT開発プロジェクトと軍隊（戦争）について

前にITプロジェクトと建築土木について書いたので。今回は、ITプロジェクトと軍隊（戦争）の類似について考えてみる。
似ていると思うところ。

1. 戦略と戦術がある。
1. 戦略目標は超重要。戦術レベルでいくら勝利しても。戦略的には敗北はする。
2. 大部隊を動かす。
1. 戦争にも大小あるが、総力戦になると数百万の人が動く。
2. ITプロジェクトは最大規模でも数万だと思うが、十分大人数。
3. プロジェクトのあるいは戦闘の初期段階では、情報が足らない。
1. ITプロジェクトの場合は、要求、要件が不明確。できないことも不明確。
2. 戦闘の場合は、敵の全容が不明確。現代戦ではあまりないのかもしれないが、味方の別部隊の動きも不明確（フォークランド紛争の戦記を読んで思いました。またしばしば味方への誤爆もあるから現代においても完全には相互連携は実現されていないのだと思う。）

戦略目標が重要というのは、これまでにも書いてきたので省略する。

戦術というのは、ITプロジェクトにおける各種方法論だと考える。戦略が破綻していれば、戦術（方法論）がいかに優れていても敗北する。

大部隊を動かすというのは、ITプロジェクトも軍隊も同じだが、（かってな思いだが）各々の兵隊が任務を達成して、それが全体の目的の達成につながるというのは軍隊の方が優れているのではないかと思う。ITプロジェクトにおいては、数千の人間がいても、そのうち何割かは何もしていないか、あるいは無駄なことをしているのを見てきた。

軍隊においてはそれはないと信じたい。なぜなら、少なくとも何かしていないと「死ぬ」から。（想像だが）軍隊においては個々の行動規範が明確化、マニュアル化されており、それに従った訓練がなされているから。千変万化する戦場において、（できるだけ）的確な行動を個人がするためには、それがマニュアル化と訓練が必要だと思う。

※なんとなく行動する軍隊とか想像できない。

ITプロジェクトでは、そのマニュアル化と訓練ができていないと思う。

各々の役割に対する行動規範が不明確で、また日々の訓練も出来ていない。大した研修もなしにOJTと称して最前線に投入されるのは、よくあることと思う。プログラミング研修などは、兵隊がライフルの撃ち方を教わるレベルであって体系立てた訓練とは言えないと思う。

ただし、ITプロジェクトは日々立ち上がるのに対して、戦争はそう滅多に起こらない。なので訓練の余裕がないのかもしれない。

また情報の不明確さに対しては、軍隊は情報をを重視する（どこに敵がいるかがわからないとお話にならない）ため、あらゆる手段を講じて情報を得ようとする。現代戦においては、「情報戦が勝敗を決める」とまで言われているようである。

ITプロジェクトにおいては、その情報を得て分析する努力が足りていないように思える。「見える化」が声高に言われて久しいが、見えた後の分析と行動ができていないように思う。事前に見えるようにもしない。（プロジェクト企画は常にバラ色の未来で、問題やリスクがあることを明記してあるのを見たことがない）

戦争においては、できるだけ本格的な戦闘の前に情報を得ようと、偵察を重視する。ITプロジェクトにおいても本格的なプロジェクト開始の前に「偵察」行動が必要なのではないか？それは、プロトタイピングかもしれないし、要求の分析、RFPをちゃんと書くことかもしれない。プロジェクト企画の段階で、「偵察」のプロが偵察行動を行うだけで、戦争に負ける＝プロジェクトが失敗することを防げるように考える。

ubuntuで新規ユーザーにsudoの権限を与えるコマンド

新規ユーザーを作成した後、sudoの権限を与えるコマンド。
（基本的にrootで作業したくないため）

一行だが
gpasswd -a username sudo
※usernameは任意のユーザーID