「きしだのはてなのあれってどうなの勉強会」やってきました

24日の土曜日に、「きしだのはてなのあれってどうなの勉強会」やってきました。
【東京】きしだのはてな勉強会 〜「きしだのはてな」のあれってどうなの〜 - 日本Javaユーザーグループ | Doorkeeper


んで、あいかわらずその場にいないと意味がわからない資料ができあがりました。


運営のmegascusさんは

思ったよりもきしださんの人気が薄かったのか人が集まりませんでした。
【東京】きしだのはてな勉強会 〜「きしだのはてな」のあれってどうなの〜をやってきた - 水まんじゅう

とは書いてますが、内容もなにか具体的にわからない、参加費3000円、そしてPlay勉強会とかぶる(時間的にはかぶってなかったようだけど)という中で21人集まってもらえたのは、なかなかありがたいことだなーと思いました。
運営のmegascusさんと岡澤さん、おつかれさまでした。


参加者視点での内容や様子については、susumuisさんのまとめで。
「きしだのはてなのあれってどうなの勉強会」 #kiskai に参加してきました - susumuis Info


ここでは、しゃべった視点で内容について補足もまじえつつおおまかに説明しておきます。


まずは買ってきたビールの紹介をしました。
今回は、コンビニでどこでも買えるようなビールとしてはリクエストのあったプレモルと、一番絞り・ヱビスが数本ずつあっただけで、あとは店を選ばないと買えない・飲めないビールをなるべく選びました。米やコーンスターチの入ったビールはなかったはず。なので、アメリカやアジアのビールは買ってません。
ということで買ってきたのは大きくわけて地ビール、ドイツビール、ベルギービールです。シメイ青のでかい瓶は、購入満足感高いです。買うだけで楽しいです。もちろん飲んでもおいしかったです。
ビールじゃないものもちょっと混じってます。


んで、乾杯をしてメインコンテンツが終わったので、あとは余興。
まずは、プログラマとしてメシを食う分野を大別します。
ここで、組込みとの間には特別な背景がある人以外は人材の異動がないので、話から省いています。あと、ユーザー企業の場合もひとまとめで話す内容ではなく、ここでは省きます。
なので、ここではSIer的かサービス的かという大きく2つに分類して話を進めます。もちろん、その混合や中間的な企業・組織、開発チームも多いと思います。話を簡単にするために分類していると思ってください。


2013年の産業経済省IT人材白書の概要(PDF)では、SIerからユーザー企業、サービス系企業に人材が流れているという図がありました。ただ、これは2011年に対する調査なので、現在の、サービス系企業の勢いが弱くなり、SIerの需要が盛り返している状況では、流れが変わっているかもしれません。


で、SIer的な開発の特徴としては、顧客は企業で、その企業がエンドユーザーとつながるという形です。
そして、顧客企業とSIer企業が契約を行い、その契約を満たそうとする形で開発が行われます。つまり、プログラマとエンドユーザーの距離が遠いということです。また、プログラマが比較的多いこともあげられます。
ここで重要なのは、契約どおりの量の成果を出せば、お金が払われるということです。実際にそのソフトウェアによって結果が出るかどうかは、契約段階では考慮されますが、開発段階では ほぼ考慮されません。
その中では、プログラマ個々人の開発能力を高めることよりも、確保可能なプログラマの能力でいかに無駄なく戻りなく効率的に開発が進めれるかが大事になります。


一方でサービス的な開発の特徴としては、開発企業が直接ユーザーとつながっていることがあります。
開発企業がそのままサービスを行い、ユーザーに使ってもらえるように開発を行います。プログラマとエンドユーザーの距離は近くなります。また、開発に関わる人数も比較的少ないです。数十人関われば大きいほうなんじゃないでしょうか。
ここでは、いくら計画通りの開発を行ったとしても、ユーザーやスポンサーが気に入らない限りはお金が支払われません。そのソフトウェアによって結果が出るかどうかが非常に大事です。
そうすると、開発の効率は高いほうが望ましいですが、ユーザーの満足するサービスを開発できるプログラマが求められます。ただしこれは社内教育ではなく人材確保時点での能力によって必要なプログラマが揃えられる傾向が強いです。


