GoTheDistance

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

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

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に登録しております。そしたら、なかなかファンキーなメッセージを前面に打ち出している会社さんがおりました。

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

マス広告は話半分で

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

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

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

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

成長推しの会社は要注意

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

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

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

賞与が細かい会社も怖い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

イケダハヤト氏に学ぶ社会人としてやってはいけないこと

毒を食らわば皿までと申しますので、自分に負けてイケダハヤトに言及するという罪を犯したからには徹頭徹尾言及させて頂きたく思うわけであります。

対談イベントの提案をされたのはやまもといちろう氏なのですが、イケダハヤトちゃんはその提案を飲んだわけでして。これでもう当然のごとくハヤトちゃんの大好きな対等な関係になっているわけですね。しかも自分が企画運営するとインターネッツにてブチ上げてしまったからには、そこには然るべき運営責任が生じていると考えるのが妥当です。その認識は当然おありなわけなので、各方面に奔走されていたのだと思います。

奔走されていることは先方(やまもと氏)には関係ない訳ですから、詰めの甘さからやまもと氏に「どうなってんの？」って突っ込まれてしまっただけのことじゃないですか。ちょっと嫌みの一つぐらい言いたくもなるでしょうし、氏の芸風を鑑みれば織り込み済の記事の内容かと思います。

そこで「あ、すいませんでした」って自分から頭を下げてフォローアップ体制をこうしますみたいな感じにまとめておけばよかったのに、自分の段取りが悪いことを突っつかれた程度のことで逆ギレして「つーかツイートしたし、よくみろよ。こんな誤解で一方的に対談相手を誤解して裁くような人とは一緒に仕事をしたくないね。」と寝言を放ったことには慨嘆致しました。ソースはこちらです。

ぼくの手際が悪いのは認めますが、一方的に対談相手を誤解して裁くような人とは、一緒に仕事をしたくありません。

もう一度書きます。あなたはぼくが主催するイベントにゲストとして呼ぶに足らない人格者です。

対等な立場で対談したければ、態度を変えて出直してください。あなたはぼくを見下しているようですが、ぼくはあなたを対等だと思ってますよ。それがプロの仕事でしょう。

http://www.ikedahayato.com/index.php/archives/20629

イケダハヤトちゃんの最大の間違いは、自分のアウトプットに対して不都合な点を突っ込まれていること自体を悪魔化してやまもと氏に対する人格攻撃に切り替えてしまっていることです。自分の不手際を棚に上げて人格が足りないから出直せと切り返せる段階で大人としては絶望的です。あと、自分で企画運営するって言っといて突っ込まれた内容で心が折れて企画できませんって自分から戦力外通知を出しているじゃないですか。印象が悪くなったならプロブロガーとして挽回すればいいだけじゃない。よくそんなこと言えるねぇ・・・。これぞ「見下しすぎて見上げてる」というイケダハヤトの華麗な芸風の極み。雅であります。刮目してご覧頂きとう存じます。

あかんって、棚に上げたら。社会人としてやっちゃいけないと自戒しております。起こった不都合な事実をスルーして都合の良い理屈をつけてしまうと、そこから成長が止まり出せる成果は頭打ちになり誰にも指摘してもらえなくなる。だから「あー、このひとは理解できないんだろうなぁ」と思われちゃうんですよー。何言っても無駄ってのは死刑宣告と一緒ですよー。

イケダハヤト氏のような自分は童貞なのにあたかもその道であるかのような勘違いPMのせいで技術的負債を抱えてしまいプロジェクトが大きく間違った方向に進み、しっかりと炎上させておきながら逃げちゃったひとの仕事を引き継いで同僚と沈下した苦い思い出が再燃されてしまい、ハートがシクシクしています。

しかし現在最もハートがシクシクしているのは今回の騒動を収めることを打診されたAMNの徳力様なので、イケダハヤトちゃんはどんな理由があったにせよ自分で抱えきれないのは事実ですから徳力氏にご迷惑をおかけして申し訳ございませんと謝罪申し上げた上で、丸投げせず尽力して頂きたいと思うわけであります。

イケダハヤトちゃんの社会への復讐活動の今後のご精進とご発展を末筆ながらお祈りいたします。

イケハヤをスルーできなかったブラザー達の記事

