はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる

CCI の小坂です。 担当プロダクトの中で、以前からの課題だった ビッグバンリリースを改善したことについて書きます。 開発システムの概要 やってることはCCI の社内システムの開発で、媒体社から提供された媒体資料をもとに、原稿規定を データベース化しています。 データベースをもとに、原稿素材の規定チェックから管理までを行うことができるツールです。 技術スタックとしては バックエンドがJava,Spring Bootフロントが Vue.js,Nuxt.js を使ってます。 これまでの開発フローと課題感 リリースは2-3ヶ月ごとのリードタイムがあった 開発周りのお話です。以前の開発フローは以下です。 - ユーザー要望を issue に起票 - 1-2 ヶ月で開発を行い、ステージング環境で動作確認 - その後にリリース判定 - ビジネスサイドにリリース時期を共有し調整 - リリース この流れを

はじめに こんにちは、fluctでエンジニアをやっているyanyanです。 この記事は、仕事でバックエンド開発をするときに考えていること の続きです。 前回のスライドでは、私がバックエンド開発をするときに大事にしている考え方や思想の話をしました。今回は、じゃあそうした思想の下で実際にどういうものを私が作ったかという話をしようと思います。なので、この記事を読む前にスライドの方を読むことをおすすめします。 speakerdeck.com 何を作ったの？ すごいざっくりいうと、顧客向けWebサービスのバックエンド部分を0からつくりました。 0からと言っても、インフラ部分に関してはすでにあるECSサービスにタスクを追加するだけという形を取りましたが、アプリケーション開発というスコープでいうと技術選定からやり始めました。 どんなサービスなのか fluctが広告配信をしたり、運用支援をしている媒体社が

こんにちは！CTOのsuzukenこと鈴木です。この度、CARTA HOLDINGSとして新しく、エンジニア組織、ひいてはテクノロジーに関する将来への指針としてTech Visionをつくりました。 ここでは社内に向けたメッセージもそのままに、どのように考えてこのTech Visionをつくったのか、というのを載せてみています。オープン社内報的に読んでいただけると幸いです。 昨年末からエンジニア組織、あるいはCARTAとしてのテクノロジーに関する価値観、将来といったものをどう描こうか、と考え続けてきました。 CARTAではエンジニアリングに携わるメンバーが170人程度います。来年、あるいはその次の年にもどんどん新しい人も入ってきます。そのときに「CARTAのエンジニア組織はどこに向かうのか？」「どうなっていきたいのか？」という問いに答えなければならない。何より、自分自身が「こうしていきたい

こんにちは。技術広報のかーたー(@y_carter0405)です。 弊社ではEngineers in CARTAと題して、CARTAのエンジニアに加えてゲストに様々な方をお招きしつつ、技術的な知見を共有したり、語り合う勉強会を行っています。 その第二回目となる『Engineers in CARTA vol.2 #MySQL』を、昨年の12月17日開催しましたのでレポートします！ cartaholdings.connpass.com 当日の様子 CARTAセッション「ECナビ脱Oracle、MySQL一本化への道」 www.youtube.com DIGITALIO(旧VOYAGE MARKETING)のエンジニア、浪川 大輔による講演。 リリースして約20年になるECナビのバックエンド基盤は、OracleとMySQLのハイブリッド環境でした。 ただ、併用していることによる 概念や使い方、ク

2022年1月、CARTA HOLDINGS（以下、CARTA）の新CTOに鈴木健太（@suzu_v、写真左）が就任しました。2012年、VOYAGE GROUP（現CARTA）にソフトウェアエンジニアとして入社し、幅広い領域で開発に従事。「すずけん」の愛称で親しまれてきました。 一方、前CTOである小賀昌法（@makoga、写真右）は、VOYAGE GROUP時代から10年に渡り、エンジニアリングの観点から幅広く経営に携わってきた存在です。 小賀さんのCTO就任当時からのこれまでの10年、そしてCTO交代の経緯やCTO退任後にチャレンジする領域についても聞きました。 （記事内の写真は、撮影時にのみマスクを外して撮影しています） 後編はこちら：新旧CTO対談 後編「これからのCARTAエンジニアリング」 CTOに就任した当時の状況 鈴木健太（以下、すずけん）：小賀さんは2010年から約10

