イケてる環境のWEB系の労働生産性がイケてないSIerのたった三割しかない件

久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。

【Web系最高って言うけど本当なの？】SIから転職したエンジニア達に聞いてみた - paiza開発日誌

まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。

最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。

 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。

イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割

http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf

上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。

大体10年前からIT業界の動向などが分析されている資料で、業界動向にかかわる人間なら一読しておいたほうが良い資料だったりします。

で、この資料ってずいぶん昔から公開されているので、みんな知っているものかと思いきやPaizaの記事やブコメ見るに案外知られてないような気がしてます。

このPDFは平成27年度版。現時点の最新版です。

P.64を参照してもらえると、IT業界内の各業種ごとの労働生産性が記載されてます。

ITにかかわるすべての業種の労働生産性が記載されており、見づらいので、SIer（便宜上情報サービス業*1）とWEB系（インターネット付随サービス業）を抽出したグラフを作成するとこんな感じとなります。

まあ、見ての通りなんですが、WEB系業種の労働生産性は2007年をピークに下がり続け、現時点では293万円となりIT業界で最低、半面、SIerの労働生産性はリーマンショックの影響を受けてピークを打ち、現在は992万円。

アジャイルを使い、GitHubを使い、各種ツールを使い内製をしてるWEB系は、ウォータフォールを使い、SVNを使い、Excel方眼紙で多重請負構造のSIerと比べ、労働生産性がたった3割しかない状態です。

労働生産性の全業種・IT業界全体への寄与度では直近マイナスをキープし続けている状態。いわば、日本の労働生産性の足を引っ張っている状態です。

よく、Paizaなんかでは「Web業界は知的集約産業。SIerは労働集約産業」なんて言ってたりします。この知的集約産業ってのは、「高い知的生産を持って、労働力を用いた労働集約的な側面も持ちつつも高い労働生産性を持つ産業」なんて言われたりするわけで、労働生産性は「労働サービス産業＜知的集約産業」という関係性を持つことがあります。

SIerは全産業平均よりも高く、知的集約産業の面目を保っているわけですが、WEB系は労働生産性を見ればほぼ労働集約産業といった水準。小売業（349万円）以下、飲食業（262万円）や医療・福祉・介護業（291万円）と同等水準。屋台で焼きそば焼いていたりするのと生産性に大差ない。

なぜWEB系は生産性が低いのか

はてなのテクノロジーカテゴリみていると、このPaizaを筆頭にWEB上げ、SIer DISの記事やブコメばかりで、まっとうなWEB系の生産性の低さを分析・問題視している記事を見た記憶がありません（見落としているだけかもしれないけど）。

WEB系の外部から見たなんとなくの風景です。憶測なので、ここはぜひともWEB系の人からの分析・意見がほしいなあ。

せっかく、前述のとおりWEB系は開発環境がイケているそうなので、そこからざっくり考えると

• 「イケてる」WEB系の開発環境がほんとはイケてない（生産性を下げている）
• 開発環境はイケているけど、それに余りあるほどウェブエンジニアの能力が低い
• そもそも、業界自体のビジネスがイケてない

ってのが予想されます。

ただ、よく考えてみると、開発環境についてはたまに「かえって生産性下げているよな、それ」みたいなものを見かけることがあるものの、SIerとくらべ著しく労働生産性を下げる要因には見えない。

ウェブエンジニアの能力についても、従業員教育に金渋っているな～って見える場面がしばしばあるものの、SIerから転職した人間もいるし、著しく労働生産性を下げる要因には見えない。

となれば、業界自体がイケてないんじゃないだろうか、と予測できる。

 ざっくりとだけ言う*2と、WEB系はプログラムを作成する開発生産性が高いものの、ユーザが金を払ってでも使いたいと思わせるような付加価値の高いプロダクトが作れてないのが原因じゃないのかなって気がしてます。開発生産性ばかり高めることに目を向けるあまり、過剰生産となり、例えばあるヒットサービスが出たら雨後の筍のように類似サービスが出現するなど、顧客を食い合って互いに付加価値を削りあっているレッドオーシャンに見えたり（いわばウェブサービスのデフレ状態）。

結局のところ、業界をマクロでみてみれば

「SIerのプロダクトは、ユーザが高い金を払ってでも欲しがる故にどんくさい」

「WEB系のプロダクトは、無駄なく・素早く・大量故に付加価値は限りなく低い」

っていう対比関係にあり、プロダクト特性をあまり理解せず開発生産性の一点だけを持ってSIerはイケてないって言っているような気がします。

高い付加価値を得るために、法、契約、資産効率などの理由からあえて今現在の開発スタイルをとっている部分を「非効率」といったりとか。

「日本のエンジニアの地位を上げるというサービスとしての目的」

 元記事では、「日本のエンジニアの地位を上げるというサービスとしての目的」なんて記載しているわけだけど。。。

でも、イケてないSIerの特定企業をあたかも業界全体みたいな感じで適当にDisって、一部の事例でWEB業界がイケているようにごまかし、労働生産性が著しく低いWEB業界で優秀なIT技術者を使いつぶそうとするのって、本気で「日本のエンジニアの地位を上げる」って考えているのだろうか。

よその業界をDisって悦に入っている暇があるなら、まずは、WEB業界の労働生産性の低さに向き合って、きちんと知的集約産業として誇れる水準に持っていけるよう、ユーザへの付加価値を高めることを努力することじゃあないのだろうか。

もちろん、イノベーションを達成するためには、投資として一時的に労働生産性が低い時期があっても仕方ない。ただ、それがもう10年近く続けば、そろそろイノベーションのための投資とも言ってられない状況。

