ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】「Yコンビネーター シリコンバレー最強の~」を読んで

読書感想文です。今回読んだ本はこちら。

 

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

 

本文中でYCと記載しているところはYコンビネータ―の頭文字をとった略称です。

 

この本を読もうと思った理由

ハードカバーの本は嵩張るのであまり好きじゃないんですが、Yコンビネータ―というスタートアップスクールの話は何かで聞いたことがあって、面白そうだと思った記憶があったので読んでみました。

あと作者が外国人で、翻訳された本というのも選んだ理由の一つです。海外で出版された本で、クソみたいな本は翻訳されないですからね。たまに内容がクソで商業的に成功しただけの本もありますが、Amazonの評価も高かったのでまぁ大丈夫でしょと読んでみました。

 

全体の感想

書評家みたいなことは書きたくないですが、本書は劇薬です。取扱い注意です。

ITの力を信じていて、でも普段の仕事ではそれを実感できなくて、世界のテック企業と自分のいる場所に隔たりを感じ諦めてしまっている方は、本書を読むと熱気にほだされる可能性があるため注意してください。文章を通して強い熱気を感じ取れる良書ですが、熱すぎて火傷の危険性があります。

 

繰り返します。良書です。私は今まで何冊もIT系やビジネス系の書籍を読んで来ましたがトップクラスです。

