GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

5分でよく分かるロジカル・コミニュケーションのポイント

ロジカル・コミニュケーションを考えるのにとてもぴったりのエントリが２つ並んでいたので、便乗させて頂きます。

このように全く反対のことを２つ並べて考えるのが、最も思考訓練になると思います。「Aは最高や！」と「Aはマジクソ」の本が２つ並んでいる書店って気が効くなぁと思う。

何かを主張するのなら断定的であるべき

特にインターネットで顕著なんですが、何かを意見表明して主張をしたいなら言い切るのがベストです。ネットの文章はタイトルが全てとはよく言われますが、言いたいことが簡潔でないと伝わりにくくなりますし、読まれるかどうかも怪しくなります。読まれないと始まらないという、鶏卵問題がありまして。

実は「AともいえるがBともいえる」言説は、読者のためにならないことが多いです。私はこーゆー観点に立ってこう考えたよというのが明確でなければ、相手に響くものがありません。受け取った情報から考えて頂くきっかけも生まれません。一周回って、自分に得るものもありません。発信においては、毒にも薬にもならないことは意味が無いし、それぞれの立場を配慮したような意見は不要と僕は考えています。

ただ主張が強いだけの単純バカ

その主張が正しいかどうかは、主張それだけで判断できません。その主張が「そのように言える」かを検証するためには、以下の２つが必ず伴っている必要があります。

・理由：なぜ、その主張を言えることが可能なのか。

・根拠：その理由を支えることになる事象・現実。

これらが抜け落ちている or 明らかにそのつながりに矛盾があるのに、主張を振りかざすことを単純バカと言います。イケハヤ尊師がよく批判炎上しているけど、大抵この辺に原因があると思う。

単純バカの一例をあげると「大企業で成長できるとか完全に嘘やねん」という主張の理由が「上司がリスク取らんから」みたいな。いやいや、それ大企業でなければ起こりえないことちゃうし、リスク取ってくれる上司やったら成長できる根拠はどこにあるの、みたいなね。

主張を分析する「シリコン」フレームワーク

今日は情報過多の現代社会で生き抜く皆さんのために、僕がちきりん曰く成長できない大企業の研修で教わったことを、半分うろ覚えだけどシェアさせて頂きます。

f:id:gothedistance:20131125113454j:plain

確か・・・講師はマーケティングで著名な佐藤義典さんだったと思う・・・。６年以上前なので、講師の方も正直うろ覚え。

だけど、「何かを主張するのであれば理由と根拠が組み合わなければならず、主張を崩したいのであれば"主張⇔理由⇔根拠"のつながりを叩け」というお話を頂戴した時は、マジで目から鱗だった。それだけは非常によく覚えている。ええこと聞いた。

主張を崩したいなら主張そのものに「いやそれはおかしい」と反論しても無駄。ちきりんさんの「AともBとも言える」が役立たずなのはこの意味において。確かにそういう方は多い。相手の言っていることを叩くのではなく、相手の言わんとしていること(理由と根拠)を汲み取って、その上で「その主張が通るのであれば、この理由はおかしくないですか」という話をしないと、議論が進まないからね。

そうなると、逆説的だけれども「AともBともいえる」シリコンのトライアングルが出来る。それでいい。受け手のそれぞれの立場によって、正しいかどうかは違ってくるんだから。

極論は議論の幅を決めるもの

「Aしかない」という極論には、確かに何の意味もない。ただ、「Aしかない」を活かすには「Aなわけがない」という対となる極論が必要になるだけなんです。

  • 大企業で成長できるとか嘘
  • 大企業で成長できないわけがない

どっちも極論です。どちらも、それだけでは何の役にも立ちません。でも、この極論の間を「行ったり来たり」することで、自分にとって「大企業に入ると成長できるのか」という問題に対する仮説検証が可能になるんですね。どういうケースなら成長できるんだろう、どこで間違えると成長できないんだろう、って感じで。仮説はいくつあってもいい。所詮、大本の立ち位置が変われば全部変わる。人間は社会的生物なので、立場が変われば考えも変わる。ノープロブレムですよ。

この極論の狭間を行き来するって話は、以下の書籍に書いてあった。もう絶版っぽいですね・・・。中古ばっかり。図書館などにあると思うので、是非。

