GoTheDistance

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

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

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

「納品」をなくせばうまくいく ソフトウェア業界の“常識

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

納品のない受託開発とは

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

一括請負契約の問題点

作ることが目的になる

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

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

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

費用対効果が悪い

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

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

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

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

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

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

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

「納品」をなくせばうまくいく ソフトウェア業界の“常識

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

【書評】システムインテグレーション崩壊 これからSIerはどう生き残ればいいか？

技術評論社の傳様より献本御礼。

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

工数積算のビジネスは終わる

SIという言葉が指し示す範囲もSESから受託開発まで幅広い中で、著者の斎藤氏は「工数積算を前提としたビジネス全般、請負や準委任などの受託開発やSESや技術者派遣ビジネスも同様に崩壊に向かう」という内容の趣旨が、表紙をめくって１ページ目に書いてありました。アクセル全開です。エンジニア人月０円セールと、ござ先輩に見た未来 - 山本大＠クロノスの日記っていう話もあるぐらいですからね。

崩壊に向かう理由は大きく３つあると書かれてあり、最初に挙げられている理由が「工数積算で成果保証を担保されるSIビジネスは、構造的に不幸にしかならない。」というものです。システムを欲しい顧客は「ビジネス上の価値向上」を目的としています。しかし、上限が決まっており瑕疵担保責任を負う立場のSI業者は「決められた仕様を満たすシステムを納めること」が目的となります。このゴールの不一致が構造的に不幸にしかならない理由だと説明されており、古くは2006年に現在ソニックガーデン社の代表である倉貫さんのディフェンシブな開発 〜 SIビジネスの致命的欠陥で指摘されております。色んな人がいろんな視点から同じことを言っていることに意味がありますね。

ビジネス上の価値を目的とするシステム構築が何故出来なかったのかについては、SIer/ユーザー企業双方に非があるということで、その理由については第２章で触れてあります。成果保証を求めるのにエンジニアの工数積算で根拠を出すこと自体がナンセンスではという疑問に触れながら、それにはそうなってしまった理由もあるのだということで。

３章以降は新しいポストSIへの取り組みを紹介しています。既存のビジネスがダメなら、ビジネスモデルを変えるか新しいことを始めるかのどっちかしか道がない中で、両方の道をどうやって歩むのか、実際にどういうビジネスモデルに変えた会社があるのか等、色んなヒントが書かれています。「問題認識→その背景を分析→次はこっち」って感じですごくまとまってるので、通覧するには最適の一冊ではと感じました。

が、これはちょっと待ってくれという提言がありました。「アジャイル型請負開発モデル」の提言です。

アジャイルで請負ってちょっおま

何故この提案が引き合いに出されているのかと言いますと、ウォーターフォール型のように後工程とのつじつまを合わせることが出来ないやり方は必ず歪みがでてしまう。先ほどの構造的な不幸を引き起こす一因である、と。ビジネス価値達成という共通の目標に向かって、重要な機能から先に作ってリスクを低減しながらシステムを育てることを目標に、フェーズを切ってその都度請負契約を結んでゴールの不一致から脱していこうという話でした。聞こえはすごくいいけど、積極的に請負でやろうという会社がどれだけあるのか疑問です。違う形でつじつまが合わない未来がすごく見えたし、仕様が不透明だとしたら工数積算しか出来ないと思います。２人あなたの案件に貼り付けますのでみたいな。

そういう風に考えるとはじめの１ページ目で指摘されていた工数積算前提のビジネスは崩壊するってあれ・・・という矛盾を感じました。このモデルを進めていくことで未来が明るくなるとは言い難いのではないでしょうか。

僕の考えるポストSI時代

本書でも記載がある通り、既存のビジネスがダメなら新しいことを始めるか、ビジネスモデルを改良するかのどちらかの道を取るしか無い。新しいことを始めるのはベンダーでは無くユーザー側になると見ています。新しいIT事業をSIerが始めてシェアを取って新しい業界地図が出来るという未来にはなりそうもない。成長ドライバがユーザー側にあるとすれば、以下の様な未来がやってくるのではと思っています。４年前にツイートしていた自分、グッジョブ。

奇しくも昨日、ITProの名物コラム「極限暴論！」を連載されている木村記者が同じ内容の極論(木村岳史の極言暴論！ - ユーザー企業がITベンダーを駆逐する：ITpro)を掲載されていました。我が意を得たり、でございました。

