GoTheDistance

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

国内ラボ開発という新たな受託開発のビジネスモデル

古い読者の方はご存知かと思いますが、僕は受託開発においてアジャイル開発をそのまま適用するのは否定的で、アジャイル請負は自爆テロと紙一重だとすら思っています。上手くやれる組織もあるんでしょうけど・・・。

アジャイルを受託開発で正しく推進するのなら、ビジネスモデルを大きく変える必要があると見ています。永和さんの価値創造契約や、倉貫さんの納品のない受託開発等、新しい受託開発のビジネスモデルが出て来ました。そんな中、こんな会社があるんだけど知ってますかと連絡がありました。(株)プラムザさんが掲げる「国内ラボ開発」です。

labo.plumsa.co.jp

受託開発専業の会社さんでアジャイル開発を独自の方法論で推し進められているようなので、2/20に開催されたセミナーに潜り込んでみました。

国内ラボ開発のビジネスモデル

契約は準委任契約で、最低契約期間3ヶ月。それ以降は月額課金となり契約解除が可能になる。初期費用も頂かない。ここまでは「よくある話」なんですけど、この進め方の絵にご注目下さい。

f:id:gothedistance:20170221222506p:plain

各々のロールに沿って、プロジェクトの進行と共にチーム構成やそのロールを担う人の稼働が変わっています。最初はPMとSEが多めで、開発が進んでくるとPGが多め、みたいな。稼働の見積もりが「日単位」で、チーム構成は月単位で柔軟に変えられる。過剰に人を割り当てるとお客様に不要なお金を払ってもらうことになるからギリギリまで合理化しよう、というポリシーでやっておられるそうです。最適なチームをその都度構成するのがベストだと考えられているのでしょう。

仕事の進め方も「最初からすべての要求を確定するのは辞めて、走りながらやりましょう」というスタイルです。要件定義をかっちりやっていったら、時間ばかりかかってしまう。最小契約期間の3ヶ月で何も動くものが出来ないのが、最も望ましくない。ゴールをシステムの完成におかずに利用し続ける限り手を入れて、システムを進化させていきましょうという考え方ですね。

青天井をどう捉えるか

この手のビジネスモデルを考えるには、費用をどう捉えるかが重要です。やる方は、システムに手を入れ続ける限りお金が入ります。お客様からすれば青天井になります。支払いに終りがありません。

そうはいっても、そのシステムが継続的に利用され事業運営に資するものであれば、常に最善の形は変わっていくはずです。また、業者が手を入れるか自分たちで管理するかだけの違いになるでしょうし、メンテナンスする人員は必要。お客様の立場で定期的にメンテナンスできる体制があることの意味がご納得頂けるかどうか、そこがポイントなのかな〜と感じました。

色んなモデルが出てきて欲しい!

一括請負以外の受託開発における色んなビジネスモデルについては引き続き勉強したいので、もしこんなことやってる会社があるよ!というお話があれば、僕のブログのお問い合わせフォーム等から頂ければ嬉しいでーす!

色んなことをソコソコできる人が、生きる道

僕は器用貧乏です。色んなことがそこそこできるという、一般的なキャリア論では最もダメな部類に入ると思います。餅は餅屋。ドラッカー先生も言うてはる。あなたは何によって知られたいのか、それが重要だと。

エンジニアとしてキャリアをスタートさせて、恐ろしいことに10年以上の月日が経ちました。残念ながら、エンジニアとしては絶対に大成しないという確信があります。コードを書くのは好きです!でも、要素技術を突き詰めようという気持ちがすごく弱いのです。1つに絞り込むってことが、生理的に出来ない...全く違う分野に対して興味を持ったら、もう止められない。

そんな人って、実は技術職のエンジニアでも結構いるんじゃないかなっと感じたので、ブログ書きました。1つの分野の専門性が築けなくて悩んでいるのなら、「そーゆーの向いてないわ、俺」で諦めちゃったらいかがでしょう? 僕のように。

僕より優れたエンジニア、僕より優れた営業マン、僕より優れた書き手。たくさんいます。

でも、僕のようにエンジニアをそこそこやれて、経営者との折衝/IT戦略立案/要件定義をそこそこやれて、(やりたくないけど)プロジェクト管理もそこそこやれて、そこそこ読ませる文章を書ける人って、ほとんどいないんです。おかげさまで、思いもしないオファーを色々と頂くことができました。

