Software Design 2015年01月号に寄稿しました

Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]

先日書いた、永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistanceに端を発した特集記事Part2、ソフトウエア開発の未来というテーマで10ページ寄稿しました。

本特集の見どころ

SI崩壊を乗り切ろうとしている３つの方法と謳っておりますが、立場の違う３人の人間がどうやって今を生きようとしているのかを書いています。

トップバッターは、上述の価値創造契約のマネージャー、木下さん。会社として様々な契約形態を駆使してリスクを極小化しながら堅調にビジネスをしているものの、どういう形態にせよ人月という単位から逃れることが出来ない。労働集約的モデルからの脱却への挑戦の一環で、価値創造契約という新しいスキームに挑戦された一部始終が書かれております。

２番手は、ノーチラス・テクノロジーズの代表である、神林さん。木下さんの流れを受け、「いや、請負型のSIが無くならないから。請負でやるか止めるか、その善し悪しを踏まえてちゃんと考えようよ」という論陣を張って俯瞰的にSIビジネスを解説されています。価値創造契約等も含めた新型のSIについても言及されています。

３番手が、私です。ソフトウェア開発の現場からだいぶ離れた位置にいる私が、ユーザー企業にエンジニアが入る意味やその成果って一体どういうものなのか、開発の現場から離れてもエンジニアとして食っていける場所があるのかどうかとか、そういう話を書いています。ここ３年の集大成といった位置づけの記事です。

自分で仕様を決めてガンガン攻めていこう

ソフトウェアが当たり前になったことで、ソフトウェアを使って仕事をする・会社の業務を変えるということも当たり前になってきていると思うんですが、最も大切な仕様を決定できる人間が圧倒的に足りないように感じます。

簡単に言うと、

「ITで解決したいことがある人 >>>>> 課題解決をITでデザインできる人」

っていう図式です。ITを入手して何かをしたい人は増えても、ITで課題解決を「デザイン」出来る人が全然足りていない。デザインと書いたのは課題解決を行うには実装だけでは不十分なので、要件定義や更に上の事業戦略等にもある程度知見が必要なことがあるので、総合的な視点を踏まえてデザインと書きました。

その根本にあるのは技術の目利きであり、それは最低限のプログラミング経験がないと絶対身に付かない。プログラミングが出来るというスキルをテコにして、色んな所で「越境」していく事例が来年以降は増えたらいいなーと思います。

netgeekのRetty社叩きが下衆の極みなので黙っていられなかった件

事の発端はこの記事ですか。

関係者からすれば個人が特定される情報を散りばめておいて匿名で記事を書いてしまう卑屈さに驚きを隠せません。代表からメール来たけど代表いねぇじゃねえか舐めんなよおおおおおってブチ切れて５分で帰るって超絶微妙ですし、ふつー採用担当者がいるもんなんだけど... リクナビのスカウトメールとか見たこと無いのかな？「代表です！よろぴく！面談で僕と握手！応募してね！」を真に受けちゃうのも微妙。

百歩譲って、期待の裏返しから来る些細なすれ違いからブッチーン！って来るのは誰もあるよね、'`,､('∀`) '`,､ って終わる話なのにって思ってたら、これですよ。はまちちゃんがDISりたい時は直リンはダメって言ってた(PVが発生すると更に拡散する恐れがあるから)ので、googleキャッシュで御覧ください。

この悪質な書き方は一体何なんでしょう... 全く関係のない第三者なのに何様のつもりなんですかね。

何が下衆の極みなのか

上記のキャッシュを見てもらえればわかりますが、僕がカチーンと来たのはこの記述。

株式会社Retty（2010年設立、スタッフ30名、資本金4億5千万円）、法に反しなければ何でもありの精神でけっこうな黒いことをやっているではないか。詳しく調べて叩けば真っ黒な埃がもっと出てきやしないだろうか。

おいおいおい、お前ら何様のつもりなのこれ。スカウトメールの行き違いからRetty社が「法に反しなければなんでもあり」ってなんでそんな話になるの？ それは何の因果関係があるわけ？ 悪質なのは些細なすれ違いをした当事者なのか、全く関係ないけどボロクソに非難した第三者なのか。火を見るより明らかでしょう。

Retty代表の武田さんは(出すまでもない)謝罪文を出して説明責任を真面目に果たしているのにも関わらず、「真っ黒な埃がもっと出てくるぞ」と非難中傷をして不当にRetty社を貶めるのは、場合によっては名誉毀損として訴えられてもおかしくないと思うんですけど。

採用プロセスの些細な行き違いをダシに何の裏付けもない拡大解釈をして、この会社はブラックだ何だと悪魔化するのは下衆の極みです。恥を知りなさい！！！！！！！！

それに不必要に代表者の顔写真をバシバシ貼り付けて晒しあげるっていう書き方も、すごく下衆い。匿名で記事を書いて叩く→バイラルメディアとして拾って拡散というのはお約束ルートなのでしょうか。上記の匿名記事すら自作自演だったのではと... だとしたら、すごいね。

