ソフトウェア・ファーストを読みました
はじめに
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略を読んだので備忘録。
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
- 作者:及川 卓也
- 発売日: 2019/10/10
- メディア: 単行本
なぜ読んだか
最近、自分のキャリアを考えたときに、エンジニアとしてプロダクトを育てられうような人材になりたいと思った。
では、その文脈で語られる、プロダクト志向ってどんなものだっけと言語化したくなったので、この本を手に取り読んだ。
感想
1~3章はそれぞれ、ソフトウェアファーストとは？、日本の課題、必要な変革について書かれていた。
この辺はソフトウェアを外注していたような伝統的な企業がどうすべきかということを中心に論じられ、現在ソフトウェアを中心に割とモダンな環境で仕事をしている人には当たり前のことも多いかもしれない。
なので個人的には4,5章から学びや気づきは多かったと思う。
4章 これからの「強い開発組織」を考える
この章で特に印象に残っているのは、Howを考え実装するのが従来のソフトウェアエンジニアの役割だが、WhyやWhatの部分も考えるという部分（個人的に噛み砕いた解釈）
これは読書や勉強会等でインプットしているだけでできるようになることではないし、Howの部分に大きな楽しさがあることは事実なので、しっかりと開発段階で意識して、チームで議論しながらでないと身につかないものだなと思った。
幸いにも、そのような習慣をつけていたが、まだ規模が小さいので大きなプロダクトと大きなチームで挑戦したいと思った。
また、組織構造についても言及があった。職能別組織、事業別組織、マトリックス組織と言及があったが、大学の授業で履修していたのでそれらの一長一短は深くはないものの理解している。
その中でいいなと思ったのが、技術方針を定めておく必要があるという部分。
これは、意思決定の助けにもなるし、同じような志向の人が集まりチームワークも取りやすくなるのではと考える。技術方針を明確に打ち出しているチームは入る前にイメージしやすいだろうし、いいなと思った。
5章 ソフトウェア・ファーストなキャリアを築くには
この章は、章題の通りキャリアの築き方についてだった。最初にT型人材について話が出てきたが、これはよく聞く。
さらにそこから進化させるパターンが複数あるという。専門を深める=スペシャリストや、専門以外も深める=π型（パイ型）人材、専門を広げる等。
まだ、2年の経験しかないのでとにかくTを深めてきちんとしたT型になるように意識をしなければと思った。
また、この章だけじゃなく書籍を通して語られていたことだが、学びを辞めた時に人の成長は止まる、学び続ける必要があるというメッセージ。深く同意だ。
その他メモに残っている印象に残った言葉や考え方、自分が考えたこと
- 現代社会における多くの仕組みがソフトウェアで構成されている。→つまり世の中にインパクトを与える機会が多い
- ソフトウェアはユーザーエクスペリエンスを実現するためにある。その体験がユーザーの感情を動かす
- どのような立場にいても変わらずに変化し続けることを大切にしたい
- 生存戦略よりも成長戦略
まとめ
技術書と違ってさくっと読みやすいので、のんびり読みしてしまう自分でも1日1章で5日で読んでしまった。
読み物として面白く、納得感も得られたので読んでよかった一冊。話題になるのも分かるなあという感じ。
著者の及川さんありがとうございました。
SQL アンチパターン第21,22章を読んだ
はじめに
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第21章 シュードキー・ニートフリーク（擬似キー潔癖症）
テーマとしては、主キーに欠番があることだった。
個人的には、気にならない。
アンチパターンとしては以下が挙げられていた。
- 欠番を割り当てる
- 複数台のアプリケーションサーバから同時処理が行われた場合に、片方がエラーになるため良くない
- 既存行に番号を振り直す
- ステップ数が多い
- そのキーを参照しているレコードがあった場合にそちらもupdateする必要がある
- キー管理テーブルの変更も伴ってしまう
上記のようなリスクがあるため、基本的には変更をかける必要がない、識別のための番号なので連番である必要性はない。
また、GUIDについても言及があった。
GUIDとは、128bitの擬似乱数のこと。
同じ識別子が振られる可能性は極めて低いが、ディスクの使用スペースが多く値が長いことがデメリット。
第22章 シー・ノー・エビル（臭いものに蓋）
テーマはクエリのコーディングについて。
アンチパターンは以下。
- 診断せず判断する
- データベースへのアクセスした後のクエリを確認しないこと
- 画面には何も表示されないことが多い
- 見逃しがちなコード
- SQLクエリの構築時のコードしか読まないこと
ここに関しては、かなり起こりにくいアンチパターンかなと感じた。
開発者として、返り値の確認や、期待した結果が得られなかった時のデバッグ過程の中で発行されたクエリを確認することは当たり前だと思う。
灯台下暗しみたいなことなのかな。
SQL アンチパターン第20章を読んだ
はじめに
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第20章 SQLインジェクション
ここら辺もフレームワークがよしなにやってくれる箇所だから意識していないが、意識しなければ。
難しいのは、望まない操作を許可しないように、ソフトウェアをセキュアにすることです
大事。
対応策として用意されているのが以下。
初学時にプリペアドステークスで対策をするように言われたことを思い出した。
この一言で、改めてアンチパターンは知識として持っておくべきだと感じた。
また、「20.5.1 入力のフィルタリング」や「20.5.4 ユーザーの入力をコードから隔離する」に関しては普段から慣れてできている。改めて確認することができてよかった。
まとめ
この章の内容もある程度知識として持っているものだった。
ただ、フレームワークを使い慣れているとどうしてもそこまで深くは意識しないので、アンチパターンに対して正しい対策と、レビューを心がけようと思った。
初学者時に、プリペアドステートメントでSQLインジェクション対策を行なっていたことを思い出した。
SQL アンチパターン第19章を読んだ
はじめに
最近結構読書をしているが、まとめてというよりはこまめに読むかつ、厚めの本を読む機会もあるのでインプットしたことをなるべく早めにアウトプットしようと思う。
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第19章 リーダブルパスワード
めちゃくちゃ普段から意識しなければならない内容。
アンチパターンについても、うなずける内容だった。
めちゃくちゃうなずける反面、普段使っているLaravelだと意識せずとも、Hashファサードが用意されており、簡単にできてしまうのでアンチパターンとして学ぶことができてよかった。
なので意識すべきことは、
- SQL文に平文のパスワードを含めない
- 予めハッシュ化したパスワードをデータモデルに引数で渡すことで解決
かなと思う。
また、リセット手法については書籍に記載している、トークンを用いる方法を使っている。
Laravelでは使用したことはないが、これも用意されているみたいですね。
リーダブルコードを読んで
はじめに
2年目エンジニアも終わりそうな今更、やっとリーダブルコードを読了したので感想とか。
実は、1年目の6月くらいに先輩に勧められて購入したものの、実務に入っておらず、読んでもあまり頭に入ってこなかったので諦めていた。
今なら血肉になるのではないかと思い改めて読み始めてみたもの。
対象読者
結構巷では初学者が読むべきと書かれていることも見る。
内容的にも割と基本的なことが多いが、個人的には、実務経験を積んだ人が読むことでより意識して良いコードが書けるようになるのではないかと感じた。
内容とか感想とか
1部【表面上の改善】
変数や関数の命名について、コードの表面上の統一性、コードブロック、コメントなど表面上について書いてあった。
特にコメントについては、あまり強く意識したことはなかったので為になった。
変数名、関数名、読みやすさなどはチーム開発において、コードを読むことに対して大きく影響を与える。
他人=チームメンバーや数ヶ月後の自分が少ないコストでコードを理解することに役立つ為、常に意識し、改善していくべきだと思わせられた。
この1部は初学者でも読みやすく意識しているとチーム開発にもスッと溶け込めると思う。
2部【ループとロジックの単純化】
行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
この1文に内容は詰め込まれている。
ループ内部のネストを浅くすることや、変数スコープを小さくするなどは割と、日常的に意識できているのではないかと思う。
ただ、説明変数を作ったり、要約変数を作ることは割とチームの文化であったり、好みにもなってくるのかなと感じた。
バランスも難しいが、コードが増えていくことを考えると上記の変数達はあったほうがいいのかなとも感じる。
結構複雑なif文の条件を作りがちになるので、教訓にはしたい。
リーダブルコード8章8.4にある「どうして1行で書こうとしたのだろう？そのときは『オレは頭がいい』と思っていたのだ。ロジックを簡潔なコードに落とし込むことに一種の喜びを感じていた。」
— Kazuki Takahashi | kop (@cuzkop) 2020年1月2日
これクッソわかる
この通り。
3部【コードの再編成】
Utilを集めたり、タスクを小さく分割したりと、割とコーディング中に頭の中で設計しがちな内容だった。
自分は割と汎用コードをたくさん作るが、初期段階で経験則から汎用的になるだろうとして作るものの、意外と使う場がなかったりすることもある。
割とYAGNI原則に反してしまっており、汎用コードは汎用的になる場面で改めて作ろうと感じた。
また、やっているつもりではいるが、気づいたらメソッドが大きくなっていたりということもあるので、小さく軽量な1タスクのメソッドやクラスを作ることを意識していこうとおもう。
まとめ
割とサクッと読める読み物なので、やはり界隈で言われるように必読の名著だと思う。
数年に一度読んで振り返るのも大事かも。
次は、なぜプログラムは動くのかを読む。
2019年を振り返る&2020年の目標とか
はじめに
2019も残すところあと6時間ほどになったので振り返っていこうかなと思う。
細かくやるとしんどいからざっくり
アウトプット
Qiita: 12記事 ブログ: 15記事 Commit: 391コミット
出来事と思ったこと
上司が退職
- めちゃくちゃ辛かった。上司の元が一番成長実感あったし、人間的に尊敬していた
Goを始めた
- もっとしっかりやるつもりだったけど、少しだけになってしまった。クローラーを開発してリリースした。コスト2万削減。予算貢献という分かりやすい貢献ができて嬉しかった。
- GoCon Springにも行った。
インフラ周りが去年よりちょっと触れるようになった
機械学習の勉強始めた
- 個人的にこれが一番大きかったと思う。
- まず、勉強の癖がついた、楽しいからあまり勉強とも思わなくなった。
- アウトプットの習慣も前よりついた。
- Pythonも始めた。
- 会社にKaggleサークルも作った。
2020の目標
初めてのデータ関連タスクを終えての振り返り
はじめに
この記事はデータサイエンスに関して By データミックスコミュニティ Advent Calendar 2019の25日目の記事です。
普段ならQiitaに書くけど、ちょっとポエムな内容なのでブログに。 普段バックエンドを中心に割と何でも屋的にやっているエンジニアである筆者が、データミックスで学んだことがきっかけとなり、データ可視化・分析タスクを行った。当時の日記と主にその振り返りがてら備忘録。
やったこと
- トレジャーデータからGoogle Cloud Storageへのデータの抽出、流し込み
- Jupyter Notebookでのデータ加工、可視化
- 上記に付随した分析
- レコメンドモデルの作成
大変だったこと
知見を持った人が社内に1人もいない
文字通り。当時の日記には、
自分自身も社内にもナレッジが全くないのでグループ巻き込んでやっていきたい。楽しみ9割不安1割
と呑気なことを書いているが、調べ回るの結構大変だった。
トレジャーからどこにどのような形でデータを移せばいいかも分からない、どこで可視化すればいいかも分からない、先が見えない状態でスタートした。
結局は、先にCloud Datalabで分析することを決定。これは、データミックスの立川先生に教えてもらった。
その後は、GCP上にデータを移すということで、BigQueryにするかGCSにするか迷ったが、使ったことあるGCSを選択。
幸いにもトレジャーからGCSへの抽出は便利なワークフローがトレジャー側に用意されていたので登録ということで決着。
さらっと書いたが、ここにたどり着くまでに6営業日も要している。
全部で5500万レコードあるので、どうしようか悩み中。
悩んでいたようだ。
重すぎるデータ問題
GCSからローカルに落とし、jupyterで加工をしているが、凄く遅くて話にならない 書き方が悪いのか否かわからない
上にもちょっと書いてあるが、何しろレコード数が多く、回らなかった。
分析の上手なやり方も分からないため、自分は、6つの可視化項目に対して、全部盛り巨大データをPandasで処理して対応しようとしていた。
これだと到底回らなかったので、トレジャーからのデータのエクスポートの粒度を可視化項目単位に細かくすることで解決した。
一人で泥臭く開拓していくのってここまで大変なのかと感じた2週間くらいだった。
ただ、これで分析のための準備は終了。
レコメンドの精度合っているのか問題
精度が良いのかどうかは分からないが、見た感じだと結構推薦できてそうな雰囲気。
雰囲気はよかったっぽい笑
教師なしのクラスタリングっぽい問題なのでなんとも言えなかったが、観測範囲内ではいいものもあれば悪いものもある。
季節も影響するだろうし、何しろ商品数が多いので精度がバラついた。結局正解が分からなかった。
作成後にデータミックスの授業があったので、久松先生に伺ったところ、次元圧縮をしなければ遅いし、精度も怪しかったらしい。
確かに恐ろしい行列だった。
学んだこと
定義は大事
データ分析の前段にはどのような背景があるのかを理解するべきだと学んだ。
ライトユーザーの割合を出したいと最初に言われ、そのまま受け取ったが、進めていくうちに、それは何回Countできたらだ？と疑問になった。
そのような場面が数回ほどあったので、分析対象に関しては、数字での定義が必須だし、最初にしておくとすんなりと進めると感じた。
また、この辺は結構ドメイン知識も重要になるのではと思う。
触ってなんぼ
よく、勉強で出てきていたが、イマイチ使いどころが分からなかったが、実際に見たいものがあると分かりやすい。
これはすごく感じる。
Pandasもだいぶ書き慣れたし、一番効果があったのが箱ひげ図だった。
最初に箱ひげ図を見た時ってなんだこれしか思わなかった。
でも、自分の知ってるデータで出してみるとなんと分かりやすいもんなんだと感動。
やっぱりエンジニアはとにかく手を動かして学ばないとなとも思わせられた。
前処理が8割の格言
界隈でよく言われることだが、すごく感じた。
また、前処理が8割とよく言われるが、それがよく分かった。
日記にも書いてある。
テーブルによってデータの形式は違うし、分析したい内容次第では、めちゃくちゃ正規表現使うし、とにかくpython,pandasって感じの期間だった。
データを前処理して使いやすい形にしたものを改めてディレクトリに保存、後からそこを参照するという形に落ち着いた。
自分（技術者）が分かるだけではダメ
ビジネスサイドとの作業だが、グラフを載せる順番によって見やすさも変わるし、分析を進めていくともっとこのデータが欲しいといった依頼が来たりと、学びが多かった。
こういう感想の通り。
今回はBizサイドからの依頼だったので、めちゃくちゃ対話もしたし、結果を見せた。
その中で言葉選び一つ、グラフの見せ方一つ、分析結果の共有の仕方一つで捉え方や見やすさが変わるのだなと学んだ。
特に、共有に関しては、依頼シートにベタ打ちで最初渡してしまってすごく見にくかった。渡すフォーマットとかを考えるのって大事。
また、コードコメントを書くようにJupyterにもコメントを書くと結構捗った。
感想
総じていうと、
- 普段のインプットアウトプットを信頼していただいて新しい挑戦をすることができた
- 全ての流れを体感できた
- めちゃくちゃ手を動かして作業ができた
- 楽しさを感じることができた
- レコメンドモデル作成が一応できた
といったあたりに非常に満足感を感じている。
それに対し、
- どうしても顧客データなので即アクションに繋がらない
- 正しい（効率の良い）やり方なのか分からない
- フィードバックを受けられない
ここはすごくもどかしかった。
満足9,不満1くらいかな。
日記には、
自分で手を動かして分析したり、レコメンド作ったりととてもいい経験をすることができた。
楽しいと書いてあった。
もっと機械学習していきたいなと感じた、終わり。