僕は主役が変わる未来が一番いいと思ってますが、皆さんはいかがでしょう？ 本書をあたりながら次のIT業界の主役は誰になるのかを考えていくのが、一番面白い読み方だと思います。

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

【書評】プログラムは技術だけでは動かない

技術評論社、傳様より献本御礼。

プログラムは技術だけでは動かない　?プログラミングで食べていくために知っておくべきこと

プログラムは技術だけでは動かない　?プログラミングで食べていくために知っておくべきこと

本書は「技術的な力はあっても、仕事として作った技術を活かした製品やシステムが、使いものにならないことがある。」という問題意識が根幹にあります。技術力を活かして飯を食うために「プログラマとしての仕事力」という観点で自分のキャリアを考え直してみたらどうだろうか、という位置づけになっています。決して技術力を卑下しているわけではなく、技術を活かすのであれば仕事として評価されないとダメだという話です。

いくつか、僕が響いた内容をピックアップしていきます。

作るだけでは仕事にならない

プログラマとしての仕事力というのは当然いくつかの能力があるわけですけれども、本書で一番最初に出てくるのは「作るだけでは仕事にならない」ことを念頭に置くということでした。出来たかどうかじゃなく、依頼者の課題を解決できているかどうかという意識を持つ。全くその通りだと思います。

でも、お客様の依頼を請けて、それを自分の手で直接実装して製品を作って納めたりっていうフィードバックを受ける機会を得られること自体が稀かもしれないという心配もあったり。元請けじゃないと出来ないけど、元請けが自分で作ることがない場合はその限りじゃないし。逆に言えば、もうそのような機会を積める会社にお勤めの場合はとても恵まれているかもしれないな、と思います。

ソフトウエアはいくら自分が完璧だと思っても、それを使う人やそれを担いでくれる人にとっての完璧とは質が違うもの。その辺のすれ違いを超えられることが大切ですね。

知ってもらわねば損をするだけ

プログラマとして仕事を請けるにあたっては、自分のことを知ってもらう活動(大きくいえば広報活動)がすごく大切だとおっしゃってます。自分が何が出来るのか、どんな仕事をしてきたのかというバックグラウンドを知られているのとそうでないのとでは、全く違う、と。今ではソーシャルメディアのおかげで自己PRの場所はたくさんあるわけですから、能ある鷹は爪をジャンジャン研いで出しましょう。

プログラマとしての得意分野とは言語等のことではない

これが個人的に１番響きました。

得意分野としている技術が廃ることは困るという意見も、実際そんなことはないだろうと。自分が得意としている分野の問題解決で専門性を発揮していれば、応用も効く。

「自分がCが書けます、Railsが出来ます」というスペックとしての話ではなく、「得意なプログラミング技術を用いて、どんな問題を解決するのが得意なのか」が、プログラマとしての得意分野。そこを意識して欲しい。

本書にはそのように書かれておりました。

受託開発と製品開発の両方で食ってきている著者の方ならではの視点が多く、読み応えがあります。プログラミングの仕事をしている人だけでなく、プログラマに仕事を依頼される方にも一読して欲しい本です。

プログラムは技術だけでは動かない　?プログラミングで食べていくために知っておくべきこと

プログラムは技術だけでは動かない　?プログラミングで食べていくために知っておくべきこと

無理なものは無理と割り切れる才能

最近、無理なものは無理と割り切れるのもひとつの才能というか、技能なのかもしれないと思うことが増えましたので、その辺書いてみたいと思います。

逆算して物事を考える人、そうでない人

お仕事におきましては、解決したい問題や課題があります。それを解決できるためのゴールをまず決めて、そこから逆算してここからスタートしたら良いのではという仮説を作り、それを検証していくというのが生産的ではないかと思います。

逆算せずにその道をまっすぐ進んでいけばゴールに辿り着けると考える人も少なくないですが、そうなると上手く行ったらオレやみんなが頑張ったから、上手く行かなかったらまわりの頑張りが足りなかったらという自分本位の見方から抜け出せることが出来ませんので、また同じ間違いを繰り返します。アカン。

10の力では20の重さのモノを動かすことは出来ない

