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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要は、

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

以上

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

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

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

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

2015/03/12 11:37

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

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

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

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

• モデリング
• 計測分析
• 管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マイクロサービスの現在

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 まとめ

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

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

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

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

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

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

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

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

以上

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

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

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

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

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

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

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

ソフトウェアの耐災害性

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

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

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

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

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

冪等性

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

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

例えば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

 

以上

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

DDDの思い出２つ

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

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

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

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

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

で、その場で出た話。

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

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

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

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

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

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

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

※表現はぼかします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

以上

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

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

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

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

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

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

バッチ処理 - Wikipedia

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

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

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

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

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

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

具体的には

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

など。

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

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

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

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

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

ハンズの本当の評価

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

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

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

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

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

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

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

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

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

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

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

まとめ

まあ色々書きましたが

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

なんて感じかと。

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

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

以上

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

SIerのこと知ったかしている子たちへのツッコミ

前回、システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 - プロマネブログの記事でコメントを頂いたのを思い出したので。

id:sayurin7
paiza開発日誌　2015-01-26
【エンジニア対談】SIer・大手からスタートアップへの転職前に知っておきたい事
でSIerのこと知ったかしている子たちにも何かひとこと、ぜひ 

あ～、あまりにも酷かったのでブコメでツッコむ気も失せていた記事ですね。。。

まあ、せっかくコメントを頂いたことですし、確かに間違いを指摘するのも大切なことなので、カンタンに。

自分の知らないこと≠存在しないこと

ITを後付けするんじゃなくて、ITをベースにして今までに無い事業やビジネスモデルを考えるべきだと思ってました。そういう事やるのって受託ビジネスでは無理だから、やっぱり自分はSIerじゃなくて自社サービスを開発する仕事がしたいと。

ATMも、電子マネーも、ネットの電子送金もきっと知らないんです。金融取引などは既に高度な電子化がされてますが、それを受託で開発したのではなく、独力で作られたと思っているんです。多分。

もちろん、ウソですけど。

彼らにとってはおそらく、見えないこと＝存在しないこと、なんです。だから、SIerの仕事は自分の経験した範囲でしか語れない。過去、paizaの記事に何度かツッコミ入れましたが、大体の結論は「狭い経験でしかSIerを語らないし、きちんと業界分析ができてない」です。

SIerの受託の仕事は、当然ですが「裏方」仕事です。ユーザの手助けをする仕事なのに、自分の成果だと喧伝するわけはない。外からはとかく見えづらい。

だから、前述のような思い込みが発生してしまいます。残念なことに。

SIer≠受託ソフトウェア開発

自社サービスに向いている人、SIerに向いている人 

 前述の、SIerの仕事を知らないってことにもつながりますが、SIerの仕事は受託開発だけではないです。転職前の経験が受託ソフトウェア開発だけなので、それしかイメージ出来ないと思うのですが。。。

実は、オッサンはASPを作ってます。自社サービスですね。パッケージを作っていたりもしてます。

他にも、電話システム構築など、ソフトウェアはパッケージで、回線の敷設や機器導入など、非ソフトウェア開発の仕事も多い。

会社にもよるけど、ウチなんかは受託開発が3割、その他が7割だったりします。*1

SIerと自社サービス開発は相対する概念でないことは、きちんと理解しなければなりません。

そもそも、受託開発のイメージすらも怪しい

佐藤：とにかく能動的な人でしょうね。SIerで開発をしていた時は、何もしなくても仕事を振られたので、それを淡々とこなしたい、受動的でいたいという人はそれでいいのかもしれませんが、僕は「この機能を追加した方が便利になる」と思ったら、「やるな」と言われてもやってしまうような人間なので、受動的でいると楽しくないんですよね。

伊藤：同感です。ルールの中できっちりやっていきたいという人は、SIerがいいかもしれませんね。自社サービスの場合は自分達でルールから作っていかなければならないので、難易度が高い面はありますが、それも含めて楽しいですよね。

