読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

家計簿アプリ業界について思うこと

暮らし

ここしばらく仕事にやる気が出ず、シロギス釣りばっかりやっていたら、ブログ更新もすっかり滞ってしまってました。

久しぶりの更新です。

 

 

いやー、家計簿アプリ業界、そのうち絶対にヒドい事件がおきると予想します - ツイナビ | ツイッター(Twitter)ガイド

個人で作っているサービスで仕方なくスクレイピングしているならともかく、法人として運営しているサービスなんだしきちんと金融機関に仁義通して金払って企業間連携用のapi利用すりゃいいのに。

2015/07/02 08:58

 

う~ん、家計簿アプリのチョンボなわけなんですけど、ブコメでは銀行側がミョーなとばっちりを受けておりますね。。。

なんていうか。。。微妙。

 

「金融機関側がAPIを用意」しても解決しない

金融機関がAPIを用意しないせいで家計簿アプリ側が「乱数表」情報を入力せざるを得ないって意見を結構な数見かけます。

でも、実際金融機関側でWEB-API用意したところで、認証のための情報は必要になります。

APIだからといって、認証を無くすわけには行きません。セキュリティホール作らないためにも、同レベルの認証が必要です。

 

となれば、ログインIDやパスワードなど、認証するために必要な情報を家計簿サービス側はもたざるを得ないわけで、結局のところいまのと同じ入力が求められるわけで。

 

スクレイピングでもAPIでも、情報加工のしやすさの違いはあれど、セキュリティ的にリスクになることについては大差がない。

 

本格的な問題解消にはならないかなと。

 

金融機関APIは実は存在する

と、色々書きましたが、実は金融機関はお客さんの資金情報や取引履歴などの情報を提供するためのAPIを用意していたりもします。

 

例えば、大和証券では、大和ネクスト銀行の預金情報を証券口座から参照したり、取引のための資金に使えたりします。

ダイワのツインアカウント | ダイワのサービス | 大和証券 というサービスです。

 

大和証券大和ネクスト銀行は同一グループではありますが、別会社別システムで構築されております。ファイアウォール規制のためです。

このため、上記のサービスを実現するためには、システム間をAPIでつなぐことが必要となります。

大和証券は「銀行代理業」を取得しており、大和ネクスト銀行と契約を結び、企業間ネットワークを通じて情報連携しているわけです。

 

まあ、こういった代理店向けのAPIをそこそこ金融機関は用意しています。

つまり、「金融機関はAPIを用意してない」ってのは正確ではなく、「誰かれ構わず利用できるAPIはないが、信用できる代理店と情報連携するためのAPIを用意している」というわけ。

 

 

家計簿アプリの問題

セキュリティの話から始まりましたが、ここまで書いた上で家計簿アプリの問題を考えてみたく。

 

なんで「ログインID」や「パスワード」等の機密情報が家計簿アプリでは必要なのかっていうと、「金融機関が提供する情報連携APIを使いたくなく、スクレイピングで対応したいから」

 

もうちょい言うと、情報取得の正規ルートであるAPIを使うためには銀行代理業や証券代行業務等の資格を取得するのが大変なので、ログインIDやパスワードを取得し、利用者個人になりすましてネットからスクレイピングで取得しようってわけですよね。

 

身も蓋もない言い方すると。

 

こう書くと銀行代理業とかの認可に敷居が高いせいじゃないか、なんて考える人もいるかもしれません。

でも、銀行代理業者の名簿を見ればわかりますが、個人や不動産屋などもいたりするようなものだったりします。

 

業者一覧 : http://www.fsa.go.jp/menkyo/menkyoj/dairi_a.pdf

 

銀行代理業者自体は敷居は個人でもとれるようなものですが、代理業者が顧客に損害を与えたら補填する責任が生じたりもする重いものです。

 

 

家計簿アプリなんていいつつも、実際には銀行口座の資金内容を見たり、取引を参照できたりするわけで実質的には代理店業務を行っているようなもの。

にも関わらず、金融代理店資格を取らず、金融機関のAPIではなくスクレイピングで対応するのは、万一の時の責任を負いたくないからって責任逃れと捉えられてもしかたがない。

 

 

ついでに言うと、ログインIDやパスワードを家計簿アプリにわたしてしまうと、預金保険制度(ペイオフ)の対象にならない可能性も出てきます。

ログインIDやパスワードを他者に知らせた場合、認証方法を適切に管理していないとみなされてしまうからです。

 

ネットバンキング「不正引き出し」2億円超 「消えたお金」を取り戻せるか? - ライブドアニュース

 

結局のところ、家計簿アプリ提供会社が、サービス提供する上で必要となる金融代理店となるためのコストを、利用者のセキュリティ上のリスクや、ペイオフ対象外になるなどの見えない利用者利益の削除などに転嫁していることになるわけで。

 

家計簿アプリがきちんとID管理できる人だけが利用するならまあいいか、といえるかもしれないですけど、テレビCMバンバンうっているわけで。。。

そういったカジュアルユーザーに、メリット以上のデメリットを負わせかねないってのはいかがなものかなあ。

 

まとめ

 

さて、色々書きましたが。

 

オッサンが思うに、スクレイピングで口座情報を取得、なんていうのは、利用者個人の裁量で行うべきで、法人化された家計簿アプリ提供会社は卒業しても良い頃でしょう。

 