ソコソコも1個じゃダメですけど、毛利家の3本の矢のごとく束ねることが出来たら、とても価値があります。その価値を他業種の方が認めてくれます。

高い専門性が理解できるのは、基本的に同業者だけです。同じことをやってるから、その人の持ってる技術の意味がわかります。同業者に自分を売り込むのなら、専門性を突き詰めるのが良いでしょう。

器用貧乏で、1つに絞るのが生理的に嫌。だけど、何でも面白がってやれる。同業ではない方に自分を買ってもらいたい。そういう指向性をお持ちなら、そこそこやれるスキルをいくつも身につけて下さい。時間はかかるけど。そういう方が一緒になって仕事をデザインしてくれると、本当に頼りになる。僕もそうありたい。

エンジニアであることと、エンジニアとして生きることはイコールでなくても良いはずです。専門分野をソコソコのレベルで留めてしまって違う道をゼロから始められるのは、一種の才能だと思います。道草食っても、その道の味がわかれば楽しいからいいじゃんで、振り向かないで生きていける。独立したら楽しくなるタイプな気がします。安易に勧められないですが、視野に入れてほしいです。

SIの未来は、技術力を武器にSIを行うことで見えてくる

小野さんが、SIの未来についてブログを書かれていました。今後の取組にも期待しております!

小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来

SIの未来を探すという永遠の課題

SIという仕事は必ず必要であり、そこにいる人たちがハッピーになる未来を語りたいけれど、何が未来像なのか明確になっていない。そんな印象を持っていますし、僕が社会人デビューした2003年ぐらいから変わってない気がします。

未来のあるなしを考えるなら、これは未来がないよねという所から始めるのがわかりやすいと思います。出発点を決めるのに役立つので。というわけで、僕から提起します。上流と下流(という言い方がお嫌いの人が多いけど)で工程の分断をするモデルには、明るい未来がない。これだけは確かです。消耗戦の先に新しい未来はないもの。

技術力を武器にSIをやれることが、SIの未来を考える第一歩

未来のない状態を裏返せば、多少なりとも未来に近づきます。なので、SIの未来を考えるということは「工程分断型のビジネスモデルから脱却して、技術力を武器にSIをやる為に必要なこと」を考えるのに等しい。そう考えました。

工程分断型から逸脱するのに必要なことは実は1コしかなくて、顧客と直接契約して価値を届けることだけ。何を届けるかは僕が知りたいというのが本音だけど、形態(やり方)としてはココしかないです。下に入って抜け出せなくなってしまえば、そこから新しい未来を描くことは極めて困難です。

SIが本来持っている価値は、「顧客が行っている事業で築き上げる資産をいかにITで活用するかを考えて、新しいステージに到達すること」だと僕は思います。その価値をどんな提供手段を持って行えば良いのかという点において、僕が最も可能性を感じているのが「作らないSI」です。

だって、労働集約的なやり方をやめたいんだよね?

様々な企業のニーズに応える必要があるSIビジネスにおいて最大のリスクは、プログラムを手組みすることです。案件を回す立場(Not 下請けの進捗管理)になれば、その意味は嫌という程わかります。純粋にソフトウエアを作るということと、顧客にとって必要なシステムを作るということは、どうしても文脈が異なります。しょうがないの、もうそれは。埋まらないって。それに、顧客のIT予算もクラウドが普及すればするほど下がるはずなので、手組みで工数を裂いて人を集めて値段を算出しても「それだと無理」っていう話になりやすいのではないかと思います。

インフラの世界では、設計書を用意してOSやコンテナを自動でセットアップするのが当たり前になっています。ビジネスアプリケーションもそうなれば良い。開発工程が自動化で圧縮されたら、短納期になります。自動化すれば、自動化するプログラム以外の不具合はなくなるので、品質の担保も容易になります。人をかき集める必要もなくなります。ここに上げた内容は極論です。だけど、「ド正論」です。僕はこういう身もふたもない話が大好きです。大抵の場合、正しいので。

・・・で、実際にそこを目指して、自前でそのような仕組みを作って案件をこなしている会社があるわけです。そのような会社さんに出会った以上、そこに未来がなければ僕も困る。なので、主に販促面でサポートさせて頂いております。詳しいお話を聞きたい方は個別に連絡くーださい。