今日も@soudai1025 こと id:Soudai がお届けします。 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第五回の今回は「エンジニアによるビジネスのための機械学習」と題してデータサイエンスチーム(以下 DS)のみんなとディスカッションしてきました！ 当日の紹介資料 資料の中にDSの紹介やパネラーの自己紹介もあります。 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回は機械学習を専門に扱っていないエンジニアでも楽しめる内容でしたね。 西林さんとところてんさんのわかりやすい解説は必見です！ おすすめポイントである、そーだいさんの「なるほど…（わかってない）」を探してみてく

2020年7月4日、5日の2日間で開催された技育祭 2020では3つのセッションに登壇した @makoga です。 CTOパネルディスカッション 初日のオープニングセッションとなるCTOパネルディスカッションでは、『エンジニアリング組織論への招待』の著者であり株式会社レクター 取締役 広木さん、ビジョナル株式会社 取締役CTO 竹内さん、 合同会社DMM.com CTO 松本さんの3人をパネラーに迎え、私はモデレータとして参加しました。 https://www.youtube.com/watch?v=83P_svRogpswww.youtube.com このパネラーで面白くならなかったらモデレータの責任だなと思っていたので、たくさんの人が視聴してくれてホッとしました。 Goライブコーディング 午後には、すずけんのライブコーディングの解説役として参加しました。 ※動画が公開されたらここに追記

こんにちは！株式会社VOYAGE MARKETINGで働くエンジニアの yopidax です。 約20年ほど続くサービス、ECナビの技術的負債の返済に取り組んでいます。 ecnavi.jp 今回は直近で、レガシーコードを大量に削除したので、そのアプローチをご紹介したいと思います。 目次 目次 解析の対象と抱える課題 アプローチ 実行されるファイルを洗い出す ログを出力するモジュール 実行 ログのサンプル いざ、大量削除 Perlファイルをgrepする リリース単位を細かくする 結果 工数 実績 まとめ 合わせて読みたい 解析の対象と抱える課題 ECナビを長年支える、Perlで書かれたバッチが対象です。コードはGitLabのリポジトリで管理されていて、規模をまとめるとこんな感じです。 ファイルの数 バッチ関連全体 : 3,315 うち、Perlファイル(.pm, .pl) : 1,111 P

