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

日本実業出版社の今野様より献本御礼。

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

東京地方裁判所でIT事件担当の調停委員を努めておられる細川氏が、ご自身の経験をまとめてシステム開発のモメるポイントを整理し「人の振り見て我が振り直せ」を啓蒙する位置づけの図書になっております。

こう書いてしまうと非常に堅苦しいですが、モメるポイントをわかりやすく伝えるために「IT事例に詳しい美人弁護士に相談する」というカジュアルな設定になっています。塔子さんがその弁護士役で、厳しい指摘がコンビネーションブローのように続いており、爽快感がありました。

一部、本書の会話内容をご紹介します

彩音　「もう設計も終わる時期なのに、また要件からやり直し！そのうえ納期は全然延ばしてくれないなんて、お客さんひどくないですか？」

塔子　「何言ってんよの。要件定義工程の完了時点で本当に要件定義が固まっているプロジェクトなんて、アタシを美人だと思わない男よりも少ないわ」

いきなり飛ばしてくれるなぁと。いや、その通りですけれども！＞要件が本当に固まってるわけない

要件定義工程は委任にすればいいじゃんって言う人いるけど、委任でやるのはいいとしてもそこでやった作業が100%の要件になるかといえば、それも違うわけで。

塔子　「ベンダは、要件の追加変更要望があった時に、場合よっては追加見積りも必要って判断が必要って判断がなされてるわ」

彩音　「一応、他の機能を削ることもお願いしてるんですけど」

塔子　「現実そんなにキレイにいかないでしょ。ダメなもんはダメ。費用が必要なら必要ってちゃんと言わなきゃ」

彩音　「そんなことお客さんに言いにくいです」

塔子　「最終的に、どうすればユーザーの信頼を得られるかを考えなさい。この程度のことも出来ないんじゃ、人から金取ってITベンダやってる資格なんて無いわ」

随分とヘビーな会話をカジュアルにされてますが、これが本書の稀有な切り口で面白いところです。

提案された解決策についてもそれが出来たらなぁって思うところもありましたが、それこそが解決策を提示された時の一番の感想ということで・・・。裁判事例を引き合いに出して司法的な判断を利用しつつ責任の是非を問う切り口はとても説得力がありました。

ユーザーとベンダーの共同関係を再考する

僕の問題意識の中で、「ユーザーとベンダーがどうやって共通言語を持ちながら、システム開発を進めることが出来るのか」というのがずっとあります。本書はそれを再考するとても良い機会でした。

システムは料理をつくる工程に非常に似ています。トマトソースのパスタという完成図は大体決まってます。ただ、パスタを作る工程やトマトソースを作る工程はレシピによって千差万別で、そのレシピの妥当性を判断するには専門的な知見がどうしても必要になります。レシピ通りにモノを作らなくてはなりませんが、そのレシピの正当性を関係者で吟味できるのか。そのギャップが埋め切れずモメるケースは、皆さんもよ〜くご存知かと思います。

要件定義段階で全ての要件をFixするのは無理というコンセンサスは、僕がこの業界に入った2003年頃からありました。ただ、やり過ぎると不信感も生まれます。また「その積みって要は保険かけてるだけ。SIは保険屋であるべきなのか」と業界内部からも批判の声が上がってます。

本書でも「正当な費用を理解できない所とは商売をすべきではない」「その場しのぎで取り繕って、問題を先送りする方がよほど不誠実」とありました。何が正当な費用なのかをユーザーにご理解頂くのかが最も難しいのですが、超えないと行けない問題です。正当な費用であるとご理解頂ける努力をしないとなぁと改めて感じました。

また、管理側に近い立場のエンジニア・マネージャの方なら、受託／サービス問わず要件定義やプロジェクト管理でモメるポイントが上手くまとまっているので、振り返りに使える一冊になっています。

とても便利なチェックシート

本書はモメる事例集に閉じること無く、プロジェクトがモメるポイントのチェックリストや成果物サンプルなどを用意してくれており、現場でそーゆー問題が起きた場合はこうするも一考やで、という転ばぬ先の杖も用意してくれています。IT事件担当の調停委員という立場から逆算して解決策を提示するアプローチは、一読の価値ありです。

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

トレンダーズの2013年第１四半期決算の営業利益が98%減の200万円な件

私の観測範囲が狭いということもあるんでしょうが、ある企業の決算において営業利益が98%減になった事例を知らないので飛びついてしまいました。この会社は平成24年に上場しておりそれ以前の数字はわからない為、2期のみの比較となります。

決算期	売上高	営業利益
H26年第１四半期	3.49億	0.02億
H25年第１四半期	3.98億	1.12億

ソースは平成26年３月期 第１四半期決算短信(PDF)にあります。

売上が12.3%減。不景気ですしまぁこれぐらいはどうってこと無いよなって思ったら、営業利益がとんでもなく減少しています。98%の減少です。トレンダーズのIR資料を読んで、原因は以下の２つにあると思います。

各事業のシナジーが全く見込めない件

１つは、大手顧客企業の開拓が想定通りに進まず大型案件の受注が減少したこと。ステマ問題があったことをほのめかす記述がIR資料に書いてあるので、ペニオク的なやらかしがあったんでしょう。「マックのステマ疑惑で非難も」上場したトレンダーズの正体（1/5） | ビジネスジャーナルに詳しい。