まあ、でも、大人数の開発をちゃんとまわすことやシステムをつくってひとつの企業をまわすというのも、性能の高いプログラムを組むことや直接ユーザーにソフトウェアを使ってもらうことに劣らず面白いので、どっちが優れてるという話ではないです。


で、ここで、ユーザーのやりたいことが、要求として見出されてコンピュータで動いて使ってもらえるまでに、どういうことを考えないといけないかという流れを元に、プログラマが勉強することをまとめました。
ここではいつもの図に比べると、コンピュータからユーザーへの線に「UI/UX」って書くのを忘れてます。
まあ、この図では、左側の「いかに作るか」という分野と右側の「何をつくるか」という分野を、ソフトウェア工学コンピュータサイエンスにわけて話をしました。
ここで「コンピュータサイエンス」は、計算機科学(=狭い意味でのコンピュータサイエンス)、情報工学、計算機工学などを含んだ、広い意味でのコンピュータサイエンスを指しています。


SIer的なソフトウェア開発ではソフトウェア工学が、サービス的なソフトウェア開発ではコンピュータサイエンスが重要視される傾向があります。
で、勉強会では、どちらかというとソフトウェア工学側が主になりがちです。
というのも、コンピュータサイエンス側って、教科書が基本的に正しいし経験はそれほど役に立たないし、理解に時間もかかるので、みんなで集まってわいわいやるよりは、ひとりで黙々勉強したほうがよくて、あまり勉強会需要がないように思います。
一方でソフトウェア工学側は、教科書やマニュアルに載ってることは基本として押さえたほうがいいけど、それをいかに適用するかが大事なので、それぞれがどのように適用してるかっていう情報交換が大事で、勉強会で集まって話をするのも大事ということになるんではないかと思います。


そこから、ここでは「コンピュータサイエンス」のほうの力を伸ばすにはという話をしたのですが、そのまま「ソフトウェア工学」のほうの力を伸ばす話におきかえれると思います。


んで、どのように勉強するかという話。
2013年IT人材白書の概要に、企業の人件費に対する教育費の割合が1%未満という企業が3割というデータが載っていました。
また、今年2014年版では、人材不足について、量的な不足感はこの5年でどんどん増しているのに対して、質的な不足感は5年間一定であるというグラフが載っていました。つまり、質的にはこれまでと要求が変わっていないということで、教育に割く予算も増えないだろうなと考えられます。
つまり、勉強は個人で業務外にやるしかないということです。


そして、さっき書いたように、勉強する範囲は膨大にあるわけです。図の中の一項目だけでもちゃんと勉強するのに数ヶ月以上かかります。そうすると、勉強はかなり長期間でやっていく必要があります。となると、いかにモチベーションを保つか、どの方向に進むかというのは大事になるので、勉強会でモチベーションや方向性のヒントを得ることが大事になります。
勉強会というのはそういうところであって、その会自体で勉強するところではないので、実のところは「勉強会」という言葉はあまり好きではないです。そういう言葉なので「勉強会は勉強にならないから無意味」とか言う人がいるので。ですが、まあ、この会に参加する人はだいたいわかってるんじゃないかと思ったので「勉強会」にしました。


さておき。
組織の求める技術能力のレンジというのは、それぞれ枠があります。んで、求めるレンジが低い組織のほうが、高いレンジを求める組織よりも多くあります。

このとき、自分が所属する組織のレンジの下のほうにいるのであれば、その中で勉強していけば問題なく能力をあげていくことができると思います。けれども、勉強を続けていくとそのうちレンジの上を超えていきます。
そして、ひとつ問題なのは、個人が能力をあげるために必要な時間よりも、組織が求めるレンジをあげるために必要な時間のほうが圧倒的に長いということです。つまり、個人は3ヶ月も身をいれて勉強すれば目に見えて能力が向上しますが、組織が求める能力をあげるためには、仕事のとり方、つまりお金の稼ぎ方から変わっていかないといけないので、かなりの時間がかかるということです。営業などから含めて、高いレンジの能力をお金に変える枠組みがなかったということなので、そういう経営的な枠組み自体を変えていく必要があります。


