2015/7/25のレッツゴーデベロッパー555のレポート。
ソフトウェアエンジニアとして心がけてきたこと 柴田芳樹氏
当日のスライド
www.slideshare.net
ソフトウェアは「人」が作る
ソフトウェアを書くことは芸術。うまくなるには10年を要する。
優秀なプログラマであれば、低レベルの言語、扱いにくいシステムであっても克服するが、 優れたプログラム環境は出来の悪いプログラマを救済してはくれない
優れたソフトウェアは人が作る。ツールや技法が作ってくれるわけではない。
プログラマー現役続行するために
読みやすいコードを書く
ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すこと。
保守できないコードは、負債となる。初心者だからといって、汚いコードを書くことが許されるわけではない。
コンピュータが理解できるコードは誰でも書ける。優れたプログラマは、人が理解できるコードを書く。
ネーミングは設計の中心。良い名前を付けることは訓練を必要とする。熟練したプログラマとなるためにはこのスキルを伸ばすことが重要。
- 優れたネーミングはシステムの理解を助け、作業を容易にする
- 貧弱なネーミングはシステムの理解を妨げ、後でシステムを扱うプログラマに辛い日々を送らせる。
論理的思考
- プログラムの失敗を観察する
- 観察と矛盾しない失敗の原因についての過説を立てる
- 仮設を使って予想する
- 予想を実験でテストして、更に観察する
- 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
- 満たされないなら、別の仮設を立てる
- 仮説がこれ以上精緻にできなくなるまで、手順３と4を繰り返す
キーボードを早く触りたい気持ちを抑えること。思考はそれに勝るとも劣らない行為。 まず深呼吸をしてから、バグを引き起こした原因について考える。
継続した学習
ソフトウェア業界で取り残されないようにするには
- 重要な本、出版物を読み、主なカンファレンスに参加すること。
- 今日読んだ情報は３年から５年で古くなるため、常に終わることのないプロセスであると言うこと。
- あなたの会社は、良くても限られたサポートしか提供しない。最悪何もサポートしてくれない。
ソフトウェア業界で取り残されないためには、自分から進んで自分の時間や自分のお金を投資しなければならない。
一冊の良い本を選べば、他の人が何十年もかかって習得してきた見識を、数日で得ることができる。
技術を創りだした人が執筆した書籍を読むとよい。
アメリカでは、プログラム言語を作った人が本を書くことが多い。
技術書には誤りがあると思って読む。 誤りがあると思ったら、間違いだと思って流さずに問い合わせたりすると新たな知見が得られたりする。
柴田さんは、Effective Java(英語版)を読んで衝撃を受けたそう。 (その後、この本を翻訳してしまう行動力がすごい)
EFFECTIVE JAVA 第2版 (The Java Series)
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
コンピュータの基礎知識
何年立っても陳腐化しない。
- ハードウェア
- コンピュータの基本動作原理
- CPUの基本構造、メモリ回路、割り込み動作、etc
- コンピュータの基本動作原理
- オペレーティングシステム
- Linuxなどのオペレーティングシステムの基本的な仕組み
- データ構造とアルゴリズム
- リスト、ツリー、ハッシュテーブル、サーチ、O表記、etc
コミュニケーション力
- 相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明する。
- 相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取るように務める。
英語力
- 専門的な技術の継続した学習と同様かそれ以上に、英語力を身に付けるための継続した学習が必要
- 内容を理解し、技術書をある程度のスピードで読むには、TOEIC900点以上が必要
追い越される人、追いぬく人
新卒と一人前のエンジニアの差は縮まることはない。
一方、何の努力もしていない人を追い抜くことは、立ち止まってる人を追い抜くような簡単なもの。
立ち止まることなく、ソフトウェア開発を楽しみましょう。
セッション１ 多階層組織の中でのエンジニアのありかた 村上正則氏
多階層組織とは
- 社長を頂点とした階層組織
- プロパが上がれる階層は決まっている
- 組織図からは読み取れない、人のつながりがある
- 業務で縦割りが基本
- プロジェクトの構成も業務で縦割り
- 1次受け ２次受け ３次受け...
プロジェクトの中で、プロジェクトを進める人の割合は１％！この人たちだけが本当のエンジニア。
この人たちだけが「プロジェクトを進めるために何をするか」考えている。この人が抜けたらPJ炎上はする。
でもこの人たちは上には行かない(出世コースに乗れない)
エンジニアの取れる選択肢
- スキルチェンジして、管理をやる
コード書くのは辞める - 組織外のコミュニティに参画する
会社での出世は諦める - 内部改善をする
モチベーションの話
優れたエンジニアは、給与とかポジションとか気にしてない
技術は面白い
- 勉強会はいたずらして遊ぶ時間
- 動いたら楽しい
- うまくいったら楽しい
楽しむためにやっていること
- 無知を装う
- 作業を丸投げされるのを防ぐ
- 作業のゴールを曖昧にさせない
- 作業のやり方、ゴールを言わせる
「お前がやると言った」と言われないように
- 管理しない
- でも、コミュ力はそこそこ必要
- 露骨な否定はしない
- 話は聞くだけにする
- 同意はしない
コミュニティに参加する
- 自分の興味のある部分だけ
- 無理しない。背負わない
- できたら貢献する
エンジニアに朗報！
管理のピラミッドの他に、技術のピラミッドが作れる環境がもうすぐ出来てくるはず。
外圧と新陳代謝
- 組織内の人も5年もすれば変わります
- 人が変われば、仕事も変わる
- 組織外の圧力には、そうそう逆らえない
組織の良い部分を使う
- 数がある
- 組織同士のコネクションがある
- 組織は時間があれば変えられる
最後に
- 作れる人が一番偉い
- 技術の価値は必ず現れる
- 組織は時間があれば変えられる
セッション２ ザ・ジェネラリスト ソフトウェア開発を勉強し始めて6年でトップレベルになるためにやったこと kyon_mm
当日のスライド
www.slideshare.net
エンジニアとは
ソフトウェア工学を知見を活かして仕事する人
トップレベルとは？
- 既存の技術を作り直せる人
- 次のステップを作れる人
always cool engineer
最高のエンジニアに対して最高の評価をする人が現れたらどうする？ その時になってから勉強しても間に合わない
No Time Release
リリースまでの時間を０にしよう。 実際に０にすることは出来ないが、これをどこまで努力するかがエンジニア。
Cyber Punk
この仕事のモチベーションは攻殻機動隊。
攻殻機動隊の世界を作るために必要なスキルは何でも欲しい
。
Generalist or Specialist
ジェネラリスト：何でも出来る人 ドラクエで言うところの勇者 スペシャリスト：特化型
8:2の法則を使うと、スキルレベル全体の8割を満たすまで達成するのは2割の時間で出来る。 残り2割を勉強するのは時間がかかるので諦める。 これらを全ての分野で行うことが大切。 たいていの人は多くの分野を知ろうとしないし、つなげることもしない。
言語学を勉強したことが、オブジェクト指向言語の理解につながったりする。(オブジェクト指向は海外で生まれた考え方なので、その国の言語学で勉強したことがオブジェクト指向の理解につながったりする)
8割を目指すのであれば形式知(本)でいける。
ある程度の技術書１冊はあるコミュニティの３年間の歴史が入っている。 技術書を年間に３冊読む人は１年で９年分の歴史を手にしている。 kyon_mmさんは技術書を年間40冊以上読むことにしている。 計算すると１年で120年分の歴史を手にしている。
愚者は経験に学び、賢者は歴史に学ぶ 。
Reading
技術書は2周以上読む。１周目は必ず3日以内に読む事。分からなくても問題ない。
どこかに詰まって読めないと、いつまで経っても読めない。
- 短期記憶とうまく付き合う
時間を空けると前の方に書いてあったことを忘れる。書いてあった事を忘れないうちに一通り読んでしまう
読んで詰まった事が後に詳しく書いてあったりする - 本の中の言葉の使い方に慣れる。繰り返し出てくる言葉には気をつける
- 書籍のクセ(構成、濃淡)を知る
本の読み方についてのkyonさんのスライド。
www.slideshare.net
Speaker, Blog, Article, Book
セルフブランディングについて考える機会。 組織やプロダクトをより良くするためにとても重要な考え方。
- 自分では気づかないことを知っている人と出会える
- 世界の広さを知ることができる。（良い面、悪い面とも）
Speaker
自分の考えを整理するスキルを身につける時間を作れる。
わかりやすく表現することに積極的に取り組んで、多少の失敗が許される。 マサカリを受けても、基本は受けた側が痛いかどうかだけ。投げている側はマサカリだと思ってない。
Concern
Scrum
権限が十分にあるプロフェッショナルな小さなチームがリズムを保って動くことで、生産性がとても高くなることをうまくルールにしている。
Scrumがうまくいってない人は、スクラムガイドに書いてある必要な事を全部やってないだけ。
BDD
フォーマルメソッドでは上手く行かない分野でうまく開発するための新しいプロセス。
kyonさんが書いたTDD/BDDの記事。
「いまさら聞けないTDD/BDD超入門」最新記事一覧 - ITmedia Keywords
MicroService with OO
PaaSとオブジェクト指向の出会い。これからどんどん世の中はSmalltalkのようになっている。 テスト不可能よりも、エンドユーザがサービスを作る時代。 (例. IFTTT、Wikipedia)
Conclusion
- ジェネラリストになるということは、ある意味でソフトウェア開発におけるマニアというか研究者である
- なんでもできるやつが絶対強い。
Extreme Fishbowl 川口恭伸氏、井上岳大氏
Pair Programming
経験が隣で見ている人に伝播させることが出来るやり方。 暗黙知は実際にやらないと伝わらない。
mob programmingという、ディスプレイにコードを映しながらみんなで議論してコーディングしていくやり方もある。
その後、ポーカーの役を判定するお題でmob programmingを実践。 迷ったけど、前に出てプログラムやってみた。 以下、やってみた感想。
- お題の内容を少しずつ実装していくとして、最初にどこまで作るか悩んだ。
Cardクラス実装しようか、判定する役が増えた場合に向けた処理構造どうしようか、等。 - 少しAPI調べれば書けるコードだと思ったけど、何も見ずに書く事が出来なかった。
ワンペア、ツーペア判定のコードはJava8のstreamAPI使えば簡単に書けるだろうなとは思ったけど、どう書けばよいのか出てこなかった。 普段から刀研いでおくの大事。 - ルール、やる事を明確化して進めれば良かった。 自分はポーカーのルール知ってるけど、ルール知らない人もいたので、最初に明確化した方が良かったかも。
- 人のマシン使うのは難しい。
この後、本もらいました。ありがとうございます。
明日から何やる？
参加者各自で、明日から何をするかを検討した。 自分が取り組む事にしたのは以下。
- 溜めてる本を全部読む。
途中で詰まったりして読むのを中断してた本が結構あるので、それを読みなおす。 - プログラムを書く。
少しでもいいので、プログラムに触る機会を作る。
書いたプログラムはGitHubに上げたりQiitaに投稿したりする。
感想とか
今回のレッツゴーデベロッパーのテーマは「エンジニア」。 自分は、エンジニアとして生きていくなら、ずっと勉強をし続ける必要があると思っている。 凄い人達は、自分より勉強してて、今も勉強し続けてるんだと分かった。
一方、コードを書く技術も磨き続ける必要がある事を改めて実感した。 昔は書けてたコードも、しばらく書かないでいると、かなり錆びついてたりする。 たとえ仕事でコードを書く機会がなくても、個人でコード書く事はやっておかないとダメ。 あと、後日のTDD勉強会でfishbowlの続きをやった時、柴田さんが言っていたネーミング技術の大事さを実感した。 読みやすいコード書くには、名前付けの技術は必須。
英語力の向上は継続課題。(-"-