現在は、アベノミクスなどの金融政策もあり、資金余りがWEB業界に集まっていると思います。なので、労働生産性が低いにもかかわらず、飲食業などと比べればそこそこ良い待遇となっていると思います（確か、平均だとSIerの3割減ぐらいだったはず）。サービス業の労働分配率が50％程度といわれることから、SIerが大体妥当な給与水準で、WEB系は相当高い下駄をはいた状態と認識しております。

言い換えれば、イノベーションがいつまでも生み出せないと判断され投資意欲が落ちたり、金融政策が緊縮に転換したりして資金流入が滞れば、たちまち待遇が激減する恐れだってあるわけで。

それが表れたのが、過去のITバブル。米国のインターネット業界が、過剰生産、過剰投資となった挙句、利上げを契機に過剰な期待がしぼみ一気に不況となったのが、2000年代前半の話。

現在の米国IT業界もバブルの再来で過剰投資では、という声はしばらく前からちらほら聞こえてきているものの、利益や付加価値は依然と上昇しており、投資に見合った成長を続けているという声もあり、バブルではないという反論も聞こえる感じ。

翻って日本は？

上場ゴールみたいな期待ばかり先行し実力が伴わないウェブ企業が頻出してないだろうか？

開発技術を追うばかりで生産過剰となって互いの首を絞めてないか？自らの首を絞めてないか？

過剰投資とならないよう、自転車操業的な売り上げの拡大だけでなく、利益・付加価値額を成長させているだろうか？

ITバブル越えの日経平均株価となった現在、バブルの芽は発芽してないだろうか？

まとめ

 しばらく前、たまたまだけど新卒でとあるWEB系企業に就職した女性の話を耳にする機会がありました。

深夜遅くまでの長時間労働、頻繁な休日出勤、ろくな研修もせず半強制的な時間外勉強会。。。SIerでも激務と呼ばれる会社で働いたおっさんでもさすがにドン引きする水準の労働環境で、ぼろぼろとなった見た目から相当疲弊しているのは明らか。

でも、その女性曰くその会社では「SIerよりもうちのほうがマシ」なんて言い訳をしている。

傍から見たら何を寝言をといったレベルでも、当事者の女の子からしたらそんなことはわからない。

その女性の姿が、ちょうどこの前の電通の過労自死問題で亡くなってしまった女性のTwitterで記された姿に重なってしまい、ついこんな記事を書いてしまった。。。

WEB系の中の人でないおっさんが書いたところで正確性を欠くし、人によってはDISりにしか聞こえないと思うし。。。あまりよくないのはわかってはいるものの、書かずにはいられなかった。

彼女は大丈夫だろうか。。。。

前述のグラフのように、SIerの職場は労働生産性は20年前の1.5倍に上昇したし、残業の扱いも厳しくなって総労働時間もぐっと減った。でも、まだまだ改善の余地はある。腐ってる企業もまだまだ多いし、Disりたくなる気持ちもわからなくはない。

だからと言って、WEB系の環境が最高か？ってのははなはだ疑問。

というか、ブコメなんかでもちらほら見かけるけど、他業種をDisることで自業種を相対的にアゲようとしている言説が当たり前のようにネットに流れている時点で、その業界ってまともなの？って思える。

繰り返しになりますが、前述のようなWEB業界の状況も鑑みずに能天気にWEB上げ、SIer Disを繰り返しているPaizaは本気で「日本のエンジニアの地位を上げる」って考えているのだろうか。

本気でエンジニアの地位を上げることを考えているのであれば、先述の女性のような労務状況を改善できるよう、米国のようにエンジニアがバブルの露と消えないよう、まず自分らの足元をきちんと見てほしい、と切に感じるわけです。

以上

バブルの歴史

*1:情報サービス業は、厳密には組み込みソフトウェアや受託WEB開発業なんかも含まれますが、SIer単独な労働生産性が記載されておらず、人数比率もSIer大きいので、とりあえずSIerとしておきます

*2:細かく言うといくらでも思いつくけど、Disにしかならないのと時間に限りがあるので割愛

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

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

久しぶりの更新です。

いやー、家計簿アプリ業界、そのうち絶対にヒドい事件がおきると予想します - ツイナビ | ツイッター(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バンバンうっているわけで。。。

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

まとめ

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

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

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

三菱東京ＵＦＪダイレクト利用規定：三菱東京ＵＦＪ銀行

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

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

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

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

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

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要は、

• ドキュメント　・・・　都度メンテナンス　→　ドキュメント不要。ソース見りゃいいでしょ。
• テストコード　・・・　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対策の構築といった災害発生時の考慮もちろんのこと、ノウハウの形式知化（ドキュメント化など）など災害発生後に備えて普段の開発活動だって気をつけることは山積みです。

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

まとめ

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

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

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

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

 

以上

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

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

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

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

同じ日経記事なのに

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

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

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

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

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

資料はきちんと読もう

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

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

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

中小企業を中心に１万７９４社から回答を得ました。 

企業の約４０％ 「正社員不足感じる」 NHKニュース

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

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

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

などなど。

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

戦後生まれのいわゆる「団塊の世代（１９４７（昭和２２）年～１９４９（昭和２４）年生まれ）」が６５歳以上となる２０１５年

わが国の高齢者介護における２０１５年の位置づけ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

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

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

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

以上

だましの手口 (PHP新書)

*1:知識集約型産業(ちしきしゅうやくがたさんぎょう)とは - コトバンク

DDDの思い出２つ

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

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

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

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

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

で、その場で出た話。

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

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

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

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

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

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

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

※表現はぼかします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

以上

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