今後どういう取り組みがSI業界でなされるのかはわかりませんし、僕が全然見えていない可能性も当然あるでしょう。僕の推しメンは可能性の一つに過ぎません。再掲しますが、「工程分断型のビジネスモデルから脱却して、技術力を武器にSIをやる為に必要なこと」という前提でSIの未来を考える議論が発展することを願います。

やっぱりこの仕事が好きなもんですから。

【書評】その「エンジニア採用」が不幸を生む

毎度おなじみ技術評論社の傅さんからご恵投頂きました。

結論から先に言いますと、僕が今までご恵投頂いたエンジニアのキャリア本で「ベスト」の一冊です。

採用という切り口でエンジニアのキャリアを見つめ直す

本書は「採用」に絞って、エンジニアが企業組織で良いキャリアを築くためには何が必要なのかを問題提起しています。「エンジニアはもっと採用されるように頑張れ」というクソみたいな話じゃなく、採用すると決めた経営陣、それに従う人事担当者、採用されるエンジニア。この3者の立場を俯瞰しつつ採用コンサルティングとして携わってきた筆者が、重厚な論調で痛快に問題点を指摘しています。

エンジニアで生きていくのと、エンジニアを活かす企業組織を作ることは、すごく難しいことはでないか。それが本書の隠れたメッセージのように感じます。

人材紹介会社のビジネスモデルがエンジニアを不幸にする

自社で集めるのが難しいから人材紹介会社を活用するわけですが、向こうも商売です。マッチングゼロだったらお前何やってんのって話になるし、転職しても3ヶ月未満で退職した場合はノーギャラになるケースもあるそうです。技術要素や担当工程が細分化されているエンジニアの事情を鑑みれば、まずマッチするケースが少ない。でこかアンマッチする案件を紹介せざるを得なくなる。その結果、雇用して退職された場合はアンマッチになった理由を検証するのが困難になって、また同じことが繰り返される… そんなことが書いてあります。なかなか、難しい話です。

良いエンジニアを採用できる採用担当者を

不幸なすれ違いを防ぐ為にどうしたらいいか。ド正論は、その企業のエンジニア採用力を上げることです。良いご縁があっても、採用の質が悪ければ意味がない。

エンジニア採用の難しい点は、エンジニアの評価はエンジニアにしか出来ないことにあるのではないでしょうか。数値化出来る要素があまりない上に、経歴ではなく姿勢が問われることが多い。C#の職務経験はないけどAndroidアプリを作れる人だしUnityも慣れたらいけるよね、みたいな判断は素人にはできない。職務経験の向こう側がね、なかなかね。

また、エンジニアはキャリアチェンジをするのが滅茶苦茶難しい。陸に上がった魚は海には戻れない的な。エンジニアを人事にして2〜3年採用業務をやったら、もう開発の現場には戻れない気がします。それを望むエンジニアの方、どれだけいます? 一般的な人事部門と全く違うあり方が望ましい気がしますし、エンジニアに限らず様々な知的労働者に応用が効きそうです。

ある企業では、エンジニアを採用する時にそのチームのエンジニア全員が採用面接に関わると聴きました。満場一致じゃないとだめらしいです。一歩間違えれば圧迫面接でしょうけど、採用はお互いの真剣勝負と考えている現れですね。

デブサミで「採用」をテーマにしたら面白いかも

次回のデブサミ、どこかのトラックで採用をテーマにしたら面白い気がします。採用で苦労していない組織はないと思うので。取る側がこんなエンジニアがほしいじゃなくて、ウチはこんな人事制度や評価制度でエンジニア像を考えています、という立ち位置で。すでにやっていたらごめんなさい。

技術や工夫を駆使してサービス作った/現場を変えたという話にもう1枚加えるとしたら、キャリアだと思う。エンジニアの祭典で優れた見本市の場として十二分に機能し、エンジニアやってる意味を見つめ直す場にもなっている。同時に、どんな技術を身に着けたら良いかでは語れることに限りがある。社内制度に踏み込んでしまうので「どこまで」という線引きが難しいですが、人事制度まで切り込んで採用に議論する場があれば業界としてプラスに働くように思います。

不幸なすれ違いをなくすために