そもそも、オンラインバンキング等へのアクセスは利用者本人がアクセスすることを前提に作られております。

三菱東京UFJダイレクト利用規定:三菱東京UFJ銀行

銀行のインターネットバンキングの利用規定を見てみれば、【本サービスの利用に際して使用できる機器は、当行所定のものに限ります】【本サービスのご契約をいただいた個人のお客さまに限ります。】なんて書いてあったりも。

 

個人の範囲を超えて、法人が自己のサービスとして利用するべき情報ではないわけです。セキュリティなど今後も問題が広がることは想像に難くない。

 

 

家計簿アプリ提供会社は、金融機関の顧客向けサービスに約款違反でフリーライドするといったグレーゾーンで活動するのではなく、代理店として責任を負い、正規のルートから情報を取得するようにし、正々堂々とサービスを提供するようにするべきじゃあないかな。

 

個人のサービスではなく、法人が提供するサービスとして。

 

きちんと金融機関と家計簿アプリ会社双方の利益になるようなスキーマを作るべきかなと。

 

以上

 

残された開発者が欲しかったもの

テクノロジー プロジェクトマネジメント論

4月ということで人事異動の時期。

新しい役職や環境で仕事をする人もいるかと思います。

 

 

オッサンも例に漏れず現在のチームから離れ、新しい仕事をすることになりました。

いや~、ここのところの人事異動がらみのドタバタでブログ更新をサボってました。

 

まあ、しばらくは引き継ぎのための現状維持なのですが。。。

まあ、過去何度もあった組織内組替の話なので、チームを離れること自体は特段異例の話ではないです。

 

問題は、残ったチームの方にありました。

 

残された開発者が欲しかったもの

自分の記事でも散々書いてきましたが、こういった突発的な異動に備えてドキュメントやシステムに関するノウハウについては、相当気をつけて残すようにしておりました。

人一人いなくなってしまってしまい、チーム活動が止まってしまうことは致命傷だから。

 

今回のチームでは従来のプロジェクトよりもずっと気をつけており、残されたメンバーは心配などしてないとおもいきや。。。いつもよりもずっと深刻に心配しているんですよね。

 

今回のチーム異動ですが、マネジメントしているオッサンを中心とした自社員メンバーが異動となり、パートナーさんだけが別の組織に移動となります。

マネジメント層だけがそっくりいなくなる形です。

 

実際の開発を行っていたメンバーがほぼ全員そっくりチームに残るわけで、一見、基本的な開発能力の低下はそこまでもなさそうに見えます。

もちろん、オッサン自身が抱え込んでいた要件、仕様などのノウハウもありますが、致命的なモノはドキュメントとして残している。

 

つまり、メンバーが心配しているのは開発力の部分ではないってワケですね。

 

 

チームに残してほしいもの 

 

さて、メンバーにヒアリングしてみると。。。どうも、チームの異動の仕方が心配と。

 

マネジメント層がそっくり入れ替わる、ってことは、新しいマネージャのやり方でチームは動く形となります。

となると、ドキュメントの考え方やソースコードに対する考え方、組織運営に対する思想も変更となります。

 

要は、

  • ドキュメント ・・・ 都度メンテナンス → ドキュメント不要。ソース見りゃいいでしょ。
  • テストコード ・・・ seleniumを使って自動でテスト → メンテが面倒。PrintScreenでエビデンスを貼り付けろ。
  • リファクタリング ・・・ 気にならなくてもこまめに改善。問題発生前に先手を打つ → 別に直さなくてもよし。困ったときに何とかすれば。
  • 進捗管理 ・・・ マイルストンが守られれば細かい進捗はあまり気にしない。ガントチャートでの進捗管理は面倒だし不正確なことも多いので不要。 → excelガントチャートで進捗度合い書け。定量で進捗率を出せ。毎日報告書を提出しろ。

などなどのような形で、今までの組織運営の考え方がガラリと変わったら。。。みたいなコトが心配ってわけですね。

 

これって、まあ言ってしまえば「プロジェクト憲章」を次のマネージャへ引き継いで欲しいって意味です。

 

 

ちょっとこれは意外でした。

今まではどちらかと言うと、要件や仕様と言ったナレッジをドキュメント化すれば引き継ぎメンバーはそこまで困らないで済むだろう、なんて考えておりました。それで上手くいってましたし。

でも、よくよく考えたら今までチームを離れた時って、長年一緒に仕事をしていたメンバーをリーダに引き上げてから引き継いでいたんですよね。

なので、気づかなかったのだろうな。

 

つまり、チームを維持するためには要件や仕様を残したドキュメントなどの「歴史」だけでなく、チームの活動の仕方や理念といった「文化」も残さなければならないってわけですね。

 

これって、Conwayの法則に繋がる話でもありますね。

 

まとめ

変化からは学びを得ることができますが、今回の組織異動についても改めて面白い発見をもらえたと思ってます。

まあ、せっかく育ててきたチームを手放すのは寂しいやら悔しいやらって気持ちもあるわけですが、そこから得られる学びがあるのであれば決して悪いことではないですね。

 

ところで、次の仕事がまだ決まらないのは気がかり。。。

個人の意志ではなく、人手不足な場所に回されることがよくあるのでどうなることやら。

 

もし営業にでもまわされたら、ブログ名を「営業ブログ」にでも変えるべきだろうか。。。

 

 