タイトルにある「Yコンビネータ―」はシリコンバレーにあるスタートアップ養成スクールです。ここでは熱意と能力とアイディアを持つ起業を目指した人間を集めてきて、投資をしつつ3ヶ月かけてスタートアップ企業として鍛え上げていくスタイルで運営されています。ドロップボックスやヘロク、エアビーアンドビーがここの出身です。あと有名どころの話としてハッカーニュースもYコンビネーターが運営しています。(https://news.ycombinator.com/

 

本書はそのスタートアップ企業を鍛える3か月間のドキュメンタリーになります。本書は最初の起業アイディアがうまくいかず参加者が悪戦苦闘している様子や、それに対するYコンビネータ―運営側からのアドバイスで構成されていますが、いずれも生々しいというか生きた言葉で綴られていてすごく惹きこまれます。パートナー(運営側のアドバイスする人)の方たちのシンプルでいて本質的なアドバイスは文章というフィルター越しに見てもとても熱いものを感じます。

 

本書内で「ポール・グレアムと話をするとみんな早くコーディングしたくなる」と書いてあるところがありました。話をしながら元のアイディアを磨いていくと、そこで話した内容を早く実現したいと思ってコードを書きたくなるという意味なんですが、私は本書を読んでいるだけで『何か作りたい』と思うようになるほどでした。

これは人の思考に影響を与えるほどの大きなエネルギーを持ったYコンビネータ―のパートナーがすげぇという事ももちろんありますが、そのエネルギーを文章越しでも感じられるように書いた著者も素晴らしいですし、更にそれを翻訳した人(Tech Crunchの翻訳チーム)も良い仕事をしています。

 

Amazonのレビューを見ると投資の世界の人たちが多く読んでいる本のようですが、これは何かを為したいと思っているエンジニアこそ読むべき本です。すごくエネルギーが湧いてきます。またスタートアップをやりたいと思っている人や実際にやっている人には本当に身になることがいっぱい書いてある本ですので、オススメできます。

 

次項に本書を読んで心に響いてきたところを引用しながら書いていきますが、「ここだけは!」という二点だけここに書きます。

YCの教義

コードを書いて顧客と話せ、早く出してやり直せ、数字で測れる週間目標を決めて集中しろ。

スタートアップ企業の大切なところとして「YCの教義」と紹介されていた言葉です。これはスタートアップだけではなく、日々の仕事や生活の中でパフォーマンスをあげなければならないあらゆる時に重要なことだと思います。基本的なやるべきことをやって、ユーザとコミュニケーションをとって、それを早く出して繰り返しやり直せと。そして計測可能な目標を定めて集中してやる。何だろう書いてあることはよく言われることなんですが、たぶん本書の読後にまだ熱気が残っていてそれにあてられてるのかもしれません。

 

もう一つ。

創業者があきらめない限りスタートアップは失敗しない

これも良い言葉。上に書いた教義と合わせて、諦めずにコードを書き続けてユーザと対話し続けろ、ってことですね。スタートアップの成功率というのは極めて低いです。そういう上手くいかないことが大半という性質を持つものは、うまくいくまでやり続けることが重要。ギブアップするまで失敗ではないというメッセージです。

 

私は本書はすごく良い本だと感じましたが、なにをもって良い本だと思ったのか考えてみました。

1つは上にも書いた文章越しに伝わってくる熱気、エネルギーです。ドキュメントだからか、参加企業の苦悶やYCパートナーのアドバイスが生々しく感じられます。この本を読んでいると本当にコーディングをしたくなる。目標が見えなくなって無気力になった時のカンフル剤としてずっと手元に置いておきたいと思える本です。

もう1つは、スタートアップの考え方を学べたことです。上で書いたYCの教義なんかもそうです。この教義だけを見ると割とどこかで言われているような内容なんですが、これがドキュメント形式の本書を通して見ると見え方が変わってくるんです。うまく表現できませんが、読めばわかるとしか書きようのない説得力があります。

あとは本書を読む前の私の考え方に近い部分があって、読んでいて心地よかったというのもあります。ひょっとするとこれが全てなのかもしれません。特にYCがハッカーを好むという点です。新しいものを作る時に、その人たちがその技術に精通していない、ようは自分たちでモノを作れないというのはダメという話です。本書を通してYC参加者はハッカーであることが望ましいと繰り返し書かれていて、この点は本当に読んでいて心地よかった。

 

良い本である理由をうまく挙げられていませんが、まぁ良い本ってのはだいたいそうなんですよ。良い事がいっぱい書いてあってダイジェストにまとめられないんです。よほど斬新で正しい内容が簡潔に書いてあれば、「AはBである。と書いてあった。目からウロコである」と感想を書けますが、良い本は「AはBだし、CはDだし、・・・・」と永遠と素晴らしい内容が続いて、しかも一冊の中でそれが複雑に絡み合いながら説得力を増していくので、どうにもまとめられないわけです。

本書の感想から少し逸れてしまいましたが、それでもこの素晴らしい本の内容は紹介したい。次項に「これキタ!」という箇所を引用して紹介します。部分的に抜き出すと、それだけではどうにも薄っぺらく見えてしまうところはありますが、私は書評家のような本を評価する言葉を持っていないのでこうするしかない。

 

「これキタァ!」と思ったところ

「これキタ!」ポイントを引用しながら紹介します。

 

スタートアップの本質は新しい会社だという点には無い。非常に急速に成長する新しいビジネスでなければいけない。スケールできるビジネスでなければいけないんだ。そうでなければ、それはスモールビジネスの開業であってスタートアップの企業ではない。

うまく言葉で言い表すことができなかったんですが、本書を読んで言語化できました。私が勤めるSIerで以前ソリューションサービスコンテストというものが社内で行われたんですが、その時にニッチなハードウェア技術を持っているチームが、「自分らの技術を使って社内スタートアップ企業を作りたい」と言っていて「なんか違うよなぁ」と思っていたんですが、これですね。急速に成長、スケールできるビジネスでないから、しっくり来なかったんですね。

 

スタートアップのアイディアを生み出すための3か条

1.創業者自身が使いたいサービスであること

2.創業者以外が作り上げるのが難しいサービスであること

3.巨大に成長する可能性を秘めていることに人が気づいていないこと

これはスタートアップだけの話ではないですね。SIerに勤めていると新事業の提案というタスクが突如与えられることがありますが、これは覚えておきたい。特に3番。

 

他の連中より真剣に考え抜いた点だけが優位性になる

これもスタートアップだけの話ではない。IT戦略やシステム提案の時に思い出したい言葉です。現実には企業勤めだと考え抜くための時間が与えられないケースが殆どですが、「この部分は考えるのが大変だから、考えた分だけ自社の優位点になる」という発想は忘れたくない。

 

最初にリリースしたプロダクトが赤面するほどひどい出来でないというのなら、そのリリースは遅すぎたのだ。

巧遅拙速のバランスの話ですね。私は巧遅の方に傾倒していて、意識しないとすぐに忘れてしまう。スタートアップでは拙速側に倒れている方が優れているようですが、完全に私に向いていない世界。。。改めて拙速の意識づけができました。

 

目標設定が効果があるのは、集中力が養われるからだ。スタートアップではやるべきことは毎日無数にある。しかし毎週成長目標を決めたら、その目標を達成するのにどうしても必要な仕事はどれか、適切な時間の使い方を必死で考え抜く必要がある。

”毎週の”成長目標というのは斬新に感じた。SIerや一般企業に勤めていると半年や1年単位の目標を作ることはよくある(大抵機能しない)が、週間目標というのは発想が無かった。もちろんスタートアップの話だから手持ち資金が底をつく前に成長しないといけないということであろうけども、SIerや一般企業の個人目標の話とは次元が違う速度が求められるということか。人の成長速度とビジネスの成長速度を比較してもしょうがないかもしれないですが、シリコンバレーのスタートアップでは1週間の単位で成長度合いを測るのに対して、日本の一般企業では26週(半年)ないし52週(1年)で測ると。しかも国内企業では多くのところで儀式化されているレベルですので達成への情熱も段違いに低いわけです。こういうところから地力の差が出てくるんだろうなぁと思いました。

 

成功するスタートアップはミートアップに行かない。アドバイザーたちと話すために走り回らない、ひたすらコードを書き、顧客と話す。

すごく納得したところです。スタートアップの本質はそれまでに無かった何かを作って市場に出すことです。”作って出す”というのが最も基本的で本質的なところですから、泥臭く時間を掛けてでもやるべきことという話です。たまに「何よりも人脈と繋がりが大切マン」と知り合うことがありますが、彼らは本当に薄っぺらい。あーなったら終わり。

 

流行語や使い古されたマーケティング用語は使うべきではない。「私たちはこの市場を破壊するつもりです」といった紋切型のフレーズは、グレアムにとっては素材写真のようなものだ。「ほかのスタートアップのプレゼンにも使えるようなスライドは使うな」と彼は言う。

これスタートアップだけの話じゃないですよね。この部分を読んで思ったのは、日本のSIerの会社紹介ですよ。あれは本当に酷いものだと思います。たぶん会社名だけ変えればそのまま使えますからね。オリジナリティーなんか欠片も無いくせに、面接では「なぜウチの会社なのかね?他社と比べてなぜウチ?」と聞いてきます。バカの極地です。

 

1ビットだけでもいいから世界を進歩させるようなプロダクト

これは言葉が気に入りました。どこかで使おうと思います。 1ビットしか世界が進歩しなくてもそれができる状態になったプロダクトはさっさとローンチしろ、というお話で使われていた言葉です。

 

うまくいかなかった点も多かったが、これはいつものことだ。うまくいかなかった点はこれから直していけばいい。どうせ私は死ぬまでうまくいかない点を直し続けることになるんだろうが。

カッコいいなと思った言葉。これもいつか使いたい言葉としてここに記録しておく。こういうことを言えるおっさんになりたい。 

 

ソフトウェアが世界を食う

今やソフトウェアはあらゆる産業のバックボーンとして普遍化している。いわばソフトウェアが世界を食ってしまおうとしているのだ。

抽象的でフレーズが気に入ったというのもありますが、正に世の中がこういう風に進んでいるなと私は思っています。他のエントリでも何回か書いていますがITシステムの中で真の価値を提供しているのはアプリケーションです。言い方は悪いですが、インフラはツールであってユーザに大きな価値は提供できない。世界を食ってしまうほどの巨大な何かはアプリケーション(ソフトウェア)だと思っています。インフラはインフラで面白いんですが。

 

本人が勉強熱心であれば、ウェブやモバイルの複雑なアプリケーションを驚くほど短時間で完成させることができる。ソフトウェア・スタートアップを起業してベンチャーキャピタルの門を叩くために、マイクロソフトやオラクルのような大企業で5年、10年と下積み生活をする必要はまったくない。

こういう言葉ですよ。前項で劇薬だとか書きましたが、生きた言葉で綴られたこういう本で、「大企業で下積み生活をする必要はない」とか書かれていると、「そんじゃ俺もやったろやないかい!」って思ってきちゃうんですよ。

 

おわりに

何回も書きましたが、良書です。本当に手元に置いておきたいと思える本です。自分で言うのもなんですが、私は割と悲観的、否定的に物事を考える癖があって大抵の本は見下した状態から入るんですが、今回は完全に覆されました。私は今までビジネス系の本は50か100かくらい読んでいると思うんですが、トップクラスです。

 

このエントリを上からここまで読んでくれた方は、狂信的とか信者かと思うかもしれません。私もこのエントリを書きながらプレビューを見たらそう思えました。ちょっと気持ち悪いくらいに。でもそれだけ良い本なんです。

内容的、分量的に誰にでも薦められる本ではありませんが、スタートアップの世界を覗いてみたい方や実際にスタートアップとして走り始めている方、SIerの中で疲弊して無気力化してしまった方は是非読んでおいた方がいい本です。

 

おわり

ベネッセ情報流出事件の地裁判決が出たニュースについて

先週、2014年に発覚したベネッセ社の情報流出事件の続報が報道されてました。最近読んだ本と関連のあるニュースだったので脳内整理も兼ねてだらだら書いていこうと思います。

 

私が読んだニュースがこれ。

www.nikkei.com

 

で、最近読んだ本のレビューがこれ。

 

ニュースの概要

ベネッセ社の個人情報流出事件で被害のあった180人が計1478万円の損害賠償を求めた訴訟を起こし、東京地裁判決が出た。「慰謝料が発生するほどの精神的苦痛があるとは認められない」として請求は棄却。原告側は控訴の方針。

  • 原告側の主張

「流出情報をもとに営業電話やDMを受けたり詐欺などの犯罪に利用されるリスクがあり重大な不安感がある」

  • ベネッセ側の反論

「勧誘行為があったとしても、日常的にありふれたものだ」

  • 判決

裁判長はベネッセ側に対策や監督を怠った注意義務違反を認定。一方で氏名住所などの情報が思想信条や性的指向などの情報に比べ、他者にみだりに開示されたくない私的領域の情報という性格は低いと判断した。また実害が生じていない事、お詫びの文書と500円相当の金券を配布した事を考慮して、原告側が求めた損害賠償を認めず。

  • 判決を受けた弁護士のコメント

「プライバシー侵害を認めながら損害が生じていないということは矛盾だ」

 

考察

損害賠償の金額

180人が1478万円の損害賠償を求めているので、一人当たりの平均は82,000円ほどですね。流出した内容をあらためてみてみると以下の通り。

 

  • 個人に関する情報

 保護者と子供の氏名・性別・生年月日・続柄・出産予定日

  • 連絡するための情報

 郵便番号・住所・電話番号・FAX・メールアドレス

 

 参考:事故の概要 | お客様本部について | ベネッセお客様本部

 

個人情報流出における賠償(和解)金額の相場はどれくらいかと調べてみたところ、みずほ中央法律事務所というところが一覧で整理して公開していたので引用。

  • 秘匿性=『低』レベル→500円〜1000円

  住所・氏名など

  • 秘匿性=『中』レベル→1万円

  クレジットカード情報、収入・職業に関する情報

  • 秘匿性=『高』レベル→3万円

  スリーサイズ、エステの施術コース

 【個人情報漏洩・流出の民事的責任(賠償金額)の実例と基準や相場】 | 企業法務 | 東京・埼玉の理系弁護士

 

住所や氏名、電話番号などの情報は直接犯罪に結びつきにくいという性格からか500~1,000円コースですね。

クレジットカードや収入、職業はお金に関連して直接的な損害に結びつきやすいため1万円コース。

センシティブ情報(機微情報:思想信条、性的指向、健康情報、DNA情報、その他好き嫌いに関する情報)は3万円コース。

 

今回のベネッセ社の事件では流出した情報の秘匿性が低いので500~1000円コース。過去の賠償例に沿った妥当なところじゃないのかというのが、傍観者としての私の意見です。

とはいえ、仮に自分が被害者になったと考えると500円じゃ安いというのは確かにそう思う気がします。

 

子供と大人で個人情報の価値は同じか

上にリンクを張った元記事では詳細が書いていないだけかもしれませんが、一人当たり8万円を求める原告の主張は弱いと思います。

 

原告側

「流出情報をもとに営業電話やDMを受けたり詐欺などの犯罪に利用されるリスクがあり重大な不安感がある」

ベネッセ側

「勧誘行為があったとしても、日常的にありふれたものだ」

 

過去の事例では、原告が主張するような不安感に対して「500円で勘弁してくれ」という趣旨でお詫び金が発生しているわけです。この事件が過去の事例とどう違うのかという点で争わないと500~1,000円コースに落ち着いてしまうのは明らかです。

 

例えば、子供の情報が中心だからリスクに晒される期間が長いとか、子供個人に焦点をあてて自分で個人情報をコントロールできない子供の情報を流出させたから今までよりも重い事件であるとか、そういった主張をすべきではないのかと。してるのかもしれませんが。

 

個人情報についての考え方として、自分の情報をコントロールする権利というのがあります。個人情報に変更があったらそれを訂正する権利があるというやつです。

この権利のことを考えると、自分の情報をコントロールする権利が認められているならば、自分の情報をコントロールする判断力の無い子供の情報というのは、大人の個人情報よりも重く見られるべき、社会的に守られるべき情報だと思えます。そう考えると情報を主体的に管理・制御することのできない子供の個人情報が漏えいしたんだから、もっとお詫び金出せよという主張もありだなと思います。

 

外部犯でも内部犯でも同じなのか?

この事件は内部犯によるものなので、外部から攻撃されて情報流出した他の事件と比べ、より管理責任が問われても仕方のないことだと思います。

外部から攻撃される穴となる脆弱性を全て完全に塞ぐというのは相当難しいです。既知の脆弱性になるべくタイムリーに対応していくのが精一杯というのが多くの企業の実情です。ここは突き詰めていくと際限なく金がかかるところなので、状況にもよりますが企業が被害者顔をして世間が納得する場合もあるにはある。

しかし今回の事件は金に困った内部の人間による犯行なので、これを止めるために現実的に出来ることは割とあったんじゃないかと思います。そもそもUSBでスマホを接続しても情報を抜けない仕組みを作るとか、統制のとれる体制で運用すべきだったとか、監視を強めるだとか、いろいろと言われていることですが現実的にやれることはあった。けどベネッセはそれを怠ったと。

 

感情的な話

冒頭にリンクを張っていますが、私が最近読んだ「あなたのデータ、お金に換えてもいいですか?」にこんな事が書いてありました。(いま手元に本が無いので記憶から引用)

不幸にも幼い子供が亡くなってしまったとして、生きてれば7歳になるという時には小学生向けのDMが届く。その後も中学校入学、高校入学、成人式、新社会人と色んなタイミングでDMや営業・勧誘の知らせが届くわけだが、親はそれを見るたびに子供を亡くした事実を思い出し涙を流す。

 

これは確かに辛い。そして情報流出が無ければ「(子供が亡くなったので)もう送らないで」と連絡するだけで傷をえぐるDMは送られなくなるはずだったわけです。しかし裏で色んなところで情報が売買されもう止めることは出来ない。まぁ引越して電話番号変えれば止められはしますが。

 

これは個人情報全体の議論からするとレアケースですが、本質的なところを考えると、子供の個人情報は大人の情報と比べて影響範囲が違う、異なる性質を持っているというお話なんだと思います。

 

日本語でググってみた感じだと、子供の個人情報について特別に規定した条約や法律は無さそうです。このあたりも裁判の結果に影響しているのかもしれないですね。

 

おわりに

今回は直近で読んだ本に関連するニュースがたまたま報じられたため、思う所を含め書いてみました。このエントリを書きながら興味深いなと思ったのは、子供の個人情報に関する取り決めが(たぶん)無く、大人と同じ枠組みで考えられるということでした。

とは言ってもまだ控訴するという話なので裁判がどうなるかわかりませんが、そのうちEUあたりで同じような事件が起こって莫大な賠償額の裁判が起こりそうな予感もしています。

”個人情報”はEUGDPRにしろ国内法にしろ曖昧さが残る部分があるので、ちゃんと考えないといけないなぁと思いました。

 

おわり

麻雀のアガリ判定アルゴリズムで苦戦したこと

ひょんな事から麻雀で使う清一色チンイツ)のツールを開発することになりました。