これに嫌気をさしたクライアントが逃げ始めてwomediaとかいうサービスの売上が下がり、営業利益も半減したとのこと。このサービスの利益率は非常に高かったので大型案件の失注・撤退が響いてる模様です。御社の商品をwomedia会員に即したターゲティングをして体験レポートというブログを通じてプロモーションしてあげますよ、というサービスらしいですね。

他にも２つ事業展開しています。１つが、Amazeというもの。会員数が10万突破したそうです。ポンパレが流行った時に出来たのかな。プランという単位で無料でコスメがゲットできたり旅行に行けるというサービスのようですが、2年間で250件程度のプランしか無いので会員数に対しては圧倒的に案件数が少なく、だんだんと飽きられて死んでいる模様です。10万人の会員がいるはずなのに、Tweet数が0とかあり得るんですかね・・・。

もう１つがキニナルモンというサービス。iPhone/Androidアプリの提供。内容はクイズに答えてFB/TWにPOSTしてポイントゲットしてお小遣いを稼ごうというもの。Amazonギフト券などを引き換えられるらしい。現在15万人が落としたそうなんですが、50万になってもだから何やねん。ポイントはトレンダーズの負債そのもので、B/Sにしっかり負債として計上されています。733万円が引当金として。どうやってトレンダーズにカネが落ちるのか見えないんですね・・・。

全てのサービスが利用者無料であり、射幸心を煽る仕組みもないので利用者から課金を行うことは大変厳しく、広告掲載やスポンサーとのタイアップで売り上げを稼ぐしかないビジネスモデルの上、各々のサービスの交流は感じられず、断絶しています。オールラウンドを目指すのはいいけどシナジー効果のないゴミをいくら集めてもしょうがないだろって突っ込まれそうです。

販管費が3000万UPしてる件

もう１つが、前記に比べて販管費が3000万UPしていることです。四半期で3000万って単純計算で通年で1億2000万アップしてます。かなり新卒を採用されたのでしょうか・・・。

天下のカルチュア・コンビニエンス・クラブと組んで新しいサービスを開始したり頑張っておられるのですが、そこには人が動きますのでどうしても固定費が高く、なかなか損益分岐点に到達していない模様です。

実はお荷物状態のキレナビ

また、美容医療ポータルサイト「キレナビ」においては四半期で1100万の売り上げを上げているもの、600万の損失を出しています。1年前の1Qでは600万の売り上げに対し1500万の損失を出しています。いいですねぇ、後に引けない感がクールですね。1100万の売上を作るのに1700万のコストが必要なので、仮にランニングが四半期に1700万固定とするとこれが黒になるには(1700/1100) x 1700 = 2627万の売上でやっと四半期がチャラ。チャラでは論外ですから、1年で1億ぐらい売らないとあかんことになります。実際には2300万前後で黒になるでしょうが、1億叩かないと会社を支える事業としては物足りない。

キレナビ自体は平成23年４月にオープンと有価証券報告書に記載があったので、残念なことにこの２年間でひたすら赤字を垂れ流しているのがキレナビを始めとしたメディア事業になっています。現状ではキレナビはお荷物以外何者でもない状態ですので、このままリソースを投入し続けるべきか悩ましい所です。営業利益が98%減ってのは、どう考えても投入すべきリソースを投入してはいけない所に突っ込んでる結果と解釈するのが自然でしょう。

追記(2013/12/24)

キレナビ事業をサイブリッジ社に譲渡とオフィシャルな声明がありました。

｢キレナビ｣事業の譲渡に関するお知らせ(PDF)

これにより特別損失が1000万上げておしまい、となるようです。

かといって、すぐには倒産しない

気になる資産ですが現金が11.9億ありますので、まだ慌てるような時間ではないのかもしれません。負債も流動・固定合わせて2億前後です。突っ込んだカネが全部溶けているだけでまだまだ燃料はたくさんある。ですが、四半期で６万弱の純利益が残り9ヶ月で爆発的に増えるとは思えません。タコが腹減って自分の足を食い始めている・・・そんな前奏曲が流れています。

最悪のシナリオは現金が唸っている状況の中で一発逆転を狙って投機性の高い商売に多角的に手を出してしまい、大損して資産を溶かしまくることです。端的には不動産投資やソーシャルゲームの乱発等。後者は考えにくいですが、一例として。SCSに吸収されたCSKは不動産投資を焦がしてから資金繰りが超絶悪化しましたので、同じ轍は踏まないよう祈念しています。

今年の12月頃にはどうなっているのでしょう。V字回復は無いとは思います。特別損失で赤字計上なら分かるんですが、営業利益が足りなくて赤字決算になるとかなり厳しい。新卒で入社されたい学生さんは現状かなり厳しい状況になっていることを認識しておくといいでしょう。

超高速開発が目指す未来像は何なのか

発表から一部で非常に強い拒否反応と共に盛り上がっているのがこちらの「超高速開発コミュニティ爆誕」のお知らせです。

• 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 － Publickey
• プロフェッショナルたちの熱い想い：「超高速開発コミュニティ」を設立――日本が19位で黙っているわけにはいかない - ＠IT

超高速開発のコンセプト自体は僕もOSSのフレームワークを活用して自動生成の恩恵に授かっているので否定しません。開発自体が高速になることは歓迎すべきことです。

今回の件はポジショニングが「いつまでも手組みでコードを書いているから生産性が低く作業も多く品質も問題が出てしまう」への解決策という立ち位置のため、「そのツールがカバーできないことが多くて結局コードを書いているのですが」という生理的拒否反応が大きいようです。その辺は情報提供を増やすことで地道に解決していくしか無いでしょう。

