CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。 普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。 はじめにこの10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。 C

はじめに PSR-12 とは PSR-2 と PSR-12 の違い PHP_CodeSniffer とは IntelliJ / PHPStorm でスタイルチェックする Jenkins でコーディングスタイルチェック まとめ はじめに この記事は PHP アドベントカレンダー 4日目の記事です。 qiita.com 昨日は @taro-hida さんでした。 qiita.com 僕は新卒から5年間ずっとPHPを触っているので、PHPのアドベントカレンダーにはなるべく参加しようと思っています。 PSR-12 とは PSR-12 とは、 PHP のコーディング規約です。 PHP のコーディング規約には PSR-1 と PSR-12 があり、 PSR-1 は Basic Coding Standard https://www.php-fig.org/psr/psr-1/ PSR-12 は Ext

今話題のこれ。 kubernetes.io これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。 blog.inductor.me blog.inductor.me にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない。 タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。 Dockerは非推奨じゃないし、これからもバンバン使え まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが 自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は

技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが

本連載では、「世の中で活躍するエンジニアの過去の失敗」にフォーカス。どのような失敗をし、どう対処し、そこから何を学んだのか。仕事で失敗してしまった時の対処法や心構えを先輩エンジニアから学ぼう！ 第３回目のゲストは、ニュース配信サービスを手掛けるGunosyのCTOから、グループ全体で40以上の事業を展開するDMMのCTOに転身した松本勇気さん。同社のテックカンパニー化を牽引する松本さんは、一体どんな失敗談を明かしてくれるのだろうか。就任からちょうど１年ということで、過去の話を赤裸々に語ってくれた。 合同会社DMM.com CTO 松本勇気さん（@y_matsuwitter） 1989年生まれ。東京大学工学部在学中より株式会社Labitなど複数のベンチャーにてiOS／サーバサイド開発などを担当。13年1月、Gunosyに入社。ニュース配信サービス「グノシー」「ニュースパス」などの立ち上げから

みなさんは「保守・運用」と聞くとどのようなイメージをお持ちでしょうか？ もしかしたら良いイメージをお持ちでない方もいらっしゃるかもしれません。 しかし、売り上げを生み出している既存コードの保守運用はビジネス上、新規機能開発と同等かそれ以上に重要な存在です。 保守運用は歴史あるサービスでは欠かせない作業ですが、STORESもその例外ではありません。 STORESの最初のコードが書かれてから、8年の歳月が経ちました。 今となってはコードの量も多く、今年(2020年)の8月に入社した私(@zakky)も全体を把握しきれてはいません。 STORESにジョインした最初の1ヶ月間、「商品の在庫数を一括で更新する機能」の開発に私は専念しており、その他の機能のコードを触る機会がほとんどありませんでした。 目の前のチケットを消化していくのに必死で、周りを見る余裕が無かったとも言えます。 「運用週」との出会い

こんにちは。 SRE の @suzuki-shunsuke です。 6000 行を超える巨大な .circleci/config.yml を分割してメンテナンス性を改善した話を紹介します。 背景 我々 SRE は日々 Developer Productivity の改善に取り組んでいます。 その取り組みの一環で Developer の方から直接フィードバックをもらう機会がありました。 その中で Monorepo の .circleci/config.yml が大きすぎて修正するのが大変という意見をもらいました。 弊社では様々なサービスを一つのリポジトリで管理する Monorepo というアーキテクチャを採用しており、 CircleCI で全てのサービスのテストやビルド・デプロイなどを行っています。 それ故に .circleci/config.yml は 6000 行を超えるものになっており

本連載では、「世の中で活躍するエンジニアの過去の失敗」にフォーカス。どのような失敗をし、どう対処し、そこから何を学んだのか。仕事で失敗してしまった時の対処法や心構えを先輩エンジニアから学ぼう！ 今回登場してくれたのは、ドワンゴ、クックパッドで活躍した後、現在はシリコンバレー発のスタートアップ・ローンチャブルの日本法人でプリンシパル・ソフトウェア・エンジニアを務める庄司嘉織さんだ。 クックパッド時代は人事部長や技術部長として、同社の全エンジニアが参加するハッカソンの開催や、社員の労働環境改善などに尽力していた。 「全ての人がより良く働ける環境」をつくるスペシャリストとして、エンジニア界隈で有名な庄司さん。しかし実はキャリアの中で、「俺のチームさえ良ければいい」と自己中心的に考えていた時期があったという。 自分のチームのすごさをひけらかし、マウントを取ることばかり考えていた日々を、庄司さんは「

エムスリーエンジニアリンググループ AI・機械学習チームの中村(@po3rin) です。 好きな言語はGo。仕事では主に検索周りを担当しています。 エムスリーの検索基盤ではElasticsearchを利用しています。社内で積極的に検索改善が行われており複数のIndexが管理がしづらいという問題がありました。 そこで定義ファイルからIndexの状態を冪等性を持って同期させるeskeeperというOSSを作りました。 この経験から「定義ファイルで〇〇を宣言的に管理する系のツール」を作る時のちょっとしたコツを紹介します。タイトルの通り今回はIaCツールを作るのではなくIaCのプラクティスを意識してCLIを作るお話になるのでご了承ください。 なぜeskeeperを作るに至ったか チームでのElasticsearchの運用と課題 eskeeperとは IaCを意識したCLI開発のエッセンス コマンド

Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前