詳しく調べて叩けば真っ黒な埃がもっと出てきそうなのは、いやーどちらなんでしょうか。あのような下衆い記事を鵜呑みにするようなことがあってはならないので、黙っていられなかったというわけです。

ここから余談

僕にはバイラルメディアとネットイナゴの違いがわからないので、検索してみました。「バイラルメディアはゴミじゃねぇ！」とおこでいらっしゃるブログが見つかった。そこにはこう書いてあった。

まずはじめに、「バイラルメディアとは何か」というところから整理したいのですが、僕個人としてはこの定義は簡単だと思っています。

「FacebookやTwitterなどのソーシャルメディアからの流入がトラフィックの中心になっているメディア」

これだけです。記事が画像や動画の引用で構成されているだとか、おもしろ系・感動系のコンテンツが中心みたいな話は関係ありません。

バイラルメディアはゴミじゃねぇんだよ

流入経路が第一優先でコンテンツの質は一切問われない定義に吹いた。ソーシャルメディアでシェアされるコンテンツは公序良俗に反する物、スパムアプリ、デマ情報もたくさんあるし、上記のような非難中傷にまみれたコンテンツも含まれます。僕のブログもFB/Twitterからの流入が中心なので、バイラルメディアと言えちゃいます。勘弁して下さいよ。

「価値があるのに埋もれてしまっているコンテンツを発掘するのにシェアが有効→バイラルメディアは価値を見出しているので、ゴミではない」という理屈らしいのですが、バイラルに伝わるインフラとなっているTwitter/Facebookがすごいだけで、お前らやっぱそれに寄生するだけのネットイナゴじゃね？ 情報ソースの拡散なら、それRetweetでよくね？ 何の付加価値があるの？

良いニュースで良い人生を送りたい読者諸氏におかれましては、下記のサイトの情報をあてにしましょう。その情報が確かであると信ずるに値する実績と信頼。これこそがメディアの価値でございます。

まなめはうす

安心と信頼のまなめオチでございました。

WordPressほど頼りになるCMSはないと思います

この辺りの議論が面白かった。

• WordPressで「ささっと作る」で請けれなくなってる現状。 | バニデザノート
• Re:WordPressで「ささっと作る」で請けれなくなってる現状。 | たけのおしごと
• WordPressを巡る理想と現実、あるいは誤解 | notnil creation weblog

ロリポップのWordPress関係の制限には驚いた

ロリポップでホストしたこと無いんですけど、wp-login.phpに対してIPアドレス制限をさせるたりログイン回数に失敗すると業者サイドでロックするのには驚いた。今すぐにロリポップ捨ててさくらのレンタルサーバ スタンダードを使おう！安くて速くて安心だ！

WordPressはコードを書けばなんでも出来るのが良い

WordPressで作れるサイトは多種多様ですので最近ではWordPressで作りますの内容がピンキリで取扱注意ってのはわかるけど、そこでうまく手綱を捌いていくのが腕の見せどころ。その辺の押し引きはキッチリ線を引きつつ、何にカネがかかるのか、何にお金をかけてもいいのかをバランス取らないとねぇ。時には、現実は少しも甘くないことを伝えるのもプロ。

お問い合わせフォームだけ必要であとはHTMLで放置でOKなら、HTMLをAmazon S3にあげてお問い合わせにGoogleフォームを使えば10円コーポレートサイトの完成。それもまたひとつの形。それに、WPの管理画面ってそんなにとっつきにくいかなぁ・・・投稿と固定ページの違いがわからんとかそんなことじゃないの。

CMSとHTMLの違いは明確にしよう

HTMLとCMSの区別がつかないお客さんは多いんでしょうけど、自分で記事を作成してコンテンツを更新するってことは、それ自体にプログラムが内包されているので「車のように持ってるだけでカネがかかる」という現実をありのままにお伝えしようよ。レンサバと契約する理由にもなるから、ページ規模に関係のない話だと思う。

僕もたけさん(@take_it02)と一緒で「なるべくコストをかけずに自分で更新したい」顧客ばっかりです。でも、乗りっぱなしでメンテ無しでも行けますけど、車って老朽化しますから一種の怖さがあるのはわかりますよねっていう話はしています。

HTMLはファイルでしかないけどPHPはプログラムであり、プログラムには実行環境が必ず必要になる。HTMLを作ることにカネがかかることはみんな理解してくれるんだから、もう１歩それを進めてプログラムを動かすって少しも甘くないわ、と。そこをキッチリ詰めてから管理費等の話をしますので、毎月管理費を払ってくれるお客さんもいれば限りなく放置でいいので管理費無しのお客さんもいます。

コードを書けば書くほど、メンテナンスコスト比例して積み上がっていく。HTMLが自転車だとすれば、WordPressは自動車だ。両者の違いは免許が必要なこと。WPを使う免許は要らないけど、使うには専門性が必要。その違いを誤魔化しちゃいけない。

