プログラマの思索

第30回IT勉強宴会で発表した資料を公開します。

【元ネタ】
第30回 IT勉強宴会ｉｎ新大阪 : ATND

関西ＩＴ勉強宴会のブログです: 第30回IT勉強宴会in新大阪　【 ソフトを他人に作らせる日本、自分で作る米国 】を語ろう

「ソフトを他人に作らせる日本、 自分で作る米国」を読んで: ソフトウェアさかば

【1】「ソフトを他人に作らせる日本、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。
数人が本の感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。
いろんな議論がありましたが、詰まる所、「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」というテーマを巡る話だったと思います。

僕は、SIとユーザ企業の両方を経験した立場から、現状の日本のIT企業(SIとユーザ企業の両方)について、話しました。

【2】「日本企業はロールが多すぎる」という問題

【2-1】SIにしても、ユーザ企業にしても、日本企業は役職が多すぎる。
特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書きがある。
さらに、○部、△部などたくさんの部署もある。
つまり、組織がフラットではなく、縦長のピラミッド階層になっていて、ロールがすごく多い。

ロールが多すぎる弊害は、特にユーザ企業で顕著。
業務システムを正式受注する前に、ユーザ企業の情報システム部門にヒヤリングしながらまずは要件定義するのが普通だが、誰が最終決定者なのか分からない場合が多い。

@hatsanhatさんは、意思決定の最終責任者はMANで探すとアドバイスされた時があった。
Money(予算)、Authority(仕様)、Needs(要求)を持つ人の略。

実際のヒヤリングで聞いてみると、予算を持つ人は情報システム部門にはおらず、経営企画部の部長が握っていたりする。
あるいは、既存の業務システムの仕様を知っている人は、ユーザ企業のプロパー社員にはおらず、協力会社の社員だったりする。
あるいは、業務システムの要望をあげる人は、情報システム部門ではなく、総務部や経理部、経営企画部の事務の女性や管理職など、たくさんの部署に散らばっていたりする。

その結果、あちこちの人と打合せのアポを取り、実際に愚痴のような要望や課題を聞き取り、その内容をまとめる作業が発生する。
その作業はかなり膨大な工数になってしまう。

【2-2】また、MANのロールが3つに分割しているだけでなく、予算の権限を持つ人が複数人のように、MANの1要素が複数人に対応してしまっている場合もある。
誰が本当の最終責任者であり、決定してくれるのか分からないのだ。
つまり、日本の組織はあまりにも権限が現場に分散してしまっている弊害がある。

そして、最終決定者が1人と判明していても、彼一人では判断できない場合が多い。
例えば、事業部長や取締役は忙しくて、既存の業務システムの仕様やあるべきシステム像の詳細が判らないために、決断できないのだ。
すると、最終決定者の一つ下の管理職が、最終決定者から委託されて、システム提案の中身を最終判断している場合が多い。
つまり、日本企業では、トップは権限はあっても本来の権力を行使しておらず、一つ下の参謀役が好き勝手に動いて決断している場合が多い。
本来の組織のエスカレーションではないし、こういう現象を下克上というのかもしれない。

【2-3】更に最悪な場合は、ユーザ企業における上記のような調整作業を情報システム部門がやるべき役割なのに、その役割を果たす能力がないので、SIやベンダー企業にその調整作業を丸投げしてしまうケースだ。
すると、SIはユーザ企業のコンサルのような立場で、ユーザ企業内部のレポートラインをどのように設計しておくと、自分たちが作ったシステム提案が稟議しやすくなり予算を獲得できるか、という「根回し」に力を注ぐようになる。

つまり、どのルートで誰に承認してもらえると、すぐに合意が取れて、プロジェクトが先に進むか、という根回しばかりに注力するようになってしまう。
こういう作業は日本社会特有の症状なのかもしれない。

個人的には、日本のユーザ企業の情報システム部門はだらしない、と思う。

【2-4】また、日本企業では決定できない会議が多すぎる。
日本企業には、ナントカ委員会という会議がやたらと多い。