そうすると、組織の求めるレンジを自分の能力が超えたとき、自分の能力をあげつつ組織のレンジもあげるというのは現実的ではないとなります。
優先度として自分の能力向上は置いておいて組織の能力をあげるか、それとも自分の能力を上げたい、活かしたいということであれば、求める技術レンジがフィットした組織に異動するかということです。
幸い、いまのソフトウェア業界では人材の流動性が高いので、組織を変えやすくもなっています。ちょっと大き目の会社であれば、転職しなくても、社内での部署やチームの異動でもいいかもしれません。


んで、これは話としては最後にやったのですが、35歳定年説の話をしました。話が長くなると思ったのですが、実際にはここまで話すと、35歳定年というのは非常にすっきりと説明できました。
ようするに、20歳過ぎから35歳まで15年近くひとつの仕事をやっていくと、だいたい組織の求めるレンジの上のほうに到達するということです。そうなると、35歳以上の能力をお金に変えるスキームを組織がもっていないので、管理など別の役割をもたされるということになります。
そこで、プログラマは35歳で定年ということになるわけです。


ここで、ひとつ大事なことがあります。それは、一日は24時間しかないということです。
技術者の使う時間として、大きく3つにわけることができます。
「生産」これはお金が入る活動です。ようするに仕事です。
「投資」これは入るお金を増やす活動です。ようするに勉強です。
「メンテナンス」これはそれ以外の、わかりやすくいうと技術者としてではない活動です。具体的には、睡眠、食事、トイレ、風呂などですが、それ以外に、家族などと過ごす時間や技術とは関係ない趣味の時間も含めます。
あと、みなさまの要望により、円グラフ書いておきました。けど、それぞれの割合は自分で選ぶ必要があります。

最近、大人になったので一日8時間働くということを覚えたのですが、そうすると仕事の日には勉強なんかぜんぜんできないということがわかりました。先ほど挙げたように、業務の中での勉強は期待できないので、仕事の時間とは別の時間に勉強する必要があります。
これまでぼくは、仕事の時間を減らしつつ、もちろん収入も減りつつ、その分を勉強の時間にあてていたということですね。あといっぱい寝てた。それでもまがりなりに生活できていたので、まあ平均的な時間単価は高かったということになります。
このように、投資の時間を増やしつつ入るお金を増やすことで、生産時間の割合を減らして、メンテナンスにまわす、という配分だったわけです。


一方で、メンテナンスの時間を減らして生産・投資の時間を増やすとか、家族のいる人だと生産や投資の時間はそこそこでメンテナンスの時間を増やすということになったりと、それぞれ優先度をつけて時間を配分することになると思います。
投資の時間、勉強の優先度が高い人だけが偉いわけではない、ということは挙げておきます。


最後に、艦これエラー娘の書き順を解説しつつ、コレジャナイ感を蔓延させつつ終了しました。


ということで、こんな感じでやったのですが、期待してた内容かどうかは別として、それなりに楽しんでもらえたようです。
あと、「Scalaの人がPlay会に行くからScalaをdisってもマサカリが飛んでこないので安心」という話をしたにもかかわらず、ぜんぜんScalaをdisったりしてない!というクレームw がありました。


次回、もう一回くらいやるとは思うのですが、興味がある人は★つけるなりブクマするなりツイートするなりしてもらえると、開催の可能性が高くなると思います。そのとき「こんな内容だとわかってれば参加した」とか「裏番組がなければ」とか「3000円ちょっと高い」とか「きしだじゃなければ」とか書いてもらえると運営がやりやすいと思います。★の人はどれか選択して★つければいいと思います。