プロジェクト管理や経営戦略の実行においての「あるある」だと思うんですけれども、いくら頑張っても頑張っても10の力しかない組織が、20の重さのモノを動かすことは出来ません。逆算できないタイプのマネージャは、10の力でも力いっぱい押せば「徐々に」20の重さの物を動かせると考えがちです。無理です。動きません。ふすま1cmぐらいの隙間は動くかもしれませんが、その壁を動かして次のステップに進むことは出来ません。

20の負荷をやっつけるには、20以上の力が必要です。努力ではどーにもできません。

ステップ by ステップの罠

これも逆算しない人に多いんですけど、同じ所で足踏みしていることを一歩一歩進んでいると勘違いしやすいです。別の地点に進んでなければダメ。その結果は経営ですと、決算の数字に現れます。売上が上がったけど仕入も経費も増えちゃって結局何のために頑張ったんですか、っていうパターン。同じ利益しか残らないなら、仕入や経費が少ないほうがいいでしょ。

売上増を目指すことは否定しません。でも、売上増を目指すためには必ず経営資源を投入することになり、コスト増につながりやすくなります。産声を上げたホヤホヤのスタートアップの場合は逆算もクソもない部分があるかと思いますが、それでも「別の地点にジャンプできているのか」と「ルームランナーで同じ地点を走っているのか」は明確に区別すべきでしょう。

頑張るという言葉には主語がない

個人の努力で頑張るというのはいいと思います。でも、仕事ではダメです。主語がない。主語がないというのは、目的がないからです。目的がないなら、やる意味がありません。意味が無いことはやるだけ無駄です。やらないほうがいいです。

僕は野球が趣味なので無駄に野球ブログの更新を頑張っています。こーゆーのは個人で解決できるから好きにしたらええやんだけど、仕事はダメ。あなたのアウトプットは、誰かのインプットです。それをつなげるのは互いに目的があるからで、「主語のない頑張る」は摩耗しているだけになりやすいので気をつけて下さい。

無理なものは無理です

無理なものは無理と言えるのは、逆算できるからです。ただ、逆算が先に走り過ぎると損得で考えやすくなり、新しい何かを生み出す時に足を引っ張ることもあります。

でも、何が必要で、何をどう変えると、どういう結果が出るかということは常に考えていくべきです。本当に新しいことはどういう結果が出るかはわからないけれど、プロははじめからどういう結果が出るかわかってないとダメでしょ。正解を再生産できないならプロじゃないし、やってみないとわからないは素人がいうセリフだ。プロはやる前からわかってないとダメなの。見積も出せないやんｗ

無理なものは無理をかけ合わせると、本当にやるべきことが見えてきますよ。マイナスとマイナスをかけるとプラスになります。そのプラスになる所が、一番の強みになるもんです。人も組織も。

会社の代表電話って無くても困らないのでは問題

先日、あるWebサイトのリニューアルの企画資料作成作業の最中で、作業に煮詰まってからのグッドアイデア降臨。紙に整理しようというタイミングで会社の代表電話が鳴ってしまい悲しい思いをしました。その内容が腐れた電話セールスだったので余計悲しかったです。

個人電話なら折り返すという技が使えますが、代表電話はスルーして折り返すことが出来ない。どんな内容かはわからないけど、出なくてはならない。憎いあンちくしょうであります。

それは僕の個人的な恨みなのですが、改めて会社の代表電話って役立たずなケースが多くてどうなんだろうって思うことが多くなりました。ちょっと吐き出してみます。

代表電話の内容はノイズばかり

２年近く代表電話を取ってきて、代表電話にかかってくる内容はノイズがとても多いです。代表電話にフィルター機能があればどんだけ楽かと思います。

不要なセールス電話を自動的に撃退し、定型的なお問い合わせはコールセンターのようにガイダンス化したい。社長さんいますか？とかいうクソみたいなセールスが来たら山田ボイス流してやりたい。

会社として誰かがやればいいしリアルタイムである必要がない(赤伝処理等)内容も多く、そんな内容ならお願いしますと紙１枚流してくれればお互い楽じゃないと思ってしまう。定型的な処理はTELではなくチケット駆動でもいいんではないかと。

事務作業は結局FAXが中心

電話はエビデンスが残らないので、お電話を頂いても確認したいからあとでFAX流してくれっていうケースも多いです。伝票処理・注文処理・請求処理・・・口頭で全てを処理出来るケースはレアです。

ご注文処理はエビデンスが残らないと「頼んだものと違う」という水掛け論になる恐れがあります。先方のミスでも居直られて泣きを見る恐れがあるので、FAXかメールで文字起こしをお願いしています。