プラグインは諸刃の剣

プラグインを使えばやりたいことがすぐに手に入るけれども、お客さんからすればプラグイン適用したのか標準機能なのかはどうでもいい。プラグインが提供している機能についての改修依頼が来た場合、みなさんどうされているんでしょう。プラグインがフィルターを用意してくれていない場合は、直接書き換えたこともあった。基本的にはコードを書いて対応しています。

僕は自社サイトをWPで運用してて、その中で取引様専用ページを作っています。そのページの中でお取引様だけに製品のカタログPDF等を配布しており、ファイルのダウンローダープラグインを使ってます。そいつがファイルの情報を登録する時にjson_decodeで日本語ファイル名がエスケープされてしまいダウンロード出来ないとか、レスポンス返す時にUTF8でファイル名がエンコードされるからWindowsで日本語ファイル名が文字化けするというクソみたいな問題にぶち当たりました。この程度で済んでよかったｗ

HTMLだけでいいのってランディングページぐらいじゃないかなぁと思います。会社案内等も修正することもあるし、単なる文字をちょっと更新する度に業者に頼むほうがめんどくさいんじゃないですかね。素人が文章を書くようにHTMLを更新できるっていうメリットは大きい。ペライチじゃない限り、僕は基本的にWordPressを使って構築しています。

これからもワンコインレンサバでWPだ

WordPressはコードを書けばなんでも出来るのがいいし、知れば知るほど面白い。インストールして放置しても最低限のことはできるし、コードが書けてWPのアーキテクチャがわかれば、お客さんの色んな要望に対応できるようになるし頂ける対価にも幅が出てくる。WP案件で食ってるわけじゃないけど、僕にとってはWordPressは頼れる相棒のような存在です。ありがてぇことです。

本日でプログラマの定年を迎えました

SIerをDISってブログを書きはじめ、気がつけばプログラマの定年の歳になってしまいました。まだ実感がわかない。Paiza開発日誌のSIerのDISり方が品がないのでちょっとイラついています。DISられるには充分なネタがあるからしょうがないんだけどね。

10年前は自分はコードを書くことは無いなとか思ってたら、ほぼ毎日しょうもないコードを書いていることにびっくりしている。平凡な誰でも書けるようなもんだけど。解決している問題が平凡だからね、LINEのインフラ作ってるわけじゃないからね。しょうがないね。どうでもいいけど、スーツとギークって完全に死語だね。肩身狭いわ。'`,､('∀`) '`,､

で、最近５年間を見て思うんですけど、これからIT業界(システムインテグレーションの業界という意味)のマーケットの成長は鈍化すると思います。ITの世界って、オーダーメイド(受託開発)、既成品の買い切り(パッケージ)、サブスクリプションの３つしかビジネスモデルがございません。大きく言えば。

上記の３つのビジネスモデルの中で伸びる可能性が高いのはサブスクリプションですが、サブスクリプションが当たり前の世界になると、業界内で食っていける人が減る可能性が滅茶苦茶高いです。なんでかといえば、Webサービスでフリーミアムだイエーイという世界と同じように、業界内競争が熾烈になって共食いが発生するからです。共食いの結果生き残った所がコモディティ化の進行に伴い価格を下げていきますので、生き残れる業者が減ります。

そのような状態で業界全体の成長が加速するかなぁ・・・と。

クラウドが当たり前になることで、クラウドの上でソフトウエアを作ることも当たり前になった。その結果、いかにクラウドの上のサービスを組み合わせて最適解を産むかというビジネスが増えた。今現在、SIで元気のある会社ってそーゆービジネスをやっている所が多いように感じます。AWSのサービスを組み合わせるとか、KintoneみたいにPaaSやるとか。

個人レベルでは、ソフトウエアがコモディティになりましたので、高度なプログラミング技術を求められる案件よりも、普通のアプリやWebを作る案件の方が圧倒的に多くなっていると思います。コモディティになるってことは入手しやすいってことですからね。でも、その普通のアプリやWebを作ることが出来る人を育成できる会社が、どんどん減っているのが気がかりです。IT業界を志す方々の裾野は広くなっていくけれども道は細くなるというか。入学するのは簡単だけど卒業する(進級する)のは難しいというか。素人++みたいな人は３年持たずに消えていくような、そんな世界になりそうです。

コードで回りを動かせたらどこでも食って行けることは間違いないので、コードで回りを動かすために何を実装すれば世界が代わるのか、何を身に付ければ作りたいものが実現できるのかを、愚直に考えて行きたいと思います。僕も。

それでは、また。

経営が苦しい会社が陥りがちな５つの問題

トップやリーダーがこういう考えで物事を判断するとろくな事にならず経営状態が良くならない。そんな「あるある」ネタが５個たまったので、シェアさせて頂きたく思います。