イケダハヤト氏の文章がなぜ不快なのかをまじめに考えた

なんて無駄な時間を過ごしたんだろう。こんなテーマでブログを書くこと自体が。私の罪を許して欲しい。

ブログを更新するたびに表題と文章の内容が全くつながっておらず、強引に書籍等を引用して自分のやっていることは高尚ですよみなさんもどうですか僕はあなたとは違うんですという実にどーでもいい話をされて違和感を覚えつつ耐え抜いて最後まで読んだけれど、やっぱり何の役にも立たない読書感想文であることにやり場の無い怒りを覚えている全国100人ぐらいはいるんじゃないだろう皆様、いかがお過ごしでしょうか？

やまもといちろうさんがイケダハヤトをどう解釈すべきかエントリを色々書いておられるので、恐らく開催されるデスマッチイベントに微力ながら華を添えるべく一筆くれておきたい。

イケダハヤトちゃんのブログは全体的にものすごい拡大解釈が強い。わかってやっているのか全く自覚がないのか判断が難しいですが、極端に言えば単純バカのフルコースになっている。もちろん何に言及しようと彼の自由ですけれど、なぜか物言いが自分がさもその道であるかのような上から目線なのが何とも言えない。ネイティブに自己を拡大できる中二病的イノセントさを感じずにはいられない。それが彼の商品価値と言えば、そうなんだろうなぁ。

例えばこちらのフリーランスのメリットは「採算度外視」で動けること - ihayato.書店 | ihayato.書店について、フリーランスになると採算度外視の仕事で自己投資できるからいいって言ってます。一般的なフリーランスのメリットじゃないやろこれ。自分がプロブロガーとして働いて感じているメリットをつらつら述べているだけなのに、最後にビバ！フリーランス！ってどういう思考回路だとこうなるのかやまもといちろうさんに是非イベントで突っ込んでもらいたい。上記の記事では「採算度外視＝お金になりにくい」という定義になっているようで、まともなフリーランサーは頭が痛くなります。自己投資ならフリーランスじゃなくても出来ますし、会社員が退勤後にイベントを開くことも可能です。もっと言えば、給料を頂ける会社員のほうが採算度外視で動けるだろっていう考えも出来ます。採算度外視で事業をやってる会社なんか無いですよ。投資に採算は関係ないことも多いけど。すごいなぁ。無駄に言葉の器が大きい。どう突っ込んでいいか困難だ。なんて言えばいい！！！ちくしょーめ！！

よっぽど会社勤め時代に鬱積した怨念があるんだろうなぁと思うので脱社畜ブログさんに持ち込みでネタ提供してあげて「採算度外視の仕事」をすることで社畜のみなさんを開眼させてみてはいかがでしょうか？是非とも上記のような具体例でフリーランスのメリットをご教示頂けるとメリットではないことが確信できて望外の喜びであります。

会社として仕事を請けて責任抱えて回してる方が、会社勤め時代にたいした成果もあげられずブログで本を薦めるだけで何の責任も負ってないイケダハヤトちゃんにまじめに突っ込んでも暖簾に腕押しになるんじゃないかなー。なんで好んで責任おわなあかんねんになるだろうし。イケダハヤトちゃんの文章はワイドショーとしては面白いんだけど、ドキュメンタリーとして語るべき内容に素人童貞が手を出すから現場で頑張ってる人にすごく反感を買っています。もちろんブログの記事を読んで何かを行動して思わぬ結果が出たことはイケダハヤトちゃんの責任じゃないけれど、トイレでう●こして流さないまま出て行きやがってみたいな怒りがあるようです。なんにせよ、フリーランスの記事については頭に来て感涙したという報告を受けております。

余談ですがこのエントリを書くためにイケダハヤトでぐぐったんですが、超絶イケダハヤト推しの記事がありました。イケダハヤト(@IHayato) - 女。MGの日記。で絶賛してたこの方はお元気なんでしょうか。第八大陸沈没してないですかね。

以上　イケダハヤト氏への応援メッセージでした。著書のリンクを張っておきますね。

年収150万円で僕らは自由に生きていく (星海社新書)

年収150万円で僕らは自由に生きていく (星海社新書)

追記(2013/01/28 12:11)

イケダハヤト氏ご本人からコメントを頂戴してしまい大変恐縮です。