実際に手を動かしてアプリを作っていったら、これが結構大変だったので時間がかかったところの考え方だけでもインターネッツの世界に書き記しておこうと思います。

 

 

何が大変だったか

ガリ判定のアルゴリズムです。インターネッツで情報公開している先駆者の方の情報を参考にしましたが、なかなか判定し切れなかったです。

 

何を引いてきたかはとりあえず考えないで、以下の手牌のアガリ判定を考える。

f:id:kwnflog:20180612114946p:plain

麻雀経験者からすると清一色の手の割に簡単ですね。

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115640p:plain

頭の中でこう分解できれば和了

ただこの分解を実装しようとしたら意外に難しかった。

 

インターネッツで調べながらコードを書いてはチェケラしていったのですが、どうも全パターンは判定できない。ネッツで調べたところ大体以下の手順でした。

①頭候補を探し順に試行していく

刻子候補を探し面子確定させる

③残った手配を順子に分割できたらアガリ

 

①の頭の確定のところはたぶん正解だと思います。特殊形を除いて頭は必ず1つ必要なので先に確定させた方が試行回数が減少するはず。

で、次いで3枚以上ある牌で刻子を確定させ、残りの手牌は順子を構成するものとする。

 

順子だけの場合は端から判定して抜き出していけば、和了の時は問題なく全部抜き取れる。ただ刻子や頭と組み合わさった時が曲者なんですね。

 

上の例だと三萬と四萬が刻子候補ですが、何も考えずにこれらを面子確定させてしまうと、アガリ形とはならない。

f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612121550p:plain

 

じゃあ、とばかりに順子から面子確定させていくと、

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121848p:plain

 

やはりアガリ形をうまく判定できない。

 

大抵の清一色手牌だったり、清一色以外の手牌ではこういう事は発生しません。刻子と順子が同じ牌を使う場合のみに発生しうるレアケースですが、私が書いていたのは清一色で遊ぼう系アプリだったためこれは避けられない問題。

 

解決法ー刻子を組み合わせで考える

この手の場合どう考えればいいかというと、刻子候補のうち三萬のみを刻子として確定させ、残りを順子の組み合わせと考え面子確定させていくが正解です。アルゴリズム的な話にすると、

 

①牌種ごとに枚数をカウントする

②2枚以上ある牌種を頭候補として、各候補に対して以下を繰り返し

③頭を仮確定させ手牌から抜く

④3枚以上ある牌種を刻子候補として、その組み合わせを求める

刻子組み合わせ候補に対して以下を繰り返し

⑥対象の刻子を面子仮確定させ手牌から抜く

⑦残った手牌の端から順子を抜く

⑧全ての牌を抜き取れれば和了

 

もう少し具体的にみていきませう。

頭はアガリ形の中に必ず1組存在するため、順番に2枚以上ある牌を試せば問題はないかと思います。 ここでは上記手牌で八萬を頭候補とした場合を考えます。(もちろん3,4,5,6萬を頭候補としてアガリ判定を行い、全て失敗し八萬に到達した状況です)

この状況。

f:id:kwnflog:20180612131633p:plain  f:id:kwnflog:20180612115640p:plain

ここで上記④の刻子の組み合わせを求めます。

刻子自体は三萬と四萬がありますが、その組み合わせなので、

刻子無し)(三萬)(四萬)(三萬&四萬)の4パターンが存在することになります。

 

仮に刻子候補が3つあればそれぞれを刻子とするか否かの二択が3つなので、2の3乗の8パターン、刻子が4つであれば2の4乗の16パターンを考えることになります。刻子が4つであれば四暗刻なので別に四暗刻判定を入れてもいいかもしれません。

 

ではまず八萬を頭、刻子無しと考えて残りを順子分解してみましょう。

 f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612132420p:plain  f:id:kwnflog:20180612115640p:plain

ノー和了

 

次は三萬のみ刻子として考えた場合、こうなって、

f:id:kwnflog:20180612132758p:plain  f:id:kwnflog:20180612115620p:plain   f:id:kwnflog:20180612115640p:plain

こう。

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612115640p:plain

和了

 

最後まで見てみましょう。次は四萬のみ刻子とする場合。

f:id:kwnflog:20180612133103p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612115640p:plain

ノー和了

 

三萬と四萬を刻子とする場合、

f:id:kwnflog:20180612133226p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612115640p:plain

これもノー和了

 

結局のところアガリと判定することができたのは、三萬のみを刻子と考えて残りを順子と見做した1パターンだけでした。

一盃口に頭がくっついた11223344であったり、それを含んだ更に複雑な形だと複数のアガリ形が存在し、アガリ役や点数に影響が出るため途中でアガリ形が求められても最後まで処理を継続する必要があると思います。

例えば、11223344456789 という形であれば頭を一萬とするか、四萬とするかで一気通貫がつくかが変わってしまうためです。

 

 

他の先駆者の方が公開している内容を見ると、頭を最初に抜き出すのは殆どの方が一致しています。

その後のアプローチに結構やり方の違いがあって、頭→刻子→順子と抜き出す人だったり頭→順子→刻子で抜き出す人がいます。

 

私がたどり着いた結論は以下。

抜き出す順番ではなく、抜き出す刻子の組み合わせが重要

刻子として抜き出せるけど、抜き出さないケースを考慮する

 

ここでは刻子の組み合わせに注目していますが、反対に順子の抜き出しの組み合わせを考えても同じようにアガリ判定ができるはずです。

ただ、

  • 刻子のほうができにくいので、数が少なく組み合わせを考えるのに適している
  • 順子は抜き出した面子によって、その後抜き出せなくなるケースが存在する

という理由で刻子の組み合わせを考える方が効率が良いと考えています。

 

例えば手牌中に以下のような形があったとして、

f:id:kwnflog:20180612140217p:plain

ここから取り出し得る順子は以下の4パターンがあります。

f:id:kwnflog:20180612140337p:plain f:id:kwnflog:20180612115610p:plain f:id:kwnflog:20180612121814p:plain f:id:kwnflog:20180612115631p:plain

ただし123を抜き出した場合は、234と345は取れなくなります。234か345で面子を作ると他の面子を作ることはできないです。

このように抜き出した面子によって、その後抜き出せる面子が変わってしまうため、事前チェックが必要となりコードとして冗長になってしまいます。

刻子であればどのように刻子面子を確定させようと、他の刻子面子には影響が出ません。

 

 

おまけ.組み合わせを考えないと判定できない牌姿一覧

清一色のアガリ形から「抜き出せるけど抜き出さない」をしないとアガリ判定ができない手牌を並べます。

この手牌は単純に刻子を全部抜き出すとか順子を全部抜き出すといった方法ではアガリ判定ができないのでテストに使えると思います。というか複雑な形が多いのでこの手牌を頭の中で瞬時に分解できれば清一色上級者と言えるかもしれません。

 

'23333444556688', '22333456667788', '22344445556677', '11123334445577', '22223333444556', '11222345556677', '22333344555667', '11333445566678', '11122223334455', '22555566677788', '23333444555566', '22566667778899', '22444567778899', '22444455666778', '12222333445599', '22223344455688', '11123334445555', '33344555566678', '44455667778999', '11112233344566', '11444556667778', '11225566778899', '44445555666778', '12222333445588', '22234555667777', '33345666778888', '11122334445666', '22223334445588', '33345666777788', '11122334445677', '22233345556677', '11223344667799', '11123444555566', '44455567778899', '33444455666778', '22234445556666', '11222334455567', '44456667778888', '11123344455688', '11222334445556', '11444566777889', '11123334445588', '11333344555667', '22234555666677', '11122333444566', '44566667778899', '55666677788899', '33334455566799', '11555667778889', '11333455566677', '22223344455699', '33344445556677', '33555566777889', '22233445556799', '11122333444588', '11122223344456', '22223334445599', '34444555666677', '44445566677899', '55556666777889', '22444556677789', '11122333444599', '11112223334499', '11334455667799', '33345566677899', '11123344455666', '33334445556699', '33444566777889', '11122233444556', '11666677788899', '33344555666788', '22233334445556', '11123334445566', '11566667778899', '11224466778899', '11224455667799', '22444556667778', '12222333444455', '22234445556677', '33444455566677', '22333344455566', '11123334445599', '33444556677789', '11122333444577', '11112223334466', '11122223334445', '22234455566667', '22223334445577', '11223355668899', '11444455666778', '11123444556688', '44555667778889', '11122334445699', '11333456667788', '11112223334488', '55566667778889', '11233334445566', '11334455668899', '33345556667799', '22233344555667', '34444555667799', '11223344557799', '11224455667788', '22333445556667', '22234445556688', '22234444555667', '11224455668899', '22234555667799', '11112233344599', '33344445556667', '44445566677888', '11112223334477', '55556677788999', '11112233344588', '11112222333445', '22234455566799', '11123444556699', '33555667778889', '22333445566678', '33566667778899', '12222333445577', '22444566777889', '22233444455567', '44455666677789', '22555677788899', '44455556677789', '44555566777889', '22233445556788', '11224455778899', '44455566777889', '33444567778899', '11444566677788', '44456667778899', '22335566778899', '33334444555667', '11223344668899', '22234455566777', '44456777888899', '33344556667899', '44455556667778', '11223344557788', '33666677788899', '11112233344555', '55567778889999', '11444455566677', '11455556667788', '33345556667788', '33344456667788', '22233444555699', '44555566677788', '11222233444556', '11122333344456', '11344445556677', '11222344555667', '44445556667799', '33555677788899', '22233444555677', '11123344455699', '11333445556667', '44456677788889', '22333455666778', '33455556667788', '11123344455556', '11334466778899', '33555566677788', '11444556677789', '44456677788999', '11122234445566', '22555667778889', '22455556667788', '33444556667778', '22233445556777', '33344445566678', '11555566677788', '33344555666799', '22555566777889', '33345566677778', '33345556667777', '33334455566788', '22233334455567', '22234445556699', '33334445556688', '11333344455566', '44455556667788', '33345566677888', '11123333444556', '33344556667888', '11222344455566', '33345555666778', '22234455566788', '22333455566677', '44455666777899', '23333444556699', '11333455666778', '11223344558899', '11444567778899', '11335566778899', '33334455566777', '45555666777788', '44456666777889', '11123344455677', '33444566677788', '11123444556666', '22444455566677', '22223344455666', '22233444555688', '11222233344455', '44456777889999', '44555677788899', '22444566677788', '22666677788899', '22233334445566', '44666677788899', '11122334445688', '22334455668899', '33344455666778', '56666777888899', '11555566777889', '55566667778899', '11112233344577', '22223344455677', '11555677788899'

 