すると、利害関係者が多いので、意見を集約しにくいのだ。
だから、プロジェクトマネージャ以上の人達は、1日中打合せに拘束され、しかもそれらの打合せではなかなか結論が出ないという悪循環に陥っている。

だから、司会者であるプロジェクトマネージャは会議のプロセスを事前設計するのが重要になってくる。
事前設計の内容は、どんな話で進めるかというストーリーと、会議の結論である落とし所を作ることだ。
これを「根回し」というのではないか、と最近は思っている。

この時、会議の根回しで重要なスキルは、TOCの「クラウド」(対立解消図)だと思う。
対立する意見が出た場合、その仮定や前提条件を対立解消図で明確にし、その前提条件を崩すことで、新たな提案を導き、Win-Winの関係を導き出す。
ちょうど、TOCの対立解消図から解決を図るのに似ているように思えるのだ。

TOCの思考プロセスの使い道～プロマネの説明責任に応用する: プログラマの思索

【2-5】そんな問題に対し、ロールはIT化で削減できることで解決できると思っている。
組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発へ: プログラマの思索に書いたように、論理的な業務データを扱うDA(データ管理者)、物理的なDBサーバーの保守担当者(DBA)、Webサーバの保守担当者、フレームワーク設計者、品質管理者のようなロールは、プログラマないしプロジェクトリーダーのロールに集約できる。
IT化によって作業内容が自動化されて作業コストが減った分、わざわざ、そのようなロールに分割して複雑化するほどもない。

また、Scrumは「SW開発は3つのロールで十分」と言い切っている。
スクラムの新しさ: プログラマの思索に書いたが、PO・SM・チームに期待されている役割が明確なので、それ以外のロールは不要であったり、PO・SM・チームに吸収されてしまう。

ロールが少なくなれば、その分、もっと速い開発が可能になる。
無駄なコミュニケーションをなくせるから。

【3】「開発プロセスがIT化されていない」という問題

【3-1】日本では、SIもユーザ企業もExcelによる管理作業が、まだたくさん残っている。
特に、「WF型開発で管理しきれない作業」「WF型開発で管理しきれない内部プロセス」をExcelで管理している場合が多い。

例えば、課題管理や障害管理のように、当初の計画では、課題や障害がどれくらい発生して抑制できるか、を正確に予測するのは正直無理だ。
だから、そのプロセスで発生する成果物の管理が、WBSから漏れて、その作業工数を追跡できなくなる。

あるいは、紙芝居のような画面モック、機能の実現可能性を調査するためのプロトタイプ作成、ビルド環境やテスト環境構築のような「WF型開発で管理しきれない内部プロセス」も、当初の計画で正確に予測するのは難しい。

WF型開発に固執していると、WF型開発で監視しれきない作業やプロセスが漏れてしまい、そこからリスクが顕在化してくる。

このようなWF型開発で管理しきれない作業や内部プロセスをチケット駆動で管理したい時、アダプタブルWFという補完型チケット駆動で対応する場合が多い。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索

【3-2】そんな問題に対し、先日の品川Redmine勉強会で、日経BP編集者の中山さんの講演で「今、ツール革命が起きている」という発言を聞いた。
95年頃はITで追いかけるべき対象は米国にあったが、現代は日本のWeb企業やSNSやゲームなどのネット企業だ。
彼らはツールによる技術革新の成果を利用して、開発プロセスがかなり進化している。
それに比べて、エンタープライズ系のSI、特にユーザ企業がすごく遅れている、と。
まさにそうだと思う。

ツール革命でソフトウェア開発が変わる: プログラマの思索

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」　#47redmine: プログラマの思索

SIやユーザ企業は、日本の製造業の成功体験が強すぎて、プロセスの標準化に注力しがち。
だが、頑張って標準化した技術やプロセスは、外部環境の変化に追いつけず、すぐに陳腐化してしまい、役立たなくなる。
標準化した技術やプロセスに外部環境の変化を取り入れて、標準化を守ろうとすると、そのコストがあまりにも大きすぎ、大量の無駄なドキュメントを作るだけになってしまう。
CMMIやISOに追随する企業は特にそうだろう。

