まつもとゆきひろが語る『ビューティフル コード』×『プログラマ35歳定年説』へ行ってきた

こちらセミナーへ行ってきた。

タイトルは、
まつもとゆきひろが語る 『ビューティフル コード』×『プログラマ35歳定年説』 〜若手ITエンジニアに送る2時間のMatzワールド〜」


テーマは上のとおりだが、テーマの範囲を超え、プログラマとしての考え方や、生き方まで幅広く話しをされていたので、よかった。


時間を気にされていたせいか(?)少し早口なので、メモは大変だった・・・。メモれたテーマ、覚えているテーマについてメモしてみる。

ビューティフルコードとは?

理解に基づいた物づいたコード。そのコードが本当に求められているものであることが大切。自分、会社、チーム、顧客、家族、友人など考え、「どれだけ知っているか」「どれだけ理解できるか」「どれだけ考慮できるか」が大切。美しさは大きく分けて「外面の美」と「内面の美」に分けられる。


外面の美

要は人間がどう感じるかが大切。人間に役に立つものを作ってほしい。でも、人間はとっても複雑で唯一の正解がない。外面はとっても非理系的で唯一の正解がない。時代背景なども大きく影響する。


人間は新しい知識を得て進化する。そんな進化を促すものがいい。現状に安堵するより、前向きに進む。長い目で見た効率を考えるのが大切。


まつもとさんは自分でキーボードの配列デザイン(ローマ字入力)して利用しているとのはなし。


内面の美

  • 「パワー美」「効率の美」

コードは美しい。文書や詩のようなものでアートである。
「できない」を「できる」に変える、見えない秘めた美しいパワーがある。


きっとこれは無理だろうと思っているものを実現してしまう人がスーパープログラマー。小手先ではなく、「アルゴリズムの力」で基本的なデータ構造の見直しなど、本質なところを見直し、アルゴリズムを見て変えていく。


現代はとてもソフトウエアに依存しており、コンピュータとソフトウエアがないと飛行機は飛べないだろう。そんなソフトウエアに依存した社会なのに、作り手が少ない。しかし需要は多い。効率、生産性の高さ、簡潔さが求められ、それが大変価値があり、そのようなソフトウエアは美しい。


内面は、外面ほど価値観が変化しない。

  • 「簡潔さは力なり」

進化はいかに簡潔に書くかということにかかっている。昔のプログラムを参考にして、簡潔になる。それが進化。
しかし、バランスが難しい。


現実は複雑だ。いくら簡潔にといっても、複雑な現実があり、ソフトウエアの複雑さも避けがたい現実。
しかし、どこが複雑になるかが問題である。


言語がシンプルになり、複雑なことができなければ、フレームワークやソフトウエアが複雑になる。
言語が複雑になり、いろんなことができシンプルに提供できればフレームワークやソフトウエアがシンプルになる。
Rubyは複雑さを買って出て、ソフトウエアを簡潔に書けるよう、泥臭くなっている。


また、人の心は単純じゃない「単純がすき」「複雑さも好き」「簡単な問題がいい」「難しい問題もいい」、バランスが大切。

  • 「冗長の排除」

むかしは、コピーしてナンボ。それは、「給料=書いたコード数」だから。しかし今はソフトウエアの価値はお客様にもたらす価値が重要であり、書いた行数ではない。Don't Repeat Yourself。


コードは設計である

お碗を例にしていた。だれがやっても同じようなことができるものではない。職人芸であり、一品もの。善し悪しがある。コードは実用品であり、使って美しさを感じてナンボである。


コードは読み物である

コンピュータに命令する文書である。人間とコンピュータの意思伝達の手段であり、人間と人間とのコミュニケーションにも使われている。例:TwitterのコードをみてTwitterを理解する。


また、コードは知識の宝庫である。オープンソース。多くのソフトウエアが公開されていて、見ることができる。Linuxのコードなどが完全に手に入る。

  • コードリーディング

コードリーディングは重要である。現代は、人のコードを読む人はどれくらいいるだろう。自分のプロジェクトはデバックのために読むけど、ほかの人は読まない。スーパプログラマーはほぼ例外なくほっておいても他人のソースコードを読む。必ず読む。


昔は、マイコンベーシックマガジンというのがあり、ゲームのソースコードが雑自に載った。昔の若い人は金はないが、無駄に時間があったので、雑誌のコードを丸写ししてゲームをしていた。その中で読む力を上げ、時にはデバックし、自分で改造しスキルをあげていった。
昔のコンピュータはOSがない。OSといってもLinuxがない。OSはだれか(会社)からもらうしかなかった。それを読んで、OSをインストールしていた。デバックなどがあれば、提案し取り入れてもらったりしていた。読んで、自分で考えてスキルをあげていった。


プログラマはアーティストでありうる

昔は、ソフトウエア工場などといわれ(今は言われないが)、プログラマに対してさまざまな誤解があり蔓延していた。

  • コードは工業製品ではない

車の生産を例にすると、車そのものを設計することがプログラムに当てはまる。
ソフトウエアはすごい規模が大きいにもかかわらず、すごく数が多い。車は数が少ない。

  • よくある誤解

すごくクリエイティブな作業なのに、流れ作業のように扱われる。

  • コピーは一瞬