おわりに

この問題は考えていて結構おもしろい問題でした。どう分解するアルゴリズムなら漏れなくアガリ形を捉えられるか、いい感じの難易度とコーディングの自由さがあって楽しめました。

 

色々やっているうちに結局のところアガリ判定はインデックス法(全アガリパターンの配列とマッチングする方法)を使うことにしましたが、その他の機能で部分的に生きてくるモジュールになるので書ききりました。たぶんシャンテン数を計算する機能で使うはず。

 

おわり

 

【読書感想文】「あなたのデータ、お金に換えてもいいですか?」を読んで

読書感想文です。今回読んだ本はこちら。

 

プライバシー大論争 あなたのデータ、「お金」に換えてもいいですか?

プライバシー大論争 あなたのデータ、「お金」に換えてもいいですか?

 

 

この本を読もうと思った理由

2018年6月現在、一般報道におけるITニュースで「データ」というキーワードが非常に多い印象を受けています。データ系記事も大きく2つあって、1つはビッグデータ。これはAIやIoTとの組み合わせで純粋なテック系の記事です。もう1つは個人情報に関するデータ系記事です。

代表的なのはFacebookが叩かれまくっているやつとか、

Facebookがゴタゴタしてる問題をいったん整理して、今起きていることを知ろう | ギズモード・ジャパン

中国企業に委託していた年金データのやつとかです。

年金制度を危機に晒す「年金機構」の実態…国民の個人情報を中国に漏洩、年金過少給付 | ビジネスジャーナル

 

およそ1年前の2017年に個人情報保護法が改正されましたし、先月(2018年5月)にはEU一般データ保護規則GDPR)も改正されました。「個人情報」とか「データ」という分野がホットなうちに一冊くらい本読んで勉強しておくかと思い適当に選んだのが本書でした。適当とは言っても日経コンピュータの記者が書いているので大外れは無いだろうと。

 

全体の感想

定価1,600円の本としては残念でした。表紙には「プライバシー大論争」、帯には「プライバシー論争を決着させる」とありますが、特に異なる意見がぶつかり合っていることもなく、最終的に何かが決着したとも読み取れませんでした。何かこう有りものの文章や、取材したけど形になっていない文章を集めてきて「釣り」的なタイトルで出版したような印象があります。800円くらいの新書で出版するなら納得かなという印象です。

 

内容としては、第一章でそもそもプライバシーとは?日本でのプライバシーってどう概念づけられてきたのかという歴史的な側面を見ながらプライバシー自体を定義しています。第二章では主に国内のプライバシー事件の紹介、第三章で個人情報保護法の成り立ちと改正についての内容、第四章で「データ立国になるには」という提言で締められています。一章と二章、三章と四章で著者が変わります。

 

一章と二章はよくまとまっていて読みやすかったです。歴史的な側面から直近のプライバシー事件まで網羅されているので、ここを読むだけで国内におけるプライバシーという概念がどう変化してきたか大よそのところは掴むことができました。

またプライバシー事件の発端が利用者による「(勝手に情報を売買されて)気持ち悪い」という感情から始まるという話は興味深かったです。何を以て個人情報となるか明確な線引きが無いため、利用者がどう感じるかによって炎上してしまうというのは覚えておかないといけないなと思いました。

二章でピックアップされている事件のうち、Suica事件については、乗降データから乗車駅と降車駅の組み合わせで個人の特定が出来る場合があるという話が興味深かったです。確かに乗車駅と降車駅の組み合わせや、時間帯を組み合わせると個人を特定することはそう難しくないなと思いました。本書ではデータの性質を個々に考えて、何が個人情報にあたるか、しっかりと考えることが必要だと書かれており考えさせられました。

 

三章と四章は、個人情報保護法や海外のプライバシー保護の仕組みに言及しているからというのもありますが読みづらかったです。目次や項や節の切り方がよくないのだろうと思いますが、順に文字を追って行っても「これ何が言いたいんだろうか」と思うことが結構ありました。率直な感想として三章四章は本書タイトルから読者が知りたいであろう内容を書いたというより、著者が書きたいことを書いたように感じました。

この三章四章では読んでいて怒りを感じた部分すらありました。個人情報の「保護と活用」はゼロサムゲーム(どちらかを獲ればもう一方を損なう)ではなく、プラスサム(活用するなら保護しなければならない)なものだと書いています。三章の途中に「次章で詳述する」と書いてあり、期待感を持たせてきますが四章に書いてある内容はごく当たり前のものしか記述されていなく、肩透かしをくった感がありました。

私は本書を読みながら、保護の度合いと活用の度合いが比例するような具体例やロジックを期待していましたが、「保護すれば信用が高まってよりデータが集まる。データが増えれば分析の信頼性が上がる」としか書いていませんでした。CCC社のTポイントの例が挙げられていますが、CCC社が利用規約の変更やオプトアウト(後から個人情報の提供を拒否する仕組み)の方法を変えたという例しかなかったです。CCC社の利用規約やオプトアウトの方法が変わったことで、「なら利用しよう」と考える人がどれだけいるのだろうか。当然社会的な要請として、利用者に歩み寄った優等生の例としては適当だと思いますが、「保護を強化すればデータが集まって活用の幅が広がる」というロジックに適した具体例だとは思えませんでした。三章から引っ張ってきているんだから、読者が知りたい内容を提示するのがフェアなんじゃないだろうかと思いました。

 

個別にビビッときたところ

(なぜプライバシー情報を)勝手に売買されることを、「気持ち悪い」と考えるようになったのだろうか。そこを理解できない事には誰もが納得するプライバシー保護のルールを作ることはできそうもない。

プライバシー情報は何がどうなったらダメという具体的な線引きが無いため、どうしても「気持ち悪い」という感情が発端となって問題が大きくなっていってしまうという話は興味深かった。これは気を付けないといけないなと思う反面、主に日本人が経営する企業で個人情報による炎上事件が発生しているわけなので、日本文化とか日本人の心が分からない海外企業はもっとキツイんだろうなと思いました。

 

英米で発達した「プライバシー」という概念が、日本に持ち込まれたきっかけは、1961年の「宴のあと事件」だろう。

三島由紀夫の小説「宴のあと」のモデルとなった人が、小説に書いてある内容についてプライバシーの侵害を訴えたという話です。日本における最初のプライバシー裁判となったようで、これは知らなかったので勉強になりました。

宴のあと - Wikipedia

 

欧州では、プライバシーを基本的人権の一つに位置付けており、それがプライバシー保護法制の原点にある。ナチス政権によるユダヤ人の探索や選別、東欧諸国の政治警察による国民の監視などを通じて、欧州は個人情報が悪用されることの危険性を歴史的経験として学んだ。これが世界でも最も厳しいとされるデータ保護規制につながっている。

先月(2018年5月)、GDPRが改正されルールが厳しくなった上に罰則も超ウルトラ厳しいので大きな話題になりました。ただ振り返ると「なぜ厳しいのか?」という観点での報道は無く、「これやってたらヤバそう」とかそういう話ばかりが報道されていました。大きな罰則が規定されていますので、そこに目が行ってしまって、どうすればいいかという話になるのは当たり前ですが。

この改正の裏にどういう背景があるのか報じられていなかったのは、本書の読後に考えるとちょっと残念です。もちろんアメリカ企業への牽制も大きな理由なんでしょうけど。

 

(ベネッセとYahooBBの情報漏えいは)対象者に500円をお詫び金として配布した。

ベネッセ事件の時は、なぜ犯行が起きたのか、どうやって犯行を犯したのか、という観点で報道されていました。こういう事件の決着のところは忘れたころにニュースになるので扱いも小さかったのか、見逃していました。企業側としてはかなり頑張ったんだろうなと思いますが、利用者の立場で考えると安いですね。 

 

JIAA(インターネット広告推進協議会)は2014年11月に「インフォメーションアイコン」の実装を始めると発表した。プライバシー保護を企業競争のツールにしようとする意欲的な試みだ。

こういうものがあることすら知らなかったので勉強になりました。

行動ターゲティング広告に共通のアイコンを表示する「JIAAインフォメーションアイコンプログラム」の認定を開始│JIAA

イコン画像を貼りたいんですが、認定を受けているわけではないのでやめておきます。適当に再現します。Web広告の右上にあるこんな感じのアイコンです。

f:id:kwnflog:20180611164826p:plain

広告上にあるこの菱形に囲まれた ”i” のマークをクリックすると、広告配信企業のページに飛べて、個人情報の取り扱いやオプトアウトの意思表明をすることができました。こういうのが存在することすら意識していなかったので勉強になったんですが、一点残念なことも。上記JIAAのリンク先から引用します。

JIAAが指定する業界共通のアイコンの表示を行います。

色んな広告を見てみると、広告の右上に上記のようなアイコンは確かにあるんですが、何か広告配信企業によって微妙にデザインが違うんですよね。Googleだと〇の中にiの文字があったり、MicroAdだと□の中にiだったり、配信企業によって違う。準拠しているガイドラインが違ったりするのかな(EUアメリカのガイドラインに準拠しているとか)とも思ったのですが、MicroAd社はJIAAのポリシーに準拠していると宣言している。

JIAAは自分たちが指定する業界共通のアイコンと言っていて、実際の広告をよく見ると、JIAAが公開しているアイコンとは異なるものが表示されている。どういう事情なのかはわかりませんが、かえって混乱を生む土壌を作っているように思えます。

しかしながら知っている人にとってはオプトアウトの方法が明確になっていますから良い事なんでしょう。世の中の大半の人はオプトアウトなんて言葉すら知らないでしょうが。

 

さらにJIAAはインフォメーションアイコンの実装と並行して、「プライバシー・バイ・デザイン実施プロセス検討チーム」という組織を発足した。プライバシー・バイ・デザイン(PbD)とはあらかじめシステムを構想する段階で、ユーザが何らかのアクションをとらなくてもプライバシーが守られている状態になるようシステムを設計段階に組み込むという考え方である。