今すぐに絶対やらねばならない話でもないのに、代表電話経由だと電話したのに処理が遅くて何事だという話になりやすく必然的に優先順位が前に来てしまい、作業が細切れして掛け持ちになってしまい生産性が落ちて弊社従業員の残業が増える一因にもなっています。

大正義「本日は終了しました」アナウンス

会社さんによっては就業終了時刻になると代表電話にTELしても「本日は終了しました」アナウンスが流れます。当初はなんやねん殿様商売かと思いましたが、あのアナウンスは従業員のオーバーワークを防ぐ意味で大正解だと思うようになりました。FAXやメールでくれるか、時間内にかけてくれるように相手が合わせてくれる。ありゃ意味がある。明日にでも導入したい。

売上になる話は営業マンに直接かかってくる

弊社においては、代表電話でこーゆー商品が欲しいんだけどという売上になりそうなお問い合わせを頂くことは殆どないです。営業担当に直接問い合わせています。本社としては営業マンが口約束していることまではフォローできないし、ちょっと込み入った話ですと営業トークを交えたほうが売上になりやすい。本社の事務担当が決められないお話だと捌き切れない。

新規取引のお問い合わせはみんなWeb

新規取引のお問い合せは、ほぼ全てWebサイト経由です。

ごくたまに電話でおたくの商品を見て取引したいという話がありますが、地雷が多いです。条件が非常に不利だったり、不良品を安く流せとかだったり、倒産した会社もありました。Webサイト経由のお取引申請の場合、現時点での地雷率はゼロですし何故か継続的なお取引が出来ています。

なんだろうこの相関関係。関係ないと思うのだけど、偶然にしてはねぇ・・・。

結局、代表電話って？

お取引先様でない方に電話番号を公開する意味ってほとんど皆無だと思います。

最近は代表電話を公表しない会社さんも多くなりました。IT系に増えているように思います。今すぐ確認して保留事項を完遂したいのに不便だなと思うこともあるし、Webに載ってる内容を探して読んでこっちが空気読んで理解せざるを得ないのはめんどい。教えてくれたってええやん、と。

しかし、電話ほど時間泥棒なツールも無いし、会社を回す立場で考えると顧客でもない人に時間を割く意味ってほとんどない。お取引先様ならお急ぎの場合はこちらまでお電話頂ければというフォローアップの意味があるけど、どうでもいいノイズ等に時間を取られるのも、と。

というわけで、無差別に電話番号を公開するのも考えものだという話でした。

峰なゆかさんのロリコン定義問題で彼女が伝えたかったことを整理してみる

普遍性の高い「ロリコン」という言葉に独自の定義をブチ込むだけでものすごい勢いで拡散した峰なゆかさん。すごい盛り上がり。

「利便性において好む」という日本語がなかなか難しい。平たく言えば「都合の良いように解釈して、こいつはしょーもないやつだなと上から目線で自己満足する」という意味なのだろう。自分をよく見せるために女性の粗を探すことでコンプレックス(劣等感)を解消しようとする男性の総称として、ロリコンという言葉を使っていると僕は解釈した。精神的未熟さと幼女・少女の性的嗜好に重ね合わせているのだろうか。

この解釈で彼女の意図を掬い取れたのかもわからず、正直神のみぞ知るセカイだった。が、そんな迷える俺達のために峰なゆかさんが図解をしてくれた。それがこちらだ。

申し訳ないが、滅茶苦茶わかりにくい。

普通のロリコンと峰ロリコンの違いを説明する為のものだろうけれど、ベン図で丸が重なっている時点で美しく致命的だ。ベン図は複数の集合の関係を図式化するために使うもので、関係性があることを表現してしまう。使っている図と伝えたい意図が真逆になっているのではないかと感じました。

「それはそれ、あれはあれ。世間一般的な解釈をしてそもそも分かるわけねーだろ」という補足説明で使われる図だと思うのだが、それならば平行線であることを示さないと伝わらず、世間一般的なロリコンで且つ峰なゆか認定ロリコンでもあるハイブリッド・ロリコンの存在が少しでも頭をよぎると「もうこれわかんねぇな」となってしまう。

通常のロリと峰ロリが交錯するポイントはそもそも無いんでしょ？

同じ単語で意味の違う話をしたいんだから、交錯するポイントがないことを説明したほうが話が速いのは当たり前のことだ。