それに対し、最近はツール革命を利用して、プログラマ主体の軽量な開発プロセスが主流になりつつある。
チケット駆動開発、Infrastructure as Code、継続的デリバリー、Social Codingなどのキーワードがそうだ。
いずれも、開発プロセスの自動化ないしコミュニケーションの活性化に注力しており、それによって、新たな効果が生まれている。
今もなお、ツール革命でどこまで可能なのか、試行している最中だと言える。

ただし、PMの観点のツールの機能はまだ弱いと思う。
プロジェクトマネージャになれば、利益を確保できるプロマネが良いプロマネなので、EVM、原価管理、要員管理がとても重要な作業になる。
しかし、それらの作業がまだExcelベースで、過去の経験則で判断している場合が多い。
EVM、原価管理、要員管理についても、PMBOKで既に理論として仕様は提示されているのだから、ツールでIT化できるはずと思っている。

【4】「導入したERPが陳腐化しやすい」という問題

【4-1】最近思うのは、ERPという名の業務システムは5年経つと必ずリプレース作業が発生する。
その理由は様々だ。
パッケージ製品の保守サポート切れ。
サーバーの保守期限切れ。
ミドルウェアのVerUp対応、セキュリティパッチ対応など。

最近はもっと速くなり、せっかく導入したシステムを3年くらいでリプレースする場合がある。
そして、サーバー交換時にミドルウェアも一気にVerUpして、デスマーチ案件が発生するパターンが非常に多い。

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

普通のプログラマは、新規開発案件よりもリプレースという名の案件の経験が多いのでないだろうか？

【4-2】その場合、設計技法はリバース・エンジニアリングが多い。
つまり、既存システムの要件や仕様をリバースして設計書を書き起こし、その内容からあるべきシステム像を提案して、最新技術を使ったシステムでスクラッチで開発するパターン。

普通は、運用保守していくうちに、設計書も保守されなくなり、設計書が本番システムの仕様と違ってくる。
だから、リバースエンジニアリングという無駄な設計作業が発生する

最近思うのは、新規開発の設計技法よりも、既存システムを理解するための設計技法の方が業務システム開発では重要な気がする。
すると、既存のUMLなどのオブジェクト指向の手法は実はあまり役立たない。
むしろ、DOAの技法を使って、既存の画面や帳票からI/F項目を抽出し、ER図を書き出し、機能とテーブルのCRUD表を作る方が、その後の開発にはるかに役立つ。

つまり、DOAという枯れた技法の方が役立つように思える。

【4-3】また、最近は特に、仕様凍結して開発する手法が取りづらい。
WF型開発の典型定期な開発手法は、要件定義で固めた要件をFix(仕様凍結)し、1年後にリリースするというパターンが多いが、外部環境の変化が速すぎるために、この手法が通用しなくなってきた。

だから、受注直後の見積内容で、要件定義工程は準委任契約で要件を抽出し、設計工程直前に再見積りして、設計以後の工程は請負契約を結ぶというパターンが多い。
つまり、2段構えで見積りするので、純粋なWF型開発よりも見積の精度はよくなる。

あるいは、要件定義で抽出した要件をサブシステム単位に分割して 五月雨式に開発するパターンも多い。
このパターンならば、要件のブレも小さく、リリース時期も早めに行える利点がある。

【4-4】さらに最近つくづく感じるのは、システム提案書が書きにくいことだ。
新しい技術を使ったアーキテクチャ設計が難しい。

例えば、最近のシステム提案では、クラウド、モバイル、データマイニングのキーワードは必須だ。
顧客も日経新聞などで最近のIT事情は知っているので、それらのキーワードがなければ、逆に古臭い提案のように思われる。