AWSはNoSQLデータベースサービスのDynamoDBが、SQLで操作可能になるSQL互換のクエリ言語「PartiQL」に対応したことを発表しました。 You now can use PartiQL (a SQL-compatible query language) to query, insert, update & delete table data in DynamoDB. PartiQL makes it easier for you to interact with DynamoDB & run queries in the AWS Management Console. https://t.co/qlRwzYZCPC pic.twitter.com/pVaX5xlEDu — DynamoDB (@dynamodb) November 23, 2020 DynamoDBはキーバ

「マネージャーの間でエンジニアに対する評価基準がバラバラだ」「どのプロジェクトにどのレベルの人が配置されているかわからない」など、ITエンジニアの評価や配置について悩む企業は多いのではないだろうか。 一休のCTOである伊藤直也氏とセゾン情報システムズCTOの小野和俊氏に、エンジニア評価へのデータ活用の可能性を語り合っていただいた。 ▲左から、一休 CTO 伊藤直也氏、セゾン情報システムズ CTO 小野和俊氏 自己評価を文章化することで、エンジニアの納得感は増す お二人ともさまざまな企業でエンジニアをマネジメントされてきた経験がおありなので、こうしたツールへの期待も含めて、エンジニア評価の現状について貴重なご意見がうかがえるのではないかと思います。 まずは、それぞれ現在の会社では、どんな基準や方法でエンジニアを評価されていますか。 小野：アプレッソを含めたセゾン情報グループには約1200人の

▲登壇時の写真 はじめまして、様々なバックエンドの開発をしている竹澤（@ex_takezawa）です。 PHPやGo、Scalaなどを用いてWebアプリケーションからビッグデータを扱う分析システムや、基盤システムを行っています。 今回は、これまでエンジニアとして経験したことを踏まえて、視野を広げることや事業性を理解してシステム開発を行うことの大切さなどを紹介していきます。 みなさんのエンジニアとしてのキャリアにとって少しでも参考になれば幸いです。 副業を起点としたエンジニアの学習サイクル 副業のススメ まず、エンジニアの副業ですが、個人的には、収入が増えるというメリットがフォーカスされがちですが、本業とは異なる事業、会社の規模、ドメイン領域に触れることが出来るという点に大きなメリットを感じています。 副業で得意な開発スキルを伸ばす、ということも当然できますが、本業とは異なるドメイン領域に触

こんにちは、小松です。paizaでは編集担当をしております。 エンジニアをはじめとして、IT関連産業は非常に人材の流動性が高い業界です。 「ステップアップのため」「新しいことに挑戦したくなった」など、どうしても現状では解決できない理由で辞めていく場合はやむをえません。しかし、実際にはネガティブな理由がきっかけで辞める人のほうが多いでしょう。マネジメントをする側からすれば、できる限りメンバーの退職は避けたいものです。 よくある退職理由の1つに「この会社ではやりがいを感じられなくなった」というものがあります。一見、会社と本人の相性の問題に見えるため、そう言われてしまうとどうしようもないように感じるかもしれません。しかし、実は「やりがいを感じられない」と言わせている原因の多くはマネジメントの不備にあります。彼らからやりがいを奪っているのは会社自体ではなくマネジャーであることのほうが圧倒的に多いの

この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ

This article was inspired by John Cutler’s ’12 Signs you’re working in a Feature Factory’. The biggest problem with most Scrum implementations is not Zombie Scrum or Cargo Cult Scrum. The biggest problem plaguing Scrum is Product Owners lacking Product Management expertise. Weak Product Ownership can only lead to very efficient Feature Factories powered by Scrum. Even if everyone understands Scrum

CakePHPのDICいれよーぜPRがマージされとった🎉🎉 (タイミング的にcakefestに間に合わせたかな？) ちゃんと内容追うぞーーー Add a dependency injection container by markstory · Pull Request #14945 · cakephp/cakephphttps://t.co/GSgNp1WBNR— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年10月1日 ということがありまして、20201005現在で「4.next」に取り込まれているｽﾃｨﾀｽです！ ※ 現行の4.1のパッチバージョンについてはmasterに向けられるので、 4.nextは「次のマイナーバージョン」である4.2を指します 「CakePHPにDIコンテナが入ったらどんな感じに使われるんだろう？」というのは個人的にかねてより興味範

サーバレスの次は「ストレージレス」の実現へ。NetAppがストレージレスを実現する新サービス「Spot Storage」を発表 AWS Lambdaなどに代表される「サーバレス」（Serverless）とは一般に、サーバがないのではなく、サーバの準備や管理が不要なことを指します。 つまり、アプリケーションを実行するためにサーバをプロビジョニングしたり、アプリケーションの負荷に合わせてサーバを増やしたり減らしたり、落ちたサーバを復旧させるといった作業が自動化され、サーバの準備や運用管理が不要であるのが、サーバレスの意味するところです。 NetAppは、このサーバレスの考え方をストレージにも適用し、ストレージの準備や運用管理を不要にする「ストレージレス」（Storageless）をクラウド上で実現する新サービス「Spot Storage」を発表しました。 Spot StorageはAWS、Mi

Docker Hubの無料プランにおける利用制限、オープンソースのプロジェクトは適用外にするとDocker社が発表 Docker Hubの無料プランにおける利用制限措置が始まっていますが、Docker社はオープンソースのプロジェクトに対してはこの制限措置を行わないことを明らかにしました。 Docker has created a special program for Open Source projects to get continued free access and freedom from restrictions for their communities and their users. Read more https://t.co/91TEbbZUt3 #opensource #Docker #Containers #Community pic.twitter.com/3V

はじめに こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIシステムの運用及び監視を担当しております。 FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。 これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。 なぜサーバーレスを採用したのか FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在