バッチ処理のあれこれと、SLA
風邪引いてしばらくブログ更新サボってました。
上記記事について、気になったので。ブコメで言及ももらったし。
ウィキペディアのバッチの利点って若干記載が古い
- 多くのユーザーがコンピュータのリソースを共有できる。
- 処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。
- 人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。
- 高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。
バッチをリソース目的だけで使うってずいぶん古い話だなあ、と思って編集履歴をたどってみたら、2006年の記載でしたか。
記載をたどってみると分かるんですけど、上記の内容って「メインフレーム」のバッチ処理に対する利点なんですよね。
そういった意味では、現在のバッチの設計とはちょっと概念が違うんじゃないかなって思います。
分散アーキテクチャの静的同期処理としてのバッチ
じゃあ、現在バッチはどのような使われ方があるのか？
実際にバッチを設計している現場だと、分散アーキテクチャにおけるリコンサイル処理で利用される場面が結構多いです。
具体的には
- SOAのような分散アーキテクチャにおける、各サーバに分散されて格納された日中フローデータのズレ・不整合のリコンサイル
- 企業間取引における日中取引結果の各企業間でのリコンサイル
- 金融取引における清算機構の清算結果と日中取引結果のリコンサイル
など。
これをミッションクリティカルなシステムで実現しようとした場合、夜間ぐらいしか業務を止めるヒマがない＝リコンサイルを夜間バッチで処理せざるを得ない、なんて状況になったりします。
でもこれらリコンサイルって、「正常なデータを企業間システムやSOA内の分散サーバにて同期を取る処理」なわけで。
業務的な言葉を一旦外せば、分散アーキテクチャ内を刻一刻と動くデータを処理するリアルタイム処理に対し、静的な同期によりデータ不整合を防ぐバッチ処理、といった形となります。バッチは、システムにおけるデータ管理・自己復旧の技術となるわけですよね。
まあ、何が言いたいかというと、バッチ処理は、メインフレーム時代のリソースシフト目的の処理から、分散アーキテクチャにおけるデータ管理技術に転換して来ているんじゃないかな、と言えます。
※他にも、システムの自動リリースや自動構成管理変更などの運営自動化などのバッチの使われ方もありますが、きりがないので除外で。
ハンズの本当の評価
で、悪玉にされがちな夜間バッチですが、ハンズの話で本当に注目するべきところは「夜間バッチを廃止したこと」ではなく「夜間時間帯をバッチを使用しないことで突き抜けリスクを受け止めるSLA管理」に着目するべきだと思います。
ぶっちゃけ言ってしまえば、上記の通り業界間リコンサイルが必要となるような大型のエンプラ系基幹システムでもない限り、夜間バッチをなくしてもなんとかなる場合って結構あるんですよね。特に社内独立で動いているようなSMBのシステムなら。
ただ、夜間バッチをなくせない理由って技術的な面よりか「社内のユーザ部門からの朝業務開始できないかもしれない不安」とかのSLAにより実現できない場合が多かったり。
言い方を変えれば、夜間バッチをなくした場合に発生するリスクをユーザ（この場合は社内部門）とシェアし、メリットを感じさせることができれば実現できると言える。
ハンズが夜間バッチを廃止できたのも、そういったユーザ部門掌握がきちんととれたから、と言うのは大きいんじゃないかな。
でなきゃ、夜間バッチを廃止することで「中度リザーブド60万が、夜間8時間停止で45万になります」なんていっても、「たった15万ぐらい安くなるためだけにリスクが負えるか」なんてユーザ部門から反発を食らってしまうわけで。
これはハンズの自社システムの例だけど、SIerの受託でも同じかな。
ユーザときちんとSLAを握りさえすれば、「夜間バッチにて、多少トラブルが発生しても大勢に影響がなければ翌日フォローで対応する」なんて感じで、夜間コール数年間0件で運用できるようにすることも難くなかったりもします。
ユーザビリティを下げないようにするためには夜間バッチが必要、でも、極力運用負担を減らしたい、なんてニーズはよくありますよね。
自分がコールで叩き起こされるのが嫌で、どうすればよいかさんざん考え続けたのですが。。。
重要な事は、夜間バッチを廃止することではなく、皆が幸せになれる適切なSLAを考えるか、じゃないかな。
まとめ
まあ色々書きましたが
- Wikipediaの内容は最新じゃない場合もあるからあんまり鵜呑みにしないほうが
- バッチ処理はリソースシフトだけではなく、分散アーキテクチャを管理するための技術としての利用方法を固めつつある
- 夜間バッチ廃止に拘るのではなく、適切なSLAを考えることが重要
なんて感じかと。
とくに3つ目が一番重要で、夜間バッチが悪玉にされるのも「過剰なまでに高く厳しいSLA」が原因だろうなってつねづね思うわけで。
これを、関係者が「まあいーか」といえるようなラインまで調整できれば、多分色々な苦難が解決されると思います。
以上
プロジェクト特性とドキュメンティングルール
いいこと書いてあったので一言何か言おうと思っていたのですけど、すっかり忘れていた。。。
ドキュメントって使い方次第では毒にも薬にもなるのですけど、プログラミングほどお作法や考え方がまとまっていないと常々感じております。
コーディングルールならぬドキュメンティングルールって案外重要なのですが、いろんなプロジェクトの様子を聞いたところ、なんとなくの過去踏襲って事例が多く、きちんと定めてないチームも多いんですよね。
プロジェクト特性とドキュメンティングルール
機能仕様書を読みやすくするためのテクニックはどれも納得いくもので、参考にすべき内容と思いますが、一点だけ補足しておきたい項目があります。
【2】仕様書テンプレートは作らない
企業や組織内で、「機能仕様書に書くべき項目を定型テンプレートにまとめておきたい」という誘惑に駆られるかもしれませんが、一般論として筆者はお勧めしません。
開発プロジェクトにはそれぞれに異なる事情があります。機能の規模やシステムのアーキテクチャもそれぞれ異なるでしょう。必然的に仕様書に記載すべき項目の種類や粒度も変わってきます。従って、その都度項目を洗い出すことが設計作業としてむしろ重要です。
（中略）
テンプレートが可能なのは、システムの対象分野や規模を限定できる場合だけだと思います。
常々感じていることで、「プロジェクト特性に開発工程や成果物は準じる」ってのがあります。
プロジェクトが、受託か内製か、バッチかオンラインか、モノリシックアーキテクチャか分散アーキテクチャか、みたいな感じの様々な要因があるかと思いますが、それらの特性は成果物であるプログラムに影響を与えますが、同時にドキュメントにも影響を与えます。
受託や内製の違いはドキュメントの納品の有無の違いにより、記述レベルの注意が必要となります。
バッチかオンラインかの違いは、利用ユーザに対する外部仕様が異なりますので、仕様の考え方が異なります。
モノリシックアーキテクチャと分散アーキテクチャの違いは、システム境界と公開仕様の考え方が違います。
とまあ、つくろうとするものが違えば当然必要となるドキュメントも違うということなんですけど、PMOとかそういった実働部隊じゃない人に限って「会社の標準フォーマットに従ってない」とかミョーな指摘をもらうハメになるんですよね。
なので、プロジェクトが開始されたら、真っ先にドキュメントの標準化（テンプレ化）、ドキュメント規約を定めてしまい、「我々のチームでは今回のプロジェクトに合わせて社の標準フォーマットを参考にドキュメント規約を作成した」って宣言してしまうのが個人的には楽かな、と思います。
外部からの余計な声に惑わされずに済むだけでなく、チームのメンバーもドキュメントを書きやすくなり、「個々の考えを形式知化し、共有する」というドキュメントの目的を達成しやすいので。
プロジェクトをまたいでのテンプレ化は参考程度にしかならないと思いますが、プロジェクトに特化したテンプレ化はお役立ちになると思います。
個人的に感じるプロジェクト特性とドキュメントの関係
以下、個人的に感じたドキュメントとプロジェクト特性の関係。
粒度（右ほど粒度が細かくなる）
- 保守期間（短 ＜ 長）
- 契約形態（内製 ＜ その他企業 ＜ 公共 ＜ 銀行・銀行関連）
- 開発形態（社内 ＜ ニアショア ＜ オフショア ）
量（右ほど作成するドキュメントが増える）
ただの個人的な感想なので、代表的なものだけ。
まとめ
取り留めもなく色々書きましたが、一番肝心なことは、成果物として、どのようなものを作成するかの定義は、プロジェクトを成功させるためには重要なファクトであり、マネージャの腕の見せどころでもあると思うわけです。
以上
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されております。
これを受けて策定しようとしたのが、２０１５年４月からの新規の「政府システムの整備及び管理に関する標準ガイドライン」です。
これには、以下の様な記述があります。
分離調達の見直し
新ガイドラインでは、合理的な調達の基本単位の考え方を明示するとともに、過去促進していた情報システム設計・開発工程における分離調達を見直し、過度な分離調達を抑制
そう、従来の政府主導の分離調達を見直し、一括調達、要は必要に応じてベンダ任せ（極論すれば丸投げ）を再度認めようって腹なんですよね。
過度の分離調達でうまくいかないのであれば。ベンダのノウハウを使う方式にしてしまおう、ってわけで。
こういう記載を見れば、元記事の木村氏、きちんと政府調達のガイドラインを見てないんじゃないのだろうか。
※まあ、従来から丸投げはいけないって純朴な考えから言っているわけで、丸投げはダメありきでしか考えてないから読み飛ばしているのかもしれませんが。。。
米国では一括発注を活用している
ところで、この方は普段出羽守なわけですけど、今回の記事では「米国政府を見習え」って言ってませんね。
実は米国政府では、システムは一括発注がメインだったりします。
実質的には有力プライム（大手ベンダー）への一括発注がほとんど
図２に示すように、システム構築全体はプライムコントラクター（大手ベンダー）が握っている。ここでは、実質的に有力プライムへの一括発注がほとんどで、プライムが受け、（必要に応じて）入札時・入札後にサブコンに振り分けている。特に、ミッションクリティカルなシステムでは、実績・関係の両面で省庁の厚い信頼を得ているベンダーにしか発注は行われない。
信用力ある大手ベンダーがシステム構築プロセス全体のend to end responsibilityを担保しているわけだが、これは、日本での状況の生き写しである。
ボストン・コンサルティングのレポートで、10年前のモノですけどその時からさほど変化があったと聞いてないので引用してます。
実は米国政府では、システム調達の不達、トラブルが多発したことから、プライムコンストラクタへの一括発注におおよそ20年前、1990年代から切り替えてます。
工程の分割などは原則行わない、プライムベンダの統括責任で行動させる、プライムコンストラクタがサブコンストラクタを必要に応じて招集するなどの、開発を成功させることを再優先にした構造となってます。
また、分割発注自体は0ではないですが、日本のよう工程別分離調達ではなく、要件別の分離調達で実施がほとんど。
日本がベンダをコントロールしようとして工程別の分割調達で失敗している状況とは対比な状況です。
ちなみに、一括調達とはいえ、日本と同じで、発注時にすべての要件を決めきれず、後追いで追加するなんてのもしばし起きうる話です。結局システム開発なんて人間が行う訳で、あまり日米関係ないってわけですね。
元記事で言っているような発注時点できちんと要件を決めきれるなんて米国政府だって実現しきれてない話です。米国ではそういった問題をベンダの権限拡大と契約(実費償還型契約など)で上手くリスクを分け合う形にしているわけ。
※とはいえ、ITコスト削減のため、近年は日本の請負契約と同様の固定費用契約を増やしてきているみたい。
なんで分割調達となったのか
じゃあ、日本のIT業界は米国の10年後追いと言われる中、なんで米国の後を追って一括発注を採用せず、原則分離調達などという無理ゲーに手を出したのか。
元記事にも一部書いてありますけど、「費用の透明化」と「公平な入札機会」が大きな理由としてあります。
費用の透明化は、システム構築コストとして無駄金を使ってないか、不正な取引がされてないかのチェックが必要という世論の高まりを受けてです。
現在の分離調達の検討が行われた時、時の総理大臣は小泉純一郎元首相でした。
うろ覚えですが、財政健全化に向けての構造改革の一環で見直しが行われた記憶があります。
※当時竹中平蔵氏のブレーンで、現民主党の岸本周平氏が「政府調達制度と IT システム―“IT ゼネコン”を育てたの誰か」*2みたいなレポートを書いていた時期ですね。
公平な入札機会は、要は、一括発注だとリスクが大きすぎて大手ベンダだけしか請け負えず、IT業界の多重請負構造を改善できない、中小ベンダも直接入札参加できるよう改善して欲しいという要望を受けてのものです。*3
開発ノウハウが固着してしまい、随意契約に頼らざるをえないと言った問題も指摘されてました。
こういった改善のために、分割調達となったわけですが。。。
結果としてみれば、費用の透明化は実現できたものの、IT調達の不達、失敗により多額の税金をドブに捨ててしまう事となってしまいます。開発の際も余計なリスク＝コストを抱えることとなり、結果としては必要経費が増加へとつながってしまいます。
開発工程を分離したものの、前述したように後工程ほどハイリスクとなってしまい、結果として大手ベンダが開発工程も請け負うようになっている始末。特許庁システム更改の時の開発工程をTSOLが請けたように。
「IT投資の無駄を無くせ」「多重請負を解消しろ」って掛け声の元の改革は、元々の問題を解決するどころか、むしろ新たな問題を発生させるだけになってしまったわけです。
まとめ
えらく長くなってしまいましたが、結局言いたいこととしては
「元記事はきちんと問題理解して記事書いているのかな？」
という疑問です。
少なくとも、JEITAの指摘しているように、分離調達の問題点を指摘することが開発者視点で必要だと思ってますが、それに触れられてません。
実効性のない問題提起は、結果として「新たな問題を発生させるだけ」になるのじゃあ無いのかな、なんて思います。
この極論暴論で語られる問題提起はまあだいたいそうなのですが。
以上
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2013/09/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
IT技術者の視点で見たホワイトカラーエグゼンプション
しばらく前の記事ですけど、上記の記事の感想を書いておこうと思っていたのでした。
裁量労働制からどう変えるのか？
そもそも、システムエンジニア自体、既に裁量労働制の対象なわけで。
所定時間内在業代は36協定で労使合意がとれていれば出ない状態なわけでして。
正直ホワイトカラーエグゼンプション(以下WE)の対象にする必要ないんじゃないかな、と思っているのですが、どうやら労働政策審議会では思惑が違うようです。
一定の年収要件を満たし、職務の範囲が明確で高度な職業能力を有する労働者を対象として、長時間労働を防止するための措置を講じつつ、時間外・休日労働協定の締結や時間外・休日・深夜の割増賃金の支払義務等の適用を除外
労働政策審議会 (労働条件分科会) ｜厚生労働省 資料より抜粋
上記の記載内容を見るに、裁量労働制との違いは「所定労働時間外労働」の取り扱いの違いみたいですね。
現在の裁量労働制でも、深夜など、所定労働時間外の労働については残業代として割増賃金が支払われるんですけど、それがなくなる点が違いとなる模様です。
システムの仕事していると、夜間立会などざらにあるわけですけど、別に自分の意思で行っているわけではなく、お客の業務都合といった半強制的なモノがほとんどなわけで、ぶっちゃけ自己の裁量で進めるものじゃあ無いと思うんですよね。
殆どの場合会社都合なわけなので。
それを、自己の成果のための自由の働き方のために制限を無くすってのはちょっと違う気がするんだけどなあ。
IT技術者の適応範囲
ところで、元記事では「労働時間規制の除外、ＩＴ技術者も対象」なんて記載がありますが、労働政策審議会の資料を見るに、プログラマは適応除外になるんじゃないかな、なんて気がします。
(2) 情報処理システム（電子計算機を使用して行う情報処理を目的として複数の要素が組み合わされた体系であってプログラムの設計の基本となるものをいう。）の分析又は設計の業務
「情報処理システム」とは、情報の整理、加工、蓄積、検索等の処理を目的として、コンピュータのハードウェア、ソフトウェア、通信ネットワーク、データを処理するプログラム等が構成要素として組み合わされた体系をいうものであること。
「情報処理システムの分析又は設計の業務」とは、(i)ニーズの把握、ユーザーの業務分析等に基づいた最適な業務処理方法の決定及びその方法に適合する機種の選定、(ⅱ)入出力設計、処理手順の設計等アプリケーション・システムの設計、機械構成の細部の決定、ソフトウェアの決定等、(ⅲ)システム稼働後のシステムの評価、問題点の発見、その解決のための改善等の業務をいうものであること。プログラムの設計又は作成を行うプログラマーは含まれないものであること。
厚生労働省基準では、「概要設計・要件定義」「外部設計・内部設計」「システム運用・保守」に該当する業務を担当するエンジニアは自己の裁量で仕事を行うことが出来ると判断してます。
そして、WEの検討資料を読んだ感じ、裁量労働制を改善しつつ、WEを導入するみたいな記載から推測するに、現在の裁量労働制対象職種から、年収基準が適合する職種が対称となるような形かな、との印象を受けました。
ざっとまとめると以下の表の様な感じかと。
| WE | 裁量労働制 | 通常労働 | |
| SE(年収1075万円以上) | 対象 | 対象 | 対象 |
| SE(年収1075万円未満) | 対象外 | 対象 | 対象 |
| プログラマ | 対象外 | 対象外 | 対象 |
ところで、昨年某社のブログだっけか、「SIerのプログラマは言われたままにプログラミングするだけで労働集約的。WEBプログラマなら自分でサービスを考えながら創造性を持ってプログラミングできる知識集約だ」とかって主張をさんざん見た記憶があります。*1
今までは裁量労働制でもなく、WEの対象とならなかったプログラマも、厚生労働省のあまりIT業界の労働実態に詳しくないお役人あたりが変に唆されて、「裁量を持って仕事が出来るんだし、WEや裁量労働制の対象にしてもいいよね」なんて変更されたりする可能性も0ではない、かも。
グレーゾーンで名ばかりSEで裁量労働制*2にしていたのが、大手を振って裁量労働制にできて経営層は大喜び、とか。
ま、そこまで変更にはならないか。
多分、現状通り対象外でしょうけどね。
そんなこと考えながらpaizaの求人見たら
勤務時間帯は基本的には固定されず出勤・退勤の時間は自由に決められる裁量労働制のIT/Webエンジニア、プログラマ求人情報です。
名目だけ、だよね。。。
まとめ
色々書いてみたものの、正直、既に裁量労働制なので、WEに変更したとして多分給料も変わらないだろうし、あまりメリットが見えないんだよなあ、って思います。
夜間立会の残業代も出なくなりそうだし。
裁量労働制からWEに変わったことでメリットを感じるIT技術者は、どんな人なのだろうか。。。
ぜひとも、モデルケースを見てみたいものです。
以上
恐怖のPM募集要項にダメ出しする
国内銀行勘定系システム再構築プロジェクト全体PM募集 PM/PMOの案件ご紹介 | 【BIG DATA NAVI-ビッグデータナビ】 |
ネタだと思いたいんですけどねえ。一応求人として問い合わせ先もあるってことはマジなのだろうか。
ただのネタと信じたいのだけど。。。
必要スキルの日本語が怪しく、実際のとこのニーズがよくわからないのですが、グッと意訳して「大手ベンダに過去所属し、多数のパートナーベンダの関わる高難易度プロジェクト(1万MM以上くらい？)の案件で火消しPMとしての遂行経験がある人、ユーザ企業側PMとして募集」ぐらいの意味かなあ。
それなりにマッチングしているけど、関わりたくない。。。
まあ、とりあえずダメ出ししておきます。
ダメな点１ ： 業務内容があいまい
クライアント側PMは良いとして、どのくらいの権限がもらえるのだろうか？火消しを行うのであれば、極端な話要件の切り捨て、次プロジェクトへの申し送りなど、かなりの利害調整が必要となります。
再構築プロジェクトだと、「あまり業務上重要じゃないけど、役員が肝いりで導入した機能」みたいなものもバッサリと切り捨てなければならないんですけど、こういうのに限って社内政治で身動きできなくなったり。
なので、通常はユーザ企業のそれなりに権限がある人が担当しないとまとまらないんですよね。
契約社員契約と書いてあるあたり、おそらく権限なんか与えられないんだろうな。。。粛々とプロジェクト遂行しろって追い詰められる状況が想像できて仕方ないです。
ダメな点２ ： 銀行業界経験がBetter → Mustにしたほうが
ダメな点１に通じるのですが、火消し案件だと案件を切り捨てる判断が必要ですが、業務知識に通じてないと、要否判断がまともに出来ないこともしばしば。
やむを得ず削った機能が、実はその後業務の根幹に関わる機能だったりすると目も当てられません。
業務知識がBetterって書いてありますが、ただプロジェクトを遂行すれば良いのだろうか。それで賄えないから今回募集したのじゃないのかな。
ダメな点３ ： 単価安すぎ
ざっくりと内容見るに、PMとしてのスキルとして高レベルの人材を求めてそうですけど、上限１３０万の単価は安すぎでしょう。
SIerではなく、フリーランス向けの求人だから、通常の単価より格安でも問題無いと判断したのだろうか。。。
まあ、ウチなんかもユーザ企業のPM支援なんて仕事もやってますが、今回みたいな高リスク案件なら３倍以上の単価で請求するんじゃないだろうかなあ。手を出したらやけどすることが目に見えているし。
上限単価１３０万円／月の案件だと、優秀なPMだと他にもっと割がよい案件へアサインされてしまうんじゃないかな。
まとめ
ブコメ見ると、某メガバン案件じゃないかと噂されてますが、昨年は他にもシステム更改案件はいくつかあったもようなので、もしかしたら違うかもな、なんては思います。
とはいえ、この求人。どこの会社の案件だろうがきな臭い匂いしかしません。
大規模炎上案件を経験したことありますけど、どんなにタフなメンタルがあっても、肉体的にはボロボロになるからなあ。
願わくば、現場のエンジニアが健康でありますように。。。
以上
バグとプロスペクト理論
直接は関係ないんですけど、これ読んで思い出したので。
バグとプロスペクト理論
長期的に利用されるシステムやソフトウェアって、殆どの場合何らかの改修開発が行われるわけですよね。
で、修正するとバグも発生することがあるわけですが、改修開発の場合「新機能バグ」と「デグレバグ」がおきます。
新機能バグは、改修で新たに追加しようとした機能で発生したバグ。要は、追加機能が目標の機能を達成していない場合のバグ。
デグレバグは、改修してない既存の機能で発生したバグ。まあ、変更してない部分で思わぬトラブルを引き起こしたパターン。
バグはいずれにせよ顧客満足度を下げるものですけど、どちらのほうがユーザの不満を高めるかというとデグレバグの方が高めると思ってます。
理由は上記の図の様なプロスペクト理論がバグにも適応されるから。
プロスペクト理論は「損失回避バイアス」。
同等の利益と損失を比較した場合、損失を回避するようバイアスがかかる、ってやつです。
つまり、新規機能のリリース延期をユーザに宣言するのと、無理矢理リリースした結果既存機能にデグレを生じさせるというのでは、時に後者のほうがユーザの満足度を下げる原因になるってことですね。
そんなこんなもあって、オッサンのとこのシステム開発の現場では、デグレバグはご法度、みたいな品質管理を行っているんですね。
テストの自動化など、ゴニョゴニョと。。。
まとめ
結局のところ、ソフトウェア開発をビジネスにするってことは、顧客満足度を如何に向上させるかという視点で、行動ファイナンス等の考え方が適合されるなって場面があると思ってます。
今回のバグの件もそう。今回はプロスペクト理論を提示しましたけど、他にも品質管理の考え方として適応できそうな物があります。
そんなこんなもあって、新規機能の追加を現行機能保証より優先しちゃったらユーザの怒り爆発だよな、なんて元記事見てたら思うわけです。
まあ、アメリカのベンダと一緒に仕事して、現行保証のところで痛い目を見たことが数度あったので、さもありなんって感じな。。。
ま、デグレには気をつけておきましょ。
以上