僕のTwitterのタイムライン上では下記のような指摘が多く見られました。

• 銀の弾丸を探したい人にツールを売り込みたいだけじゃないのか。
• 非エンジニアがそのツールを作ったものを誰もメンテ出来ないのでは。
• 超高速開発で短納期になったら価格破壊が起きて誰得じゃないのか。
• ツールの都合に合わせてくれるクライアントがどれだけいるのか。

今回の発表で最も不明瞭だなぁと感じたのは、このツールを誰に売ってどんなメリットを享受してもらいIT業界自体の市場を活性化させるのか、ということでした。ターゲット設定がぼんやりしていて、それも違和感を増幅させてしまった一因のように思います。

例えば、こんなお悩みの会社さんがあるとします。

エンジニアを抱え込む余裕はないけれど、見積の管理がしたいしそれを全員で共有できる状態にしたい。でも業界特有の慣習や社内でのチェックフローを入れこみたいので既存のツールではうまくいかないしExcel配布も限界が・・・的な。やりたいことはそんな多くないけど非エンジニアでも使い方を覚えれば社内で使うシステムを作れるという売り方ならWin-Winが見込めそうです。それ、kintone - 今日からはじめる業務改善クラウド・サイボウズのクラウド型データベースアプリ「kintone」- cybozu.comで出来るよみたいな話なんですけどね。

もしも超高速開発ツールを同業(SI・ベンダー)に売り込むとするとノンプログラミングによる生産性向上と品質の均一化、という題目になると思います。これを目的に掲げた時に、超高速開発ツールの導入がどこまで受けいられるのかは正直かなり厳しいと思っています。これから見えてくることだとしても。

受託開発の場合は環境が各々バラバラですから、自分たちが提供する開発環境・動作環境の中で動かせるケースがそんなに多くありません。更地に新しく木を植えましょうなら通るでしょうが、街が出来上がった中でよっしゃスクラップアンドビルドだっていう理屈はなかなか通らないでしょう。顧客にも予算があり、予算を明らかに下回る場合は逆に懸念されてしまうものです。また、このツールの教育機関やこれを使った時どんなアプリが作れるのか、ある程度の習熟期間が必要なように思います。

また、車輪の再発明やめようぜ的に売ろうとしても、受託開発はどうしてもプロジェクト間でノウハウが閉じてしまいます。車輪の再発明をするから属人性が高く一定の品質が確保できない問題は、僕がSIerに所属していた10年前(2003年頃)からありました。属人性によって成果物の品質が安定しないのはSI側としては死活問題なので、ある程度の規模のSIerでは開発標準推進的な部隊が立ち上がって車輪の再発明から卒業しようと努力しているのですが、卒業できましたという話を僕は知りません。

エンタープライズの世界はインフラが複雑で動作環境が多岐にわたり全体像が見えにくいでしょうから、例外例外アンド例外からの連携連携アンド連携みたいな世界にアプリ開発ツールを持ち込んでも・・・という気もします。ミドル連携ならまだ理解出来ます。

これらの超高速開発ツールが要求→仕様→設計→実装に直接落とし込むという永遠の課題を解決しようとされている感はありますが、どこまで行けるものなのか・・・。

というわけで、エンプラ開発の救世主的立ち位置は難しいんじゃないか問題を上げました。次なる問題は、これらのツールを担いでくれるSIerは現状ほとんどいないんじゃないか問題です。

なぜかといえば、SI側にビジネスモデルの転換が求められる可能性が高いからです。これを担ぐと工数を減らす必要があります。高速にできるって言って工数変わらないってなんだよって絶対突っ込まれるでしょう。案件単価が激減することは必至の中で、如何に作らない開発モデルに沿った利益モデルを構築できるのかが先になると考えます。

単価が下がっても利益が出るようにするためには、案件案件に技術者を貼り付けることは出来ないので少人数で回せるようにスケールようにするしかありません。その転換を行わないと難しいでしょう。むしろ、このようなツールをバックエンドで担いで事業会社がWebサービス展開を行うみたいモデルのほうが面白いなぁと。

そして最後の問題は、仮に導入して開発生産性を極限まで高めても、オーダーメイドの実装部分の効率がよくなるだけでオーダー自体の決定が遅ければスピードが出ない問題です。開発生産性の高いツールを使っていることがSIerの営業力UPに寄与するのか、悩ましいところです。

僕のまわりには雑貨のメーカー・卸・小売業の経営者がたくさんいます。弊社が雑貨メーカー兼卸ですので。彼らは誰も開発生産性の高さは求めていません。ある意味それ以前の段階で、的確に自分たちの曖昧とした要件ビシっとを引き出して落としこんでくれること、そして最終的には自力でそれを出来るように導いてくれることを求めていました。自分たちが何にお金を突っ込んで得られるものは何なのかというのがわかるようでわからないのがシステムの商売。マーケティングの古典話であるじゃないですか。ドリルを買いたい顧客はドリルが欲しいのではなく、穴が欲しいからドリルを買うのだと。そこですよね。

スクラッチじゃないから安くて早くて安心だねという価値観は、このドリルは穴をあけるのに最高っス！っていう話と同じように思います。それを超えたストーリーをどう作っていくのか。悩ましいことですが必須課題だと思いました。

