GoTheDistance

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

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

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

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

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

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

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

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

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

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

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メールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。

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

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

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

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

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

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

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

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

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

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

追記

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

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

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

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

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

システム化の目的は、Excelの焼き直しであってはならない

これは興味深い問題提起。

エクセルでできることができない何百万のシステム・・

Excelで出来ることが出来ないシステムとかいうものに、なんで数百万も突っ込む必要があるのか」という話には、キチンと整理して説明できるようにしておきたいもの。

機能面ではExcelには勝てない

Excelが提供している豊富な機能群は、世界でも選りすぐりのソフトウエア開発チームが途方も無い期間と金額をかけて作り上げたものです。Excelで出来る機能と同等の機能を提供することは、納期も予算も上限がある業務システム開発プロジェクトにおいて、非常にハードルの高い機能要件でしょう。業者からすると「ウサイン・ボルトに100m走で勝利しろ、期間は2ヶ月で」って言われても的な・・・

でも、「Excelとかいう最強の業務ソフトと同じこと望むなよ、そんなもん無理」で突っぱねてしまうのも違う。Excelには無い価値ってどこにあるかをキチンと共有しておかないと、システムを入れる意味もなくなります。誰得。

システム化の目的は、Excelの焼き直しであってはならない

「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログと重なりますが。

Excelでやりたいことを新しいシステムに載せたいという要望は、非常に取り扱いの難しいご要望です。即死亡フラグになる可能性を秘めています。ご担当者様からすれば、明らかにExcelより使い勝手が悪くなるシステムと毎日向き合うことになるストレス・・・結構ありますよね。

でも、システムを導入する・導入を成功させる為には「システム化で達成したいことは、Excelの焼き直しであってはならない」ということを再考頂きたく思います。

システムを導入する目的は「ある担当者の業務効率を改善する」ことであってはなりません。それが目的なら数百万のコストをかける意味は無い。業務システムを導入するのであれば、「会社全体としての業務効率を向上させる」ことによって、会社がより優れたサービスを顧客に提供することが可能にならなければならない。

Excelで頑張ったけど限界だった話

Excel使った業務でよくあるのが、発注書の作成です。仕入先から商品データの一覧表Excelをもらって、違うシートに発注書がある。その品番のセルを入力するとVLOOKUP先にあるものをひっぱって入力補完みたいな。間違い防止と効率化のためによくこの種のExcelを見かけます。

これは弊社の例なんですけど、僕の作ったシステムを導入する前は営業マンが外出先で取ってきた注文を発注担当者の本社の人間にVLOOKUP機能付きExcelでメールしていました。こんな感じの内容が続くと思って下さい。

品番 品名 数量 単価
AAA-222 イケてるデザインのマグ 5 @750
BD-21 カップアンドソーサー 6 @1200
CC9876 スマホケース 1 @600

で・・・問題が2つあって・・・。

  • 営業マンは複数人いるので、発注書を仕入先に流す時にマージが必要
  • 仕入先の商品リストに変動があると、VLOOKUPで引っ張るデータも更新が必要。Excel再配布乙。

Excelは非常に優れた機能を有していますが、情報共有には絶望的に不向きであります。ある業務から次の業務へ情報の橋渡しを行う場合は特に不向きです。Excelマネージャみたいな人が出来ちゃって大変な会社さんも結構いるんじゃないかな。

Excelを捨ててレベルアップした話

というわけで、「Excelに埋もれてしまう機会損失及び不毛な属人化」や「貰ったオーダーを正確に納品できない」という大変困った問題が明らかになりました。これは無視できないという経営判断の元、以下のようなことが可能になるようにシステムを組みました。

  • 営業マンはシステムを起動して受注入力するだけ。外出先でもOK
    • VLOOKUPで担保してた入力補完・エラーチェック機能を踏襲。
    • 過去の入力履歴も参照できるので納品単価のミスも防止可能。
  • 商品情報はCSV/TSVで一括登録。マスタ訂正すればその内容は当然即時反映。
    • Excel再配布不要に。常に最新データを参照可能。誰もが。
  • システムが受注内容を集計して発注書を作るので、発注担当者はそれを印刷するだけ
    • 発注担当者の業務負荷激減。リードタイム短縮 & 営業サポートにつける余裕も

システムを導入したことで、会社としてレベルアップしている感が伝わりましたでしょうか?

システムを経由して各人の作業内容を簡潔なものにすることで、業務プロセスがスッキリとしたものになりました。良い意味で作業分担が出来まして、システムが情報の集計・共有を行うことで人的に行うことが困難な「業務の橋渡し」が可能になっています。これが、数百万かけるシステムを導入する効果の1つです。

システムを導入する前に

どんな会社にしたいのかをしっかり議論しましょうね!木を見て森を見ずにならないこと、森の全体像が共有できていることが、1番大切です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:gothedistance:20131125113454j:plain

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

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

主張を崩したいなら主張そのものに「いやそれはおかしい」と反論しても無駄。ちきりんさんの「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 組織体でなければ、また上流と下流の工程の分断が生まれてしまう。工程の分断は絶対ダメです。皺寄せが全部エンジニアにやってくる。

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

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

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

スペシャリストを脱しろ

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

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

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

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

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

こちらからは以上です。

34歳になりました

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

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

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

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

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

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

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


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

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

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

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

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

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

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

追記

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

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

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