エンジニア採用が活発になったのは恐らくここ10年のことですから、ITエンジニアのキャリアや採用のあり方にについては黎明期なのかもしれません。試行錯誤が続くと思いますが、現時点でITエンジニアの採用についてまとまって書いてある書籍は本書ぐらいでしょう。自分がどう評価されたいのか、自社の評価軸はどこにおくのか。採用する側は何を気をつけたらいいのか。

本書をあたれば、きっと新しい発見があることでしょう。

【書評】はじめよう!プロセス設計

毎度おなじみ技術評論社の細谷氏よりご恵投頂きました。おおきに。

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

なんでプロセス設計なのか

前作ではじめよう! 要件定義 ~ビギナーからベテランまでという本を書かれた著書の羽生さんが「そもそも材料がないから要件定義なるものができない」という現場が非常に多く、要件定義のその前に考えなくてはならない「プロセス設計」についての本が必要だという考えに至ったと書いてあります。

材料ってそりゃ所属してる会社のビジネスであり自分の仕事じゃないかと思うのですけど、自分の会社が何を商売にしていて、自分達の仕事の意味や課題点を整理して、"こういう仕事に変えていけばいいんじゃない”と落とし込む為の考え方が全く浸透していない。 本書からはそのような問題意識をビンビンに感じました。

ごった煮感が強い

あとがきにも書いてあったのでツッコミますと、本書はごった煮感が強いです。みなさんがプロセス設計に近しい局面にぶち当たった時に役立つ内容が散りばめてある感じで、オムニバスのような仕上がりになっています。プロセス設計のハウツーではなくヒントがたくさんあるので何か1つでも響いてくれたら、という格好。

僕がプロセスを設計する時に考えていること

自分がプロセスを設計する時に考えていることはこの4つです。

  • その仕事はどこから来るのか
  • 作業を終わらせるために何を判断しているのか
  • 終わったら次はどこに行くのか
  • 例外(個別対応)はどれぐらいあるのか

この4つを整理すれば概ね問題なく現状を把握できると思っています。あと帳票のチェックも忘れずに。必要だから存在してるので。

で、本書にもありますがToBeを考えるときは逆算で考えます。本書ではバックキャスティングという言葉を使っています。ゴールは追いかけていくもんじゃなく、近づいてくるもの。逆算しないと近づいては来ないです。

企業のITシステムをデザインする難しさ

企業のITシステムを作るのは非常に難しい仕事のはずです。こういう仕事に変えていくとデザインして、それを実現するITをデザインして、実装して提供しなければならない。その工程はひとまとめにして分断させないことが大切です。仕事をデザインしている仕事、かっこいいじゃん。仕事を変えることの大半は仕事の中で流れている情報の流れを変えること。企業のITを作る人はそれを意識しないとね。昔はビジネスアーキテクトとか言ってたよね。素人童貞臭ハンパなくて草不可避です。

マーケットとしては企業のITをデザインするSI領域のほうがWebサービス系の領域よりも全然大きいのだから、プロセスを設計して自社の事業運営にほんとうに必要なものは何かを見定めることがいかに大切なのかってことを、本書を読みながら思いを馳せてほしいなぁと企業のITシステムばっかりやってきた僕は思います。

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

【書評】エンジニアがフリーランスで年収1000万円になるための稼ぎ方

技術評論社傅さんより恵投頂きました。おおきに。

フリーランスで一番大変なのは営業

本書は社員の方がフリーランスを検討し始めたときに最初に読む本、という位置づけです。細かい話は置いといて、フリーランスと正社員はこういう点が違うという抑えから入り、案件のとり方や自分の売り込み方、地雷案件の見抜き方などの実務に入り、最後にフリーランスで長くやっていくためのポイントを紹介しています。

本書に書かれている内容でフリーランスで最もハードだと感じたのが、営業です。僕もまだまだですが、仕事を取ってくるというのは思いの外難しいものです。ほんとにもう。筆者の方は「自分で営業する」「クラウドソーシングを使う」「エージェントに頼る」の3つがあるとおっしゃっており、最終的にエージェント活用に落ち着かれたようです。

自分で営業しても自分のことを知らない人間はまずスルーだし、万が一引っかかっても仕事を出してくれるかは別問題。間に誰も入らないというメリットは、裏返せば請求から回収まで全部自己責任。クラウドソーシングは地雷も競合も多いので骨折り損のくたびれ儲けになりやすく、どうせ手数料等を支払うのならそのお金でキチッとした仕事先と人脈を構築するためにエージェントを活用するのが最も安定していると書かれておりました。