以上

 

 

リーンソフトウェア開発と組織改革

リーンソフトウェア開発と組織改革

 

 

 

 

 

なぜWEB系企業ではソフトウェアプロセス技術が流行らなかったのか

テクノロジー

 

ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのはてな

プロダクト特性にあわせ開発プロセスを定義する、成果物を定義する、開発手法と体制を編成するなんてblogに書くとたまに?な反応があるので納得感がある。web企業だとロストしてるのか。。。

2015/03/12 11:37

 

自分でコメントしたあとふと思うことがあったのでまとめ。

 

ソフトウェアプロセス技術とは

話の前提として、ソフトウェアプロセス技術を定義しなければ始まりません。

 

といっても、組織によって微妙に使われ方が違うのでアレなんですけど、ICSSPに則れば、ソフトウェア開発における開発工程(プロセス)の

を行う技法と思っていただければOKです。

 

要は、ソフトウェア開発工程自体の定義と分析、管理により組織やプロダクトにマッチした最適な開発手法を求める技法(メタプロセスマネジメント)と考えるとわかりやすい。

よく言われるCMMIは、上記のソフトウェアプロセスに対して、それ自体を管理するメタプロセスの達成レベルを問うものです。

 

ちなみに、プロジェクトマネジメントと混同されがち。でも、プロジェクトマネジメントでは契約やソフトウェアプロセスの範囲外で発生するリスク管理等の概念もマネジメントの対象としているので、共通の概念がいくつかある、ぐらいだったり。

 

あと、何故かソフトウェアプロセス技術=ウォーターフォール開発プロセスを厳格に守ること、と勘違いされがち。

うろ覚えなんですけど、自分の周りだとJ-SOX法で内部統制強化なんて叫ばれた時に「とりあえずウォーターフォールの開発工程ごとのチェックを厳格におこなえばいいんじゃね」ぐらいの感覚で管理統制を強化しようとして混乱した記憶があります。

この場合のソフトウェアプロセス技術は「管理」だけの話に留められることが多いんですよね。

 

 

なぜWEB系企業ではソフトウェアプロセス技術が流行らなかったのか

さて、ここについての考察ですが、残念ながらWEB系の組織に所属したことが無いため、直接的に理由を知ることができません。

なので、公開されている情報からソフトウェアプロセスの分析により類推してます。

 

 

1.自社サービスが中心で、そもそもプロセスを変える必要性が薄い

同じプロダクトであれば同一のプロセスを利用するのが最も理にかなってます。

したがって、受託開発のような案件ごとにプロダクトが異なる開発を行っているSIerを中心とした組織よりも、一点もののプロダクトを作っているWEB系組織ではプロセスを変える必要性が無いのでは、と思います。

 

2.扱うWEBサービスDOA型のモノリシックなアーキテクチャが多い

色々見聞きするWEBサービスアーキテクチャですが、大雑把に分類するとDOA型のアーキテクチャか、それに類似した形をよく見かけます。また、ドメインもそこまで複雑じゃないように見えます。このようなプロダクトでは、特段データの整合性など気にしなくても良いため、ドメインに応じたソフトウェアの修正、追加開発も端々に分散した形で実現可能だったりするんですよね。

それが丁度採用していたアジャイル開発とマッチしていたため、「プロセス自身を変える」という考えは生まれづらいのじゃないか、と思います。

 

実際、DOA型からSOA型/OOA型のmicroserviceといった分散アーキテクチャが採用されるようになってウォーターフォール型の管理が必要な事例*1がでてたりも。

氏の経験では、これを達成するための課題は、多くの組織がプロダクトマネージャや開発者、品質担当者などの独自チームで構成されており、何かを成し遂げるためには、多くのミーティングやウォーターフォールのアプローチを取らざるを得ないことだ。

マイクロサービスの現在

 

3.少人数内製が多く、「自己組織化」や「メンバーマネジメント」といった言葉で代替された

WEB系企業だと、内製が中心と考えてますが、こういった内製が中心なモノリシックな組織だと、組織をまたいだプロセスやアグリーメントを多人数でとる承認プロセスといったプロセスが発生しづらい組織構成になっています。

ステークホルダーが「自社の開発メンバ」以外にほとんどないのであれば、わざわざプロセス改善という考え方を導入しなくても「自己組織化」や「メンバーマネジメント」「チーム改善」等の考え方でも、組織活動を改善することができます。

 

 

とまあ、ざっくりとですが上記のような話がソフトウェアプロセスの考え方から導けます。

 

つまり、「当初から利用していたアジャイル開発がWEBサービス開発にあまりにもマッチしているため、プロセスを変更するという考えが不要だったのでは」と思ってます。

 

あとは。。。ただの個人の感想ですけどブコメとかブログとか見るに、志向の違いもある気がします。

ソフトウェアプロセス技術って典型的なエンジニアリング技術じゃあないですか。結構泥臭。

でも、ブコメやブログ見るにウェブ系のエンジニアって、エンジニアリング志向の「エンジニア」と言うよりか、テクノロジー志向の「テクノロジスト」に見える。

全員とは言わないけど、SIerよりは比率は高そう。

なので、ソフトウェアプロセス技術は忌避されがちだろうな、とも思いました。

 

 

なぜSIerではソフトウェアプロセス技術が職人芸となりがちなのか