1. やってみないと分からんと高を括る

やったことがないことをやる意味はすごくある。やったことがないことができるから成長できる。けれども、やってみて失敗した時の影響範囲によってはものすごく高い授業料を払うことになります。

運営上の課題を整理して走り続けるのはOKなんですが、やる前にダメだった時の終わり方を必ずシミュレーションする必要があります。ここまでやってダメなら次を考える「撤退ポイント」がないと、いつかは辿り着ける症候群に陥ります。この疾患は感覚で物事を判断するタイプに非常に多く、逆算して物事を考える習慣がありませんのでやってみないと気がすまないという。

「やってみないと分かんない」の対極は「やる前から終わってる」です。ゴール(到達点)は近づいてくるものであって、追いかけるものではありません。

2. 売上はあればある方が良い

売上が無ければ何も始まらない。売上がすべてを癒す。それは正しい。

でも、安定した経営をする為に必要なのは売上を最大化することではなく、利回りを最大化すること。かけたコストに見合うリターンがどれだけなのか。そのリターンを組織力で得るため為にはどうすべきなのか。そこから逸脱していくと、環境の変化にとても弱くなります。

売上原理主義に侵されてしまうと、下記ポイントが蔑ろにされがちです。

• 売上と比例して仕入も増えていないか
• かけた経費に見合う利益は妥当なのか
• 誰か・どこかに過度な負担を強いていないか
• 次に必要なお金をかける意味があるのか

1000万の売上でかけた経費と仕入が800万、500万の売上でかけた経費と仕入が300万。どっちがいいかと言えば後者です。残る額が同じなら支払いが少ないほうが(損益分岐点が低いほうが)良い。でも、1000万の売上が減るとただ怯えるケースが多い。利益率を悪化してまで掴んだ売上の未来は、大抵暗いものです。会社のキャパやビジネスモデルに依りますが、安定した基盤を作るために売上を減らすのが最適な場合もあります。

3. お客様は常に敷居が低いサービスを喜ぶ

より早く、より安く、より細かく。より利便性の高いサービスを提供する。大変素晴らしい考え方です。

お客様が注文しやすいように障壁を下げようという話は一見素晴らしく感じますが、敷居を下げ過ぎると足元を見られます。ま、あそこならこの程度の注文でええか、と。顧客の中でのランクが下がり、自分で自分を安く売るのは身売りにしかなりません。必要以上のサービスを提供すると過剰な負荷がかかり、自社の営業利益を圧迫します。

全ての顧客に対して、各々の望む形に合わせることは出来ません。必ずどこかで意味のないサービスを提供することになります。言い方悪いですが、どの会社も明確な判断基準を持って顧客を選ぶ必要があります。「ここまでしか出来ません」という線を引く。その線の引き方が顧客管理そのものです。経営者の腕の見せどころ。

4. レベルが違うものを努力で解決しようとする

これは1番のアンチパターンにも似ているのですが、10の力しかない組織が20のことを達成するのは無理です。10の力で20の重さの石を押し続けるのは無駄。押し続ければいつかは20の重さの石をずらすことぐらいは出来ますが、その負担を別の所でしわ寄せしてるだけです。同じことを繰り返して異なる結果を期待することを、アインシュタインは「狂気」と表現しています。

努力で最も大切なのは方向性です。寿司を上手に握れるようになりたいのに、ラーメンを茹でる努力をしてもしょうがない。極端な例を上げましたが、その努力を続けても全く状態は良くならないだろっていう話は結構多いです。人の動き方が正しい方向に変われば会社はガラッと変わるものです。

5. 俺がやったほうが会社にとって都合がいい

経営における「クソジーコ問題」とは / 佐藤 裕介 | STORYS.JPと少し似てる。

創業者は凄腕の営業マンであることが多いです。誰よりも多くの情報を引き出し観察し洞察した上で、その顧客との商談を成立させます。が、洞察という行いは非常に感覚的です。言語化するとマニュアルになっちゃうというか。その嗅覚がある前提で営業マンに指示を出すからどうしようも出来ず、結局自分でやっちゃう。そしてミドル層が入れ替わり立ち変わり、振り出しに戻る。

誰かの能力に依拠して何かを立ち上げることは何の問題もないですが、会社組織は常に変革をしていかねば現状維持すら難しくなります。組織変革を阻害する一番の理由は、属人性です。その人がいないと回らない場合と、その人が足を引っ張る場合があるんですけどね。極端に言えば後者だったら切ればいいだけなんですけど、前者になると一筋縄ではいかない。

色々と書きましたが、強いて共通点を挙げるとすれば「意味の無いことをやっていれば、必ずどこかで歪みが生じる。」ってこと。その辺りがマネジメントが求められる大きな理由の１つだと思いました。

エンジニアの「出来る」を正しくマネジメントする為に必要なこと

この記事面白かったです！

「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。

私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。

実装可能と実現可能は別問題

前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。