色々厳しいことを書きましたが、案件単価の下落傾向がとどまることを知らない中で新しいIT業界を作っていく・生き残っていくための未来像を作っていくことは業界全体の問題として捉えるべきです。顧客のビジネスに寄与するという目的はブレないわけですから、それにどう沿っていけばお互いがWin-Winなのか。僕もユーザー企業側として、考えを深めていきたいと思います。

プロブロガーというネット芸人の生き方

連休最終日に図書館に本を返したら、新着コーナーに「ブログ飯」というタイトルからブログで飯を食う生き様が書かれていそうな本があったので手にとって読んでみました。

ブログ飯 個性を収入に変える生き方

お人柄によるものでしょうが、ものすごくマジメな一冊でした。マジメというのは、何度も推敲されて自分の意図が正しく伝わるように練りこまれているという意味です。文章の隙間が小さく、密度の濃さを感じました。テクニックという策に溺れるよりも、まずはあなた自身が幹となるのがプロブロガー。そういった部分を育てましょうというのが本書の主題です。そして、良き伴侶は人生のパートナーということを教えて頂きました。巻末コラムをご参照ください。

友人の@asuka_xpさんが2012年8月にプロブロガーという生き方に挑戦されました。彼のエントリを読んだ時にプロブロガーというのが１つのロールモデルになっていることに驚いたのですが、同時に何がプロなのという疑問が沸き上がりました。

文章を書くプロではないし、販売員というのもちょっと違う・・・と考えていくと一番シンプルな答えが芸人でした。

プロブロガーはネット芸人とほぼ同義だなというのが僕の理解です。芸人はネタを仕込んで面白さを提供しコンテンツとなることで、更なるメディア露出が増え知名度があがりパーソナリティを確立していきます。そこでお金を落としてもらう。芸人が売れていく経緯とプロブロガーとして活躍している人の経緯は多くの共通点があると感じました。ネタはなんでもいいんです、この人が言うことは信頼に足るし、面白いというのが先に来れば。営業マンにも似たような性格がありますね。

ただ、芸を見せるためには技能が必要です。芸となるには熟成期間がどうしても必要になります。ブログ更新は孤独な作業ですし、文章を書くことは基本的に憂鬱な行いです。継続するためには習慣化しなければなりません。記事の更新は習慣というか技術です。今となってはありふれたブログを使って芸となる技能を確立しているからそれだけで食っていけるという側面を無視してはいけません。

相手の気持ちに触れる、届ける。
つまり「思いやる」
そのトレーニングにブログは最適な手段である

上記のブログ飯にはこんな一文があり、顔が見えない不特定多数の方と触れ合うメディアだからこそ重要な考え方だなと感じました。この姿勢が初心忘れるべからず、ということなんでしょう。

芸が不快な芸人のところには人は集まらないのが普通なんですが、ソーシャルメディアの発達により個々人が発信手段を持っているので、不快に思った読者が言及することで流入が増えて結果的に収益も向上するというシステムが出来上がっています。炎上マーケティングと揶揄される手法です。これを確信犯的に繰り返してプロを名乗るブロガーは、その他大勢のプロブロガーから見てどう映るんでしょう。プロブロガーに対する印象も悪くなるでしょうから、残念なことだと思いますが。

強引にまとめますと、プロブロガーになりたいという方は自分はネット芸人として生きていくんだという自覚を持って自分戦略を立てられるべきだと感じました。また、下記の「ブログ飯」は文章を書くことが好きな方なら膝を打つ部分がありますよ。

ブログ飯 個性を収入に変える生き方

これは私の仕事ではないを貫き通すと、何もできない人になる

あんまりこのエントリの内容とは関係ないんだけど。

「これは私の仕事ではない」が強く言えない日本の職場 - 脱社畜ブログ

僕は幸いにも上記のような職場に巡りあったことはないので、頑張ってるアピールという言葉の意味していることもよくわからない。「働いている」姿勢を常に見せ続ける以外に自分が義務を果たしていることをアピールする手段がないという職場を知らない・・・。どこそこ？みなさんはそんな職場で働いているの？妄想じゃないよねこれ。僕の知る会社とあまりに違うので驚きました。

本題は別にありまして、「これは私の仕事ではない」を貫き通してしまうと、結局何もできない人材になる恐れが高いので留意しましょうということです。

これは僕の仕事ではないを繰り返していくと、ほぼ間違いなくマックジョブしか出来ない人になります。 最初から出来る事しかやらないことを繰り返せば、誰にでも出来ることしか出来ない人になるのは火を見るより明らかです。そうなってしまえば、その会社でのあなたの居場所というか存在感は無くなってしまい、任される裁量の範囲がどんどん狭くなるので、自分にしか出来ない仕事やこの場所なら自分は勝てるという場所が無くなっていきます。どこかで、自分の基準を上げる努力を求められる時が来ます。

もちろん仕事に自己実現など必要ないし最低限の事しかやりたくないのも全然OKでそれはそれで正しいのだけど、自分の仕事においてキャリアを切り拓きたいなら、「これは私の仕事ではない」が通せるのは、自分の仕事で居場所を作っている人だけだと覚えておいたほうがいい。寝言を言うなよ、自分で抱えられることが無いのにお前の仕事ってなんだよって突っ込まれちゃうよ。

どんな仕事にも責任は必ず存在するから、僕は「責任を負いたくありません」っていう人は何を言いたいのかよくわからない。責任のない仕事なんかない。コインの表と裏なんだから。責任の重さや程度は、当然立場によって違う。でも、刺身にたんぽぽを乗せることだって、ちゃんと載せるまではあなたの責任じゃないですか。責任を負いたくないって、要は自分が楽にこなせる以上の負荷をかけるなってという自己防衛の話なのかなと理解している。