社会への復讐が一部含まれているとのコメントを頂きました。ブログを書くのが社会への復讐の一環であるその独創的で前衛的な思想に感嘆致しました。レジスタンスを結成して革命でも起こすつもりでプロブロガーを演じておられるのか、と。断じて、自分が周りから評価されずに冷遇されたと勘違いしていることに対する逆恨みがモチベーションになっているなんてそんな低俗な話じゃない。チラ裏乙とかで片付けてはいけませんよみなさん。おもろないから。師の面の皮は100億シーベルトの放射線を浴びせても崩壊しない気がします。お見それしました。

「朕 is God！朕 is God！朕 is God！朕はネ申なり！朕はネ申なり！朕はネ申なり！」

優れた仕様を決定するために必要なこと

システム開発

たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。

ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!

工程の分断はあり得ません

ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。

僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。

仕様を設計するチャンスって超少ないんじゃない？

倉貫さんの言葉を借りますと「ソフトウエアの設計＝仕様の設計+コードの設計」になりますが、現実問題としてこの２つを同時にできるSI案件って少ないのではという気がします。プライム取れないとこういうチャンスに巡り会えないから。欲しいソフトウエアの仕様を決めるオーナーさんとソフトウェアの開発を行うプログラマが直接やれば話は早いけど、それができる開発プロセスが整備された会社ってどんだけあるのか僕にはわからないけど、絶対少ないと思う。

ソフトのオーナーとプログラマが直でやるとソフトウェアの密度はめっちゃ濃くなるし仕事も面白い。これは疑いようが無い。今後は内製部隊のスピンアウトで新しいサービスを作ってそれをビジネスにするSIがメインになって社内企業でものれん分けでもなんでもいいから会社化して業界を牽引して欲しいなーってのが僕の長期的な業界展望。市場規模は小さくなるだろうけど。

あ、あと内製で大切なことは、プロダクトオーナーの言うことは正しいから彼らが納得いくまで議論を積み重ねて「やる前提」で舵を取ること。変化は受け入れるべきなんだけど、水は低きに流れちゃうのよね・・・。

仕様の決定とはどういうことかを再考する

僕はひとりで会社で内製してるけど、振り返ってみてオーナーである社長から「こーゆーのが欲しい」って言われて鵜呑みで作ったものは例外無く全部ゴミだった。あんたの言う通り作ったのにって思ったけど、言ってることと求めていることは全く違う。言われたことを鵜呑みにしても、良い仕様はまず生まれない。

補足すると、社長は誰よりも業務が見えているが故に、自分にしか分からないようなショートカット的な機能を仕様として提示してきた。「この業務の次はこうなるってことが当然わかっているだろ」という暗黙の了解が強すぎた。で、自分にしかわからないものは誰も使わなくなる。その機能を元に誰も仕事をしないので、欲した本人すら使わない。それがゴミになった原因でした。なんて日だ！！！！！

「ユーザーが言っていること」➡「なんでそんなことを言っているのか」➡「何に困っているのか」➡「それをソフトウェアで解決するためには何が必要なのか」➡「必要なものを揃えるにはどんな方法/技術/機能が必要なのか」➡「最もROIに合う解決策は何か」という所までプログラマが全部用意した上でオーナーと議論をしないと、使い手と作り手のあいだで仕様の妥当性を判断することは難しい。ソフトウェアのプロが素人のオーナーにファシリテートしないと。プロが素人の先に行かないでどーすんの？

優れた仕様が決定できないのは、業務アプリだとシステム化したい業務プロセスを誰も一気通貫で見ている人がいないから「何が業務上の問題なのかを認識していない」のが主因なことが多いと感じる。自分の仕事をIPOに整理して説明できる方って多くはいない。社長に聞いてもわからん、営業マンに聞いてもこうなったらいいなは出てくるけれど、具体的な手順までは落ちてこない。何が欲しいんですかって言っても問題意識が無いんだから、ユーザーに聞いても仕様を決めることなんか出来ない。取っ掛かりとして「こんな苦労しなくても良いんですよ」って所から僕は話をすることが多い。社内ですらこれだ。もっと優れたやり方があることを知らないのは当たり前なんだから、そこはプロが提案していかないと。