技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた機能の実装が可能なのかという点に絞って前提をおきます。

仮にその機能が実装可能とします。政治的制約(大人の事情)を度外視して本筋を述べますと、「可能かどうか」と「やる必要があるか」は全く別の話になります。可能だからあったほうがいいのでやろうってのは、よい結果を生みません。哲学がないからです。本来は「無くてはならないものだから、やろう」という説明が出来る必要があります。

実装可能から実現可能かの議論を生産的に行うためには、ソフトウェア開発においては下記の代表的なポイントを抑える必要があります。

• 既存のプログラムの影響範囲
• 納期が遵守可能かどうか
• 実装コスト(工数)
• その機能があることに生まれる価値
• その機能がないと損失する価値

ほとんど政治的な部分です。作ることの意味を見出すためには、ソフトウェアを使っている人々の様々な立場を吸収して立脚点を作る必要があります。

僕の場合、経営者及び事務方の思いつきによる「これがあるといいなぁ」というぼんやりした実装依頼が結構多いです。それだけでは作る理由にはならないので、「現時点でその機能がないことでどんな損失があるのか」という話を先に詰めます。その詰めを怠ってしまうと、ソフトウェアがどんどんメタボリックになります。作ることで自分の首を絞めて技術的負債が積み上がるなんて、実にバカバカしい。非常に良くないことです。

難易度は別問題として、機能追加するのは簡単です。作ればいい。人間で言えば、食べる量を増やせばいい。でも、減らすには哲学が必要です。ダイエットに適切な方法と適切な食事が必要なように。

・・・っていう背景を前提において考えますと、ソフトウェアのマネジメントをするにあたっては「作らなくてもいいんじゃね、それ」を議論するのが一番早道だなぁと感じることが多いです。何故かと言いますと、

• その機能が無いと解決できない問題は明確なのか
• その問題を解決することでどんなメリットがあるのか
• これだけのコストをかける意味があるのか
• 作る以前に代替手段はないのか

上記４つに明確に回答できる必要があるからです。この４点を利用者・実装者・マネージャーの三者で共有することが、「やらなきゃよかった」という残念な結果を未然に防いでくれます。

なんでここまで議論する必要があるかって言うと、間違った要求が来ることも多いから、だったりします。欲しいって言ってる内容と、実現したことで期待する結果が食い違うのはよくある話ですよね。お前が欲しいから作ったのにこれは違うってなんだよ、みたいな。その乖離を防ぐことはとても重要な事です。腐った仕様を生み出して機能を提供してしまうと、誰も得をしませんから。

この問題については詳しくは下記の過去記事で議論していますので、よろしければご参照下さい。

Happy Coding!

永和さんの「価値創造契約」が大苦戦を強いられている件

この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。

俺の価値創造契約 from Fumihiko Kinoshita

永和さんの価値創造契約とは

新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。

2013年営業実績、0件

資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。

受託開発の弊害と指摘される「価値あるシステムを作りたいユーザーと、作ることが目的になるベンダーとの間に生まれる、ゴールの不一致」を解決できるビジネスモデルなのに、どうして苦戦を強いられてしまったのか。僕が思うに大きな理由が３つあったと見ています。

謳ってるメリットが伝わらなかった

価値創造契約では、「いつでも解約」「初期費用無料」でソフトウエアの利用するまでの負担をかけないという点がメリットとして謳われています。しかし、資料でも言及されていますが、ユーザーにとっては全くメリットでは無かったと書かれております。解約する前提でシステムの開発依頼をする会社は無い、と。嫌な言い方をすると、いつでも逃げられるように予防線張ってるんちゃうかと勘ぐられることもあるなと感じました。

負担がかからないから良いでしょってのは、「この商品は他のメーカーより安いからお得ですよ」という話と大差がない。極端に言えば価格勝負をしている。割安という点をクローズアップしてしまうと、自分の欲しい価値がゲットできる保証になってない。その商品である理由が説明できていないし、買った後のメリットが理解できない商品を買う顧客はいない。その辺のズレがあったのでは、と。

チケット制がうざい

月額定額なのに従量課金でチケットを売ったのも非常に不自由で、個人的には気に入らない。回数制限があったら、そう簡単に変更依頼は頼めません。もし頼んだ変更を適用した結果、昔のほうが良かったから戻したいという時に新たにチケットが発行されてしまうとなると、デメリットが際立ちます。「ちょっとした機能追加にチケット追加ならやめよう」→「チケットで予防線張っといて何もしてないのにカネを取るのか」にすり替わってしまうんじゃないでしょうか。運用しているから何もしてないわけじゃないけど、心証の問題で。

後から見えない費用がかかる可能性が高いのなら、始めに一括で払ってスッキリしたいというのが一般的な感覚でしょう。

要件定義〜リリースまでの費用をとらなかった

取るべきです。絶対。