wikipediaいわく、通常のロリコンは「幼女・少女への性的嗜好や恋愛感情のこと」だって。その資質の有無と峰ロリになる資質の有無に関係性があるのかどうかを説明するために、「熟女もの大好き男性、幼女エロ本大好き男性。両者が峰ロリコンになりうるのかどうか」を考えよう。ここに関係性が認められないなら、性的嗜好の方向性と峰ロリの資質を有しているかは無関係。検証手法がわからんが、まぁ関係なさそうだよね。

ってことで、意味が違うことをキチンと説明出来ていれば、こんなつぶやきもしなかったんじゃないのでしょうか。

オチ

僕もその1人になるんですかね（震え声

ブログのマネタイズは一切考えずに頑張ります

この記述、すごくよく分かる。商業媒体で顕著だよね。

僕自身は、「すぐマネタイズの話になってしまう風潮」が好きになれません。

「お金になる」というのは悪いことじゃないのだけれども、「お金が絡まないからこそ、言いやすいこと」っていうのも、確実にあるわけで。

プロの書評家さんたちは、それが仕事であり、収入源であるがゆえに、率直な評価を言いにくくなってしまう、ということがあるそうです。

どんなに「つまらない」と思っても、その本の著者とか編集者、出版社との今後の関係を考えると、あからさまに「ダメ出し」できない。

ネットで話題になったサイトが、広告を載せたり、IT関係の会社から「仕事」をもらったりすることによって、なんだかつまらなくなっていくのを、僕は少なからずみてきました。

ネットの世界で「老害」として生きるということ - いつか電池がきれるまで

僕もブログにおいては誰の広告も仕事も入れたくない。時々献本を頂くので、感謝の意を込めて書評を書くことぐらいだけ。それ以外は一切考えたことがない。

fujiponさんの言う通りで、誰かの立場を気にしたら、言いたいことが言えなくなるじゃん。言葉のエッジが溶けてキレがなくなる。そんなのつまらない。この考え自体が少数派なんだろうけど・・・。

簡単にいえば、自動車ライターが雑誌媒体の仕事をもらって、その雑誌の背表紙に掲載されたクルマの悪口を書くなんてやっちゃいけないことでしょ。転職エージェントに踊らされない技術 - GoTheDistanceっていう記事を書いたことがあるけど、もし僕がDoDAや@type等から広告掲載の仕事をもらってたら、流石に書けない。自爆テロみたいなもんだから。でも、あの記事大好評なんだ、転職エージェント側からも。やったぜ。

言いたいことが言えないのもつまらないけれど、言いたいことをネットで言うってのは色々難しい。ひとり歩きする不特定多数の反響との適切な距離のとり方や、言いたいことと伝わったことのズレによる「なんだかなぁ」という気疲れ、それに何よりも、ブログよりも大切なことは人生にいくらでもある。

僕は特にSI業界の上流と下流の分断を批判し続けておりますが、ダメ出しって実はすごい難しいんですよ・・・。褒めるより10倍難しい。「それよ！それがあかんのよ！」っていう批判の的確さで共感を頂けるのは、その批判が生産的であることや当事者の立場に則した内容でないと困難。一歩間違えると即炎上だし、狼少年化しちゃう。悪い意味で「またおまえか」ってやつです。

・・・でも僕は、池上彰さんっぽい事ができたらってちょっと思ってる。テレ東の選挙特番で無双する池上彰さんのように、みんなが言いにくいことをバシっと言っちゃって、巡り巡って自分が所属するIT業界の自浄作用を少しでも促せるなら、万々歳なのだ。いろんな企業さんが僕の記事を使って、メッセージを発信してくれているからさ。

これからも自由なポジションから繰り出されるキレとコクのある文章をお楽しみ頂けたらと思います。

ymsrがいなかったら今の自分はないと思った話

僕のところにymsrの訃報が飛び込んだのは、12/4のjava-ja忘年会の夜にymsrを通じて友人となった@loveatからの電話だった。不慮の事故で死んだって聞いたけどマジかっていう確認の電話を僕にくれた。電話をくれた彼の声も、震えていた。