こういったことを考えもしたことがない人が平気で社畜だ何だってとにかく会社組織を悪く言うのを見ると、社畜バカにも程があると思います。

自分の仕事でまわりに貢献できないのに他人の仕事を管理することは出来ないでしょ。だから、もちろん死なない程度に、自分で自分の仕事を抱える訓練を積まないとダメだと思う。マネージャーになれば、自分で他人の仕事の成果を抱えることになる。自分で抱える行為そのものはやっぱりリスクになるんだけど、何一つ自分で抱えられないのにリターンがあるわけないんだからさ。

Can you take it all away ?

アジャイルに限らず開発手法の議論は不毛になりやすい理由

アジャイル開発に対する論争が盛り上がってるので、僕も便乗しまーす。新野さん、秀逸なまとめありがとうございました。

「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ － Publickey

僕も２年半前にアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceという記事を書きました。アジャイル開発ってかなり牧歌的なので、内部ならまだしても外部の仕事を請けてキチンと回すのは難しいのではと書いたら、多くの方が「そりゃそうよ」と反応してくれました。その頃から、これを"ケツカッチン"な仕事で行うのは困難だと感じておりました。コミュニケーションが密に取れないと動けないじゃん。

議論の軸をもっかい振り直すと、アジャイルが確約出来る内容はあくまで人材育成・組織風土形成という不定形なサービスでしかないんじゃないでしょうか？ アジャイルな組織になりたいからアジャイルを許容する or 手懐けることが、ユーザー企業もしくは自社の事業運営にとって必要って感じでアジャイルが求められるのが典型例な気がする。なので、アジャイル開発が約束できるのはあくまで「顧客やビジネスへの変化への対応」であって「組み上げたシステム」じゃないなら、ゆーすけさんが「実証主義的な説明にすぎない」「手段が目的化する」「全体スケジュールにコミット出来ない」といったダメな理由を挙げていくのも頷ける。コンサルティングとあがっているダメな理由は水と油だ・・・。いやいや違いますよ、ウチは請け負った成果物にコミットしますよキチンと仰るのなら、是非ご指摘頂きたいです。

アジャイルが悪いって話じゃないですよ。単純に目指す所が違うだけ。それでいいじゃない、とも思う。

ちょっと考えてもらいたいのは、システムを望む顧客からすれば、

• 100万払うから責任もってこのシステムを作って欲しい
• 100万払うから一緒にシステムのあり方を共に作りながら考えて欲しい

この２つの話には大きな違いがあるでしょ？ 顧客が何にお金を払うのかという所がすっぽり抜け落ちているので、開発手法の是非の議論をした所でお互いに足を引っ張り合って何の結論も出ていないんじゃないですか？ アジャイルで請ける場合どうやって予算を取って回しているんですか、っていうことが僕は最も気になる。請けられないよがFAな気もするけれど。

顧客からすれば、WFだろうがアジャイルだろうがSaaSだろうが、手段は何でもいいじゃん。 ソフトウエアの作り方とすれば、そりゃ不都合なことはコードを書いてから現れるんだから小さく動くのがベストだけど、ソフトウエアが欲しい人からすれば「どういった開発手法やプロセスが」ベストなのかを考えていけばいいじゃないですか。ここは千差万別でしょう。

最終的な成果物が求められる場合は、ドキュメント上の要件定義が全て出来てから開発を開始するのではなく、プロト的な動作確認及び機能の妥当性確認を設計フェーズで入れながら足下を固めるしか無いのかなぁ・・・。ドキュメントだけでゴールを規定しても内製ですら違うものが出てくるから、動かないコンピュータや工程の破綻を避けるならコードを書きながら工程間を動かせるようにするしかないのでは、と思います。そこでゴールが違っても、より良いゴールにたどり着ければ問題無い。特に、内製の場合は動かないコンピュータは許されません。

ただ、「こういう風にシステムで業務を実現したいんです」と要件と仕様に整理することが出来ない組織が多すぎるのに、そこを放置して開発手法の議論をしてもしょうがないという気持ちが年々強くなっています。要件と仕様が区別できているのならば、どういうやり方をとっても大きく破綻することは無くうまく行くからさ。

これからの開発手法の議論は上流工程のあり方をどう変えていくのかという方向も見据えて議論してもらいたいです。是非じゃなくて、さ。

ダメなシステムが無くならない理由はエンジニアを正しく活用できないから

Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。

なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro

この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。

｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance

もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ。つまりはエンジニアを正しく活用できないからダメなシステムが出来るってことを焼き直しているだけだ。簡単に言えば、理由なんてそれだけでしょ？ この議論をもっとしていきましょうよ。なぜシステムがクソなのかじゃなくて、何故エンジニアをマネジメントできなかったのかという方向にさ。

エンジニアのマネジメントをどう行えば最適なのかは難しいけれど、下記に留意すればずいぶん違う。

• 要望と仕様の区別がつけられないなら、安易に業者に発注するな。変更管理が破綻する。
• 仕様の策定者と実装者は同一人物にすること。上流だけのSEは不要です。
• 工程間のフィードバックが取れないやり方を活用するな。空中分解するだけだ。
• 要望を設計に落としこめるアーキテクトを活用しろ。このコストをケチるな。
• 安易に価格を値切るな。いずれ品質が問題になる。