[新装版]30歳からの成長戦略

[新装版]30歳からの成長戦略

30歳からの成長戦略―「ほんとうの仕事術」を学ぼう (PHP文庫)

30歳からの成長戦略―「ほんとうの仕事術」を学ぼう (PHP文庫)

30歳からの成長戦略 「ほんとうの仕事術」を学ぼう

30歳からの成長戦略 「ほんとうの仕事術」を学ぼう

まずは、相手の言わんとしていることを考えよう

コミュニケーションの一番大切なポイントは、相手の言ってることではなく相手の言わんとしていることを汲み取る努力をすることだと僕は考えています。なんでそう言うんだろう、なぜ言ってることが違ってたんだろう、なぜここで困ってるんだろう。そういう断片をつなぎあわせて、シリコンをうまく組み立てながら、「あなたの言うことならば」と仰ってもらえるよう頑張りましょう〜。

SIビジネスは必要不可欠なのに何故ダメ出しされるのか

きしださん、嫌なことでもあったんやろか・・・。

要点はこのTweetに集約されています。

「与えられた課題を解決する最適なシステム」を作ることが目的ではなく、「決められた仕様を満たすシステム」を作ることが優先されてしまうので、技術的・仕様的に間違っている状態でもそのまま進んでしまうこと見えない負債が積み重なる。そして、結局誰も得をしないのです、と。はいはい。

この点につきましては何度も同じことを指摘してるんですが、大切なことは何度も言うべきかと思いました。

なんでそんな苦労をSI側がやる必要があるの？

いいじゃんいいじゃん。要件固めてこれ以外やりませんって言えばいいじゃん。なんでそんな苦労して値段下げてやるのよ。期間と人数圧縮したらめっちゃリスクでしょ？おまえがやれるかわかんねぇだろ？どうすんの？

これは、僕がマネージャのデビュー戦でSI勤務時代に言われたこと。一部脚色してお伝えしております。追加変更は受託開発の華ですね。これに反論できる唯一の案は、「変更追加をここで容認しないと本来のプロジェクトの目的を果たせません。そこをご納得頂いて追加分を確保します。」でしょう。でも、何度もそんなこと言えないよね。値段出しちゃってるのに。

要件定義や仕様書に基づいてシステムを作るお仕事が、ITが生む付加価値そのものを受け取ることが出来ないビジネスモデルになっているという話は、「経営に資するITが提供できていないのである」に置き換えられて何百周もしております。まるで、砂漠に浮かぶオアシスを見つけては消えていく情景が思い起こされます。

ITが生む付加価値を得るためには、自分たちで改善できるようにしなくてはなりません。管理できないものは改善できません。当たり前のこと。企業内システムでもネットショップでも、その点は全く同じ。自分たちで手を入れられないモノは、変化について来れず廃れていく。

フルスクラッチでやる必要はなく、手を入れるヒトは内でも外でも構いません。管理できれば、つまりどこをどうするとどうなるっていうPDCAが回せれば。でも、「事業運営にITとビジネスの知見を併せ持つ人材が必要」という点は変わらない。両方持ってる人材がいなければ or 組織体でなければ、また上流と下流の工程の分断が生まれてしまう。工程の分断は絶対ダメです。皺寄せが全部エンジニアにやってくる。

１つだけ勘違いしてほしくないのは、顧客の持っている経営資産を活かして新しい何かを切り開くSIは常に必要です。SIビジネスは必要なんですよ。不要ではないんです。オワコンって指摘されているのは下請けに流すビジネスモデルです。問題は明確ではあります。色々難易度高いけど・・・。

・・・って話を2007年頃からずっとしてて、ITが生む付加価値そのものを受け取る為にはリスクを取って内製がベストだと主張してたら、自分でたった独りで内製するハメになったアカウントがこちらです(・ω<)

SIビジネスのあかんところをもっと知りたい方は、｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistanceをご参照下さい。

スペシャリストを脱しろ

この手の話をしていると必ず聞かれるのが「じゃあ、我々エンジニアやプログラムはどうやって生き残っていけばいいんですか？」という問題。僕の回答は「スペシャリストを脱して、プロになろう」です。