受託開発の現場の怨嗟の声を度々聞きますが、「お客が要件を決められない」「SEが仕様を決められない」なんてあります。オッサン自身が淡々とこなすだけで仕事ができた、なんていうのは新人時代のカンタンな仕事ぐらいしか無いので、相当恵まれた職場だったのじゃあ無いのかな。右も左も分からない、新人時代の経験で語っているのかもしれませんが。

 SIerの仕事でも、当然誰かが動かなければ仕事は進みません。そして、大体の場合は自分が動かなければいけないわけです。

あと、過去、受託開発時代、「この機能を追加した方が便利になる」と思ったらきっちりお客さんに提案してお金貰いに行ってましたね。ユーザが「やるな」といっているにも関わらずやってしまうのは、「ユーザの反応を見てないこと」になってしまいますし。

便利になることを喜ばない人はいません。もし便利になると思って提案をしていないのであれば、「能動的な人」ではないし、提案しても通らないのであれば、自分の考えに誤りがあるか、きちんと説明するだけの提案力が足りてないのじゃないのかな。

こう言うと「アンタは元請けだから」って声が上がりそうですけど、そんなことはない。元請けの人間だって便利になる提案は大歓迎だし、実際にパートナーさんからの提案を採用している。

佐藤：どっちが良いとかではなくて、きっちり仕様を詰めて設計したものを安定的に作っていきたい人は、SIerの方が良いんじゃないでしょうか。自社サービスは何か機能を作るにしても、仕様書等があるわけじゃないので。

伊藤：仕様書じゃなくてユーザーの反応を見ながら作っていかなきゃならないですし、さっきも話に出ましたけどマネタイズとも向き合っていかないといけないので、そこが厳しいところですよね。でも、そういう厳しさを面白いなと感じられる人は、自社サービスの開発に向いていると思います。

ちょっとこれはいただけない。

前述した通り、ASPの自社サービス作っておりますが、きちんと仕様書は作っております。

ソフトウェア製品ライフサイクル管理を真っ当に理解している人間なら、開発から破棄まで、ソフトウェアをどのようにマネジメントするかを考えなければいけません。

少なくとも、長期（経験的には2年以上）にわたってソフトウェアを使い続けるのであれば、保全計画を考えなければならないわけですが、アーキテクチャを崩さないようにするため、過去開発した機能の理解を形式知としてとどめておくため仕様書は必要となります。

仕様書がなくてもなんとかなるのは保守期間が短期（もしくは使い捨てに近い）のプロダクトだけです。

スタートアップのプロダクトの場合、長期の見通しも立たないことがあるから「仕様書より開発」を優先するのはわかります。おそらくギノもそうなのでしょう。

ただし、その限定的な経験を持って「自社サービスの特徴」とするのは主語がでかすぎる話です。

まとめ

まあ、色々書いたのですけど、毎度のごとく「自分の経験だけで語るのではなく、もっと勉強が必要だ」ってツッコミで終わってしまいました。

大体が、主語が大きい話になっちゃっているんですよね。

というか、カンタンで終わらせる予定が2000文字超えているし。

失敗。。。

以上

*1:数字は多少ずらしてます

システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国

う～ん、まあ、相変わらずツッコミドコロがいっぱいあるのだけど、一番肝心なところだけ。

総務省の情報システム調達ガイドラインを読んでないよな

もちろん、政府もこうしたことに深刻な問題意識を持っており、民間から政府CIOを起用し、そのスタッフも充実させるなど更なる改革に取り組んでいる。2015年4月からはシステム調達に関する新たなガイドラインも施行する。

(中略)

　だが、あくまでも「この通りに実施できれば」の話だ。ガイドラインでは、システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。業務やITに精通するだけではダメで、ベンダーマネジメントや、利用部門を統制する“ユーザー”マネジメントなどをこなせるIT人材が必要だ。

(中略)

そして地方自治体や外郭団体に至っては、その多くがいまだに丸投げ＆ベンダーロックイン状態にある。

政府のIT調達の問題点をもしかしてきちんと理解してないんじゃないのだろうか。