この５つに留意すれば、クソの役にも立たないシステムはだいぶ減るし、エンジニアがプログラミングを行う妨げも減ります。断言します。

タクシー業界を変えた『日本交通タクシー配車』は、情シス社員2人の挑戦から生まれた【特集:スマホが企業を救う】 - エンジニアtypeで業界を変えたエンジニアの方はMacを買ってくることから始めてるんだぜ。ベンダー泣かせの実に素晴らしい事例ですよ。内製回帰厨の僕歓喜。ITProみたいにベンダーに広告もらってるメディアでは載せにくいだろうから、エンジニアTypeさんにはエンジニア目線での記事をこれからも期待しております。

ベンダーが不要になるかといえばあり得ないんですが、技術の最先端はベンダーが作ったプロダクトじゃなくてオープンソースになってるので、ベンダーの固有の技術によるソリューションビジネスという時代は終わってる。当の昔に。今はもう、如何にオープンソースをハックしてお金を頂けるサービスを提供できるかどうかという、群雄割拠の時代に入ってる。こんな時代だから内製して欲しいんですね。目の前にいるんだから、困ってる人が、経営者が。それを解決できる手段もあるんだから。システムを動かす土台は業者が365日/24体制で守ってくれます。積極的に活用したほうがいい。ただ、そこで動かすサービスの改善・改修は丸投げして欲しくないのです。進化を促せない保守などあり得ません。進化が不要なら全部投げてしまえばいいだけのこと。

上流と下流が分断されると、ITによる問題解決が出来ない人材が大量に生まれてしまいます。昔ならまだ良かったのかもしれませんが、これからは弊害しかありません。特に僕のブログをよくご覧になっている3万人SE大転換の挑戦中である富士通の方々にはよくよく留意して頂ければと思います。

どんなに車が進化しても車は運転手にはなれない

ITを活用した経営戦略を考える上で非常に示唆に富むエントリだったので、ご紹介。２回は読もう。じっくり読もう。

http://www.searchengineoptimization.jp/for-local-web-design-company-to-survive

これはWebサイトを業務システムに置換しても、全く同じことが言えます。頭の痛い問題です。

使い手と作り手の溝について

下記の記述に危機感を持てるかどうかで話は全く変わります。恐らく、一度でも自分で仕事を請けてWeb制作したことがあればすごく身につまされることでしょう。

熱心にウェブの活用に取り組んでいる地方の中小企業は数多く、全国津々浦々まで無数に偏在しています。その彼らが、一様に困っていることがあります。それは「相談相手になってくれる専門家が近くにいない」ということです。

(中略)

ウェブ制作会社ならお近くにもあるでしょう。そちらに相談されてみたらいかがですか？」と。そして返ってきた答えに僕は衝撃を受けました。その答えとは次のようなものです。

「繁盛店運営のコツを大工さんに相談する人がいますか？ 私はサイトの活用で困っているのであって、制作で困っているのではありません。それに日々の修正なら私自身でやりますし、少し難しいことでも楽天ビジネスで安く早く済ませることができます。」

http://www.searchengineoptimization.jp/for-local-web-design-company-to-survive

この問題は非常に根が深い問題ですので、少し整理してみましょう。

顧客が欲しいものは何かといえば、Webサイトを手に入れることで得られる便益及びその活用法、です。原則として、Webサイトそのものはどこから入手しても構いません。外注しようが内製しようがどっちでもいい。なので、Web屋なんて100均のボールペンほどの価値しかない | webdirectooor!!! [ウェブディレクター]という危機感へとつながります。作るにはそれなりの技術が求められるのですが、求められる課題によってはある一定以上のスキルはドングリの背比べ。

Web制作者が提供できるものは、基本的にはWebサイトそのものだけ。出入りの業者にはWebサイトを利用した事業運営のノウハウをご案内することは出来ません。制作会社が顧客の事業運営を代行できる訳がありませんので、無理ゲーと言えば無理ゲーです。その溝を埋めるべく開発手法やプライシングを変えていこうと頑張っておられる会社さんが多数おられるのですが、Webの制作手法がすごく進化しても、Web制作者が事業戦略を提供していくことは非常に困難です。どんなに車が進化しても車がドライバーに取って代わることはまず出来ないのと同じことなのです。

なので、「ユーザー」と「制作者」の溝を埋める方法って１つしか無いと思います。車を進化させても猫に小判では意味が無いので、(できれば制作者もユーザーも一緒になって)ドライバーを育てるしかない、と。で、ドライバーの育成には内製が最短最適です。乗り方がわからない物を管理するのは困難で、ましてや事業運営を変えて改善していくのはもっと難しい。そもそも、事業を設計していくという考え方を持っている経営者が少ないのだけれども。

ドライバーを育成していく為に

Webを活用して売上を上げていこうとすればするほどWebサイト及びその周辺システムの設計はビジネスモデルの設計と等価になっていきます。ターゲットを決める/集客手法を決める/何を提供するのかを決める/購買方法を決める/納品までのフローを決める・・・といったことを設計しないとITで得られる便益は限定的になるからです。事業の運営方法を決めてから、Webでレバレッジをかける所を見定めていくのがスマートです。

でも、Web制作の素人には「Webでレバレッジをかける所」を見いだすことは出来ても、実際に変化させるのは無理です。なので、制作者が歩み寄ってビジネスモデルを設計できるようになるほうが、素人がプログラマになるよりも絶対簡単。10倍簡単。さっきの例で言えば、ドライバーになるべきなのは制作者です。問題はドライバーになれる環境がほとんど存在しないことで、僕みたいに異業種に飛び込むとかSIだけどWebサービス関係の事業を社内外問わず起こすとかして突然変異的な生まれ変わりをするしかないのが辛い所・・・。