その時、僕は仕事の帰りで名神高速道路を走行していた。「いや、俺のところにはそんな話来てない。ごめんな。」で電話を切ったあと、あまりの話に驚いて直ぐに最寄りのSAに車を停めた。悪い冗談で確認電話が来ることもない。そういうことなんだろう。とにかく落ち着きたくてタリーズに駆け込んでコーヒーを飲んだ。で、facebookを見た。主語は隠されているけど多方面から似たような雰囲気のPOSTがあって、なんだよこれはっていう複雑な気持ちを一掃したくて一気に珈琲を飲み干したことを覚えている。

僕は2003年からブログを始めて、2006年にはてなダイアリーに移行した。で、ある日突然アメリカにはSIerなんて存在しない - GoTheDistanceがホッテントリに入った。ホッテントリに入るまで、はてなブックマークの存在を知らなかったので非常に驚いた。その後何度かブログを更新して、コミュニティなるものがあることを初めて知った。

僕をjava-jaというコミュニティに引き込んでくれたのが、ymsrだった。当時、amachangがIT戦士として名を馳せていて、彼らを中心に1981sってコミュニティをやってた。ymsrが僕を煽りやがって81じゃない俺たちは197Xってのやろうよって言い出した。wiki立てるだけだろって高をくくってノリだけで立ち上げたらjava-jaのみんなとお知り合いになって、グッと人生観が広がった。その経験があって「自重はダークサイド」を勝手に言い始めた。ymsrがいなかったら、コミュニティの中に飛び込むことはなかったと思う。顔の広い、他人にいつも気を配ってくれるymsrならなんだかんだでバックアップしてくれるという安心があった。

今、こうして「ござ先輩」(これはひがさんがつけてくれたんだけど)っていう愛称でブログを書いていられるのも、ブログを続ける意味を教えてくれたのも、会社の外の世界の扉を共に押してくれたymsrの存在が大きかった。とてつもなくお世話になったんだなって改めて思ったよ。

ymsrには会社に遊びに来いよって言ってもらったり、一緒に合コンにも行ったり、ビリヤードしたり、Twitterでオフ会やったり、楽しい思い出がたくさんある。ymsrを通じて知り合った友人とは、結婚や転勤等で場所が変わって事情が変わっても、交流を続けることができている人が本当にたくさんいる。

会社が変わって、環境が変わって、仕事も多岐になって、家庭の事情もあって、ここ数年は全く社外活動にかける時間がなかったけど、ymsrのおかげで今があるんだから、もっとymsrのようにいろんな人を取り持っていきたいなって改めて強く思った。

それと、会いたい人は会いたい時に会わないとダメってこともね。

残された俺達にできることは、気持ちの整理をつけたあとにymsrが取り持ってくれた縁を大切にして、北海道で飲み会をやって楽しく偲んで生きていくことかなと思う。

ありがとう、ymsr先生。

あなたは間違いなく、僕の人生を変えてくれたよ。

【書評】過負荷に耐えるWebの作り方 -国民的アイドルグループ選抜総選挙の舞台裏-

技術評論社の池本様より献本御礼。いつもありがとうございます。

過負荷に耐えるWebの作り方 ~国民的アイドルグループ選抜総選挙の舞台裏 (Software Design plus)

過負荷に耐えるWebの作り方 ~国民的アイドルグループ選抜総選挙の舞台裏 (Software Design plus)

すげー面白かったです。一気に読ませて頂きました。

本書の特徴

本書には、高密度なアクセスを捌くことが求められるWebアプリケーションを構築したいと考えるエンジニア向けとあります。国民的アイドルグループA●B48の総選挙投票管理システムの構築を題材に、システム開発や運用のお仕事がどのようなものであるのかを俯瞰できるのが大きな特徴です。

ただ、非エンジニアの方でも読み進めることが出来る一冊です。そもそも、高負荷を捌くとはどういうことかを前提おいて、先に決定しないといけないことを置いてから読み進められるので、要素技術がわからなくても「顧客より求められたことを技術的に解決するために、こーゆーアプローチを取るんだ」という思考の形跡を、余すところなく書いてくれています。

Webエンジニアの研修の一貫として、これと同じものを1ヶ月で作ってみようなんてことやっても面白いなーと思いました。

総選挙システムの勘所

本書にも記載がありましたが、最も頭を悩ませたのは「シリアルナンバー」の発行だということでした。単純な命名規則ではすぐに破られてしまい、シリアルナンバーの採番ロジックが問題で不正投票が起こりうる。これが本システムの最大のリスクであることは疑いのない所。数値のみでどうやってアイデンティティを保つことが出来るのか、という難題。