WF型でもアジャイル型でも、要件が決定しなければ次の工程に進むことはできません。特に柔軟に変化に対応することを前提とするアジャイル型の場合は、WF型よりも顧客にかかる負担が大きくなるはずです。だからこそ、期間を決めて金銭を発生させることで真摯な議論を積み重ねるようなビジネスモデルにすべきでした。要件定義が遅延すると追加料金出ますよぐらいでもいいでしょう。その後が月額定額なんだから。どの案件でも要件定義は不可避ですし、そこできっちり詰めていればフェーズ分けの議論もしやすいでしょう。

この部分が無料になってしまうと、発注側は「無料だからいつでもいいや、後から考えよう」になりかねないし、開発側は「明確な縛りがないから、詰めたくても押し切れない。非常にやりにくい。」という中途半端な状態になるんじゃないでしょうか。また、このまま進めてリリースして大丈夫かという不安にもつながります。要件定義等のコストをサービスしてしまえば開発者のモチベーションを下げる結果になるでしょう。

上記３点のビジネスモデル上の欠点が大苦戦の背景にあるのかなと思いました。

その他資料に記載されているエピソード(失敗談)は、このモデルに限ったものではないと思ったので取り上げておりません。詳しくは資料をあたってください。

今後の展開は？

どうしましょうかねぇ・・・ まぁ、頂くべき対価の設定を間違えてしまったのなら、価格体系を大幅に見直すべきでしょう。そうなると今までと何も変わらないよって話になりそうだから何とも難しいのだけれども。

長く使い続けられるシステムを育てていくことがWin-Winなのは間違いありません。でも、価値を提供するためには然るべき所で対価を頂く必要があります。今後どのような巻き返しをなさるのか、期待しております。

はてブを頂くことで生まれる悲喜こもごも

突然はてブやTwitterで著名人に拾われて自分のブログに大量アクセスがやってきた・・・そんな時はどうしたら良いのか問題。

• 「そういうときは身を隠すんだ！」――ネットの乱気流に巻き込まれたら - シロクマの屑籠
• インターネットでは軸足をブラすと死ぬ - インターネットの備忘録

最近のはてなオフ会的クラスタの方からみればお前誰だよだと思いますが、不詳ござ先輩、今まで38,000弱のはてブを頂いております。乱気流に頭から突っ込んでどーゆー感じで心のバランスを取ったのかみたいな、そんな話を連々と書きます。

はじめてホッテントリに入った時のこと

「もういいじゃん・・・」っていうのが正直な感想でした。アメリカにはSIerなんて存在しない - GoTheDistanceという記事が2007年に突然ブクマ頂きまして、色んなコメントを頂きました。コメント内容云々よりも、早くこの乱気流は終わらないかな、と。色んな人に見て頂ける事自体は嬉しくても、僕には何のメリットもなかった。ブログで商売してるわけじゃないから。

「どこまで伸びるのだろうな〜、うひょひょー」という期待感は全くなく、どこまで伸びちゃうのこれっていう焦燥感しか無かったです。

アテンションの濁流でバランスを崩す

読み手に自分の意図した通りに読み取って頂けない場合は、原則として書き手の問題です。誤解を生むような書き方が悪いと考えるべき。でも、それが不特定多数だと・・・どう対処していいかわからないんですね。

頂いた大量のコメントに目を通すと、「すいません、それ違います。こういう意味です」っていうポイントが複数生まれます。色んな人が見に来てくれるので、余計気になります。訂正・追記したりはするんですけどね。またそこでDISられるのは・・という気持ちにもなります。書いた記事によっては「ここだけは曲解してほしくない」という所もあり、そこを守るように予防線を張るとその行いがバカらしくて自分で凹んだりしました。

ホッテントリに入って１番堪えたのは、不特定多数のコメントを頂き続けると自分が否定されているような感覚になったこと。あくまで記事についてのコメントなんですけれども、「この記事なんなの」と「コイツ何なの」って非常に距離が近いのです。そこから自己罪悪感というか、そういうのも生まれた。この肌感覚はホッテントリに入らないとわからないかもしれません。

情報の取捨選択は受け手の自由

その自由を阻害したり、解釈を強要することは絶対に出来ません。

はてブで頂いたコメントを見ては｢なんで言わんとしていることがわかんねーかな、随分と勝手な解釈しやがって｣という苛立ちを感じていた頃もございましたが、この行いが天に唾を吐くのと同意だと気づいたら気が楽になりました。

そういう気持ちになると「この記事で伝えたいことはコレなんで、そこだけ伝われば後は何でもいいや。」という絶妙なバランスを取ることが出来るようになりました。ホッテントリに入ってから、２年ぐらいかかりましたけど。

段々と守りたい主張とツッコミ所を記事内で両立させることが出来るようになり、頂いたコメントも「あ、やっぱそこですよねー(・ω<)ﾃﾍﾍﾟﾛ」的な感じで受け流せるようになりました。何かを主張するってことは何かしらの立脚点を持っていますので、その立脚点の違いに拠る見解のズレは当たり前のことですから。良い悪いではなくて。