プライバシーバイデザインという言葉も本書を通して知りました。

プライバシーバイデザイン - Wikipedia

Wikiを軽く見てみましたが、オプトイン・オプトアウトの話はもちろん、デフォルトで非公開設定にするなど、断片的に何となく知っている内容もありますが、こういうものが体系的にまとめられているのはいいですね。エンジニア的には最低限守るべきラインというのが示されていると開発に集中できますし。そのうち勉強したいことリストに加えておこう。

 

えー、ちなみにですが、本書を発行しているのは日経BP社です。日本経済新聞社の子会社です。そしてJIAAの副理事長は日本経済新聞社の方です。いや別に何がってことはないですけど。

 

まとめ・おわりに

前述したように、特に後半部分が読みづらい書籍でした。情報が断片的になっている感じがあり、項や節ごとの繋がりが見えなかったことが原因だろうと思います。しかしながら、プライバシーの定義や国内の主要なプライバシー事件のまとめなど面白い内容が割とありました。後半部にいくにつれて読みづらく、総合的に何を言いたいのかわからない感じがでてきますが、断片的な情報としては役に立つ情報もありました。

 

最近はAIやビッグデータ周りで、カメラを設置して人の流れを追うとか、顔認識の仕組みを入れて自動化を図るとか、様々な取り組みが始まっていますが、「個人情報とは何か」ということを考えるきっかけとして本書は無しではないかなと思います。

 

積極的に推したいレベルの本ではないですが、個人情報周りだと、個人情報保護法や個人情報保護士のテキストなどどうしても法律関連の固い書籍が多いので、読みやすさ重視でまず本書を手に取るのはありだと思います。法律寄りというよりもビジネス寄りの書籍として良書に出会えたことがないので(あるのか?)、とりあえずビジネスパーソンとして目を通しておいて損はないかと思います。特に一章と二章は。

 

 おわり

 

【読書感想文】「SEの教科書【完全版】」を読んで

読書感想文です。今回読んだ本はこちら。

 

SEの教科書 【完全版】 (技評SE選書)

SEの教科書 【完全版】 (技評SE選書)

 

 

この本を読もうと思った理由

今回この「SEの教科書」を手に取った理由はネガティブな理由からです。そもそもSEというのは明確な定義が存在しなく、大よそ広義的にはIT業界にいる下っ端全般を指したり、狭義では上流の設計をする人とか、コードを書かなくてマネジメントと称した調整とドキュメントを書く人を指す言葉だと思っています。

業界的に100人に聞いたら100人が同じ答えを出すわけではないSEという仕事に関して教科書という名前で書籍を発行するのはいかがなものか、たぶん著者独自の定義に従った狭い見識の元、たまたまうまくいった成功例をひけらかすしょうもない書籍なんだろうと思いました。つーか日本人が書いたこの手の書籍でロクな本に出会ったことがないので、これもまたしょうもない本なんだろうと見つけた瞬間に考えました。ただそういった文化的ゴミレベルの書籍がいっぱいある中でも、本書タイトルの「教科書」という言葉はやり過ぎだと感じました。特にここ10年くらい、書籍タイトルでの「釣り」が多く、出版業界の何でもやる感に呆れかえっているので、技術評論社もやるのか、いや技術評論社はまだ誇りを捨てていないはず(願望)と思い、その確認をせにゃならんと本書を手に取りました。

 

全体の感想

技術評論社は誇りを捨てていなかった。すいません、良い本でした。

私の中では本書のタイトルと、まえがきに記述してある「本書の方法で仕様変更ゼロを2回実現した実績のある方法」という文言が気になっていて、2回だけかよ、それたまたまだろと思っていました。しかし本書全体を読むと著者が如何に「プロジェクトを成功させるために本気で考えて仕事をしているか」が伝わって来て、地に足を付けたホンモノのエンジニアであると思いました。

書いてある内容は泥臭い内容が多いです。本当に必要なこと、不要なことを著者が自分の頭で考えて、それを実践して得られた最終的な上澄みのノウハウが凝縮された本です。本書はあくまで業務システム開発を対象にしているので、業務システム開発プロジェクトのアプリ設計、調整役としてのSEが主な対象です。しかしながらITにおける開発の本質部分を突いていると感じましたので、インフラ屋やWEB屋の方が読んでも得るものは多いと思います。また技術系の本では無いため、IT業界への就職を考えている学生にもオススメです。

 

個別にビビッときたところ

「コレ来た」と思ったところを紹介します。引用部は間を省略していることもありますが、基本的に全て本書からです。

 

顧客はコンピュータやプログラミングというものの実態をイメージのしようも無い状態ですから、目に見える開発側担当者の言動や出来上がった画面の動きそのものから受ける印象でのみ、物事を判断することになると思います。

ここでは、顧客はプログラムの実態がわからない → 不安になる → 目に見える物でプロジェクトの状態を判断するしかない → 目に見える物がちょっと違うので修正を依頼する → 出来ないとか間に合わないと言われる → 更に不安になる → 開発担当を信じられなくなる、というコミュニケーション上の問題に対して言及しているところです。見える物をさっさと出すのが宜しい、という著者の考えには賛成です。ただ見える物を出すと、顧客側の決断できない承認者にプロジェクトを止められるリスクがあるので、判断が難しいところではありますね。

 

マネジメントを本当の意味で成功させるには、PMよりも上位の管理者から経営者までの人たちは、「成果物を作る」直接的な技術について、長期間にわたって実際に体験していて、実務として行える程度に詳しく理解していることが必要です。

これは正しいと思いますが、現実的には難しいケースがある。SIerに勤めていると、会社レベルの力学が働いて、どうしようもない人間が管理職に収まることが多い。私の上司で3つほど役職が高い人は、某銀行の開発プロジェクト上がりですが、アプリ保守をずっと続けていた人で、インフラやWEBはド素人です。そんな人間が上位の管理職をやっていて、口出ししてくるわけです。私はインフラ屋ですが、何もわからない顧客にシステムの説明をするのと同じくらい疲れる。そしてその割にアドバイスがあるわけでもなし、トラブってもその上司は頭を下げてくれるわけでもなし、結局は無駄な社内儀式に成り下がっているわけです。

 

プロジェクトのスタート時に、目安となるスケジュールを作成していると思いますが、そのスケジュールにはスケジュールの最適化を行うタイミングをスケジュールしておきます。(中略)当初から提示していたスケジュールで進められそうであれば、それはそれで問題ありません。(中略)スタート時のスケジュールにはいろいろと前提としている事柄があるはずです。

これすごい大事。頭の固い顧客にあたると、「営業提案時のスケジュールと違うやないか!正式な説明を求む」って話になることがあるんですよ。「リリース日は動かしてねーんだからいーだろ、つーか何か困るわけ?」というのがこちらの思い。実際は困る事も無く、お客さんは不安になってるだけなので、ビシッと筋の通った説明をすれば理解してもらえますけど、ぶっちゃけ超面倒なので最初のスケジュール提示時に作業環境や制約条件によって別途スケジュール調整しますと話しておくのがベストだと思います。大日程の提示時に隅っこに小さく書いているレベルではだめです。スケジュール表上にプロットしておくくらいが正解と思う。

  

筆者は「要求は徹底的に話してもらう」ようにしてきました。夢のようなことまで全部話してもらって議事録に記録します。要するに抑えよう抑えようとするから、後からちょっとずつ出てきて、仕様変更になるのです。

これも筆者の書いている通りだと思います。私の少ない経験からでも、徹底的に要件を話し合ってから現実的な話で合意できると、後から揉めるパターンは少ないです。お客さん側でも次フェーズの予算確保に動きやすくなるので、皆ハッピーになりますね。また徹底的に拘って要求を聞いていくと、お客さんからの信頼も得られます。そうなると、「あ、この人が無理って言うなら無理なんだな」と思ってもらえる関係性を構築できます。

 

よくありがちな、「だいたいの業務分析を行って、要求定義をそこそこのドキュメントの積み上げで済ませ、次は設計で、開発。設計でもいろいろと新事実が出てくるし、開発して形になってからもいろいろと加えなければならない事が出てくるが、それは当然の事」という考え方は不十分です。「マネジメントの怠慢」「上流工程そのものを理解していない」といえます。

あぁ、その通りだとも思うし、耳も痛い。私は小規模案件でマネジメントやることがありますが、このパターン多いです。やっぱり本書にある通り徹底的に要件ヒアリングをするのが一番いいんだろうなぁ。なぜ出来ないのだろうか?たぶん上流工程のスキルが足りていないのだろうと思います。研修言っても教科書的なことしか教わらないし。あと気持ちの問題(色々な人たち、ごめんなさい)。

 

(SEが)プログラマーより楽をしていていいわけはありません。しかも、ただ大変ならいいわけでもありません。

これも同感&耳痛です。当たり前の話なんですよね。調整役の只のSEモドキといっても外注会社の社員より高い単価であるのは明白だし、給料だって自分の方が高いだろうし、なのに楽しているとか最悪です。IT業界というか産業界全体なのだろうと思いますが、純粋な開発力で単価が決まるわけではなく、会社の格で単価が決まるのは労働者の意欲を削ぐ歪んだ慣行だと思います。もちろん会社の格が高ければ、そこで働く人や組織への信用度が違うのはわかりますが、客の御用聞きYesマンSEが開発者より高単価であることはおかしいと思います。

 

たとえば、急遽開催されることになった会議があったとします。(中略)少なくとも1日から1日半ぐらいは、間違いなく会議のための「それらしく見える資料作り」に費やされることになります。

わかる!これは開発者側の立場で書きますが、顧客との間に中抜き企業のSEモドキがいると、ひどいもんになります。実態がわかっていないのに、顧客に怒られたからという理由で、末端の作業者に報告資料を作らせるやつです。害悪ですね。

 

当初、「簡単なシステムですよ」とか「こんなかんじです」と、お客さんや関係者から言われることがあります。実際にはあまり正確でない場合も多く、それを後でどうこういったところで始まらないということになります。「自分が作るからには、自分が知らなければならない」ということさえ頭にあれば、かなり多くの問題が回避できると思います。