コードが書けて業務が設計できるってことは、その会社のインフラを握っているのと同じ。これってとんでもない存在感だと思うんですけど、あんま同意されない。ソフトウェアを導入して得ることが出来る効用が自社にとって何の役に立つのかを、会社の事業を運営する視点から体系立てて整理できるプログラマになれば色んな所で居場所が作れるはずなのだが・・・。

何にせよ、プログラマは優れた仕様を決める訓練を積むべきなのは間違いない。優れた仕様を決める一番手っ取り早い方法は、自分がコード書いてそれで他人の仕事を回してあげること。Excelマクロでも何でも良い。作り手は使ってる人がシステムから得られた情報を元に何を判断して次のアクションを決定しているのかを知る機会が不足しがち。それを知ることが出来ないと、そのソフトウエアが抱えている欠陥をプログラマが欠陥だと認識できない。そこで止まると優れた仕様が何だったのかを考える機会を失う。もったいないなぁ、と。

時間が無いから出来ないけど、いつか「Excelで業務を回している会社を救う、イケてるソフトウェア設計者と共通言語を持てるための本」が書けたら良いなって思う。

たぶんそこから、色んな価値が生まれてくるはずだから。

【書評】Webサービスのつくり方〜新しいを生み出すための33のエッセイ〜

著者のゆーすけべーさんより、献本御礼。

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

一言でいうと、読んだ後に「あー俺も何かWebサービスを作ってみたいなー」っていうモチベーションを与えてくれる本です。

本書はエッセイの形をとっているので、あえて薄く広く窓口を広げることによっていろんなヒントを提供するという狙いがあるのかなぁと思いました。プログラミングの本じゃないので、そーゆーのは専門書をあたるべきかと。それよりも、本書では何のためにWebサービスなのか、という点に焦点を当てています。

読者ターゲットは基本的に「Webサービスを作りたいけど何をやれば良いのかわからない方」向けなんでしょうけど、おっぱい画像をいかにして効率よく収集するかというプログラミングを嗜む男子なら刮目して読むべき一節があるので、結局みんな読んだほうがいいということになりますね。間違いないですね。

個人的には第３章の「設計」が一番参考になりました。アイデアをどうやって形にするんだろうっていう時に、ゆーすけさんはユースケースを活用されているんだなぁと。ユースケースからシナリオまで落とし込んで、DBへと続く、と。あと、本書はかなりnginx推しだったので、この本を読んだことがきっかけでnginxを勉強するようになりました。nginxいいっすね。apache全く使わなくなりました。

ハイパフォーマンスHTTPサーバ Nginx入門

ハイパフォーマンスHTTPサーバ Nginx入門

プログラミング言語は何から始めたいいのか問題については、僕はjavascript推しです。何でもできるんだもん、最近のjavascript.言語仕様を覚えながら画面を作ってその動きを楽しんでからの、httpやdatabase等への理解を深めてWebアプリへと続く道がよろしいのではないでしょうか。まずはUIから入る。画面作りは結構大変。本書にはチュートリアルとして一からWebサービスを作る章もあるので、その辺の流れを追いながら週末にお勉強、ってのもアリ。

P.S

2013年のシーズンこそは、横浜スタジアムでベイスターズ戦を見に行きましょう！！！

コードで周りを動かせるエンジニアになろう

CAREER HACKさんというWEBサイトに掲載されている、エンジニアのキャリア論レポートが盛り上がっていると聞いてやってきました。

で、盛り上がっている論点は｢技術以外のことも出来るように vs ゼネラリストなんて目指すな｣と、｢汚いコードでも稼いだもん勝ちってそりゃあんた｣っていう2点なので、その辺書いてみたいと思います。

ゼネラリストなのかスペシャリストなのか

自分で論点を立てておいて大変恐縮なんですが、結論から言えば、スペシャリティのないヤツがどうやってゼネラリストになれるんだっていうのが僕の見解です。

まずは、自分の得意分野を磨くことが全てだと思います。プロジェクトの成功という目的を達成する為に何をもって自分が貢献できるのかってことが一番大切ですし、その貢献できるポイントなんてそうそう多くない。ライバルはたくさんいるんだから。まずは出る杭にならないと始まらないと思います。そこで芽を出す。芽を出していく中で、自分以外の仕事の意味というのが、自分の仕事を通じてわかるようになる。自分以外の仕事の意味を自分の仕事を通じて理解しているから、他人のやっていることの凄さもわかってくるし、自分の引き出しも増えていく。そうやってゼネラリストってのは生まれてくるんじゃないかと思います。なので、まずは牙を磨けっていう意見には大賛成。自分が何を持ってチーム・プロジェクト・社外に知られてたいのかっていう視点を時々でいいから振り返りたいよね。