ドライバーが増えていくことでドライビング技術という共通言語を持ってプロの制作者(ドライバー)のすごさを肌で感じられるようになり、最終的にはWin-Winにつながっていくと僕は考えております。

個人的には、ドライバーとなったエンジニアは事業を起こす格好のチャンスが巡ってきていると感じています。自分の作ったモノで自分のことを知ってもらえることが出来るのは、うれしいことですね。内製してつくづく思うのですが、事業の運営をシステムでカバーすることにはキリがありません！簡単な話で、ちゃんと運営していけば改善点が生まれて事業は変化するので常に違ったニーズが生まれてくるからです。

自分が作ったシステムで会社の事業を運営すれば、同業や顧客の悩みがダイレクトに入ってきますので、より強力なパートナーシップを築くことが出来るし、更にはそのシステムを販売することも可能です。顧客との適切なパートナーシップの構築が、一番売上があがるんですよ。何故か。顧客の問題は我々の事業運営の問題に跳ね返ります。それがわかれば、そこを改善してあげれば顧客の事業が回りやすくなるので、大抵売上もあがります。

これからもこういう話はどんどんブログに書いて、事業運営におけるエンジニアの活用について啓蒙していきたいと思います。

成長をやたら謳う会社には気をつけましょう

利用して転職する気は全然ないんですが、世の中には色んな会社があることを学べるのが面白くてリクナビNEXTに登録しております。そしたら、なかなかファンキーなメッセージを前面に打ち出している会社さんがおりました。

リクナビNEXTのオファーで「短納期で仕事量が多いため残業が多いですが、 その分、スピード感のある成長が望めます。」と書いてある会社があって驚いた。

2013-02-27 12:27:52 via web

逆にここまでブラック色を前面に出しておられるのも大変貴重なのですが、全国の前途ある若者が上記のようなメッセージを鵜呑みにしないように気をつけるべきポイントを列挙しておきます。

マス広告は話半分で

基本中の基本ですが、就職サイトの媒体に載せている情報は絶対に鵜呑みにしては行けません。そこに書いてあるようなポジションや待遇にあなたが就くことができるかどうかは、全く別の話です。活躍している誰それが・・・なんていう話も鵜呑みにしないでください。当社比で、それらの活躍している誰それは既に退社している確率90%です。鵜呑みにせず、裏を取りにいくんですよ。会社に使われたくないならね。鵜呑みにして困るのはあなた自身ですからね。

労務管理は会社の仕事です

これも基本ですが、労務管理は会社の責務です。なので、本来「仕事多すぎて残業ばっかり」と転職斡旋サイトで載せるのは非常に問題で「誰でも良いんで、常にハイプレッシャーのなかで馬車馬のように働いて欲しい。」と公言しているようなものです。マッキンゼーやBCGのような世界に冠たる確かな会社で在籍したことがブランドとなる会社さんならハイプレッシャーの中で働く見返りもあるでしょうが、仮にプレッシャーに負けて休職した場合はその傷を癒すのに大変なパワーを要します。海の物とも山の物ともつかぬ会社で朽ち果てる理由は、どこにも無いでしょう。寝言は程々にお願いしたいものです。

一番大切なことは、その会社があなたに秩序ある労働環境を提供できるかどうかになります。ここだけは忘れないでください。福利厚生/会社の売上/知名度/規模等は、単なる飾りです。

成長推しの会社は要注意

成長を全面に推して転職サイトでメッセージを出す会社さんは多いんですが、主語が無いんですよね。「誰が」成長するのか、という。よくよく見てみると成長したのは会社の売上だけで僕の健康は地に堕ちました、なんてことも十二分に考えられます。仕事を沢山すれば成長できる・・確かにその一面はありますが、経験から教訓を得なければ、どんな人も仕事で成長することはできません。どんなに仕事ができる人でも抱えきれる量に限界がありますので、誰が見てもオーバーフローはオーバーフローです。スピードがあるのは結構ですが、速度超過は事故の元です。ケントベック曰く、人は自分の速度でしか成長できないのですから。

僕の定義ではブラック企業というのはブラックホールのようにその人間のキャリア形成を飲み込み、会社を存続させる燃料にさせて消費してしまうこと、です。資産ではなく燃料にしてしまう。ハードワークの見返りを自分で感じているならそれはそれでOKです。そうでないなら、会社のあり方に致命的な問題があるってことです。

そもそも成長というキーワードに魅力を感じてしまうこと自体も問題で、そういう方は仕事で何を成し遂げたいのかを具体的に説明できません。だから煽られて不安になる。そこがダメなんです。自分の持っている技能が何なのかを説明できることが先です。そうすればくだらない過大広告に踊らされることは減ります。自分の仕事から相手が求めている仕事が類推できて比較できるからです。

賞与が細かい会社も怖い

四半期でパフォーマンス見直して賞与をアップさせることで20代でも年収1000万みたいな話も結構ありますが、まず無いから安心してください。理論値にすぎませんので。年間の昇給(給与改定)回数、賞与回数がやたらと多い会社は危険です。成果には給与でいう考え方は良いんですが、単純に考えると前回の成果を上回る成果を上げ続けないと給与が上がらないことになります。同じぐらいのパフォーマンスならUP評価はあげられない、みたいな。くわえることができない人参を追いかける制度になっている場合がございます。