ソフトウエアは基本的に情報なので、流れ作業のコストはゼロ。


アーティストの条件

アーティストは自分がプログラマであるという自覚と自発性が必要である。
プログラムを書き続けて仕事をしたい、幸せになりたい、理不尽を拒否していきたいなら自分の人生に対して自分で責任を持って自分で考えることが大切で、そしてプログラマとしての自覚を忘れないで、自発的に創造的にプログラミングをし続けることが大切。

センスはある程度必要。同じような努力をしても成果は違うという現実があるので無視できない。でも、センスは自覚が大事。ほっておいても作るし、勉強する。継続重要。継続のためにはプログラミングが好きかどうか。モチベーションの源は自覚。

  • 怠惰のための勤勉

「手抜きは美しくない」しかし「苦労を見せびらかすのは粋じゃない」、「水鳥のごとく、水上は優雅に、水面下では懸命に」


エンジニア+アーティスト

プログラマは歯車ではない、作業員ではない。コードはアートである。創造的、自発的に何もないところから、生み出す、クリエイティブなこと。自分がやりたいからやるというのが鍵。


しかし、商売なので「納期」「顧客」「チーム」などのことを考慮しないと食えない(w)


エンジニア+アーティストのような人はほかの業界には山ほどいる。プログラマも学べる。同じような仕事でも、人によって考え方が全然違う(金を儲け家族を養うため?価値あるものを生み出すため?)。

  • 仕事の仕方について

エンジニアの幸せは自分で決めるものである。いまは、Rubyを100%やっているから、Googleの20%の5倍し幸せ(w)でも、昼飯は自分で払ってるよ(w)(googleのように食べ放題ではない)


プログラマー35歳定年説を切る」

世間では「プログラマー35歳定年説」があるようだが、それはどうなの?という話し合い。現状35歳説は日本に実際に存在する。原因は、日本の組織や構造の影響が大きいかもしれない。


背景にあると思われるもの
  • 35歳くらいになったらプログラミングは若い人に任せて、マネジメントしないといけない。
  • 35歳なら体力的にむり?新しい技術が覚えられない?年齢的な限界。
  • 35歳を超えてると、プログラマは激減しているというデータはある。ただし、40歳代まで生き残ったプログラマの給与は1.8倍に膨れ上がっているというデータもある。
  • 会社の経済合理性
  • 日本の給与体系(肩書きがないと給与が上がらない)
なんでこうなる?

ソフトウエアの価値が認められていない。

世間的にプログラマが知られていない。世間的には具体的にどんな仕事をしていて、どんな苦労するのかわからない。ソフトウエアによって生み出す価値をなんで認めてもらえないのか。そのような日本をなんとかしたい。月9でエンジニア主演のドラマをやれば世間の目は変わる(主演:キム○ク、深○絵里)?


海外はパフォーマンスによって給料が上がる。そういう社会だと、パフォーマンスを維持しようとがんばるのではないか?フリーランスエンジニアとしてやっている人が多い。


アメリカはプロジェクト単位で人を採用する。日本とアメリカの仕事の文化の違いがある。


プログラマー35歳定年説を切る」のまとめ

高度な知的労働は年をとってもできる傾向がある。経験がものを言うので、年をとってもやっていける。医者や弁護士は資格がある。35歳を超えてもプログラミングができるかどうかがプログラマの試験であるかもしれない。


ほんとうに好きかどうか。これしかない。好きじゃない人は、30歳でも20歳でもプログラマに向いてない。価値を高めていかないと(昔のやり方で進化しないと)、体力勝負になってしまうので若者に負ける。


自分を差別化をしないといけない。代替可能な自分は組織によっては居場所がない。組織の思いのままはよくない。オープンソースを作るなどして差別化して、自分の居場所を探す。


日本人は、人間力は高いが、生きる力は弱い。生きる力は例えば中国人は強い。


自分の人生は他人に任せられない。結局は自分で決めないといけない。日本では、ほかの人と同じことをしないのが大切かもしれない。差別化を考える。幸せになりたい、理不尽なことを拒否したい。自分の人生に対して、自分で責任を持ち自分で考えることが大切。


そのほかでた話
  • 人数が多ければ生産性があがるわけではない

遅れてるプロジェクトに多い人を投入するとより遅くなる。コミュニケーションコストがかかってしまう。つまり、1人のマネジャーが50人をマネージメントしたところで、1人のスーパープログラマにはかなわない。できるプログラマーはできる、できないプログラマーは一生できないという現状がある。それを理解できるマネージャーがいるかいないか。スーパーなプログラマーはだいたいあつかいにくい。そのようなプログラマを判断できるマネージャーが必要。

自分に価値があると思っていて、待遇が悪いのであれば、会社を替わるなどしてもいいかも。

  • 自分の力をどやって図る?

営業は売り上げがあるのであるいみわかりやすい。エンジニアは難しい、数字に出しにくい。社内の近場の人がわかるときがある。そのときの時代や境遇も影響する。


今回の感想

今回のセミナーはまつもと氏の「コードの美しさとは」について聞けたのがよかった。また、「コードの美しさ」のみならず、「スーパープログラマとは」「プログラマはアーティストである」などプログラマについても話がありとっても刺激を受けた。