そう、本当にその通りだと思う。小規模チームだと早い段階でこの考えに慣れることができます。「自分でやらないといけない。自分が理解しないといけない」と思うと、会議やプロジェクト進行に対する姿勢が変わります。会議中なんかは頭をフル回転させて、自分のタスクを整理したり、全体の矛盾点が無いかを考えるようになる。自分で言うのは何ですが、そうやって「自分でやらなければいけない」状況になった時が自分的に一皮剥けた時期だったなと思います。逆に大規模チームの一人という立場にあって指示は自社の上司という若人は、注意した方がいい。

 

多くの場合、上流工程で問題は発生しているが、ここに関わっている人々は、それによって直接の影響をあまり受けない。問題に直接影響を受けたり、とくには変更管理的な対処までを行うのは、主としてプログラマーである。したがって原因を作り出したところには、具体的な苦痛は無い場合が多い。

これは本書を読む中で、一番グサっときた文章でした。
中抜き企業のSEモドキはこれが一番わかってない。SEモドキはお客さんに対してYesマンで、開発者に対しては「やっとけ」「何とかしろ」という立ち位置を取る人間が多い。SE側も開発側と同じレベルの品質で上流工程をやる覚悟を持つことが必要だと感じます開発側のバグや不具合と、SE側の仕様不備は同じレベルの罪であると認識すべき。

  

(PMの安易な兼務はダメです。なぜなら)他のどのステークホルダーよりもプロジェクトを知らない状況に陥ったり、スケジュール調整がうまくできないことなどで顰蹙を買ってしまい、交渉前から最も弱い立場になったりしてしまうなど、不必要なトラブルのオンパレードになってしまいがちです。

周りからは「あの人は(優秀なので)忙しい人なのよね」「兼務しているからしょうがない」という雰囲気になりがちですが、ダメですね。結局はPMの配下にいるメンバーにしわ寄せが行ってしまうので、自分がいるプロジェクトのPMがロクにマネジメント出来ないなら声をあげるべきなんだと。ただ問題が発生する前に、「このプロジェクトのPMに兼務させんな」と下っ端から言うのは難しい。またPMを任命したのはそのPMより偉い人です。上で書いたことと似たようなことを書きますが、PMを兼任させた人は、PMが兼任することで現場に発生する負荷を全く負わない形になっています。下の痛みを知れよ。

 

上場企業レベルの担当SEやPMは実質は、「直接ソフトウェアを作るプロジェクトチームのプロジェクトマネージャ」ではなくて、あくまで技術営業兼関連部署調整役、下請け外注先調整役であって、「本質的にソフトウェアを作るという意味で、技術者としての経験をすることはない(場合によっては生涯ない)」(以下略)

耳痛(激痛により昇天)

 

プロジェクト目標の決定

「顧客の得たい利益は何かを定義する」

「××システムの構築」は目標ではない。顧客は「システムが欲しい」わけではなくて、「システムが稼働し続けることによって得られるであろう利益そのものが欲しい」わけです。

これは小規模な特攻隊で動いていると、よくわかる話です。小さい会社の案件なんかだと経営者が乗り出してくることが多いです。そこで話をしていると、正に経営者のマインドというのは、「如何にしてシステムで利益を出すか」に集中していて、考え直させられることがよくあります。UXの考え方に似ているかもしれないですね。と思っていたらCustomer eXperience、CXという考え方が存在する模様。

 

(会議の場でいつも否定的な意見を述べる人は)一度どこかでケチをつけておけば、「トラブルを避けるための活動を何かしら行った」「自分は警告した」というアリバイ作りになる、というわけです。このようなタイプの人には意見を求めずに、決まった活動だけおこなってもらうようにすることで、他のメンバーのモチベーション低下を引き起こさないようにする必要があります。

それなりの規模のプロジェクトだとどこにでも保身に走る輩がいるものです。そして1人が保身に動くと、囚人のジレンマの如く(違うか?)周りも動かざるを得なくなり、プロジェクトチームが機能不全となるケースがあります。また保身のための発言が出ると会議が冷えるんですね。警告を発した事実と余計な発言をしない姿勢から、どんどん会議が冷えていく。結果として、参加者が「如何にして問題を解決するか」ではなく「如何にして責任を負わないようにするか」に向いてしまう。当然、問題は解決しない。

 

あるプロジェクトの元請けは、何となくそれっぽいことを言ったり、檄を飛ばしたりしていますが、どうも中身がなく、いざ決めようとしても、どこか逃げている感じがしました。(中略)そして何かにつけ「それは顧客には言えない」とか「もう言ってしまった」などと、何とかして交渉自体を行わないで済ませようとする意見を口にするというのも、その会社の社員全般に共通していました。(こういうのは会社のクセみたいなものだから気を付けようという話)

同意&耳痛。「それは顧客には言えない」「もう言ってしまった」私が経験したシステム開発プロジェクトでは良く聞いたセリフです。

「もう言ってしまった」→「じゃあ訂正してよ」→「やだ、何で俺が。お前が自分で言えよ」→「それを言うのがSEの仕事だろ」

こんなやり取り。自分でも気づいていない、自社の常識(世間の非常識)に毒されているであろう事実を認め、改善していく清き心を持ち続けることが大事なのだと思う。(自信は無い)

 

(ソフトウェア開発の失敗パターンは根源的な理由は同じ。出来ないものを引き受けて失敗していたということ。)ソフトウェア開発という、作るもの自体が見えにくい物であることによって、「できない根拠」が示せなかったらです。

そうなんですよ、馬鹿な奴は「出来ない根拠が示せない」=「出来る」と考えてしまうんですよね。根拠の示せない”何か”が存在する可能性を考慮できないんですよ。そしてそれが単純に馬鹿なやつがいつもそう考えるというならまだ対策は可能なんですね。しかしこの話、そんな馬鹿な奴ではなくとも、予算未達の営業がやりがちだからタチが悪い。そういう0/1に単純化した思考で、受注を目指すか、撤退するかを考えるものだから、ピンチな時は細かな事は考えずに営業が自分を正当化する武器として、「出来ない根拠が示せないなら出来るってことだよな。うん大丈夫」となって多くの歩兵が昇天していく。

 

 

まとめ・おわりに

超簡単にまとめると本書で著者が書いていることは以下に凝縮される(と思う)。

・要件定義は徹底的に

・PMやSEはちゃんと計画を立てろ

 

本書は二部構成を取っており、元は別の書籍であったものを合体させて1冊にまとめたようですが、一部と二部の繋がりは意識して書き直されているようで、特に違和感なく最後まで読み切れました。ただ第二部のところで記載内容が不明瞭に感じる部分もあり、第一部のクオリティから見ると、若干ですがクオリティが落ちていると感じました。

 

とは言っても、第一部の内容は国内SIerに勤めるリーマンSEなら必読の内容だと感じました。またSIerだけではなく、WEB屋さんやイラスト・コンテンツ屋さんのような企業に勤める人、就活中の学生、マネジメント層にもぜひ読んでほしいなと思う内容でした。

 

日本のIT業界で働くIT戦士が書いた本となると、妙に外国かぶれをしている人だったり、実現性の無い施策を唱える人だったりで、「は?で?」と思うことが多いのですが、本書は珍しく当たりの本でした。

 

気になる方は是非ご一読くださいませ。

 

以上

 

若手の離職を防止するための3つの考え方

新聞の読者寄稿欄にすごくいいことが書いてあったので備忘のため自分の考えと合わせて整理しておく。

 

www.nikkei.com

日経の記事は無料登録すると月10記事まで無料で読めるので、全文読みたい方は登録して読んでみてください。

寄稿者はNPO法人老いの工学研究所理事長の人。

 

記事概要

新入社員の早期離職が止まらない。企業側も対策として、メンター制度や配属前研修、人事部面談といったことを実施してきた。それでも早期離職が減らないのはいずれも小手先の対策に過ぎないためだ。

 

企業がとるべき姿勢は以下の三点である。

①脱・標準化主義

仕事において型は大切だが、自分の若かった時の「あるべき新人像」と比較して修正を迫るのはだめ。新人は萎縮と遠慮の日々だから辞めたくなって当然。

②脱・形式主義

目的があいまいな儀礼・慣習、意味の薄い会議やルール、価値の低い業務などに巻き込むべきでない。これらを通じて成長や貢献は実感できない。

③脱・修行主義

反復行動を強いる修行のような働かせ方は若手を放置するのと一緒。心身鍛錬のために入社するのではない。仕事の意義を説き、夢を語り、フィードバックを欠かさないようにすべきだ。

 

考察・感想

①脱・標準化主義

仕事において型は大切だが、自分の若かった時の「あるべき新人像」と比較して修正を迫るのはだめ。新人は萎縮と遠慮の日々だから辞めたくなって当然。

これは結構難しい問題だと思う。自分の若かった時の「あるべき新人像」が正しい場合もあるからですね。ただ会社や先輩側が唯一無二の正しい新人像が存在すると考えていて、自分の思う新人像が絶対的に正しいと考えている場合はやっぱり間違いなんだと思います。

新人は新人で自分と違う人生を歩んできていて、違うことを学んできているわけです。社会人としてのキャリアが無い分、これから洗練されていく部分はありますが、新人側が思う正しい新人像”も”正解である場合があると思います。

そうなると安易に否定して修正を迫るのはダメですね。ちゃんと話をして考えの根源にあるのは何なのか、先輩の考えの元になっている部分と何が違うのか、これを明らかにすることが大事です。きちんと意思疎通できれば、ただスタートとなる場所が違うだけで考え方自体は正しいということもある。そうなれば新人に対して、会社や先輩がどういう考えを元に「あるべき新人像」を求めているか理解してもらうことができる。ちゃんと話をして相互理解することが大事です。

 

ただそのような話をする中で、会社や先輩側は自分が圧倒的に強い立場にいることを理解していなくてはいけないと思う。異論を唱える新人をイジメる気は無くても、新人は「(イジメられるかもしれない)」と考えてしまう可能性がある。

強い立場の人間が、自分の強さを理解せずに考えを押し付けると、組織としては結局のところ損をしてしまうと思う。短期的には自分の思う通りに人を動かせるが、長期的に見た場合、「あの人の意見に反対しても(職位的な)パワーで押し通されるだけだから反論しても無駄。言うだけ気分が悪くなる。」と考える人が増えてしまい、チームとして能力を発揮できなくなる。本来はチームで議論をすれば人数分の正しさ(品質や洗練さ)が得られるはずが、こういう人がいると誰も反論しないため、チームで議論したはずなのにアウトプットは1人分の品質しか得られないという状況になる。