まず、業界が縮小したら職が無くなるわけではないことをしっかりと自覚して頂きたい。業界が右肩下がりになったら自動的に自分の未来も右肩下がりにはならない。落ち着いていこう。活躍の場は１つではない。キャリアは驚くほど多角的なもので、絶対に一本道ではない。

スペシャリストってのは、与えられた問題を自分の持っている技術で解決するだけの存在。でも、プロは問題そのものを発見する能力と解決する能力を併せ持つ存在。技術は移り変わるが、問題を見つける能力は移り変わることがありません。スペシャリストで生きていくためには、ピラミッドの頂点を目指す or 居続ける努力が必要です。僕の10倍優秀なスペシャリストは国内だけにとどまらず、腐るほどいるし。この道は険しい。とっても。

プロになる最大の近道は、自分の半径5メートルを変えることだと思います。能力だけでは仕事は出来ない。能力を磨く努力は誰でもやっているように思いますが、活かす努力って意外とやってないように思います。能ある鷹は爪を出してナンボ。働きかけないと活かせる場所、見つからないかもよ。

高いスキルを持っている人よりも、異なる分野の高いスキルを持っている人をつなげて、その会社なりが抱えている問題に対してこーゆーことができないですかねっていう話が出来るひとが圧倒的に少なくて、しかも頼りになるんよ〜。

こちらからは以上です。

34歳になりました

OH… 光陰矢のごとしでございます。

昨年からめっきりブログの更新をしなくなってしまって、目の前のお仕事に邁進する日々が続いてしまいました。家と事務所が近すぎるので出不精になってるだけなので、皆様に於かれましてはお気軽になんか呼んでください。

また、僕自身が自分で仕事を取ってくるようになって、地上に舞っている葉っぱを手づかみで掴むようなことが増えました。その葉っぱがどんなものかもわからないけど、取りに行かねば取り付く島もないような、そんな感じです。本来、シゴトってそーゆーもんなのかもしれませんね。

ブログの内容も1年ぐらい小難しく硬い内容が続いたので、やわい話もちょろっと更新していきたいと思います。

また、こっそりと趣味の野球のブログを始めておりまして・・・野球好きの方、どうぞよろしくお願い致します。

ギブミーお誕生日プレゼント

僕にお誕生日プレゼントを送ってもいいという慈愛と博愛に溢れている方は、こちらを是非ご検討下さい。


だいたい、こんな感じです。

これからもどうぞよろしくお願いいたします。

はてなブログへ移行しました。

こちらの記事に「はてなブログは無料プランでもamazonのアフィリエイトIDを自分自身のものにできる」と書いてあったのでカッとなって移行しました。

はてなブログに移行したらアフィリエイト収入が急に増えたよ - give IT a try

移行にあたって不満な点はいくつかあるんですが、最たるものは自己紹介ページの内容がクソってことです。書いた記事数や自分がどのモードではてなブログ書いてるかを一般世間に公開して誰が見てそれを喜ぶんだ。プロフィール内容ぐらいHTML好きに書かせてください。もしくは、はてなダイアリーを踏襲してほしいと切に思います。

id:hatenablogさん、これは大変なことでございますよ。個人的に。

追記

移転したわけではなく、ブログの構築サービスをはてなダイアリーからはてなブログに移行しただけなので、コンテンツも全く同じですし旧ブログから勝手にリダイレクトされてこっちに飛んできます。

ドラゴンボールがドラゴンボールZぐらいになった程度だとお考え頂ければ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なぜ、システム開発は必ずモメるのか? 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字回復は無いとは思います。特別損失で赤字計上なら分かるんですが、営業利益が足りなくて赤字決算になるとかなり厳しい。新卒で入社されたい学生さんは現状かなり厳しい状況になっていることを認識しておくといいでしょう。

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

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

超高速開発のコンセプト自体は僕も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だろうが、手段は何でもいいじゃん。 ソフトウエアの作り方とすれば、そりゃ不都合なことはコードを書いてから現れるんだから小さく動くのがベストだけど、ソフトウエアが欲しい人からすれば「どういった開発手法やプロセスが」ベストなのかを考えていけばいいじゃないですか。ここは千差万別でしょう。

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

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

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

SQLを学習できるWebサービスを作りました。