こんにちは。社内でWebアプリケーションエンジニアをしつつ、社内の音響サポートしている @brtriver です。 VOYAGE GROUPのAJITOでZoomを使ったオンラインイベントを何度か開催しましたが、その中の1つの日本CTO協会( https://cto-a.org/ )が主催する会員限定のイベントで実際に配信で利用した機材、設定で工夫した内容についてせっかくなのでまとめてみたいと思います。*1 cto-a.org このオンラインイベントでは全員が個別にZoomに参加するのではなく、発表者はオフライン会場であるAJITOに集まりその様子をZoomを通して配信する形式で開催しました。 オフラインの会場の様子 4行でまとめると Zoomは他のプラットフォームに比べても音質が良い。ただし癖も有り できるだけソフトウェアではなくハードウェアに頼る。ATEM mini はコスパ最強 スラ

こんにちは。Zucksでエンジニアをやっています@karahiyo_nです。 先日社内向けに「Zucksで働き学んだ成果に繋がるプラクティス」という発表を行いました。今回はその一部を紹介したいと思います。 発表では6年間でシステム構成がどう変わってきたのかと実際にやってきたタスクを紹介しつつ より妥当な意思決定をするために より早く価値を提供できるように システムの複雑性と戦う方法 などいくつかプラクティスを紹介しました。 今回はその中のひとつ「システムの複雑性と戦う方法」について書きたいと思います。 対象のシステム像 元の発表ではZucksのシステムを取り上げて解説したのですが、ここでは次のようなシステムをイメージしてください。 非常に高いサービスレベルが求められるシステム(例えばAmazon Compute SLA相当) 低レイテンシ、高トラフィック(で、さらに増加傾向) 機能要望は尽

こんにちは、CTO歴も丸9年以上になりました @makoga です。 Podcastや勉強会で話をしたときに好評だったので、今回は私が面接時に見ているポイントを書きます。 ※この文章の元ネタは2016年1月に社内に公開したものです。 面接時に見ているポイント 3行まとめ 事実と意見を分けて説明できるか 実際の課題を解決しようとしているか 技術をどう理解しているか この文章の目的 30分から1時間の面接で一緒に働きたいかを判断するのは難しいことです。私も経験を積んで学んできました。 まだ経験が浅い面接官に私が実践していることを伝えることでVOYAGE GROUP全体の判断の精度を上げていくのが目的です。 事実と意見を分けて説明できるか 圧倒的にこれは重要。これができない人はかなり厳しい。 関わったプロジェクトのなかで、自身が一番活躍できたと思うプロジェクトについて聞く 学生の場合は1人で個人

ポイントメディア事業本部の福田です。 Developers Summit 2019にて、「レガシーとのいい感じの付き合い方」と題して、ECナビの4年に渡る改善事例を発表しました。 講演資料を公開します。 セッション詳細 event.shoeisha.jp 公開資料 当日の反響(togetter) togetter.com 発表を終えて ネタが地味目なので、当日どれくらい来ていただけるのか少し不安でしたが、満員＋立ち見の盛況でした。 当日ご参加いただいた方、ありがとうございました。 アイスブレイクとして、会場のみなさんには「何年もののレガシーシステムに取り組んでいるか？」について質問させていただいたところ、「10年以上」という方が半数超え(※壇上からの主観です）で、レガシーシステムの問題は顕在化していることを実感しました。 目立たずに水面下でじわじわと苦しめられてる問題だと思うので、私達のよ

こんにちは、株式会社fluctで fluctSSPの広告配信に関わっている坂本です。 私はfluctでは新しい広告(PMP, NativeAd)の追加をしたこともありましたが、ここ1年半くらいは自分で追加した広告機能や既存機能のサポートエンジニアとして働いています。 (インフラの保守・運用は専門部署があるのでおまかせしています) 経歴 SIer(金融・ECサイト開発等)のピラミッド構造で開発に従事していた6年 Web系の会社(VOYAGE GROUPとは別会社)にてSESとして仕事をしていた4年(ここ終わりでVOYAGE GROUPに転職) Web系の会社(VOYAGE GROUP/fluct)にて正社員として2年半~現在に至る 今の自分の行動指針はSIer時代に培われたものがほとんどですが、Web系の会社に入って考えを改めたものもあるので、自分のスキルの棚卸しを兼ねてそれを整理してみます

こんにちは。 @at_grandpa です。普段はバッチを書いたりメンテナンスをしています。 今回は、先日起きた障害対応の時、チームの状態をスムーズに変えることで対応コストと精神的負荷を抑えられた、ということを書きます。 目次 目次 障害発生 普段の対応 今回の対応 原因究明と現状把握 関係者が会議室に集まる 対応用Slackチャンネルを開設 ペアワークで実対応 落ち着いたら自席&Slackコミュニケーションへ移る 対応完了の確認と報告・チケットまとめ まとめ 障害発生 先日の朝に「レポートの数値がおかしい」という連絡がきて確認したところ、とあることが原因で、バッチの自動実行が約半日行われていないことがわかりました。 普段の対応 普段の対応は以下のような形です。 エラー発生をSlackの全体チャンネルで報告 バッチ系チャンネルにて、考えや現状を垂れ流す わからないことがあれば有識者にメンシ

こんにちは、fluct SSP開発本部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です） ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明