しかし、クラウドやモバイルを使ったアーキテクチャ設計は、汎用機の頃や、JavaによるWebシステムの設計ノウハウとは全く違う。
かなり癖があるし、技術も枯れておらず、どの場面で有効なのか、見極めにくい。

すると、プロジェクトマネージャの過去の経験が有効でない場合が多い。
普通のプロジェクトマネージャは40代、50代であり、彼らは汎用機＋Cobolの成功体験に固執しすぎている。
彼らの経験は全く通用しない。
だから、彼らはシステム提案書を書くのにかなり苦労している。
実際は彼らはもはや書くことができず、部下であるプロジェクトリーダーに書かせている場合が多い。

【4-5】いわゆる超上流工程における最近の課題は、ウォーター・スクラム・フォールから脱却できないか？という問題だ。
開発工程がアジャイル開発であっても、肝心の要件定義は従来のWF型開発の延長であり、仕様凍結している。

つまり、仕様凍結した要件の範囲内で、アジャイル開発をしているに過ぎない事例が多い。
「ハイブリッドアジャイル開発」もその事例に相当するだろう。

本来のアジャイル開発では、要件定義も変化を取り入れて、要件を入れ替えたり、不要な要件は削除して除く。
そのような柔軟な要件定義があれば、外部環境の変化に合わせて、ユーザの要求をより速く反映しやすくなる。

だから、超上流工程をアジャイル化するために、アジャイルコミュニティから数多くの手法が試行されている。
リーンソフトウエア開発、リーンスタートアップがそうだし、平鍋さんが最近提唱している「IMPACT MAPPING」もそうだ。
これらはいずれも、要件定義も軽量かつ反復的なプロセスを志向している。

【5】他の方々のお話のほとんどは「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」がテーマだった。
いわく、昔は、欲しいシステムを実現するには、自分たちで作るしかなかった。
内製化しか手段がなかった。

でも、今は、パッケージ製品を買うとか、特注でシステムをSIに発注するとか、SaaSで使う、とか、いろいろな選択肢がある。
内製化は一つの手段に過ぎない。

本来はユーザ企業でも内製化したい。
自分たちの業務システムを作りこむことで、自分たちの業務をスピーディに強化できる。
自分たちの業務システムの技術や運用ノウハウも社外に流出しない。

しかし、自社で内製化しようとするとハードルが高い。
ユーザ企業が若い社員にプログラム開発をさせるが、ある程度育つと設計や運用に回り、プログラム開発しなくなる。
若い社員も、単価の高い設計や管理などに向いてしまう。
プログラム開発の楽しさが伝わらない、など。

皆さんは色々話されていたけど、僕は違う意見を持っている。
おそらく、ユーザ企業に限らず、日本のIT企業はプログラミング技術を軽視している文化があるから、人が育たないのだ。

プログラミングを重視する文化にしたいなら、最終的には、オープンソースへの理解やアジャイル開発の推進に向かうだろうと直感している。
実際、プログラマが生き生きとしている職場では、オープンソースに関わる技術者が多く、彼らはアジャイル開発の好きな人たちが多いはず。

しかし、日本企業は、自社を作業場にした開発は自社のコストだから、オープンソースで公開するのはご法度だろうし、そもそもアジャイル開発のことも知らない。
だから、そんな文化を生み出せない土壌がある。

しかも、汎用機からクラサバ、そしてWeb、さらにモバイルとクラウドへ技術が変遷した今、プログラミング技術から離れた人ほど、新しい技術で設計するのは困難だ。
システム提案書が作りにくいと嘆くPMがまさにそうだ。

アジャイル開発は常識だ: プログラマの思索にも書いたが、ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。

そういう問題意識とソフトウェア開発の特徴を持ち続けることが重要だろう。

【追記】
My Aha! (or maybe sometimes blah) Moments In San Francisco: 『「ソフトを他人に作らせる日本、自分で作る米国」を読んで」』を読んで

L'eclat des jours(2014-03-10)　日本型ソフトウェア開発

エンジニアリングの話と、ビジネスの話を混ぜるとよくわからなくなるよね - おろかな日々