更に具合の悪い事に、新人はとても不安定な生き物だから先輩からの影響を受けやすい。「学生と社会人は違う」「学生気分が抜けてない」「社会に出ることは大変なんだ」こういう事を吹聴する人が多いので、多くの学生は社会というのは自分たちが今まで住んでいたところとは全く違う恐ろしい世界と考えがち。そんな魔界みたいな場所で経験値も積んでなく、戦うための武器(スキル)もない、周りにいる先輩が味方なのか敵なのか判別する術も持たない状態で職場に来ているわけだ。自信過剰な馬鹿と極めて優秀な人間以外は、目の前にいる先輩に服従する姿勢を見せることが最も利のある選択となってしまう。

元記事にある通り、新人は配属後に萎縮と遠慮の日々を送っている。我々先輩エンジニアも1人で客先常駐するのは避けたいと考える人が多いと思う。知り合いが1人もいない現場に送られた時は、それこそ新人と同じく萎縮と遠慮の日々を送ることになる。先輩エンジニアの場合、何らかの具体的なスキルを期待されて送り出されることが多いため、専門家として大事にされることもあるが、新人はそうはいかない。期待されているレベルも分からない、社会という魔界の常識もわからない、そんな状態で自分の意見を問答無用で否定される日々を送っていたら、それは辞めたくなって当然だ。

 

②脱・形式主義

目的があいまいな儀礼・慣習、意味の薄い会議やルール、価値の低い業務などに巻き込むべきでない。これらを通じて成長や貢献は実感できない。

曖昧な儀礼・慣習・ルール、意味の薄い会議のところは概ね同意です。曖昧なルールは新人にとって、近づきがたい存在になります。大丈夫だろうと思ったところが実は踏んではいけないところだったという話はよくあります。社会人としてエンジニアとして当然大丈夫だろうという前提で作られたルールは新人にとって理解できないことが多い。

こういった曖昧な環境で育ったエンジニアは、先輩と同じく曖昧なルールを好むエンジニアになりやすい。特に若い時に同じシステム開発現場で3年も5年もいて、そのシステムが名のある企業のシステムだったり、一次請け企業が名のある企業である場合、「一流企業に認められている正しいやり方」と勘違いしてしまう痛いエンジニアが結構いる。色んな開発現場を見ていると、どのシステムにも癖(独自の考え方やトラブル回避で行った暫定策)があって、その特殊性を理解している開発現場の人たちはちゃんとしている人が多い。途中で人員追加となっても、「これはちょっと変ですが、これがここの特殊なルールです」と説明できる。

勘違いエンジニアは自分たちの現場が特殊性を持っているということを理解できていないため、特殊(普通ではない)ではなく、素晴らしいスペシャルな方法であると思っている。そしてそこに入ってずっといる若手エンジニアはいつの間にか、先輩と同じ考え方で、素晴らしいスペシャルな方法で運用されているシステムであると思い込む。当然一時的な人員追加が発生しても、自分たちが特殊だと認識していないから、相手の共通理解を得ることができない。そしてその特殊性を理解していないと、その場における正しい判断を導き出せないため、外部から入った人間は世間一般のルールをベースに考えて地雷を踏む。

 

少し話が逸れた部分もありますが、曖昧なルールはトラブル発生の元になるし、中途半端なルールは人材育成にも大きな影響があるのは確かです。何よりそこに新たに配属された人間には非常に強いストレスがかかることを受け入れ側は考えないといけないんだと思います。会社に勤めているとたまに自分たちの組織はこれからどうあるべきか、なんて話になることがあります。そんな時には「今のメンバーで上手くいってるから」ではなくて、新人も含めた第三者が入ってきた時に困らないかという観点で曖昧性の排除を考えるのもいいなと思いました。

 

③脱・修行主義

反復行動を強いる修行のような働かせ方は若手を放置するのと一緒。心身鍛錬のために入社するのではない。仕事の意義を説き、夢を語り、フィードバックを欠かさないようにすべきだ。

これも完全同意です。上述した通り、新人から見ると会社や社会というのは魔界みたいなものですから、修行のようなことをさせていると、離職するか、そういう場所なのだと勘違いしてしまう。なぜその作業が必要かを説明して、アウトプットに対しては作業時間や品質、方法アプローチに対して適切だったかを返してやらないといけない。適切だったと言ってあげれば新人は安心し、自信を持つきっかけにもなる。何も言わなければ「とりあえずダメでは、、、無い?それとも文句言う気も出ないほど社会人としてレベル低いのかしら。。。」と考え不安を感じてしまう。

 

私が新人で初めて現場配属された時が正にそうだった。数年分に及ぶ大量のログファイルを渡されて、集計方法だけ教えられやっとけと言われた。これが何の役に立つかわからない上に、膨大な単純作業だった。

この作業の目的は何でしょうか?と聞くと、偉そうなこと聞くなお前、とにかくやればいいんだよと。

スクリプト書いて自動化していいですか?と聞くと、手作業でやれと。

何で手作業でやるんですか?と聞くと、スクリプトが正しいと証明できるのか、と。

スクリプトを見てくれて、テストすれば正しいと考えることが出来るのでは、と言えば、それは証明ではない、お前は理系なんだから証明の意味くらいわかるだろと。

確かに証明ではないが、そもそもプログラムが正しいことを絶対的に証明することは出来るのだろうかと疑問に思った(その後プログラムに対して正しさの証明など無いことを知った。だからテストがあるんだろう)。そのクソ先輩はどうやら手作業でやる以外の選択を受け入れるつもりは無さそうだし、既に半分キレている状態だった。私にとって社会人になって最初の仕事だったもので、素直に従うことにした。クソ先輩の説明には納得できなかったが、現場において圧倒的弱者である新人の私が宣戦布告しても利益は無い。

そしてもちろんフィードバックは無かった。最終アウトプットを先輩に送り、説明しようとしたが、「あぁ、見とく。次は〇〇さんに指示を仰げ」と。結局私は何のために作業をしていたのか、そして期待通りに作業が出来ていたのか、何もわからず不安と不満だけを積み上げた。

 

これは作業の意義も説明しないし、大して役にも立たない情報を手作業で集計させるという典型的な修行作業だったと思う。

私も普通の人間なので新人の頃は、社会に出てやっていけるかという不安と、会社や社会に貢献したいと思う気持ちも持っていた。しかし指示された作業は何でやるのか分からないものだった。仕事をするってのはこういうことなのか、それとも自分が期待しすぎていたのか。

今思うと、あのクソ先輩のやり方は間違っていると思える。しかし自分が期待しすぎていた部分もあると思う。私が先輩方を社会と言う魔界の住人と思う一方で、先輩方も私のことをスライムレベルなのか、バブルスライムくらいの尖った能力を持つのかわからなかったのだと思う。とは言っても、新卒新入社員が入ってきた時にどちらが歩み寄って、どちらが気を使うかと言ったら、それは受け入れ側の義務であると思う。

 

私の話が長くなってしまったが、やはり新人の離職防止や育成のことを考えると、早くから配属先で意味のある仕事(難易度は関係ない)を任して、居場所を作ってあげることが重要だと思う。そして十分にコミュニケーションをとって、その仕事がどんな意味を持つのか、誰にどんな風に役立つのか、アウトプットは期待通りか話をすることが重要だと思う。

 

おわりに

このエントリの元記事に目が留まったのは、「老いの工学研究所」なんて如何にも(頭が)堅そうな組織の長がどんな事を書くのか、どうせ見当違いのこと書いてるんだろうなと思ったからです。

しかし実際に読んでみると、書いてあることはむしろ若者に寄り添ったものであり、かつての世代でやられていた無駄な精神修行への批判的な内容だったので驚いた。そして落ち着いて考えてみると短いコラムではあるものの、企業側がとるべき姿勢について簡潔にまとめられていて、何らかの形でクリップしておきたいと考えてこのエントリを書きました。

短いコラムを読んで自分の考えをダラダラ書いただけですが、良い本を一冊読めた時の満足感に近いものが得られました。日経は無料で本文読めるので、全文が気になる方は是非。

 

おわり

大学新入試-プログラミング試験検討

興味深いニュースがあったので、概要と考察です。 長いです。

 

 

 

www.nikkei.com

www.nikkei.com

記事中にある未来投資会議はここ

https://www.kantei.go.jp/jp/singi/keizaisaisei/miraitoshikaigi/

 

ニュースの概要

政府は大学入試センター試験に変わって導入される「大学入学共通テスト」の科目にプログラミングや統計などの情報科目の導入を検討する。ビッグデータ人工知能活用の必要性が高まる中、文系・理系を問わず素養を身に着けさせIT人材育成につなげる。

17日の未来投資会議で議論に着手する。

プログラミングについては、高校では22年度から共通必履修科目に「情報Ⅰ」を新設し、すべての学生が学ぶことが決まっている。そして情報Ⅰを学んだ学生が受験する24年度の新テストから情報科目を導入する計画。試験はCBT形式による実施を視野に入れる。

背景にはデータサイエンティストなどのIT人材不足がある。IT人材は15年時点で17万人が不足しており、30年には需要がさらに拡大し、最大で79万人不足する見込み。日本では統計学専攻などの大卒者は年間4,000人、米国の25,000人と比べ少ない。

 

考察

プログラミング

何をやるか?

プログラミングの教育、そして大学入試・大学教育へつなげるということを考えた場合、一番重要なのはどの言語をやるかだと思います。ビジネスの現場ではどの言語を使うかは最も大事な要素ではないと思います。何を使うかというよりどう実現するか。そしてその先に現実的に実現できる言語は何か?という話になる。本質的には学校教育の場でも同じです。プログラミングの基本的な考え方を身に着けて、状況によって必要な言語を選択することが最も効率がよく、本質を突いていると思います。

しかし授業や入試で取り扱っていくことを考えると、以下の要件を満たす必要があり、どの言語で学ばせるかは非常に重要な要素となると思う。

①プログラミングやコンピュータの本質を学べる
②言語仕様に変更がかかりづらい
③権利的な問題が発生しない 

 

私はインフラ屋、セキュリティ屋なのでアプリは専門外ですが、C言語になるんでしょうかw

