Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

制作 : 和田卓人 
  • ラムダノート
3.93
  • (11)
  • (8)
  • (7)
  • (3)
  • (0)
本棚登録 : 177
感想 : 14
  • Amazon.co.jp ・本 (224ページ)
  • / ISBN・EAN: 9784908686092

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 成功も失敗も記した、克明な体験談のまとめ。
    ソースコードは出てこないが、対処の仕方は結構具体的に記されている。
    「やっぱりそこでハマるか」とか、「そう来たか」とか感じることが多いと思う。
    自分の身にも、活かせるようにしたい。

  • 株式会社VOYAGE GROUPのソフトウェア技術者へ、様々なサービスについての改修についてインタビューした本。
    個人的にVOYAGE GROUPというと、ECナビ等のポイントサイトの印象が強いのだけど、どちらかというと広告事業がメインなのかなと思った。
    長い歴史のあるサービスだと、どうしてもレガシーな部分というのがでちゃうものだけど、その改修というのは大変なんだろうなと思った。
    だいたい、こういうレガシーシステムの改善の話と言うと、ユニットテストがどうのという話が多い印象なのだけど、テストについてはあまり書かれてなかった印象。まさかテストを書いてないのかと思ったけど、読み進めるにつれて、テストを書くのは当然すぎてわざわざ語ることではないということなんだろうなと感じた(インタビュアーがテスト駆動開発で有名な和田卓人さんだし)。
    オンプレミスを選択するメリットとして、「会計上の資産になる」ということが書かれてあってなるほどと思った。クラウドの利用だと負債扱いだけど、自社サーバだと資産扱いということなんだろうか。案外、会計的にはオンプレミスのほうがいいということなのかもしれない(そんな単純なことではないけど)。
    ビッグデータの処理については詳しくないのだけど、Amazon EMRよりは、Google BigQueryのほうが速いとのこと。EMRで30分かかることが、BigQueryでは3秒になったらしい。その違いを実感した時は、確かに感動的だったんだろうなと思う。
    管理画面の実装は汚くていいというのはかなり自分にも心当たりがある。セキュリティもたいして気にしなくていいだろうしと思ってのことだけど、やっぱ保守についても考えて開発したほうがいいのだろうな。
    古いドキュメントを有効だと思って参照してしまう話も心当たりがある。最初のリリース時に資料を作るけど、以降の改修では資料を更新しないとか。まあでも、前に何かの本に書いてあったけど、今動いているコードが仕様という考えにしたほうが、手間もかからないしいいのかな。仕様を分かりづらくしないインタフェースにするというのが一番大事なんだろうなと思った。
    それにしても、いくらレガシーなシステムだからといって、データベースに1200を超えるテーブルがあるという話は驚いた。Yahoo!ぐらい様々なサービスがあるなら分かるけど、ECナビ一つで何でそんなに数が多くなるのかと。そりゃ、情報が重複してるし誰も管理できないだろうなと思う。他のWebサービスではどれぐらいのテーブル数なのだろうか。
    ISOに性別に関する規格があることを初めて知った(ISO 5218)。今でも、性別を選択するサービスに、男と女しかないことあるけど、こういう概念は変えていかないといけないのだろうな。
    システム開発において、依頼する場合はなぜ必要かを聞くようにしているというのは大事だと思う。なぜが分かれば、他のいい方法を提案できるかもしれないしね。たまに、「画面をこう変更して」としか言わない人いるけど、なぜかも伝えてほしいとは思う(だいたい理由を予測できることではあるのだけど)。
    依存ライブラリを毎週更新する(ガーデニングというらしい)ようにしているという話は驚いた。それだけテストをしっかりと書いてるということなんだろうなぁ。ただ、やっぱり工数はかかってしまうらしく、VOYAGE GROUP内のfluctというサービスも昔は頻繁に更新してたそうなのだけど、やめたらしい。
    本題と関係ないけど、就活サービスの『サポーターズ』を担当している、@nekoya という方のプロフィールで「就活サービスをやっているけど、就職活動をしたことがないのが悩み」というのに笑った。そんな人もいるのか。

  • 【所蔵館】
    総合図書館中百舌鳥

    大阪府立大学図書館OPACへ↓
    https://opac.osakafu-u.ac.jp/opac/opac_details/?reqCode=fromlist&lang=0&amode=11&bibid=2000952199

  • 事業をエンジニアリングする技術者たち
    VOYAGE GROUP https://voyagegroup.com/
    ネット広告 https://voyagegroup.com/service/ad-platform/
    ポイントメディア https://voyagegroup.com/service/pointmedia/
    ゲーム攻略サイト、就職情報サイト https://voyagegroup.com/service/incubation/
    で、2000年-2020年の事業変化、クラウド黎明期(2010年前後?)からの技術変化によって生じてくるレガシーコードとの闘い方、ビジネス/技術判断を追体験できた気がする。

    安易にフルリプレイス、ビッグリライトを選択するのが簡単な気がしたり、技術力を活かせる、評価を高められる気がするが、それがうまくいくほどビジネス環境は単純ではなく、リアーキテクティング、リファクタリングを地道に続けたほうがうまくいくという事例だった。
    1つだけリプレースしたシステムがあったが、それも状況によっては旧システムを捨てない選択肢も残しながら慎重に進めていた。
    そんな過去の開発者やビジネス側のステークホルダーを安易に批判しない態度に、共感し誇りを持てる。

    式年遷宮、テセウスの船のようなアプローチで、残すべきものを残しながら新しく生まれ変わらせる。
    事業の撤退縮小、機能の縮小、コードの削除によって役割を終えたものを葬るための、経営判断には技術的なコストの理解が不可欠になっている。
    週末のガーデニングのように依存パッケージのバージョンアップを取り込む。
    業界は違っても同じような開発の日々や、真似したい活動がいくつも出てくる。

    ネット広告にはなんとなく批判的な印象を持っていたが、技術やメディアが成長し
    よりよいネット社会を実現していくためには不可欠な事業なのかなと応援したくなった。

    関連ブログ:

    エンジニアがエンジニアの求人を本気出してつくったことを通して、本当に言いたかったこと
    https://note.com/ryosuke_kawamura/n/nb5fc4d34a7c8
    株式会社Zucks アドプロダクト事業本部 Webアプリケーションエンジニア
    https://hrmos.co/pages/voyagegroup/jobs/zu-e04

    Netflixにおけるフルサイクル開発者―開発したものが運用する
    https://techlog.voyagegroup.com/entry/2019/02/04/171325

    デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。
    https://techlog.voyagegroup.com/entry/2019/02/19/182539
    事業、機能、コードを葬る。

    動的解析を利用し、実働6日でレガシーコードを1/3削った話(Perl編)
    https://techlog.voyagegroup.com/entry/2020/05/07/120000

    運用、追加開発しづらいPHPアプリケーションに未来を与える方法
    https://speakerdeck.com/ara_ta3/yun-yong-zhui-jia-kai-fa-siduraiphpapurikesiyonniwei-lai-woyu-erufang-fa

    毎週のように依存パッケージを上げ続ける努力
    https://techlog.voyagegroup.com/entry/2016/06/27/080000
    ガーデニング

    セマンティック バージョニング
    https://semver.org/lang/ja/

    Pattern Recognition and Machine Learning
    パターン認識と機械学習-上-C-M-ビショップ
    https://www.amazon.co.jp/dp/4621061224/

    Google BigQuery で DWH 構築 / Naoya Ito
    https://www.youtube.com/watch?app=desktop&v=2ADUzBjMmr8

    「人工知能でいい感じの成果を出してくれ」という偉い人の脳内はどうなっているのか
    https://tokoroten.medium.com/96f4da85b924

  • ビジネス書か技術書かで言うと微妙なところだが、ソフトウェア事業におけるエンジニアたちの取り組みの「組織的、ビジネス的」な面が強いため、ビジネス書とした。

    ここまで具体的にソフトウェアエンジニアの仕事の機微について触れられた本が他にあるだろうか。技術的負債にどう立ち向かっていったのか、事業をスケールさせるためにどういう設計や組織構造を選んでいったのか、そういったウェブ業界のエンジニアの「あるある」な仕事の難しさが語られているが、それらに取り組む上でのビジネス的な視点をエンジニアたちが大切にしていたのが強く伝わってくる。同じ業種のものとして共感しかない上に、そういった先人たちの背中をしかも具体的な事例を通して見れるのが最高にエキサイティングだった。

    ウェブ業界のソフトウェアエンジニアとしてのキャリアを志す人にはぜひ読んでほしい。

  • ITエンジニア本大賞より (https://www.shoeisha.co.jp/campaign/award)

  • 内容は面白い!
    でも読みにくい!エンジニアにはそんなことはないかもしれないけど...
    プロジェクトX、IT版という内容で、次々と起こる難題にエンジニアが立ち向かうという感じですね。
    信頼できるヒト=rootを任せられるヒトというのが実感こもっててイイですね。
    このご時世、WaterfallかAjileかなんて区別するのはナンセンスですかね。

  • [技術書・ビジネス書大賞] 2021年技術書部門大賞・特別賞

  • 世の中のサービスはエンジニア達の地道な努力によって成り立っていることを実感した。
    特にエンジニアの仕事は0から1を作り出すものや10から20に増やすものに注目されがちだが、100を80、60と減らすという意識をもつことも重要だと感じた。いかに無駄なシステムを作らないか、技術的負債を後に残さないかを考えるのは地味な作業だが、エンジニアの本質と言えるのかもしれないと感じた。

    また、自分自身もエンジニアとして働いているため、共感できる部分や、そういう考え方をしてプロジェクトを進めていくのかといった新たな発見も得られた。
    他社の実際のプロジェクト進行を細かく知ることのできる機会はなかなかないと思うのでこの本は非常に参考になった。

  • 技術や組織論もそうだけど僕にはエンジニアの「知恵」と「勇気」の話に読めた

全14件中 1 - 10件を表示
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×