本書の最高のパワーワードは「自分でWebサービス作って儲けようとして1年間無収入で作ったけどゴミしか作れずウン百万溶かした」です。自社サービス開発をやるのは全然ありだと思いますが、順風満帆だとしても開発が終わってリリースして結果が出るまで2年ぐらいかかりますので、その期間どうやって生きていくのかを考えるのが先になると思われます。

安定とは動かないことではなく、動じないことです。フリーランスでも正社員という形態はメリット/デメリットがあるだけで、善し悪しはありません。どちらの立場を選んでもご自分の立ち位置を振り返って動じないのなら、素晴らしいことです。

エージェントでもクラウドソーシングでも、案件の目利きと自分の技術の伝え方は絶対に必要になります。フリーランスは自分で仕事を取ることからスタート。案件の取り方、見極め、そして継続。本書のコアはそこにあります。ご興味がある方はぜひお手にとってご覧ください。

余談

フリーランスから更に進むと事業運営を行う組織へと変貌を遂げます。僕自身もそうですが、僕の周りでは「自分の食い扶持は自分でできるけど、目指す未来のために(できればお互いの食い扶持を共に稼ぎつつ)事業運営を行える人との出会い」にぶつかっている方が多いです。グルグル回ると自分の今の仕事すらネガティブになってしまうので良くない。ここを超えると個人事業から会社になれるのかなぁ。

medium.com

プログラミングの学習に最適なWebサービス「CODE写経」

僕が作ったものではありませんが、面白いコンセプトだなぁと思ったので紹介します。(株) レベルエンターの代表、山本さんがおひとりで開発されたサービスです。その名も「CODE写経」です。画像をクリックするとサービスのページにジャンプします。

CODE写経

写経はハードルが高い

プログラムの文法に不慣れな初学者にとって、写経は少しハードルが高い。カッコを付け忘れるとか半角を全角で書くとか変数名をtypoするとか、コピペではない手段でプログラムを書こうとすると色んな罠があります。不注意と言えばそれまでですが、何が不注意だったのかもわからないのは可哀想です。

とにかく動くプログラムを書かないと、学習を先に進めることは出来ない・・・ 

山本さんはプログラミングを教えるお仕事をされているので、間違えずに写経ができるサービスがあればと思ってこちらのサービスを開発されたそうです。

操作動画

youtu.be

Chromeでしか動作確認とっていないので、Chromeでやってみてください。

プログラミングの学習効果の向上を目指す

プログラミングを教えている教育機関や企業を対象に、オリジナルの教材を提供しているとのことです。教材とコードをご用意頂き、レベルエンター社がCODE写経にパブリッシュ。そちらを使ってワークショップや研修などを行えば、より高い学習効果が期待できるというわけです。ログイン不要のでもアカウントもあるので、とりあえず触ってみてはいかがでしょうか?

今後の展開に期待しています。

起業に向いている人の特徴を1つだけあげるとすれば「ストイック」な人

cild.hatenablog.com

この記事に賛同してしまうような人が最も起業に向いていないなぁ...。イケハヤの劣化コピーかと思うぐらい適当なことしか書いていない。

職場の空気すら読めないのにどうやって商談の空気を掴んでいくんだって思うけど、大丈夫かな。自分でやった方が早いと思っちゃう人は、作業と仕事の区別がついてないので起業に向いていない。仕事が目の前にあればあるだけやってしまう人は、自分がボトルネックで取引先に迷惑をかけるし、無駄に消耗戦を戦って安く買い叩かれるので、起業に向いていない。休日にゴロゴロすることも出来ないぐらい逼迫してるなら、やってても楽しくないのでキチッと休めるサラリーマンの方が良い。まだまだ書けるけど、バカらしいや。

こんな調子で書いてしまうとアレなので、僕がこれだけは間違いないなと思う「起業に向いている人の特徴」を1つあげます。ストイックな人です。複合的な言葉になってしまうのですが、要はこんな特徴がある人です。