では、WEB系組織では流行らなかったソフトウェアプロセス技術ですが、SIerで流行ったのか、というと微妙。

 

まず理解しなければならないのは、SIerで利用されているとされるウォーターフォールは既にウォーターフォールではないって事実です。

実際に、いろんな開発の現場を散々見てきましたが、名目上ウォーターフォール開発と呼んでいたものの、ウォーターフォール開発を厳密な意味で守っている開発の現場はとんと見たことがない。

 

実は、SIerでは「ウォーターフォールの裏プロセス」が存在してます。

オープン系の開発でウォーターフォール開発をし、それなりに成果を出しているように見えるプロジェクトには、いままで挙げたようなリスクをヘッジするための裏プロセスが存在する。

 その裏プロセスを表プロセス化すると、それはもはやウォーターフォール開発ではない。筆者の感覚でいうと、反復プロセスとも違う。一般的な裏プロセスを含むウォーターフォール開発は、並行開発プロセスのようなものに近い。

 

ソフトウェア開発の匠(3):「現状のソフトウェア開発は間違っていないか?」(プロセス編) (3/3) - @IT

 

まあ、昔からウォーターフォールウォーターフォール言われてますけど、やっぱり失敗することも多い開発手法なので、現場の知恵で案件に合わせて独自の開発手法として定義するってことが当たり前のように行われてます。

あるものはスパイラルモデルにそっくりだったり、またあるものはまんまアジャイルだったりと、現場現場に応じて使わけるのが当たり前となっております。

 

アジャイル開発の技術講習がアジャイルの専門家からされた時も、「それは今現在の開発手法と同じじゃないか」という感想がよくでるんですよね。そんなこともあり、オッサンの周りではアジャイル開発だとむしろ案件の大小・複雑さの変化に対して対応しきれない(アジャイルのアジリティの限界)ってことで積極的に採用されない場面もあるんですよね。余談ですけど。

 

つまり、ソフトウェアプロセス技術の中でも「プロセス定義」については当たり前すぎて技術としてあまり認識されてないって感じです。

 

じゃあ、SIerではソフトウェアプロセス技術を使いこなせているか、というとそんなこともない。

なぜそのプロセスなら成功するのか、どうしてそのような特殊なプロセスが必要なのか、を計測・分析してなかったりすることがほとんど。リーダやマネージャの勘だったりすることも多い。こういうのがSIerの秘伝のタレと呼ばれている技術だったりして、場合によっては「○○社が独自に定義した開発手法で、他社には真似できない」なんて呼んでいたりする原因だったりもします。

 

ちなみに、元記事にもあるように若手のうちはプロセスの「管理」を徹底的に叩き込む反面、「プロセスの構築」はプロジェクトリーダ以上から、「分析・計測」はそもそもやらないってことも多い。 

つまり、技術と呼ぶには中途半端で未成熟な場合が多く、あまり使いこなせてないなあって印象なんですよ。

 

ざっくりまとめると、全体的には「ソフトウェアプロセス技術は確かに存在し、部分的には使われているけど、メタプロセス管理の視点が弱く、工学的手法ではなく、職人技的手法となっている」って感じ。

 

ソフトウェアプロセス技術って結構面白い

 

まあ、ソフトウェアプロセス技術って「管理」だけの観点で語ると非常につまらないし、人によっては苦痛にしか感じないんですけど、「構築」や「分析・計測」まで含めると結構おもしろんですよね。

感覚的には、ソフトウェア設計に近いし、プログラミングの感覚に通じるところがある。

 

自分なりにはいくつかのプロセス設計パターンを作れたりもして、それらの中から比較的有効なプロセスを過去記事で紹介してました。

 

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

 

メタプロセス管理という考え方を持つと、上記のようなプロセス設計もできて面白いですよ。

 

 まとめ

 長い。ダラダラ書きすぎました。疲れたのでこのくらいで。

 

 最後に、元記事の内容に少しだけ触れておきます。

 

でも、すでにWebは成熟して、しかも作成するソフトウェアの規模が大きく複雑になっています。コンピュータの世界では完結せずに、外側の実ビジネスと連携することも多くなってきています。そうすると、あらかじめ決めることを決めてからソフトウェアを開発することも重要になります。もちろん、ユーザーの触る部分は早いリリースや試行錯誤が重要でもあります。きっちりしたプロセスときっちりしてないプロセスを混合してまわしていく必要が出てきているように思います。 

 

 

これが現実に起きているのならば、WEBサービスの世界もゲームのルールが変わったってことかな。であれば、ソフトウェアプロセス技術が、変化したルールに対応するための手法として必要となるのもわかります。

オッサンが過去記事で記載したハイブリッドアジャイルが参考になりそうな気がする。

 

ま、前述したようにソフトウェアプロセス技術の話って面白いので、勉強する価値はあるんじゃないかな、なんて。

 

 

なお、CMMIから内部統制に拘ると沼に入り込むので注意したほうが良いかな。

※管理原理主義者は扱いづらい。。。

 

以上

 

 

ソフトウェア・プロセス改善のROI―プロジェクト・マネジャーとソフトウェア・エンジニアのためのメトリックス

ソフトウェア・プロセス改善のROI―プロジェクト・マネジャーとソフトウェア・エンジニアのためのメトリックス

 

 

