「オブジェクト指向でなぜつくるのか」を読んだ
会社の先輩に借りた「オブジェクト指向でなぜつくるのか」を読み終わったのでその感想を書きます。
読んだ本について
読んだのはこちらの本です。
- 作者: 平澤章
- 出版社/メーカー: 日経BP社
- 発売日: 2011/04/07
- メディア: 単行本
- 購入: 6人 クリック: 92回
- この商品を含むブログ (20件) を見る
↑のリンクは第2版ですが、私が読んだのは2004年に出版された第1版でした。こちらの著者の方のページで説明されている通り、私の読んだ第1版から、現在最新の2版では内容が結構変わっているようです。本記事はあくまで第1版を前提とした内容で書いています。
感想
全体
タイトルや表紙からは堅めな技術書の匂いがしますが、実際はそれに反して初心者が読むことを前提とした説明がなされていました。サンプルコードや図もこれでもかというぐらい載せられており、出先でもサクッと読み進めることができます。
さて書名にもなっている「オブジェクト指向でなぜつくるのか」という問いですが、結局自分の中でしっくりとくる答えは見つけることはできませんでした。ただ「なぜオブジェクト指向が作られたのか」については、読む前よりも理解が深まったような気がします。これは大きな収穫でした。
本書の内容は大きく2つに分けることができます。 プログラム技術としてのオブジェクト指向を説明した1~6章と、そこから派生したソフトウェア設計手法としてのオブジェクト指向を説明した7章以降です。 特にプログラミング技術という文脈でのオブジェクト指向について知りたかったので、前半はしっかりと2,3度、後半はさらっと1度だけ読みました。
前半部分
本書では一貫して、「オブジェクト指向が現実世界をそのままソフトウェアに表現する技術である」という(よく為されがちな)説明とそこから派生する例え話を「間違い」と批判しています。(38ページ) よく初心者向けの本で使われる「犬がクラス、ポチやハチがインスタンス」みたい例え話のことですね。
そういった例え話をたくさん聞いて「で、実際にどうコードにするの?」とモヤモヤしていた私にとって、「現実世界との対比は、例え話と割り切るのがコツ」(58ページ)という本書のスタンスは、ある意味、目から鱗でした。
その前提の元、以下のような内容がありました。
- オブジェクト指向が産まれるまでの経緯。
- オブジェクト指向の三大要素
- クラス・ポリモーフィズム・継承
- サンプルコードが多くあり、「こういう時に」「こうすれば」「こう嬉しい」ということを確認しながら三大要素を理解することができました。
- この辺も言語仕様として知っていても、自分の手で書けないという状態から一歩進むのに有意義だと思います。
- オブジェクト指向プログラミングのメモリの使い方
- プログラムの実行中、メモリがどのように使われているのか解説します。著者曰く「プログラマのたしなみ」だそうです 😩
- 専門的な勉強をしたことがない私にとって、とっつきにくい部分ではありましたが、図をたくさん使って説明してくれているので、「あー確かにメモリの節約になっている」ということを理解することはできました。
再び全体
後半部分は前述の通りさらっと読んだので、「そういうのがあるんだね」ぐらいの理解でした。必要になったらまた戻ってきたいと思います。
マイナス点も少し上げます。
- たとえ話は混乱の元になる、という論調ですが、本書内でも時たま変な例え話が出てきます。そして大抵はてなマークの浮かぶ例え話でした。まあそれだけ例え話がリスキーなんだと思いました・・・
- 前後半はある意味全く異なったレイヤーの話でした。突然違う話が始まり、私は最初「ん?理解できない!!」と混乱しましたが、後から考えるとそれもそのはずという感じです。初めて読む方はお気をつけください。
全体として、「オブジェクト指向に変な理解をせず、1つのプログラミング技術として捉えるべき」という思いが底流していました。 機会があれば次は最新の版を読みたいと思います!!
【まつもとゆきひろ氏特別講演】若手エンジニアの生存戦略 に行ってきた感想&講演内容メモ
Rubyの生みの親Matzことまつもとゆきひろさんの講演「若手エンジニアの生存戦略」に行ってきました。
講演中や後に感じた雑感と、取っていた講演メモをまとめます。聴きながら書いたメモなので乱筆はお許しください😃
感想
- 去年の同じ時期に開催され話題になっていたので、ぜひ行きたいと思いイベントページが開かれた瞬間応募した。
- サポーターズのオフィス&会場きれい!
- 最初に「メタ戦略」を持つことの重要のお話があったが、非常に納得。うまく行った事例、というか事例とまで行かない日々の小さなできごとについて、全く同じ条件が回ってくることはまずないので、そこからエッセンスを取り出すことの必要性は「KPT」などの振り返りフレームワークでもなんども語られている。
- 今回聞いたMatzのロールモデルもメタ戦略を作る材料にしなきゃいけない。
- というかそうしろと言っていた気がした。なので自身のメタ戦略を話す時に「まあ答え合わせになっちゃうんですけど」と半笑いだったのかなと
- 「リアル世界でチートを使う」という表現は、「そんな表現があるのか」と驚いた。割とみんな「Don't work hard ,work smart」じゃないよねと最近思っていたので、「リアル世界でチートを使う」という表現はいろんなところで使っていきたい。
- 「20代エンジニア」という対象層が広かったためか、目新しい話はそんなになかった気がするが、自分の持っている思考やモヤモヤを言語化した言葉をたくさん知れたのでよかった。
- たくさんの人のメタ戦略を聞いて、そっから自分のメタ戦略をどんどんアップデートしていきたいと思った。
- 「しんどい所からは逃げろ」が一貫していた。質問で「周りがしんどいことをしていたらどうすればいい?」と聞いたら「逃げろ」だけ教えてくれた。わかる。
- アウトプット大事!ただそれを恐れてしなくなるのは人間の本能だという話を聞いて、安心感を感じるとともに、自分のモヤモヤの理由を言語化できた。そして「本能に従うことにそんなに価値はない」そうなのでどんどん出していきたいと思った。
- ということで、帰り道の駅のベンチでPC叩いて書いてます
講演内容
とりあえず聞いたことを全部書いたのでめっちゃ長文になりました。見出しだけをどんどん読んでいくと話の筋がわかると思います。
サポーターズ楓さん挨拶
自己紹介
- 地方やエンジニアに課題感
- エンジニアすごいのに恵まれてない!
- (勝手に)皆さんのキャリアを応援しています!
サポーターズ紹介
- 過去2年で1億円以上の交通費を支給
- 1日2回勉強会やってます
サトアズ(@satoazu_sp)の紹介
- pythonとgoをやってます
- Tシャツも売ってるよ
今日の目的
- matzのご尊顔を拝もう
- エンジニアとしての生き方、勝ち抜き方を考える
- 何かを始めるきっかけにしてください
Matzさん講演
Matz自己紹介
- フルネームが長いので英語圏ではmatz
- ニックネームじゃなくてファーストネームを読んでもらったらぞわぞわする
- ドイツ系だとMatzという苗字がある
- 「rubyを作った人です」
- いろいろ賞をもらいました。日本で一番有名なプログラマー
- 政府IT総合戦略本部委員
- 首相会議に行って話しているが、あんまり意見が採用されているような気がしない・・・
- 松江市の名誉市民
生存戦略
- 生き残るには「死なないことが一番」
- IT業界は「大変な働き方」をする人が多い
- なので一生懸命働いちゃう→「たやすく絡みつく死の鎖」
- 命が危ない
- 誰にでも適応できる生存戦略はない
- 具体的な方法はあまりないが、学ぶべきことはある
- 成功した経営者にアンケート
- X IQ、学校の成績、コミュニケーション能力
- ◯ パターン認識能力が高い人が多い
パターン認識≒抽象化
- 抽象化が大事
- 毎回違う状況に対して適用できるのは何かを感じ取る
- 「メタ戦略」→共通のパターン戦略
- 「メタ思考」→メタ的な考え方を中心にする
- 人間の強み
- 抽象化の強み
- 具体的なものは寿命が短い
- アプリ解説書VSアルゴリズム解説書
- アプリ→言語→OS
- 抽象度が高いものほど寿命が長い
- 具体的なものは寿命が短い
- 抽象化が万能ではない
- アーキテクチャ宇宙飛行士
- どこまでも高みに行って話が通じなくなる
- 抽象化のモレ、例外が生まれる
ロールモデル
今日はロールモデルとしてここでお話ししているかもしれないが、真似することは無理です
- 環境が違う(インターネットがない時代だった)
- バタフライエフェクト(映画みてね)
- 過去のことを話すが完全に記憶している訳ではない→バタフライエフェクトで役に立たない
- Matzの経験からパターンを引き出すことが今日の課題
昔の話
- 12歳でボードマイコンに遭遇
- プログラミングを理解するには至らなかった
- 15歳でポケットコンピュータ
- 初めてのプログラミング
- 限られたプログラミング環境→すぐに辛くなる
- 高校の時にPascal入門
- 大学→ここは天国か
就職
- 通勤が苦痛で東京で働きたくなかった
- 浜松に就職→職住近接
- 同期200人居たが、コンピューターサイエンスを専攻して居た人は6人
- 社内システムを作って居た
- 「どうあるべきか」を決められる
- どう実装するかも裁量が与えられていた
- 大掃除の時にスーツじゃない服を来て行っても問題なかった
- 怒られて説明して風穴を開けようと思ってTシャツとジーンズで行った
- でも誰も触れてくれない
ここからパターン認識をしてみると
- 鶏口牛後
- 大きな組織に追従することはあんまり意味がない
- 我慢の価値
- 「頑張って」は英語に訳せない
- 頑張ることをよしとする社会にいる
- 「みんながやっているから我慢」はあまり理由にならない
- 目的のある我慢
- 納得できない理由で我慢を押し付けられることは結構ある
プログラマ三大美徳
- 怠惰 全体の労力を減らすために手間を惜しまない←もっとも大切
- 短気 コンピューターが怠慢な時に感じる怒り
- 傲慢 人様に対して恥ずかしくないプログラムを書こうとする気質
- 普通ならこっちだよね
- 勤勉
- 美徳
- 寛容
上から下まで勘違い
- 社会的な圧力
- 「我慢」に価値
- 苦痛に耐えることに価値を見出す構造に無自覚
- 労働は我慢ではない
- 報酬は価値の対価
- 理不尽は拒否しなければならない
- 理不尽への我慢は死につながる
- でも我慢に鈍感になってしまう
- そしていつか「致死量」を迎え死ぬ→ダメ絶対
- ポジティブ思考
- みんながやらないやってもいいこと
- 「ずるい!」って言われるが・・・
- ゲームでは裏技と言われる
- リアル世界でチート使えたらいいよね
- 少ない苦痛
- 少ない我慢
- みんながやらないやってもいいこと
リアル世界でチートを使う
- 空気を読まない
- 成果をあげる
- 成果を上げていれば無理は通る
- Don't work hard ,work smart
- 価値観にアプローチする
- 上司に付き従うことが無価値であることを説明する
- 会社が嬉しい価値は0
- 上司が喜ぶだけ
- 上司に付き従うことが無価値であることを説明する
- 社会的圧力を自覚する
- 理不尽に対して声をあげる
- 扱いにくい部下でもいいよね
- 言った方がいいことも多い
- win-winな関係を築く
- 長く続く関係はwin-winかno deal(取引しない)
- 場合によっては逃げること
メタ戦略を考える
- 我慢に価値を置かない
- 社会的圧力に負けない
- 自覚的・自発的になる
- 本能は現代社会の持つ問題、圧力を感じ取ることができない→自覚的になる必要
- いつもするのはめんどくさいが、要所での判断は自分の判断で行わなくてはならない
- 脳内のプログラム、社会的圧力に流されない
- 自分を知る
- Matzがどうかではなく自分がどうか
- 自分がどういう状態か、どういう環境について知っていれば百戦危うからず
- 継続すること
- 勘「こっちに行くと幸せになれそう」は大事
- 社会的圧力に対する鈍感さ
- 「空気を読める」ことは自分を苦しめることもある
- 時たま捨てましょう
- 思い込みに自覚的になる
- 思い込みってキャッシュみたいなもの
- 無効化が効かないキャッシュ
- 昔(=そのキャッシュが作られた時)は意味があったかもしれないが
- バグ原因の95%は思い込み
- プログラマーの仕事は問題把握から始まる生産性向上
- 同じ原則を人生にも適用→プログラマーは人生の勝ち組
コントロール意識
- けなす、叱ると生産性は容易に下がる
- コントロールできないと感じる(=強制される)と生産性低下
- コントロール意識→物事、道具を自分がコントロールしているという意識
- プログラミングの醍醐味の1つは万能感(=コントロール意識)
- コンピューターをコントロールして価値を産むべき
- コンピュータの奴隷になりがち
- 意識的に「コンピューターの主人だ」と自覚する
- 自分の人生の主人公は自分
- 人間の本能に従うことに価値はない
インプット・アウトプット
- インプットは必要だが、差別化の要因にはならない
- 外に出す
- アウトプットして他人に評価される人が成功する
- クオリティはとりあえず棚上げ
- 人間の可塑性にかける
- 人間は置かれた状況によって変われる
心理の怖さ
質疑応答
- プログラマ35さい定年説
- 注目している言語は
- エリクサ
- 分散
- 自分はstreamを作っている
- エリクサ
- アウトプットについてどうやって羞恥心を乗り越えたのか
- 昔はインターネット人口が少なかった→注目されづらかったので今の方が怖い
- 慣れ、場数
- 狭い範囲のアウトプットを繰り返してなれていく
- 小さい勉強会
- 理不尽に耐える人への対処は (My question!!!)
- 言って伝える
- 自分に近いところの人、組織がそうであるなら逃げろ
- 最近技術書以外で読んだ本は
- だいぶ本を読むのは減った
- ライフハックス
- 巨神化計画
- 火星の人
- 結局問題解決の本
- アメリカ人エンジニアには当てはまるけど日本人エンジニアには当てはまらないことって何?
- 組織の違いが大きい
- 文化的な違い
- どんなロールモデルを持ってる?
- ラリーウォール
- 上司が今日みたいな話をしてくれるが、変化についていけない
- 我が道を行っていたのであんまり葛藤は感じなかった
- 逃げろ
- 意識的にしてきたことはあったか?
- 自分の思ったこと感じたことを外に出すようにしていた
- 自分はデータサイエンスを深くやっているが、終わる時がくるかもしれない。深く狭く?広く浅く?
- データサイエンスがすぐなくなることはない
- 世の中には状況によってすぐに市場がシュリンクするものはある
- そういうことが起きるということを頭の片隅に入れておくことは大事
- 中堅になった時に関わる要素は
- 体力です
- 自分のバリューがどのドメインにあるか考える
- 自分のマーケットでの価値が変わると思うがどうやってその状況をキャッチしているか
- RSSリーダーを活用してニュースサイトやブログを片っ端から見て傾向を感じる
- 他の人にもコントロール意識を持って欲しい
- 上司は何もしないのが一番
- 今20代なら何をしている?
- ゲームにハマっていた
- 今Matzが持っている目的目標は?
以上
会場入り口の黒板です
※ 随時加筆修正します
「公共交通ナビサービスの開発現場のリアル」に行ってきた。
5/18日にDevLOVEというコミュニティが主催していた「公共交通ナビサービスの開発現場のリアル」という楽しいイベントに行ってきました!!
そのイベントでの雑感と講演のまとめを書きます。
雑感
会場がきれい!ナビタイムさんのオフィス1階にあるイベントスペースが会場でした。今月オープンしたばかりだそうで、色々なイベントに便利そうだなと思いました。
ナビタイムさんのイベントスペース凄いな #devlove pic.twitter.com/nF1rvOMYAP
— Manabu Uchida (@uchimanajet7) 2018年5月18日
同じナビサービスを運営する2社から講演者がでるということで、業界的な話とアジャイル的な話の両方を期待していきましたが、結果どちらも聞くことができ大満足な講演会でした!!
特に吉尾さん(3番手の発表)と小田中さん(4番手の発表)の発表では、とても具体的なアジャイルプラクティスが紹介され、メンバーでない私もまるでそこに参加しているような感覚を覚えると共に、実際のイメージを持つことができとても勉強になりました。マネージャーのお二人がとても嬉しそうにその成果を発表する様子が印象に強く残っています。
全ての発表を通じて、円滑で健全で活発なコミュニケーションが多くの問題を解決する様子を見ることができました。なかなか実行することは難しいですがスクラムなどのフレームワークにも頼りながら、明日からでも頑張ってみたいです。
ちなみに最後のパネルディスカッションの際のグランドルール「質問じゃなくて意見表明でもいいですよ」はとても感動しました!そうそうこういう時、まとまってないけど絶対クリティカルだと思う感想を抱いて、でも言っていいのか迷っているうちに時が過ぎるよね。。。と思って聞いていました。
以下は講演とパネルディスカッションの内容です。 ※正確に表現することを心がけていますが、聴きながら取ったメモですので曖昧な記述や誤った記述が含まれるかもしれません。ご容赦ください。
講演内容
オープニングトーク
- ナビタイムと「駅すぱあと」のヴァル研究所が同じイベントにでるって、なかなかやりにくかったんじゃないですか?
- ナビタイム社内では割とスムーズでした。
- ヴァル研究所もですよ。ちょっと社内がざわついたけど。
- 会場は今年のGWにできたらしく、きれいですね。
株式会社ナビタイムジャパン 村川さん
<テーマ>「ナビタイムの働き方改革」
※諸事情*1でトップバッターのヴァル研究所 下村さんが順番繰り下げ
第1の課題「サービスを出せていない」
2007年まで順調に新規サービスを生んでいたナビタイムだが、2008年ごろ新しいサービスが出なくなってしまった。
- 要因:何をするにもコストがかかりすぎる
- 階層構造が厚く、かかりすぎる調整コスト
- 「意味がない」「決まらない」会議多数。階層構造ゆえなんども開催される定例。役職者のパフォーマンスは低下
- 解決策
- 技術ごとの部ではなく、サービスをもつPJ*2を創設。
- 部長以外の役職を廃止し組織をフラットに
- 結果
- 会社がフラットになりました。
- PJは評価教育を切り離し、サービス開発に専念できた。PJ内に様々なロールの社員がおり、能動的な開発。開発速度が向上。
第2の課題「事業 VS ACTS(研究開発)」
事業を行なっているPJと研究開発の間で相互理解が不足してしまった。
- 解決策
- ジョブローテーションを充実させ、横断的な知識を持つゼネラリストを増やした。
- 全PJの報告会を誰でも質問、資料全公開なオープンな場にするなど、コミュニケーションの活性化に努めた。
- 結果
- プレスリリース増加(≒新規サービス増加)
- 有料会員数増加
- 残業時間削減(平均13時間)
株式会社ヴァル研究所 下村さん
<テーマ>「駅すぱあとの開発現場 - 維持する30年とは」
駅すぱあとの歴史
- 1988年発売 首都圏版 当時、ヴァル研究所の本流ではなかった
- バブル崩壊で経費の削減が求められた時、定期分割機能がヒット
- 当初はデスクトップアプリとエンジンが一体だった。mac対応をきっかけにエンジンを分離、他の商材でも活用するようになる。
Cで実装
- コアエンジンはスピードが命であり、Cで実装している。
- Cで直接使うのは面倒なので、バインディングを多く作った。
増え続ける機能
最初の開発者は3名だった。30年続いているソースリポジトリ。「ソース腐ってんじゃないの?」。当時はバージョン管理もなかったが、今はgitに移行中
- 機能的にも増えてきた。
- テストコードがろくになかった
- ノウハウが溜まっている検査チーム(QAチーム)が助けてくれた。が、テスト実行に12時間
- 次にインフラチームが助けてくれた。Azure使って並列化、自動化し、50分でできるようになった
- どちらも別チームから「越境」に助けられた。
- 現在は本体にも単体テストを追加
- 日々のメンテナンス
- ダイヤ改正、臨時ダイヤ、新しい料金体系、新規路線などは外部からの情報で常にメンテナンス
- サポート、ユーザーレポート、エゴサ
- 実地調査や事業者からのデータ
まとめ
- モブプロ、モブワークで知識を広めている。
- 「越境」するチームの力に支えられてきた。
株式会社ヴァル研究所 吉尾さん
<テーマ>「駅すぱあと バス制作だってアジャイル・プラクティス!」
バス制作チーム
吉尾さんがリーダーを務めるバス制作チーム
- バス社局からもらったデータを駅すぱあと用データに変換するバスデータの保守部隊
- 半数がプログラミング経験なし
課題
吉尾さんが配属された当時、全ての業務は非効率で辛いものになっていた。
- 状況
アジャイルプラクティスを実践
- 朝会
- KPTでふりかえり
- ペア作業
- 属人化解消が目的。
- それまでの担当者の手順に「なんで?」「わからん」というツッコミが入り、レビューの側面も
- 星取表
- カンバン
- 目的は「メンバーの状態」「タスクの状況」「タスクの属性」の見える化
- 朝会のコミュニケーションツールにもなっている。
- スプリント
- 計画会議で始まりふりかえりに終わる、一定の時間枠を繰り返す。「終わり」を決めることで恒久的な作業にメリハリがつく。
- DONEのみが成果であり価値
- 見積もりにはプランニングポーカーを使用。徐々に感覚値の精度が向上し、現在では2ヶ月先まで見通せるように。
- バーンアウトチャートを使った進捗の共有
- 全てはコミュニケーションに繋がっていた。
結果
- 対応バス社局数が増加、4/1改正対応数も改善、作業時間は減少
- 吉尾さん指標で作業効率は3年で160%に!!
- これからもたゆまぬカイゼンを
株式会社ナビタイムジャパン 小田中さん
<テーマ>「ナビタイムR&D部門がたどるカイゼンのキセキ」
自己紹介
- ACTS ルートグループ責任者
- ACTSのミッション
- 新価値提供(知って使ってもらう)
- 品質改善
最初のチーム「R&D部門」
- ゴールからずれるチームメンバー
- スキルが高く、突き詰める研究者肌な開発者たち
- その性格ゆえに、気になることがゴールからずれ、試行錯誤で堂々巡りする。
- デイリースクラム・スプリントレビューで高頻度に軌道修正
- 結果
- ゴールからのズレがなくなった。
- 最初に出なかったことは後回しになってしまった。
- ふりかえりシートの不備から、Problemがたくさん並ぶだけになってしまい、プロセスのカイゼンが進まず。
第2のチーム「チャットボット開発」
- タスクが無限に増える
- スキル、開発速度共に申し分ないプロフェッショナルたち
- それゆえ、周囲からタスクをどんどん積まれてしまう。
- 必要なものにフォーカス
- ユーザーストーリーやPDCAサイクルを作り、ログとユーザーボイスで正確性を担保
- プランニングは各メンバーに委ねた。
- 結果
第3のチーム「乗り換え経路探索エンジン開発」
- チームの目標達成進捗がよくない
- 若手が多い
- 個人のタスクが膨大
- 「よろしいならばスクラムだ」
- ようやくスクラム開始
- スクラムの完全導入すると、個がチームになった。
- 終電後ルート機能をイテレーティブに改善。目標を達成し、社内で表彰された。
まとめ
- フォーマルなスクラムは強力。型を少し崩してチームに最適化するのもあり。
- スクラムに懐疑的だった社員が「やりながらカイゼンしていけばいいよ!」
- スクラム経験者同士のハンガーフライトを実施した。
- R&Dと事業側、エンジニアとデザイナーが繋がるところをみた。つながりをどんどん増やしていきたい
パネルディスカッション(抜粋)
質問だけでなく意見表明もウェルカム!
「スクラムを導入するのは大変?」
- 小田中さん「超大変」「足かけ2年ぐらいかけた」
- 吉尾さん「開発の時はマッチョにやっていた。朝会などやりやすいところからやれば良い。」
「朝会とリモートワークは相反するのでは?」
- 吉尾さん「ハングアウトを使った。」
- 小田中さん「slackのGeekbotに昨日やったこと今日やることを投げて共有」
「どんな人を採用しているのか」
以上