1つ目は、「自分で決めた目標や基準を、自分の勝手な判断で取り下げない」ことです。今日はこの作業までを終わらせると決めたら、それを明日に持ち込まないこと。割り込みが入ろうが関係ない。サービス残業も関係ない。自分がそこまでやると決めたら、完璧でもなくてもいいからまず終わらせる。区切りをつけて前に進む。

僕もそうですけど零細企業の社長は雑用も多くなるので、仕掛りの作業って増える一方。起業したら割り込みもサービス残業もない。代わりはいない。終わらせないと積み重ねることも出来ない。ここで脱落する人、すごく多いと思います。請けたけど納品バックレなんてよくある話なので。

2つ目は、「これが今のベストなのかと、常に問う姿勢があること」です。そこには2つの側面があって、ひとつは自分たちの仕事のやり方はこれでいいのかという点と、もう一つはこの顧客に納品する成果物はこれがベストなのかという点です。仕事のやり方に課題がないなんてことはあり得ないし、(色々すっとばすけど)これが出来たらベストっていうのが見定められないと迷走します。

もう1つの顧客の観点で言えば「お客さんがこういったから」という鵜呑みにしているのがマズいです。お客さんが欲しいからこういうのを提案 or 納品しますでは、バカの一つ覚えにしかならない。要望と要件は違います。僕のようなIT系は不定形な成果物を商品にしているので、特にそれを感じます。ベストを考えていくと、より鮮明に成果物の内容が見えてくる。やる意味が無いから辞めようと良い意味で撤退することも出来ます。仕事は選ぶものです。

3つ目は「一人の時間を持て余さないでいられること」です。僕も修行中ですが、起業したらどれだけ自分を見直すことが出来るかがすごく大切だと感じています。自分の判断や価値観によって、事業を行う方向性が大きく左右されるからです。なので、ひとりの時間をじっくりと考え事に当てて考え続ける必要があります。とても憂鬱な行いですけれど。

社長になっちゃたら、上手くいかないことは自分に原因を求めるしか無くなります。あいつが悪いとか取引先がクソとか時代が悪いとか言っても、どうしようもない。事業が立ち上がらない/回らない理由を外に求めても、各々の立場があるので自分には合わせてくれません。自分たちが変わるしかない。だから会社は倒産するわけですので。前職では、毎月のように管財人の弁護士からFAXが会社に来ていたなぁ。

魚は頭から腐ります。頭から腐らないように、瞑想と運動と野菜を摂取して心身をヘルシーに保つ必要があると著名な先生は口を酸っぱくして警鐘を鳴らしております。

おあとでよろしいようで。

【書評】虹を待つ彼女 〜AIが織り成す心の螺旋階段を駆け下りていくミステリー〜

友人が横溝正史ミステリ大賞を受賞されまして、その処女作を読了したので感想を書きます。ネタバレしないから大丈夫です。

虹を待つ彼女

虹を待つ彼女

twitter.com

あらすじ

舞台は渋谷のスクランブル交差点から始まります。カルト的人気を博した女性ゲームクリエイター水科晴は重度の病に侵されていました。その彼女が選んだ最期は、自身が作り上げたオンラインゲームの標的となること。ゲームに登場したゾンビは、水科晴自身。ゲーマーの操作するドローンは本当の銃を詰んだ渋谷のスクランブル交差点の上を飛んでいるドローン。そして、彼女は銃撃されて死を遂げます。

ソフトウエアのプログラマーである工藤は、「フリクト」という人工知能のサービスを開発者。人工知能という制御できないプログラムをプログラムすることに技術者として面白さを感じていたが、フリクト自身は完成されており(色んな理由で)ユーザーが少しづつ離れていった。そんな時、人工知能の別の可能性として「死者を人工知能として蘇らせる」というプロジェクトの発足が決定する。その試作品の対象に選ばれたのは、水科晴。

工藤は水科晴の人工知能を完成させるべく、水科晴の調査を開始する。彼女が衝撃的な死を選んだ理由、断片的なエピソード、開発したゲーム、彼女を知る人物。それらを追っていく中で晴への渇望を抑えきれなくなる工藤の前に「晴の調査を辞めないと殺す」という脅迫者が現れ…

こんな感じのあらすじです。

人工知能の社会性