また、自分の作ったアウトプットでビジネスをしたいと思っているのなら、重要なことが１つあります。前にもブログに書いたのですが能力が高くても仕事を請けることは出来ない - GoTheDistanceっていうこと。自分の能力が高くても、能力を買ってくれるのはその能力が分かってくれる人だけ。つまり、同業だけ。同業だけを対象にビジネスをやっても先がないわけですから、問題は自分の能力を注ぎ込んだアウトプットを自分を知らない人に売ることができるかどうかになります。スペシャリティがあるだけでは足りなくなる。なので、けんすうがその点を強く補完して話してくれている。アウトプットの技術的難易度・高度さっていうのは、さしたる意味を持ちません。それが問題になるのは、アウトプットが受け入れられてから。マーク・ザッカーバークが｢Done is better than perfect｣って言ってるじゃない。そーゆーことなんじゃないかなぁ。

汚いコードでも動作させることが勝ちなのか

スタートアップに焦点を絞れば、その通りです。PythonだRubyだなんてことはどーでもいい、目の前の道を開いたヤツが勝ち。なので、金山さんというチャラい社長さんに賛成です。

僕の事例で恐縮ですが、昨年の夏頃に利用していた徒歩圏内の倉庫が使えなくなり、色々あって10月末に某所に物流センターを構えることになりました。10月末には40ftのコンテナが数本入ってきます。1週間弱で本社と物流センターとの間で仕事が出来るシステムを作らなきゃ行けなくなり、確信犯的に非常にドブ臭いコードを書いて１週間で仕上げました。何がこれから求められるかわからないし、そこで仕事を回さないことにはこれからのことも決められないので、スピード重視で動くモノを用意しました。わかっているものだけを先ず作って何を改善するかを考える。Whatがブレるのが当たり前なら、スピード命でしょ。品質？そんなのWhatが変われば全部変わるから考えるだけ無駄。他人に納めるなら話は別。

その後、年明けから弊社の取り扱いアイテムが爆発的に増えてしまい｢倉庫だけじゃなく複数の仕入先から商品を引く」ことを行うようになりました。倉庫にあるモノを出せば良いってもんじゃなくなり、業務の複雑さは飛躍的に上がりました。元が元なんで大改造も出来ずひょうたんツギのようにパッチを当てて運用でカバーという呪文を唱えて逃げていたのですが、今年のGWちょい前にこのままでは崩壊することがわかりました。ここまで聞くと「ほらみたことか、汚いコードを書いたからだ」って思うかもしれません。でも、求められるモノが違えば綺麗でも動かないコードになり、会社から見ればゴミにしかなりません。

ということで、これらの課題を解決して新しいステージに登るためには、ヒョウタンツギのコードを捨てて設計からやり直して全く新しいものを作るしかなかったので、GW明けから着手を開始して7月中頃に原型が出来ました。求める動作がほぼ確定したので、それから1ヶ月かけて徹底的にリファクタして機能は一緒だけど内部は別人のものを作り、8月にリリース。様々な仕入先からなる顧客の注文を今のメンバーで確実にデリバーできるようになり、売上もあがりました。

なので、僕は常々思うのはコードの汚さが問題になるのはコードでまわりを動かしてからでしょってこと。お仕事でやってる以上、自分の仕事の成果を元に誰かが動くわけです。誰の得にもならないものを綺麗なコードで作っても会社は回らない。自分が満足するだけなら額縁に入れて飾ればいい。でも、それって仕事とは言わない。

自分の価値を決めるのは自分以外の方々なので、エンジニアならば自分のコードで周りを動かしてみんなでハッピーになろうぜって思います。

33歳になりました

風のように過ぎ行く　季節の中で求め続け
僕が描いた憧れに　負けたくはないから

燃えつきない想い抱いて
遠くへ　もっと　遠くまで

自分がココって決めたところまでは絶対行きたいので、今年も自重せずチャレンジするでー

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