少なくとも①を突き詰めるとCだと思います。

②はある程度歴史を重ねてきたものならOKだけど、Pythonを例に見ると、1.0系が94年にリリース、2.0系が2000年リリース、3.0系が2008年にリリースされています。1.0のリリースから14年が経過した後にリリースされた3.0系ではそれまでの2.0系と仕様に大きな違いがある。

③はアカデミック教育とはいえ、一企業が権利を握っている言語は使えない。「来年から教育目的での使用を有料化することにした」という話になると大きな混乱が発生するから。Java

 

やっぱりCなんじゃないの。

共通試験でCやらせるなんて草、と思ったんですがよく考えると私は数学のベクトル問題や物理の電磁誘導とか大学行っても全然使わなかった内容が普通に入試では問われていました。旧来の大学入学試験におけるポリシーを維持するなら、学問的に基礎を為す知識としてC言語で出題されても違和感はないような気がします。

ただ今回の共通試験導入の目的は時代に合わせて変えるということなので、それを考えると色んなライブラリが公開されていて簡単に高度なことが出来る軽量言語である方が目的に適っているとも思えます。

情報工学の基礎を身に着けた人間を育成したいならC、コンピュータって楽しいんだよならHTML、簡単に高度な計算もできるよと理解した人間を育成したいなら軽量言語の選択になると思います。小学生はHTML、中学生で軽量言語、高校と大学入試でCってのが妥当な感じでしょうか。

 

しかしどうなんだろう、CにしろHTMLにしろ軽量言語にしろ、座学で学ぶより実機で書いて動かす方が遥かに効率的に学習できると思うんですよ。じゃあ自由に使えるPC持ってない学生は非効率な勉強を強いられるのかという話もこれから出てくるんじゃないでしょうか。義務教育なんだから国がPC支給しろよという主張も出てくると思う。貧困の連鎖という問題を考えると確かにそう。貧困世帯は机上デバッグしなさいってのは乱暴ですし。結局は、税金でPC配るか、PCルームを作って開放するか、はたまたPCの保持に関係ない授業内容になるか。特に大学入試にあたっては家でも勉強できるというのは非常に有利に映るはずです。また自治体によっては学校へPCを十分に準備できないところもあるはずで、そのあたりの格差が発生しないような環境を準備しなければならないのは結構大変だと思います。 

 

どう変わる?何が変わる? 

ここまでダラダラと考えを書いてきましたが、CでもRubyでもJavaでも何でもいいですが、プログラミングが新試験に導入されたとして、世の中どう変わるか、妄想してみました。

  • プログラミング塾が人気になる
  • Web屋さんが塾運営を始める
  • エンジニアを引退してプログラム講師や家庭教師に転身する人が出てくる
  • 廉価で軽いPCや、Webサイトフィルタソフト界隈が少し盛り上がる

 

新試験でどのような問題が出題されるかわかりませんが、教育に力を入れる親は早くからプログラミングを学ばせる場に子供を入れたくなるんじゃないですかね。特に新試験が始まって数回は出題予想も難しいですから、画一的な対策を講じにくいわけです。そうなるともう基礎力を高めるしか対策はありません。基礎力を高めるのに必要なのは根気と時間です。これを短期間でやろうとすると負担が大きいですから小さいころからコンピュータって楽しいんだよってことを刷り込んで、自発的にPCを触るような教育環境を作らなくてはいけない。

2022年に高校で授業が開始するなら、4年後なので今の小学生世代が対象ですかね。小学生向けの楽しいプログラミング塾が本格的にビジネス化していきそうです。

多分最初は塾運営のノウハウを持つ学習塾業界やITに特化した新興IT塾が盛り上がりをみせて、その後フリーランスエンジニアがその周りで低価格とか家庭教師みたいな形でやり始める。出遅れた大手Web屋が最後にブランド力を前面に出して動き出す。塾業界や大手と戦うのが嫌になったフリーランスエンジニアが動画サイトで講義動画を公開して広告費目当てでお金を払わない層を囲む。

 

オフラインで対面授業をウリにする学習塾業界、完全特化型の新興IT塾、ブランド力で高品質なWeb講義やスカイプ講義をウリにするWeb屋、Youtubeで講義動画をブロードキャストするフリーエンジニアの4軸による戦いが始まる。(はず!)

 

中学の技術・家庭科のモノづくりは楽しかった

ここで話を戻して学校教育現場での話です。

元記事によると、中学校の「技術・家庭科」の授業を拡充するという記載がある。拡充する分が純粋な授業時間の増加に繋がるならいいと思うんですが、これによって他の授業が割を食う形になるのはあまり良くないと思います。

私が中学校の頃も技術・家庭科という授業がありましたが、その授業では木工の作業やセンサーをハンダでくっつけてという簡単な電子回路の工作をやっていました。純粋にこの授業は楽しかったし、色んな工具の使い方を学べる義務教育にあるべき授業だったと今振り返ると思います。

時代の流れで将来ハンダを使う人と、コンピュータを使う人どちらが多いかと言えば後者であることは間違いないですが、あのような授業が無くなってしまうのは宜しくないと思います。(私の好みであることは認める)

 

他の授業を削るほど重要か

現行実施されている他科目の授業時間を削るほど重要かと考えるとこれが結構難しい。

将来役立つかという観点で考えると、国語算数英語並みかそれ以上に役立つスキルになると思います。国としてどういう人材を増やしたいかと言うと、もっと理系人材を増やしたいだろうから理科系科目も重要。音楽や図工などの芸術系や道徳系の授業はと言うと、それこそ義務教育でやるべき科目。

私は総学習時間が増えても他科目を削らずに情報系科目の授業をやるのがいいと思います。教育現場では色々とあるんでしょうけど、私は(安易に)そう思います。

どうやって情報系科目の授業時間を作り出すかは興味深いところです。

 

高校の授業で採用されるのが2022年度からで、24年度から新試験が始まって、大学に4年通った学生が社会に出てくるのが、2029年です。その先は段階的に中学から情報教育を学んだ世代、小学校から学んだ世代が順に社会人となるわけです。まだ10年20年先ですが、私はそのころまだまだ現役世代なので、その新人類と一緒に仕事をすることもあるでしょう。

きっとジェネレーションギャップを感じるんだろうなぁ、最近の若者はとか言うんだろうなぁ、裏で老害扱いされるんだろうなぁ。

 

統計

元記事には統計も情報科目の一部となることが記載されている。これについても思う所を書いていく。

目的、目標

最終的な目標はデータサイエンティストの育成にあるんでしょうが、高校生まででやれる内容はせいぜい平均値・中央値や分散、標準偏差といった基礎的な統計量と、行っても検定、回帰分析くらいが限界のはずです。

一般的なビジネスパーソンとして上記の知識があれば、大体こと足りるはずです。それ以上の知識が必要であれば、それはもう専門家に投げればよろしい。平均値や中央値の計算、グラフ化、それらの解釈が出来なくてビジネス案件を取り逃すレベルではグローバルな世界では戦えないので、そのレベルは最低限わかってくれということだと思います。

結局のところ基礎は数学

上述の統計量や検定、回帰分析、そして更に複雑な統計分析はその基礎に数学があります。回帰分析までは高校数学でやれると思いますが、その先は大分苦しくなる。ぶっちゃけ大学数学を学んだはずの私でも統計分析や経済学のモデル分析はきつかった。(ちなみに私は学生時代に統計学を履修していました。マクロ・ミクロ経済も。)

データサイエンティストは不足するのか

元記事ではデータサイエンティストなどのIT人材不足が危惧されています。IT人材の不足は確かにそうかもしれませんが、データサイエンティストが不足するとは正直思えません。現状は世の中でうまく噛み合っていない感じは確かにあります。

 

統計学周りにいる非情報系人材はRやSPSSなどをツール・ソフトウェアとして使っていて、IT自体に強い関心がある人は少ないです。(私調べ)

情報系人材はデータサイエンスがカネになることは大方わかっていますが、統計学をちゃんと学ぶのはやりたくない。

 

ここに壁があるように感じます。この統計屋と情報屋の壁を乗り越える根性がある人や、適正のある人が現在データサイエンティストを名乗っているというのが現状だと思います。乗り越えがたい壁があって、イマイチ人材が増えない。

 

ただいつまでもこの壁に阻まれて進めないってことは無いでしょう。世界中の専門家や技術者が知恵を絞ってこの壁を低くする努力や壊す努力をしていくことになるでしょう。純粋なデータサイエンティスト育成による純増に加え、両分野の一部の人たちが互いの分野に入り込むことで一気に対応人材が増えていく時期が来ると思います。

 

たぶん将来的には「統計学の習得が大変?大丈夫、データサイエンスシステムがあればね。」となると思います。その時データサイエンティストはどうなるか。他の職人的な分野と同等で極めて優秀な人や同じ組織でずっとやってきた人だけが残る世界になるものと私は考えています。

情報屋の観点で言うと、大規模でミッションクリティカルなシステムのアーキテクトが出来る人みたいな立ち位置になるのではないでしょうか。一応みんなそれなりに頑張ってレベルを上げようとするが、良い経験を積める案件は結局昔からやってる一流の人がやってしまって一流と二流の間の溝が深いといったそんな状態。

 

今後10年くらいは足りない足りない言われると思いますが、その後は一流しか残れない世界になると思うので、データサイエンティスト一本でやっていこうと思うと、汎用性をある程度切り捨てた特化型の人材を目指していく必要があると思います。そして特化型人材はハマらないと他へのツブシが効かないので人生苦労すると。(まぁ世の中の特化型人材はみんなそういう状況で頑張っているので、そういう人と同じですが)

 

おわりに

学生時代に統計学を使って研究していて、社会人になってからはITエンジニアとして、ビジネスパーソンとして働く私にはドンピシャテーマだったので、書きたいだけ書きました。冗長になった部分や妄言もありますが、大きく外した内容は書いていないはずです。

私は30代半ばにして未だに子供心を忘れていない、というかまぁ子供みたいな考え方で50代60代の守りに入った世代を嫌悪している部分があります。しかし、20年後には全然違う教育を受けた世代と一緒に仕事をして、自分も嫌悪される存在になったり、老害扱いされるんだろうなぁと考えると、やっぱり今を頑張って生きるしかないなと決意を新たにしました。きれいに結べました。

 

おわり