頼りになるのは、横のつながり

ここまで読んでしまうと、どの会社にも勤められなくなりそうで怖くなってますよね。でも、上記のような会社は稀です。普通に働ける会社はたくさんあります。月並みですが、最大の情報源は実際その会社で働いている人です。そいつが死にそうじゃ無かったらまともな会社です(え

ITエンジニアなら会社を超えたコミュニティがたくさんありますので、いくらでも情報収集できます。気持ちがあれば。また、同業他社のつながりってのもバカになりません。ジョブマーケットに出てくる会社なんて一握りですから。取引先に請われて転職する人もたくさんいます。

目の前のことを片付けましょう

転職しようにも自分に力が無ければ何にも出来ません。目の前にある仕事、それが今のあなたの仕事の全てです。目の前の仕事をちゃんと片付けない人にまともなオファーを出す人はいません。まずは、目の前の仕事を片付けて自分で自分の可能性を広げないことには、なーんにも始まりません。詳しくは「仕事の法則」 | おごちゃんの雑文を参照ください。僕の経験上、ここに記載されていることは全く正しいです。

業務効率化を成し遂げたいなら、エンジニアを味方に付けろ

会社組織における業務効率化の限界について - 脱社畜ブログに寄せまして。

書いてある内容は、何度も何度も繰り返しやる必要の無い単純作業を自動化して楽が出来たと思ったら、楽になったんならこっちをやれと言われちゃうので負担自体は変わらないし給料も変わらない。それもアホみたいだから、自分は楽をしているのをバレないように小難しい顔をして仕事をしているフリをするのが個人として最適な戦略になる、と。自分で自分の首を絞める理由がないのだから、業務効率化を図るには正直者が馬鹿を見るようにしてはならないということかと思います。

確かに「仕事を片付ければ片付けるほど、仕事が増えていく」ということはあります。仕事は片付けることが最優先なので出来ない人よりも出来る人が相対的な時間給として見ると損をしやすい。出来ない人には任せられないのだからどうにかして片付けちゃう人に負荷が集中してしまうのは普遍的なこと。その分アウトプットを出しているのだから給料を上げなさいという理屈はわかるが、出来ない人がやらかした赤字の補填に出来る人の生み出した利益が回るのが会社の常なので、思うように給料に反映されませんねぇ・・・。お金のある会社の場合は位が上がって給料に反映されるんですが。なぜだろう、胸が苦しい・・。

しかし、自動化できる仕事を自動化しないのもアレですので、何にせよ視点を一つ上にするといいでしょう。自分が抱えている問題を紙に書いて「問題 VS 私たち」の構図をイメージして置き換える。個々人の仕事内容をDISってもしゃーない。自分が抱えている問題をみんなが困っていることとして一つ上から見直し、立場を超えた組織として解決するようにしなくてはならない。これが難しいけど、絶対にやらなあかん。リーダーが。個人の自主性に過度に期待するとそれこそ社畜乙になる。え？リーダーが役に立たない場合はどうするかって？外堀埋めるしか無いかも。外部の人間に説得させるとか、チームメンバーでリーダーを孤立化させるとか。そう、最も手っ取り早いのはリーダーをグーで殴ることだ（え

自主的な業務効率化を促すのは無理でしょう。自分の仕事の何が問題なのかを把握している人は絶対的に少なく、それを説明できる人はもっと少ないです。また、部署横断型の仕事の場合、ある部署の負担が軽くなっても別の部署の負担が増えれば、負担を付け替えただけなので何の解決にもなりません。仕事のやり方を一段上から見直して「悪しき現状維持」をぶっ潰していく必要があります。変わらなきゃダメ。変わらない業務効率化ってあり得ないの。金と時間の無駄なの。

業務効率化には個人レベルでは限界があることを、痛感します。正直者が馬鹿を見ることがあるのと、変えても別の箇所が痛むから変わらないという２つの意味で。なので、どうしても会社/部署/チームという単位で個人に依拠しない業務改善をみんなでシェアできる仕組みを作るしか無い。みんながハッピーになって良かったねっていうカタチにする。最終的には経営の仕事です。でも、できない。すごく難しいんだ。これが。ほんと。会社を変えるにはやることを変えるしか無いんだけど、それがとても難しい。社畜乙になるのも無理も無い。

これが特殊なのは百も承知ですが、弊社の場合は全ての業務が私が作ったシステム上で行われております。経営者/営業/倉庫/仕入/経理の全ての立場に僕が立って、彼らの利害関係を調整してます。業務運営の全てのしわ寄せが僕に集中している状況です。一般的には死亡フラグ。でも、複数の立場を見ることが出来ない限り健全な業務改善は出来ないからしょうがない。先ほど書いたように、局所的な対処では患部が置き換わるだけで病気は治らないので。会社を変えるのは僕の仕事だし。人を責めてもしょうがないからシステムを変えようって言う割にはまだまだ変わらない会社が多いけど、弊社は僕が動いてシステムを変えれば全員の動きがすぐに変わるレベルになってます(ﾄﾞﾔｧ

仕事のやり方を変えるためには、業務を仕組みに落とせるエンジニアの力が必要不可欠です。エンジニアをうまく活用して利益にならない仕事は全部潰しちゃってみんなが潤うようになればいいなぁと思うし、それが絵空事にならないよう僕も頑張ります。