最終的にJavaの標準コードでわずか20行弱のコードで、堅牢なシリアルナンバーの発行に成功したとのこと。そのヒントは本書に記載されています。

運用監視やボトルネックの検知

総選挙システムでは、DBアクセスを軽減すべくベタでハードコートしている箇所もいくつかあったり、シリアルナンバーの妥当性チェックもコードだけで行うなど、最大限の配慮がなされていました。また、投票画面を除いてセッション渡しもクエリ渡しを使い、なるべく不要な負荷を与えないよう、その時最適な手法をとっていることが伺えます。

運用監視では非常に感動的なエピソードがあるんですが、それは本書を当たって頂ければ。

過負荷に耐えるWebの作り方 ~国民的アイドルグループ選抜総選挙の舞台裏 (Software Design plus)

過負荷に耐えるWebの作り方 ~国民的アイドルグループ選抜総選挙の舞台裏 (Software Design plus)

色んなシステムの舞台裏が公開されることで、エンジニアの仕事がより面白くやりがいのあるものであることが伝わればいいなぁと最後に感じました。

Eメールで作業内容を管理するのはやめましょう

BacklogとかサイボウズLiveとかをご存じないクライアント様が結構多くて、そのような方々にとってのコラボレーション・ツールはほぼ間違いなくEメールになります。まずその啓蒙から入って仕事をさせて戴くことが多くなりました。

お打ち合わせの場でAction決めて、その後はちょいちょいメールフォローでだましだましやってこれた時もあったのですが、やっぱこれダメだってことになったので、その話をしたいと思います。

Why Email Collaboration SUCKS

そもそも、Eメールは双方向性があるようで無いツールです。Eメールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。

１つのメールに複数の事項が含まれることがある

例えば、Xさんに対してAという事項の修正事項が記載されたメールに対して、Xさんが返信を行ったとします。その返信に対して別のBという事項のご相談があると、追いかけるのが困難になり、対応が遅れる or 対応漏れが起こりえます。

また、XさんとYさんに対して同時に作業を依頼するメールがやってきた場合は、指示されたXさんとYさんからすれば「お前の進捗どうでもええわ」になりかねませんし、「各位 ご意見下さい」メールなどめんどくさいだけのメールはそっと消えていきます。

Eメールで話の流れを変えられるのはツラすぎますし、その中でドキュメントやソースコードの改訂が入った日にはそのバージョン管理も同時に行わねばならず、しなくてもいい苦労をすることになります。

対応したログが残らず、どんな意思決定をしたのか見えなくなる

メールは返信で追跡できるとはいえ、「５件ぐらいメールをやり取りしたけど、今はどうなったの？」という状態管理を行うのには向いていません。誰が・いつ・どうやって・どのように完了したのかをメールを一連のトピックに紐付けて管理せねばならず、結局の所は終わったか流れたかぐらいしか脳内に残らず、終わったけど結局コレでいいんですかねっていう議論はなされにくいです。

懸案事項に対する対応の流れや状況管理が出来ず、全体が見えない。

メールベースでは、誰にどれだけ何の仕事(作業)があるのか全体像が把握するのが難しく、作業の優先順位をつけることが困難になります。何か色々な人が動いているんだけど、結果的によくわからないことになります。

情報共有の肝は、「お前は直接関係ないけど取り敢えず見とけテロ」を如何に排除できるかです。必要な人に必要な情報だけを如何に届ける事ができるか。自分のアクションに関係ないノイズを減らさなければコミュニケーションのオーバヘッドが大きくなる一方です。その上で初めて、皆で本当に共有したらいいこともハッキリしてくると思います。

というわけで、「なんでそんなプロジェクト管理の為のツールが必要なの」って言われたら上記のEメールで仕事を管理するのはダメっていう弊害をうま〜くお使い頂きまして、少しでも生産性の高いプロジェクト環境にして頂ければと思います。

追記

Eメールでは過去の情報に新しいメンバーがアクセス出来ない、というご指摘を頂きました。

そして一度送られたEメールは、どこか共通の場所に格納される、ということはありません。情報が適切に蓄積されないわけですね。

その結果、新規に参加したメンバーが、過去の情報にアクセスできなくなります

これは新規参加メンバーからすると、非常にツラいのです。

Emailがコラボレーションツールに適していないもう1点 - 技術情報棚卸し(平日限定)

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