*1:この話は事前に予想できてたんですけど、実際に当たると嬉しい。問題に合わせてアジャイル、ウォーターフォールを工夫することが肝要だよね - プロマネブログ

システム開発における「俺の屍を越えてゆけ」

テクノロジー

東日本大震災がおきてからもう早4年がたちました。

震災を経て、家族関係や生活観など、影響をうけたものは幾つもあります。

家族と少しでも長い時間一緒に入られるようにしようとか、家族で避難場所を決めておこうとか。 

 

 

ソフトウェアの耐災害対策についてもそうです。色々考えるようになりました。

 

ソフトウェアの耐災害性

 

4年前の大震災の日、たまたま金曜日ということもあり、休日の僅かな業務を維持できれば良い状態でした。

週明けの月曜日からは、ミッションクリティカルなシステムが万一にも停止したら日本経済がストップしてしまう、ということで24時間の張番が必要だ、みたいな形で交代制で待機体制を用意してたりもしました。

 

その当時はあまり深く考えてなかったのですけど、これって結構恐ろしい話ですね。

 

実は、昔から災害対策(DR)に備えコールドスタンバイ・マルチサイト運営みたいな施策自体はあったものの、実際の災害を目にして動作シミュレーションを考えた場合に問題が発生するってことに気づきました。

 

ソフトウェアをDRに耐えうる形にするためには「冪等性」「エラー忘却型アーキテクチャ」「人をシステムに組み込まない」って3つが必要と考えております。

 

冪等性

DRが発生しサイト切替が行われた場合、データベースの内容などは同期が取られていることも多いのですけど、丁度災害が発生した際に処理中だったアプリケーションのメモリ情報まで引き継げることは保証できなかったりする場合があります。

となると、直前のチェックポイントから再スタートするわけなんですけど、この時に災害前の中途半端なデータベース更新等があると、正しく処理ができない場合があります。

例えば、

  • データインクリメントを行っている
  • insertやappendを伴う処理を実行している
  • ファイルを削除している

など。こういった処理が行われている時、再実行時にトラブルとなることもままあります。

 

こういった問題を解決するために、アプリケーションに冪等性を持たせることが必要です。

いろんな方法がありますが、基本は「入力されたデータ(データベース内容など)の内容を更新しない」「冪等性がない処理とは分離する」など。

とにかく、単純に再実行して同じ結果が保証できるようにするってことですね。

 

エラー忘却型アーキテクチャ

エラー忘却型コンピューティングの半分パクリですが。

 

昔の独立したシステムならともかく、現在のシステムは複数のシステム間接続を行った複雑な構造となっております。災害規模のトラブルが発生した場合、自システム内であればデータの整合性がとれたりもするのですけど、他所のシステムまでデータの保証がとれるか、そもそもデータの連携すらない場合だって考えられます。

完全な状態でのサイト切替後の処理継続ができることを保証できないわけですね。

 

つまり、ある程度は「データがない」「データが不正」な状態を許容して処理が出来るような設計が必要なわけです。

 

ミッションクリティカルなシステムだって、100%のデータ整合性が必要な機能(クリティカル系)もあれば、99%の整合性でなんとかなる機能(非クリティカル系)だってあります。

クリティカル系で必要な機能でデータのトラブル等が発生した場合は、不正データの対処を行い、処理継続とする反面、非クリティカル系では、エラー忘却型コンピューティング同様にデータ不正があった場合はロギング、ないしはメッセージ通知を行い処理を優先するような仕組みを考えておく、みたいな感じです。

 

こういった機能のフローの中でクリティカル系、非クリティカル系を上手く整理したアーキテクチャを考えておくことが必要かなと。

 

人をシステムに組み込まない

前述の2つは震災前もある程度考えておりましたが、震災後特に考えたのが「人をシステムに組み込まない」です。

 

よく、DRマルチサイト設計を行う場合「データセンタに隕石が落ちても大丈夫な設計」みたいに語られることがあります。「データセンタが吹っ飛んでも、別サイトに切り替えてシステム稼働を継続させる」みたいな。

これだと「データセンタだけが被災した場合」の想定となるのかな。

 

しかし、この前の震災で学んだことは、データセンタだけが壊滅する、なんて生やさしい話ではなく、「データセンタと同時に自分も吹っ飛んだ場合はどうするのか」ってことだと思います。

つまり、自分が死んでもシステムは動き続けられるのか、と。

 

これ達成するためには、自動切り替え・再ランを行うツール等の活用やハンド作業が不要なDR対策の構築といった災害発生時の考慮もちろんのこと、ノウハウの形式知化(ドキュメント化など)など災害発生後に備えて普段の開発活動だって気をつけることは山積みです。

 

これは結構しんどい。一つ一つ行動する都度、「本当にこれは自分がいなくてもシステムを継続できるように考慮されているか」を考え続けなければならないわけで。

 

まとめ

まあ、色々書きましたが、東日本大震災を経て得たシステム開発に対する思いとしては「自分が死んでもシステムは生きろ」ってことですね。

 

俺の屍を越えてゆけって。

 

責任者が死んだらシステムは維持出来ません、なんてのはシステムの復元性を損なってしまうわけで、そういうのはせっかく有効な技術を使いこなせていることにならないかな。なんで、プロマネならそこまで気をつけたいなあと思ってます。

 

 

 

まあ、人間の知能をコンピュータで再現できるようになれば、こんな考慮も要らなくなるのかもしれませんけど。

 

 

以上

 

 

俺の屍を越えてゆけ (通常版)

俺の屍を越えてゆけ (通常版)

 

 

 

多重請負と騒ぐITpro、もういい加減にしなさい!

タイトルは真似してます。

 

 

今回の記事はいつにもましてヒドイな~。

 

同じ日経記事なのに

供給より需要が多いのであれば値を上げればよいだけであり、“売るもの”が無いのなら売らなければよいだけである。技術者不足で困るのは客側なのだが、ITベンダーは御用聞き商売ゆえか、客側にマインドコントロールされ、「大変だ。大変だ」と騒いでいるのだ。 

 ご自身の媒体のITPro。日経系列だよね。。。

およそ一年前の記事なのでもうお忘れか。

 もう既に入札不調や案件見送り、受託価格向上なんてのは発生しとりますがな。公共システムだってしかり。別に無理して売ろうとはしてないわけで。

 

ここでいう大変だ、ってのは「儲け時なのに儲けられないのは大変だ」ってことでしかないですね。

 

資料はきちんと読もう

しかし、この調査で「不足している」と答えているITベンダーは“わずか”6割にすぎない。つまり、残りの4割のITベンダーは少なくとも「足りている」ということになる。

 「なんだ。技術者不足は『2015年問題』などと大げさに言うほど深刻じゃないじゃん」と早合点してはならない。実は、これこそがIT業界の SIガラパゴス、つまり多重下請け構造の為せるワザなのだ。ほぼ断定的に言えるが、「足りている」とするITベンダーの多くは、元請けとなるSIerなど大手ITベンダーで、「不足している」と回答したITベンダーのほとんどは下請けベンダーのはずだ。

 

いやいや、元の帝国データバンクの調査資料ちゃんと読みましょう。

中小企業を中心に1万794社から回答を得ました。 

企業の約40% 「正社員不足感じる」 NHKニュース

 

足りているって答えているベンダーも、大多数は中小IT企業なんですよ。

 

 

この手の調査資料を読むときには、いくつか注意点が必要。

  • 現れた差は業界特有なのか、日本共通なのか
  • 景気動向の問題なのか、それ以外の原因があるのか

などなど。

 

この方は、「2015年問題」を歪めてしまっているのですけど、元々の問題としての2015年問題が隠されております。

戦後生まれのいわゆる「団塊の世代(1947(昭和22)年~1949(昭和24)年生まれ)」が65歳以上となる2015年

わが国の高齢者介護における2015年の位置づけ

 

上記の不足している、の中には、元々の問題としての2015年問題としての団塊の世代の定年延長後の定年を迎える時期だったり、そもそも中小企業DIの改善に伴う投資意欲増加などといった意味合いからの人手不足の意味合いが大きい。

 

59.3%のITベンダーが従業員の不足を訴えており、この割合は同じく人手不足に悩む建設業と比べても5ポイント近く高い。

今回の調査で、全体平均で「人手不足」を答えたのは37%。これをベータとみなせば、IT業界特有の事情での人手不足は22ポイント。

そもそも、IT業界自体の成長率は、日本のGDP成長率よりも高いわけで、単純に成長市場としての人手不足もある。

これを言い換えると、「成長率がマイナスとなっている建設業と、GDP成長率よりも高い成長のIT業の差はたったの5ポイント」ってことだよね。

供給圧力のためしぶしぶ人を増やすってだけでなく、将来の投資に向けての人員確保の要因も透けて見える。

 

しかも、これら中小IT企業に含まれるのは、別にSIベンダーだけじゃあない。ネット系企業やソフトウェア業等でも情報サービス業に含まれている会社はいくらでもあるわけで。

 

こういった内容を考えたら、きちんとロジカルな思考ができる人なら、前述のような記述はとてもできない。てか、ただの確証バイアスじゃないですか。

 

何が「多重下請け構造の為せるワザ」なのか。

 

 

そもそも「正社員」を雇用する意図

今回の技術者不足は、SIガラパゴスの最後の宴に咲いたアダ花である。「東京オリンピックが開催される2020年までは大丈夫」と楽観論を唱えるITベンダーの経営者もいるが、もしそうだとしても、その先はどうなるのか。団塊の世代後期高齢者に移行する2020年代には日本経済は急速に下降線をたどり、SIのような古色蒼然としたビジネスは大絶滅のときを迎えているだろう。

 

この人はどうしてもオレオレ定義の「2015年問題」が確実に起きると確信している模様なのでしょうけど、そんなもの誰もまともに信じてはいません。

 

今回の帝国データバンクの調査を見れば明らか。「技術者」ではなく「正社員」が不足している、つまり、現在の需要増を短期的なものではなく中長期的なもので見ているってことですよね。

本当に、2015年問題がおきて需要が今後シュリンクするなんて考えていたら、正社員ではなく別の形態での人員確保にて需要が急増してます。

 

2015年問題がおきている、見たことかって意気込んでいるみたいですけど、誰も信じてもいない現状もきちんと見たほうが良いかと。

 

 

まとめ

需給関係が圧倒的に有利で労働集約から脱却するチャンスなのに、好況のときほど労働集約型産業の地金が出る。相変わらずのアホである。

 

SIの仕事が動向に応じて人の増減が発生することを指して、「労働集約型産業」なんていう人がいます。

 

しかし、「知的集約型産業」を定義した通産省産業構造審議会では「知的集約型産業とは、知的労働を中心とする労働集約型産業」と記述しているんですよね。*1

そりゃそうだよね。知的活動は人間が行うわけなんだから。

 

SIerだってなんでも力技でやっているわけじゃあない。

オッサンのチームだって、繰り返し作業する中での定型作業なんかは自動化している。保守の現場だから。

 

ユーザがほしいのは出来合いのパッケージではなく、どこにもない新しい情報システムがほしいというニーズが高いから。景気後退期の時期から、景気拡大期になったらなおさら。攻めのITが欲しくなるわけで。

新しいシステムをつくろうとする受託の現場は、とかく技術者が多数必要になることが多いです。 

そういった仕事は新しいことだらけで、定型化出来る余地なんて殆ど無かったり。下手に自動化を行おうとしたら、余計に負荷が高くなることだってある。難易度は跳ね上がる。でも、一セット1万円なんて安値でなく、数百万、数千万、数億といった報酬がもらえる。

 

現在、労働者不足が発生しているのは、「定型な単純作業を人手で仕事しているから」なのか、「非定型な新たな知恵が必要な仕事を行っているから」なのか、きちんと見極められているのかな。

 

ユーザのニーズも、価値の源泉も理解せずに「労働集約型産業の地金が出る。相変わらずのアホである」なんていう人は、まあその。。。色んな意味で残念ってもんじゃあないですかね。

 

 

以上

 

 

 

だましの手口 (PHP新書)

だましの手口 (PHP新書)

 

 

DDDの思い出2つ

テクノロジー プロジェクトマネジメント論

年度末になると宿題の駆け込み・年末の道路工事と同じく急な案件見積もりや技術調査依頼なんてのが入るもんで、すっかりまいっておりました。

こういうのももうちょい計画的にやってくれたら楽なのに。。。

 

 

上記のエントリ見て2つほど思い出したことがあったので。

 

ドメインを甘く見てはいけない

仕事をやっていると、外部公演や外部研修といった場で他企業でエンジニアやマネージャやっていた講師の話を聞くことがあります。

 

で、その場で出た話。

 

講師「まず、プロジェクトを進めるためには、プロジェクトマネジメントやアーキテクチャ、プログラミングと言った開発能力が必要となります。」

当方「それらが必要なことは理解しておりますが、業務知識・ドメイン知識はより重要ではないのですか?」

講師「業務知識はユーザがもてば良いもので、開発者はそこまで重視しなくても大丈夫です」

 

この話。ずーっとモヤモヤしてたのですよね。

なんだかんだ言って顧客の作りたいもの理解しなければ、顧客に提供しようとしているものをイメージできなければ、たとえどんなに円滑にプロジェクトが進もうと、開発ができても顧客満足度を上げられず失敗になるんじゃないの?って。

 

この講師の方は、オッサンの会社のライバル会社出身の方で、超大手に分類される方でした。

 

実はその方の出身の会社って、ここ数年顧客と「求められるシステムを作れない」なんて大騒ぎになってちょくちょく話題になったりしてたんですよね。

※表現はぼかします。

 

ただまあ、こういう話を思い出すと、海外でDDDが話題となった理由も何となく分かるかなあ。

今思えばやっぱりなって感じなんですけど、ドメインや業務知識といった能力はシステム開発のベースになるんだし、それを無視したら行けないだろって思うんですよ。

 

以前、DDDの話を最初に聞いた時にそんな感想を持った次第でした。

 

ドメイン・エキスパートとソフトウェア開発者は一体とするべきか

元記事だと一体化するべき、という意見なんですけど、個人の経験的には分離したほうがよい、って思うんですよね。

 

最大の理由は、「ドメインモデルの難易度と、ソフトウェア開発の難易度に相関があまり見られない」から。

つまり、複雑で解決困難なドメインモデルがあったとしても、実際のソフトウェアを作成する際には、案外簡単なものとなっていることがよくある話。

逆に、ドメインとしてはカンタンなものでも、実際にソフトウェアをつくろうとした場合に非常に苦労するようなこともある。

※非機能要件がらみの開発物とか。

 

となれば、優秀なプログラマ・ソフトウェア開発者をドメインモデルのタスクに割り当てて時間を消費することは、ときとしてもったいないことだったりするので、適材適所で上手く役割分担をしたほうが良いって感じたりもするんですよね。

 

プログラミングのスキルを鍛えるのにパワーが必要になるように、ドメインを理解し定義できるようにするにもパワーがいる話なので、理想的には両方の能力を鍛えることとはいえ、どちらかにならざるのは仕方ない部分もあるんじゃないのかな。

なので、その現実を直視し、

ドメインモデルが、開発者とドメイン知識をもつ人(ユーザ、専門家等)との間の共通言語となるようにする

 

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場

ってのがDDDの基本的な思想なんだろうなって思うわけです。

 

DDDの話に触れた際に、チームとして頑張りましょうってことなのかな、なんて考えたことをふと思い出しました。

 

まとめ

まあ、ざっくりと書いたのですが、結局言いたいこととしてはドメインの重要さを軽視せず、また重く見過ぎず、上手く付き合えるようにしたら良いんじゃないかなと思います。

 

いつもどおり、バランスが大事ってことですかね。

 

以上

 

 

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

 

 

 

バッチ処理のあれこれと、SLA

テクノロジー

風邪引いてしばらくブログ更新サボってました。

上記記事について、気になったので。ブコメで言及ももらったし。

 

ウィキペディアのバッチの利点って若干記載が古い

  • 多くのユーザーがコンピュータのリソースを共有できる。
  • 処理をコンピュータのリソースがあまり忙しくない時間帯(多くは夜間、休日)にシフトできる。
  • 人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。
  • 高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。

バッチ処理 - Wikipedia

 

バッチをリソース目的だけで使うってずいぶん古い話だなあ、と思って編集履歴をたどってみたら、2006年の記載でしたか。

記載をたどってみると分かるんですけど、上記の内容って「メインフレーム」のバッチ処理に対する利点なんですよね。

 

そういった意味では、現在のバッチの設計とはちょっと概念が違うんじゃないかなって思います。

 

分散アーキテクチャの静的同期処理としてのバッチ

じゃあ、現在バッチはどのような使われ方があるのか?

実際にバッチを設計している現場だと、分散アーキテクチャにおけるリコンサイル処理で利用される場面が結構多いです。

 

具体的には

  • SOAのような分散アーキテクチャにおける、各サーバに分散されて格納された日中フローデータのズレ・不整合のリコンサイル
  • 企業間取引における日中取引結果の各企業間でのリコンサイル
  • 金融取引における清算機構の清算結果と日中取引結果のリコンサイル

など。

これをミッションクリティカルなシステムで実現しようとした場合、夜間ぐらいしか業務を止めるヒマがない=リコンサイルを夜間バッチで処理せざるを得ない、なんて状況になったりします。

 

でもこれらリコンサイルって、「正常なデータを企業間システムやSOA内の分散サーバにて同期を取る処理」なわけで。

業務的な言葉を一旦外せば、分散アーキテクチャ内を刻一刻と動くデータを処理するリアルタイム処理に対し、静的な同期によりデータ不整合を防ぐバッチ処理、といった形となります。バッチは、システムにおけるデータ管理・自己復旧の技術となるわけですよね。

 

まあ、何が言いたいかというと、バッチ処理は、メインフレーム時代のリソースシフト目的の処理から、分散アーキテクチャにおけるデータ管理技術に転換して来ているんじゃないかな、と言えます。

 

※他にも、システムの自動リリースや自動構成管理変更などの運営自動化などのバッチの使われ方もありますが、きりがないので除外で。

ハンズの本当の評価

で、悪玉にされがちな夜間バッチですが、ハンズの話で本当に注目するべきところは「夜間バッチを廃止したこと」ではなく「夜間時間帯をバッチを使用しないことで突き抜けリスクを受け止めるSLA管理」に着目するべきだと思います。

 

ぶっちゃけ言ってしまえば、上記の通り業界間リコンサイルが必要となるような大型のエンプラ系基幹システムでもない限り、夜間バッチをなくしてもなんとかなる場合って結構あるんですよね。特に社内独立で動いているようなSMBのシステムなら。

 

ただ、夜間バッチをなくせない理由って技術的な面よりか「社内のユーザ部門からの朝業務開始できないかもしれない不安」とかのSLAにより実現できない場合が多かったり。

言い方を変えれば、夜間バッチをなくした場合に発生するリスクをユーザ(この場合は社内部門)とシェアし、メリットを感じさせることができれば実現できると言える。

 

ハンズが夜間バッチを廃止できたのも、そういったユーザ部門掌握がきちんととれたから、と言うのは大きいんじゃないかな。

でなきゃ、夜間バッチを廃止することで「中度リザーブド60万が、夜間8時間停止で45万になります」なんていっても、「たった15万ぐらい安くなるためだけにリスクが負えるか」なんてユーザ部門から反発を食らってしまうわけで。

 

 

これはハンズの自社システムの例だけど、SIerの受託でも同じかな。

ユーザときちんとSLAを握りさえすれば、「夜間バッチにて、多少トラブルが発生しても大勢に影響がなければ翌日フォローで対応する」なんて感じで、夜間コール数年間0件で運用できるようにすることも難くなかったりもします。

 

ユーザビリティを下げないようにするためには夜間バッチが必要、でも、極力運用負担を減らしたい、なんてニーズはよくありますよね。

自分がコールで叩き起こされるのが嫌で、どうすればよいかさんざん考え続けたのですが。。。

重要な事は、夜間バッチを廃止することではなく、皆が幸せになれる適切なSLAを考えるか、じゃないかな。

 

まとめ

まあ色々書きましたが

  • Wikipediaの内容は最新じゃない場合もあるからあんまり鵜呑みにしないほうが
  • バッチ処理はリソースシフトだけではなく、分散アーキテクチャを管理するための技術としての利用方法を固めつつある
  • 夜間バッチ廃止に拘るのではなく、適切なSLAを考えることが重要

なんて感じかと。

 

とくに3つ目が一番重要で、夜間バッチが悪玉にされるのも「過剰なまでに高く厳しいSLA」が原因だろうなってつねづね思うわけで。

これを、関係者が「まあいーか」といえるようなラインまで調整できれば、多分色々な苦難が解決されると思います。

 

以上

 

 

 

ポケモンセンターオリジナル ぬいぐるみ 等身大マーイーカ

ポケモンセンターオリジナル ぬいぐるみ 等身大マーイーカ