政府のIT調達において、「ベンダ任せをせずに政府側で開発コントロールする」こと、つまり「分離調達」がしばし問題となっております。

分離調達というのは、「要件定義支援」「設計／開発」「保守運用」など、フェーズごとに受託者を分けて受注する方式のこと。要件定義を担当したベンダは保守に入札できないなどの制約を受けることとなっており、特に大規模な案件では、分離調達が必須となっております。

で、この分離調達ってのは少なくともシステム開発する上で問題になることが多い。

この政府調達方針もそうだけど、情報システムにおけるエンジニアリングの知見で、「システム要件が決まらなきゃ、開発手法も契約方式も成立しない」ってのがあります。

分離調達で開発工程ごとに契約を結ぶ、しかも要件定義工程も別途設ける、ということは、「何を」を決める前から「どうやって作る」「お金をどう払う」が決まってしまうこととなります。

分離調達では、ウォーターフォール開発が前提となります。システム開発をよく知らない人が良くする誤解でウォーターフォール開発は手戻りができないってのがありますが、実際は前後工程間のフィードバックを重ねながら品質を高めるコトが必要な開発手法です。

分離調達で要件定義・設計・開発が分離されてしまうと、それらのウォーターフォールのフィードバックを効かせることも困難です。

つまり、通常であれば後工程になればなるほど、リスクが減少するはずのウォーターフォール開発にて、後工程ほどフィードバックできずに積もり積もった品質上のリスクが積もっていくという恐ろしい状態となります。

これを、従来開発しているベンダが請け負うのならともかく毎度契約を結び直すわけで、知見の蓄積もできない。事前にリスクを洗い出すことも、要件を整理することもできない。

もちろん、上記の様な開発計画を立てるための知見を政府内で育成するって考えもあります。ただ、それは「定期異動」によって阻まれてしまいます。知見を育成しても、定期異動で別部署に異動となってしまえば知識は失われてしまう。

定期異動を行わなくすれば？

そうすると、今度は業者との癒着と言った懸念が上がってしまいます。

つまり、構造的にうまくいくようになってないわけです。

これらの指摘は、政府調達の問題点としてしばし指摘*1されております。

これを受けて策定しようとしたのが、２０１５年４月からの新規の「政府システムの整備及び管理に関する標準ガイドライン」です。

これには、以下の様な記述があります。

分離調達の見直し

新ガイドラインでは、合理的な調達の基本単位の考え方を明示するとともに、過去促進していた情報システム設計・開発工程における分離調達を見直し、過度な分離調達を抑制  

http://www.soumu.go.jp/main_content/000325351.pdf

そう、従来の政府主導の分離調達を見直し、一括調達、要は必要に応じてベンダ任せ（極論すれば丸投げ）を再度認めようって腹なんですよね。

過度の分離調達でうまくいかないのであれば。ベンダのノウハウを使う方式にしてしまおう、ってわけで。

こういう記載を見れば、元記事の木村氏、きちんと政府調達のガイドラインを見てないんじゃないのだろうか。

※まあ、従来から丸投げはいけないって純朴な考えから言っているわけで、丸投げはダメありきでしか考えてないから読み飛ばしているのかもしれませんが。。。

米国では一括発注を活用している

ところで、この方は普段出羽守なわけですけど、今回の記事では「米国政府を見習え」って言ってませんね。

実は米国政府では、システムは一括発注がメインだったりします。

実質的には有力プライム（大手ベンダー）への一括発注がほとんど

　図２に示すように、システム構築全体はプライムコントラクター（大手ベンダー）が握っている。ここでは、実質的に有力プライムへの一括発注がほとんどで、プライムが受け、（必要に応じて）入札時・入札後にサブコンに振り分けている。特に、ミッションクリティカルなシステムでは、実績・関係の両面で省庁の厚い信頼を得ているベンダーにしか発注は行われない。
　信用力ある大手ベンダーがシステム構築プロセス全体のend to end responsibilityを担保しているわけだが、これは、日本での状況の生き写しである。

04Legacy09