その辺のやわい気持ちをまとめた記事が他人からの評価は受け止めちゃいけない - GoTheDistanceになります。よろしければ。

承認欲求

今は全く無いですけど、はてブに慣れてくるとブクマを集めることが面白くなった時期も確かにありました。このテーマの記事じゃ伸びないからやめようとか、これを記事にすれば絶対伸びるなとか、そんな打算というか。初めて1000ブクマ超えた記事を書いた時は、正直テンション上がった。

コメントに対する耐性がついたので、書く以上はいっちょやったろか的な気持ちがで出来ちゃった。書いた記事が全くブクマつかないのはつまんなくなってしまい、ちょっとかっこ悪いぐらいに思ってた時もあった。こういう気持ちのことが承認欲求なのでしょう。

しかしですね、それらの感情はブログというかネットから距離を置くとス～ッと消えていきました・・・。

もう3万8千もはてブを頂きましたので、はてブを頂くことで何かを得たいという欲求はさすがにもう無いです。ブクマページのコメントを非表示する予定はありませんのでご安心下さいませ。百花繚乱、大歓迎です。

はてブのおかげで今がある

ブログをやり続けてきた１番の理由は、やっぱこれ。近しい人・友人が見守ってくれたから。その延長線上で、ブログを見てくれて参考にしてくれた人が増えたという好循環があって、色んな出会いや機会を僕にくれました。そうなると、辞める理由も無かった。もったいなくて。

それもやっぱり自分の軸足は普段生活しているこの世界で、自分が信頼してるパートナーや理解してくれる人たちが分かってくれればそれでいいや、と気付けたからだと思います。

インターネットでは軸足をブラすと死ぬ - インターネットの備忘録

はてブのおかげで今があるし、はてなでブログをやっていて良かったです。

また、７年前からずっと記事を取り上げてくれたカリスマ個人ニュースサイト管理人である「まなめ」氏には大変感謝しております。「はてな生まれ まなめはうす育ち」と申しますか。

最近はめっきり更新ペースが落ちてしまいました。すいません。これからも頑張りますので、よろしくお願い致します。

【書評】「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

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

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術に続く、細川氏の第２作。前作ではITシステム開発の難しさを題材に網羅的にユーザーやベンダーがプロジェクト運営で失敗してしまうポイントを挙げられておりました。いわば、入門編という位置づけですね。本作では実際にプロジェクト運営でモメてしまう所も判例を通じて論じており、いわば「実践編」という立ち位置になっています。モメてしまうポイントを先回りして、フェーズ毎にヘルスチェックをして頂いております。

本書は女性弁護士キャラは出てきません。悪しからず。

システム開発は複雑系の極み

本書ではITプロジェクト運営を成功裏に導くために、77個の鉄則(チェックポイント)を掲げてこのチェックポイントをうまく抑えておかないと水が漏れるように浸水する可能性があるぞ、という警鐘を鳴らしています。

・・・77個もあるのか、というのが僕の正直な気持ちです。請負でこのリスクを背負うベンダーはよく商売ができるなと。ディフェンシブになるのが当然。転ばぬ先の杖を提供するのがプロの仕事だから当然のことだよ。転べば転ぶほど金も時間も喰っちゃう。

MosCow分析を徹底する

僕が自社の業務システムを運営している中で感じるのが、どの課題も等しく同じ重要だと考えがちな人がとても多いこと。これでは課題管理にならない。課題管理表を回覧板にしないために、WBSの粒度(更にはタスクを定義)を決めるために最も重要なのが、本書の132pで触れられているMosCow分析だと感じました。

Must	その要件が実現されなければ、システムやサービスの導入目的が果たせないもの
Should	その要件が実現されなうても、システムやサービスの導入目的が果たせるが、メリットが大きく損なわれるもの
Could	その要件が実現されなくても、システムやサービスの導入目的が果たせるしメリットもあるけれども、実現すれば更に大きなメリットを享受できるもの
Would	現時点で議論する必要がないもの。実現の要否判断をしたところで、導入目的にもメリットにも寄与しないもの

この区分けができていれば、課題を構造的に管理できるし、どの課題を潰せば他に影響が出るのかも議論しやすいと思う。

他人に仕事を任せることに不安な方にもおすすめ

本書は最も複雑なIT系のシステム開発プロジェクトを題材にしてモメないようにヘルスチェックが出来ますので、細かく厳密に状況を俯瞰できます。本書に挙げられた基準を元に他社様に依頼した作業の管理手法を見なおせば、ご自身のお仕事の管理効率UPにも繋がります。部下を持った、パートナーと共に働く。そういったことに、ちょっとでも不安を感じた方は一読をおすすめします。

ここから本書と関係ない話

モメないプロジェクト運営をする最適な方法を教えます