このミステリーを読む中で考えたのは「人工知能の持つ可能性と社会性」でした。死者を人工知能で蘇らせるというアイデアは近未来的にあり得ますし、短期的には恋愛シミュレーションも作ることが出来る。自律する学習回路があるコンピュータの持つ可能性の大きさと、その可能性が諸刃の剣にならないための社会性。社会のインフラとなり得るために守らなくてはならない制約と言うか秩序というか、そういうものをどう設計したら良いのか。そういったことを頭に巡らせながら読むとより一層楽しめます。

工藤と晴

この二人の思いが交錯する所が本書の面白い所なので多くは語れませんが、うまいなあと思ったのは展開はミステリアスなんですよ。進み方はとてもミステリアス。でも、エポックとなっている出来事は、じわっと感情が揺さぶられる。このバランス感覚が、次へ次へという期待を胸に読み進める力となっているように思います。僕は第一部だけで読んで、ちょっと置いてから一気読みしましたが、ラストの展開は完全に外しました!

虹を待つ彼女

カバーにも書いてあるんですが、この小説には「雨」という人物が登場します。水科”晴”と”雨”です。そして、タイトルには「虹」を待っている人物がいます。晴と雨と虹。僕が一番ぐっときたのは、この3者の関係性でした。皆さんも、晴と雨、そしてそれらが織り成す虹という自然現象の意味を頭に巡らせながら、ラストまで読み進めて欲しいです。完成度の高さに舌を巻くと思いますから。

ミステリー小説なんて西村京太郎しか読んだことがなく、森博嗣ですら完全スルーした僕ですが、ストーリーが良く練れていて面白かったです。この書評を30分で一気に書きあげることが出来ました。ミステリー小説に縁がない方も、是非お手にとってご覧頂けたら。

虹を待つ彼女

虹を待つ彼女

仕事の大半はルーチンワークで、楽しいのはごく一部だよ。

休学して起業すれば良かったのに。大卒という看板は一生自分についてくる。片道切符を掴む必要はなかったよね...。済んだことからしょうがないけど。

www.ishidanohanashi.com

レールの乗った人生というのが何を指しているかわからないけど、お仕事はルーチンワークというレールの上を進まねばならない。あなたが憧れている方も滅茶苦茶レールの上を歩いている。社長でもフリーランスでも会社員でもアルバイトでも、みんなに言えることですが、「仕事で楽しいのはごく一部で、大半はルーチンワーク」です。同じことを繰り返すのが仕事の大半。何かを継続することは、同じことを繰り返すこと。仕事を変えたいと思って行動しても、帰結する先はルーチンワークなんですよ。なので、こいつを楽しめなかったら無茶苦茶消耗します。

新卒フリーランスという謎の言葉が一時期バズってた。限りなくニートに近いけど言い方がファンキー。その親玉っぽい方はキャンピングカー生活をされているそうだが、今頃「楽しいことはごく一部」だと痛感しているかもしれない。ブログを書き続けるというルーチンワークから逃れられない。サロン運営もルーチンワーク。フリーランスとして時間を自由に使える所がマブしく見えるかもしれないけど、みんな会社員より働いている。ルーチンワークが会社員よりすごく増えるし、仕事を成立させて入金まで管理するのも大変だし。

ブログを書いて稼げます!というのは能力ではあるけど、職能ではない。「ブログを書く」を麻雀やパチンコに置換するとわかりやすいでしょう。職能は大きく言えば社会の問題解決に役立つ能力であって、それは事業運営をしている組織に属さないとまず身につかない。パチンコで稼げてもその能力を会社の事業に活かせない。なので雇う理由もおカネを払う理由も無い。僕はこんなことが出来るのに何故活用させてくれないんだわからないんだと消耗すると、高知への片道切符をつかんでしまうよ。(察し

仕事で成果を上げている人って、その大半のルーチンワークを陳腐化していないというか、必ず新しい変化や挑戦をどこかで盛り込んでいるように見える。そこがごく一部の楽しい部分のひとつ。プロは同じことを何度も繰り返して正解を常に生み出せるからプロなんだけど、その正解の質はどんどん変わらないと嘘なわけ。奥行きだったり密度だったり、色々さ。

どういう立場で仕事をするかは人それぞれだけど、ルーチンワークで多かれ少なかれ消耗します。起業したら会社員よりさらに消耗するポイントが増えます。そこで不貞腐れず続けて行こう。楽しいことが必ず見つかるはずだから。

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