ボストン・コンサルティングのレポートで、10年前のモノですけどその時からさほど変化があったと聞いてないので引用してます。

実は米国政府では、システム調達の不達、トラブルが多発したことから、プライムコンストラクタへの一括発注におおよそ20年前、1990年代から切り替えてます。

工程の分割などは原則行わない、プライムベンダの統括責任で行動させる、プライムコンストラクタがサブコンストラクタを必要に応じて招集するなどの、開発を成功させることを再優先にした構造となってます。

また、分割発注自体は0ではないですが、日本のよう工程別分離調達ではなく、要件別の分離調達で実施がほとんど。

日本がベンダをコントロールしようとして工程別の分割調達で失敗している状況とは対比な状況です。

ちなみに、一括調達とはいえ、日本と同じで、発注時にすべての要件を決めきれず、後追いで追加するなんてのもしばし起きうる話です。結局システム開発なんて人間が行う訳で、あまり日米関係ないってわけですね。

元記事で言っているような発注時点できちんと要件を決めきれるなんて米国政府だって実現しきれてない話です。米国ではそういった問題をベンダの権限拡大と契約(実費償還型契約など)で上手くリスクを分け合う形にしているわけ。

※とはいえ、ITコスト削減のため、近年は日本の請負契約と同様の固定費用契約を増やしてきているみたい。

なんで分割調達となったのか

じゃあ、日本のIT業界は米国の10年後追いと言われる中、なんで米国の後を追って一括発注を採用せず、原則分離調達などという無理ゲーに手を出したのか。

元記事にも一部書いてありますけど、「費用の透明化」と「公平な入札機会」が大きな理由としてあります。

費用の透明化は、システム構築コストとして無駄金を使ってないか、不正な取引がされてないかのチェックが必要という世論の高まりを受けてです。

現在の分離調達の検討が行われた時、時の総理大臣は小泉純一郎元首相でした。

うろ覚えですが、財政健全化に向けての構造改革の一環で見直しが行われた記憶があります。

※当時竹中平蔵氏のブレーンで、現民主党の岸本周平氏が「政府調達制度と IT システム―“IT ゼネコン”を育てたの誰か」*2みたいなレポートを書いていた時期ですね。

公平な入札機会は、要は、一括発注だとリスクが大きすぎて大手ベンダだけしか請け負えず、IT業界の多重請負構造を改善できない、中小ベンダも直接入札参加できるよう改善して欲しいという要望を受けてのものです。*3

開発ノウハウが固着してしまい、随意契約に頼らざるをえないと言った問題も指摘されてました。

こういった改善のために、分割調達となったわけですが。。。

結果としてみれば、費用の透明化は実現できたものの、IT調達の不達、失敗により多額の税金をドブに捨ててしまう事となってしまいます。開発の際も余計なリスク＝コストを抱えることとなり、結果としては必要経費が増加へとつながってしまいます。

開発工程を分離したものの、前述したように後工程ほどハイリスクとなってしまい、結果として大手ベンダが開発工程も請け負うようになっている始末。特許庁システム更改の時の開発工程をTSOLが請けたように。

「IT投資の無駄を無くせ」「多重請負を解消しろ」って掛け声の元の改革は、元々の問題を解決するどころか、むしろ新たな問題を発生させるだけになってしまったわけです。

まとめ

えらく長くなってしまいましたが、結局言いたいこととしては

「元記事はきちんと問題理解して記事書いているのかな？」

という疑問です。

少なくとも、JEITAの指摘しているように、分離調達の問題点を指摘することが開発者視点で必要だと思ってますが、それに触れられてません。

実効性のない問題提起は、結果として「新たな問題を発生させるだけ」になるのじゃあ無いのかな、なんて思います。

この極論暴論で語られる問題提起はまあだいたいそうなのですが。

以上

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

*1:http://home.jeita.or.jp/page_file/20120515154921_sR4leNPzOb.pdf

*2:http://www.rieti.go.jp/jp/events/03020501/pdf/kishimoto.pdfを参照

*3:http://www.soumu.go.jp/main_content/000070266.pdfを参照