非常に簡単な事です。開発をベンダーに依頼しないで自社で開発することです。これで全てのリスクは自社内だけ。僕は本気でそう思っている。日本の会社の99%は中小企業だし、中小企業が日常的に使うシステムを作るインフラは有り余っている。弊社内製システムはVPSで動かしているので、モメるのは物理的障害(プリンタ接続)ぐらいしかない・・・。中小企業のトランザクションなど年間で１万レコードあるかどうかだし。パフォーマンスの問題などまず出ない。

オーダーしたことでコントロール出来ないなら、オーダーしてはいけない。自分でExcel/Access/各種PaaSで自作すればいい。もしくはASP/SaaSを借りたっていい。いわば、自習。Access使って簡易的システムを構築する本など巷にあふれている。これがWebベースでかつインターネット上に構築して売上を取るようなサービスになると話は別だけど、事務作業の代替手段なら自習しよう。お兄さんとの約束だ。

言い方悪いけど、素人だから生兵法は怪我の元でプロに依頼して、プロに対する仕事の依頼方法がわからずに爆死すること程、愚かしいことはない。

ソフトウェアは完全にコモディティ化しており、制作するだけならいくらでも手段がある。何百万もかける予算があるなら自習期間にお金をかけたほうが、後々IT戦略を立てる時に地に足の着いたものになります。

【書評】「納品」をなくせばうまくいく 〜ソフトウェア業界の“常識"を変えるビジネスモデル〜

著者の倉貫さんより献本御礼。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

納品のない受託開発とは

簡単に言うと「一括請負契約をしないで、お客さんの欲しいシステムを受託開発すること」になります。何故一括請負契約をしないのかということが理解できないと、このモデルで契約する意味を感じられないでしょう。本書の主題の１つに「完成(納品)を前提とした一括請負契約がシステム開発をダメにしている」という問題意識がありますので、そこを重点的に補足したいと思います。

一括請負契約の問題点

作ることが目的になる

一括請負契約では完成責任を果たすことが求められます。その為に要件定義を行い完成となる条件を決めます。そして要件を満たすソフトウエアを作るために仕様を策定することになります。

その要件を満たす為のソフトウエアを作ることになるので、本当に顧客が必要な機能を改めて開発したり、コード上にある技術的負債を直すことにはつながりません。コストが増えるだけだからです。完成基準がどんどんブレてしまっては、何のためにその仕事を請けたのかわからなくなります。

「ソフトウエアを作ってから達成したい目的」と「ソフトを作ること自体が目的」との乖離は、必ずつきまとう問題です。

費用対効果が悪い

一括請負をするためには、不完全なリスクに対応するためにバッファを積みます。ベンダー側も必ず予定通り進むとは思っていないので予定とずれた時の為の隠し貯金を積んでいます。完成を引き受ける以上、完成リスクを負うのはベンダーですから、そのリスクを軽減するために当然のことと言えます。そのリスクを負ってしまう以上、高品質なソフトウエアを作るために必要なお金以外のコストが多くかかります。完成すればそれで終わりじゃ無いのに不必要なコストがかかってしまうことを問題視されています。

継続的な手直しが出来ない

ソフトウエアは使い込めば使い込むほど、様々な変更点が出てきます。僕は内製で業務システムを組んだのですが、その変更点は細かい使い勝手から大きなビジネスの流れをサポートする機能まで幅広かったです。改善と前提した運用が出来ることの意味を肌で感じています。進化のないシステム運用を強いられると、自社の業務やビジネスをより良くするチャンスを失うことになりソフトウエアがビジネスの足を引っ張りかねません。これでは、折角オーダーメイドで作ったソフトウエアを使い続ける意味が何なのか、わからなくなってしまいます。

ビジネスをITで成長させたい顧客に最適のモデル

上記の３つの負の側面を無くすために「ビジネスの成長に寄与しながら、エンジニアのプレゼンスを最大限高めるビジネスモデル」を倉貫さんが考案され、月額定額制の顧問プログラマを活用してソフトウエアとビジネスが共に成長することを目的とした受託開発モデルが「納品のない受託開発」であるいう理解を、本書を読んで新たにしました。必要な企業に必要なITを提供できるモデルだからこそ、優秀なエンジニアの地位も高まっていくという相乗効果についても書かれています。

ソフトウエアって経営に何の役に立つのだろうと漠然と考えられている経営者の方にも、このモデルはありがたいのではないでしょうか。発注側のリスクが殆どありません。変更OKの前提で作ってもらえて本当にそれが必要なのかどうか確認しながら月額料金だけ払えばいいというモデルは、一括請負に比べて実に頼みやすいのではと感じます。自社の競争優位をITで築くことの意味を共に考えていけるわけですし。

個人的にはビジネスに寄与できるプログラマが特に非IT企業で当たり前の存在になって欲しいので、経営の外部ブレーン(顧問)としてプログラマとしての働き方がこのモデルで更に加速することを、期待してやみません。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル