プロダクトの機能の肥大化をどのように防ぐか？
PM Library サンフランシスコのスタートアップでプロダクトマネージャーをしています。日本語では読めない、プロダクトマネジメントに関する深い分析記事・エッセイをキュレート・翻訳し、公開しています。定期的に更新しているので、メール登録して頂けると幸いです。 プロダクトを作るとき、どの機能を作り、どの機能を手放すかの線引きが難しいことがあります。この線引きがうまくいかないと、「フィーチャー・ブロート（Feature Bloat）」という、プロダクトが遭遇する最も恐ろしい用語に行き着くことになります。 フィーチャークリープ、フィーチャーファイト、フィーチャーオーバーロードとも呼ばれるように、機能が多すぎることは、すべてのチームが気をつけなければならないことです。顧客離れ、複雑すぎるプロダクト、そして予期せぬ技術的負債につながる可能性があります。 このような罠を回避し、目的を持って機能を構築
プロダクトが成長し、コードベースが増えてくれば、その分負債もたまる。いつリファクタリングをするべきか、丸っと一から作り直すべきか、それとも小さくマイクロサービスとかに剥がしていくべきか、いろいろ選択肢はあると思います。 銀の弾丸なんてなくて、結局はユースケース次第ってことになるんだろうけど、先人たちの知恵はありました。Netscape, Basecamp, VS Code, etc. これらのプロダクトの開発の裏で、どんな意思決定が下され、どういう結果をもたらしたのか、詳細に解説されている記事です。 RailsのDHHとかも出てきます。プラクティスを学ぶだけじゃなく、単純な読み物としても、プロダクトや会社の歴史が知れておもしろかったです。 結構長い記事で、日本語訳で2万字近くになりました。（疲れた） ▼元記事 以下、訳です。 「ソースコードが錆びてしまったかのようだ！」 ー ジョエル・スポ
こんにちは。サーバーサイドエンジニアの薮です。 もうすぐGWですね。みなさんは今年のGWに何か計画を立てていますでしょうか？ 「時間があるしインプットに当てたい」 「特に予定を立ててないし本でも読もうかな」 「最近本を読んでいないので何か読んでおきたい」 そんな方もいるかなと思いまして、今回はコロプラのサーバーエンジニアがおすすめするGWに読みたい技術書をご紹介したいと思います。 低レイヤ周りの基礎知識 1) コンピュータシステムの理論と実装 2) マスタリング TCP/IP 入門編 3) パケットキャプチャの教科書 4) ふつうのLinuxプログラミング 5) Goならわかるシステムプログラミング 6) Go言語による並行処理 7) Go言語でつくるインタプリタ 設計 8) エリック・エヴァンスのドメイン駆動設計 9) Clean Architecture 達人に学ぶソフトウェアの構造と
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、初日の記事です。 これはなに？ 日々の開発をただ漫然とこなすだけでなく、獲得した技術や知識を外に向けて発信することは、他のエンジニアを助ける、自己の成長につながる、思わぬ機会を得られるなど、さまざまな恩恵をもたらします。 Qiitaアドベントカレンダー2022という折角の機会ですから、あらためて技術発信することの意義や恩恵を見直し、モチベーションアップに繋げられればと思います。 また、本記事に記したノウハウによって、発信内容のクオリティアップに少しでも貢献できればと思います。 この記事のゴール 以下の理解を得ることをゴールとします。 技術発信はさまざまな恩恵をもたらすこと 技術発信がより有効なものとなるノウハウを把握すること 筆者の発信実績 説得力を持たせるために一応記載します
この記事は クラウドワークス Advent Calendar 2021 の１日目の記事です。 crowdworks.jp でフロントエンドの可能性をやはり模索し続ける @yamanoku です。アドベントカレンダーを今年もやっていきます。去年と引き続き、初日の盛り上げ手としてやっていきます。よろしくおねがいします。 フロントエンド活動の振り返りをしてみよう 去年もフロントエンド活動の振り返りをしてみましたが今年もやっていきます。 報告ができるということは、なんらかの進捗が出ているということだと思います（解釈）。 そして、現時点ではフロントエンド専属チームは存在していませんが、徐々にその役割が見えてきたことがあるのでその報告もさせてもらえればと思います。 それでは、ご覧ください。 全体総括編 #frontend を #jp_frontendに分化 Slack のチャンネル名を変更した話です
crowdworks.jp のフロントエンド活動を振り返る 2022 - クラウドワークス エンジニアブログ
この記事は クラウドワークス Advent Calendar 2022 の１日目の記事です。 クラウドソーシングサービス「クラウドワークス」（以下 crowdworks.jp）にてエンジニアをしております、フロントエンドの可能性をしつこく信じ続ける @okuto_oyama です。 一昨年・去年と引き続き、今年もアドベントカレンダー初日の盛り上げ手としてやっていきます。よろしくお願いします。 フロントエンド活動の振り返りをしてみよう 一昨年・去年もフロントエンド活動の振り返りをしてみましたが、今年もやっていきます。 qiita.com engineer.crowdworks.jp 去年と変わらず crowdworks.jp にはフロントエンド専属チームというものは存在しておりません。ですが、今年は去年よりも重要なフロントエンドにまつわる活動をしてこれたと思っています。 それでは、ご覧くださ
テスト技術者資格制度 Foundation Level シラバス Version 2018.J03 International Software Testing Qualifications Board テスト技術者資格制度 Foundation Level シラバス International Software Testing Qualifications Board Version 2018 ページ2／86 2019 年 8 月 26 日 © International Software Testing Qualifications Board ©日本語翻訳版Japan Software Testing Qualifications Board Version 2018.J03 Copyright Notice This document may be copied in its en
メリークリスマスイヴ！エンジニアリングマネージャーの さとうだいすけ @dskst9 です！ この記事は Engineering Manager Advent Calendar 2019 24日目の記事です。 みなさんはプロダクト作りを楽しんでますか？ 私達エンジニアの存在意義であるプロダクト開発において、プロダクトマネジメントは切っても切れない存在です。 本稿では、エンジニアが持つべきプロダクト思考とは何かを探求します。 エンジニアにとってプロダクトとは プロダクトの価値がゼロになると プロダクトにおける技術的負債の返済 プロダクトの機能と価値と負債 プロダクトの価値を高める、あるいは負債を返済する ストーリーを知る ファクトを集める 機能の価値を見極める ネゴシエートする 成長するプロダクトを描く おわり エンジニアにとってプロダクトとは 私達は機能を作っているのではなく、プロダクトを
Object-Oriented Conference概要 ※イベント及びセッションの概要は公式HPから引用しました。 2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学 #ooc_2020 Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。 オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。 オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！ 開会の挨拶 オブジェク
チーム横断組織の活動を成功へ導くファシリテーション技術 - スタディサプリ Product Team Blog
こんにちは。ソフトウェアエンジニアの @ttokutake です。 今回はスタディサプリ小中高プロダクト開発部の技術戦略横断ワーキンググループをリードしていたときに 実践していたことや気をつけていたことを書き出してみようと思います。 もう少し具体的に言うと、ワーキンググループの活動においてどのようにファシリテーションを工夫したかという内容になります。 技術戦略横断ワーキンググループとは 詳しくは以前書いたブログ 技術戦略横断ワーキンググループの活動報告 の この部分 をお読みいただければと思います。 改めて簡単にグループについての説明をすると、以下のような感じです。 「組織横断で解決すべき技術課題にメスを入れていく」のが技術戦略グループ 技術戦略グループの中にいくつかのワーキンググループがある 「特定の分野に限らない課題・議題を取り扱う」のが技術戦略横断ワーキンググループ 技術戦略グループ
TreasureData -> Snowflake へのデータ基盤移行のお話 - FLINTERS Engineer's Blog
こんにちは、データマネジメント部でデータエンジニアをしている井山です。 この記事は10周年記念として133日間ブログを書き続けるチャレンジの15日目の投稿になります。 今回は、現在FLINTERSデータチームで行っているデータ基盤移行PRJ（実施中）についてのお話をしたいと思います。 はじめに データ基盤の現状 移行の背景 発生していた問題点 暫定的な対策 移管対応でやったこと等 まとめ Snowflakeにしてよかった点 リソース問題はほぼ解消 格納できるデータ量も無制限なのでライフサイクルも廃止（全期間のデータを格納できる） コスト的な部分でのメリット DWHの構成管理ができるように（一部例外はあるが） メタデータ関連がかなり強力 副次的にいらない・使っていないデータソースとかを排除する動きが活発に 困ったこと・苦戦したこと Digdag WFからのSnowflake接続 Treasu
Amazon の製品検索で使われるロバストなキャッシュ手法の論文「ROSE: Robust Caches for Amazon Product Search」
Amazon の製品検索で使われるロバストなキャッシュ手法の論文「ROSE: Robust Caches for Amazon Product Search」 2022-03-03 Web 検索とデータマイニングのトップカンファレンス WSDM2022 のワークショップで The First International Workshop on INTERACTIVE AND SCALABLE INFORMATION RETRIEVAL METHODS FOR ECOMMERCE (ISIR-ecom) が先日開催された。 テーマは e コマース上での検索において 検索システムのスケーラビリティどうやって適合性(Relevancy)をシステムで改善したかシステムの改善についてをテーマにした検索エンジニアなら垂涎もののワークショップとなっている。 同様の検索システムや実応用に注目したワークショ
エンジニア採用で最低限にするべきことは？ 佐藤歩氏（以下、佐藤）：今村さん、ありがとうございました。全般に渡ってすごく解像度の高いお話をいただきました。私自身はどちらかというと、組織のマネジメントや人事よりの人間ではありますが、特に後半の組織パートではものすごい頷いていました（笑）。ありがとうございます。勉強になりました。 ではここからは質疑応答のお時間ということで、ZoomのQ&Aから。投票数の多い順から拾っていければなと存じます。それではさっそく1個目にあるやつですね。「エンジニア採用において、採用専門の体制を構築するパワーが組織にない場合、最低限これだけはやったほうがよいことはあるでしょうか？」というご質問ですが、いかがでしょう？ 今村雅幸氏（以下、今村）：特にスタートアップの場合「そもそも人事がいません」みたいなフェーズがあるかなと思います。これだけはやったほうがいいというのは、き
ソフトウェアアーキテクチャには、依存関係のデザインという側面がある。その目的は多くの場合において、ソフトウェアの振る舞いに対する変更容易性を高めることではないだろうか。 ソフトウェアプロダクトは、そのライフサイクルを通して、繰り返し変更し続けられていく宿命にある。それがユーザーや顧客の要求であり、彼らの価値につながるからだ。そしてその提供には迅速さも求められる。依存関係のデザインは、これを実現するために組み込まれたソフトウェアの構造なのだ。 アーキテクトの悩みのひとつは、このような目的に基づいて自らがデザインしたソフトウェアの構造が、儚く崩れ去っていくことだ。アーキテクチャとは所詮はルールでしかない。開発チームが厳密にルールを守らない限り、望ましい構造を構築・維持することはできない。アーキテクチャは脆いのだ。それこそが技術的負債の一因でもある。 無償のJavaライブラリとして提供されている
特定のフロント エンド アプリケーションやインターフェイスによって使用される個別のバックエンド サービスを作成します。 このパターンは、複数のインターフェイスのために 1 つのバックエンドをカスタマイズすることが非効率な場合に役立ちます。 このパターンは、Sam Newman が初めて説明しました。 コンテキストと問題 アプリケーションは、当初デスクトップの Web UI 用に導入される場合があります。 通常、バックエンド サービスは、その UI に必要な機能を提供するために、並行して開発されます。 アプリケーションのユーザー ベースが増えてくると、同じバックエンドとやりとりする、モバイル アプリケーションが開発されます。 その結果、バックエンド サービスは、デスクトップとモバイルの両方のインターフェイスの要件に対応する、汎用的なバックエンドになります。 しかし、モバイル デバイスの機能は
不要なコードを見極めて削除するポイント
この記事は カオナビ Advent Calendar 2023 4日目の記事です。 はじめに 皆さんはコードを消していますか？？ 不要なコードが残っていると後から技術的負債となって重くのしかかってきます。 そこで今回はコードを書くより、消す方が好きな私が不要なコードを削除することについて 日頃から行っている削除対象の見極めるポイントを書いていこうと思います。 どんなコードが不要なのか まずはどんなコードが不要なのかを知らないと消せないですね。 一応、私が考えでは不要なコードは次の通りかと思っています。 未使用な変数、定数、メソッド、関数、クラス わかりやすいですね。 使っていないコードは不要なコードと判断できます。 コメントアウトしたコード 極端な例ですが、次のようなコメントアウトしたコードは不要ですね。
この記事は 食べログアドベントカレンダー2023 の２日目の記事です。 こんにちは、食べログAndroidアプリをメインで担当しているsadaです。 今回は弊社でAndroidアプリのテストフレームワーク Spek Framework の利用をやめたお話をさせていただきます。 （タイトルが今年のDroidKaigiにあったセッションと似た感じになってますが、ちょっとノリで寄せてしまいました、すみません。） 目次 Spek Framework とは Spek Framework を利用していた理由 Spek Framework をやめた理由 Spek Framework から JUnit5 への移行 まとめ 最後に Spek Framework とは Spek Framework（以下、Spek）とは公式ドキュメント にも書かれている通り、 JavaScript の Jasmine や Ru
Kaigi on Rails 2022で気になったセッションは？『ふりかえりKaigi on Rails 2022』文字起こしレポート - STORES Product Blog
2022年10月24日に『ふりかえり Kaigi on Rails 2022』と題してイベントを開催しました。イベントでお話した内容を文字起こしレポートでお届けします。 自己紹介 kwappa：そろそろ「ふりかえりKaigi on Rails 2022」を始めます。みなさん、こんにちは。 みんな：こんにちは。 kwappa：Kaigi on Rails、みなさんお疲れ様でした。楽しかったでしょうか？このイベントは、STORES 株式会社のエンジニアを3人もKaigi on Railsの登壇者に送り込むという快挙に成功しましたので、ぜひその登壇者を集めて振り返りながら、また来年も楽しみだなという気持ちになっていくというイベントです。まず、登壇者のみなさんから一言ずつ自己紹介をもらいましょうか。藤村さんからお願いします。 藤村：藤村です。僕はRailsを10年ぐらいやってました。Kaigi o
開発効率、運用性、保守性のカギを握る「アーキテクチャ」選定ポイントとは？──ISIDの現役アーキテクトがアーキテクチャの学習ステップを解説 - TECH PLAY Magazine
アーキテクチャが不在のレガシーコードは、エンジニアを疲弊させ、ビジネスのスピードも遅延させてしまう。そんな事態を避けるためには、開発の開始段階から適切なアーキテクチャを導入することが重要だ。そもそもアーキテクチャとは何なのか。どのような種類があり、どれを選択すればよいのか。設計や実装における注意点なども含め、電通国際情報サービス（以下、ISID）の現役アーキテクトが解説する。 アーキテクチャの定義、プロジェクトにおける設計・実装を解説 株式会社電通国際情報サービス Xイノベーション本部 エンタープライズプラットフォームセンター チーフアーキテクト 米久保 剛氏 最初に登壇したのは、2008年にISIDにジョインした、米久保剛氏だ。米久保氏はアーキテクトとして複数の大型SI案件への参画を経験した後、現在は非IT部門の担当者でもノーコードで、社内の各種申請業務を電子化するワークフローシステム「
新規プロダクトでFlutterのローコードツール利用とそのリファクタリング戦略 - KAKEHASHI Tech Blog
概要 こんにちは。PocketMusubiチームの南光です。 今回は、ローコードツールを利用してアプリを開発した際に工夫した内容を記事としてまとめました。 ローコードツールの開発知見記事はあまりみない気がするので、興味を持っている方やこれから利用を検討している方の参考になれば幸いです。 ローコードツールとは ローコードツールの定義が曖昧な方も少なくないのではと思うので、一応wikiの抜粋を記載しておきます。 ローコード開発プラットフォーム (英: low-code development platform, LCDP) (ローコード(英: LowCode)とも言う)は、従来の手書きのコンピュータ・プログラミングの代わりに、グラフィカル・ユーザ・インタフェースと設定を通じてアプリケーション・ソフトウェアを作成するために使用される開発環境を提供するソフトウェアである。ローコードモデルにより、様
まえがき書いてたらめっちゃ長くなった リブセンスにおけるEMとはなんなのか 転職会議におけるEMとはなんなのか EMの必須業務じゃないけどやってるやつ 目標設定・評価 1on1 スクラムマスター エンジニア採用・採用広報 事業部全体の戦略・行動方針決定のために必要な開発関連の情報整理、事業部内への共有 転職会議の開発組織課題の検討、改善案の立案 会社全体のエンジニア組織づくり、育成 リブセンスでEMとして働く魅力 周りに悩みを共有、サポートしあえるEMがいる エンジニアもエンジニアじゃない人も開発組織の文化づくり、イベント開催などに前向き プレイングマネージャーやプレイヤーへの転向に寛容 直近の転職会議の組織課題 さいごに こんにちは！転職会議事業部でエンジニアリングマネージャーをやっている落合です。 いつも社内では自己紹介のたびに「転職会議の背景芸人としてオンライン会議のバーチャル背景で
組織を横断した取り組みに注力するEngineering Officeとは - コドモン編 - コドモン Product Team Blog
メリークリスマス！ Engineering Officeのおかぱるです🎄🎅 こちらの記事はコドモン Advent Calendar 2023とEngineering Manager Advent Calendar 2023の25日目の記事です。 私が所属するEngineering Officeは「開発チームの機動力を上げる」ことを目指し、組織横断での取り組みの推進や組織課題の解決などに注力をしています🔥 Engineering Officeがどんなことを目指し、具体的にどんな仕事をしているのかについて紹介していければと思います。同じように組織に向き合っている方の参考になったら嬉しいです...！ コドモン開発チームにEngineering Officeが誕生した背景 チームメンバー Engineering Officeが注力している分野 仲間集め 技術広報 評価の運用・改善 学びの支援
テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 International Software Testing Qualifications Board テスト技術者資格制度 Foundation Level シラバス International Software Testing Qualifications Board Version 2018 V3.1 ページ2／87 2021 年 5 月 12 日 © International Software Testing Qualifications Board ©日本語翻訳版Japan Software Testing Qualifications Board Version 2018V3.1.J03 Copyright Notice This document may be cop
tebiki.connpass.com こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会の概要 会の様子 Speeeさんの発表 セッション SpeeeさんからのQ&A 視聴者や角谷さんからのQ&A アルダグラムさんの発表 セッション アルダグラムさんからのQ&A 視聴者や角谷さんからのQ&A Tebikiさんの発表 セッション アルダグラムさんからのQ&A 視聴者や角谷さんからのQ&A おまけ〜アジャイルってなんだっけ？〜 全体を通した感想 会の概要 以下、イベントページから引用です。 「アジャイル開発は企業で実際にどう生かされているか」の具体例を知りたい皆さまに向けて、Speee社、アルダグラム社、Tebikiの3社のエンジニアが登壇して各社の取り組みを紹介します！特別ゲストに「アジャイル開発にくわしい」角谷さん(@kakutani)をお迎えし、それぞれの
月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ スタートアップへの投資を検討する際に、最も難しいのはスタートアップチームを評価することかもしれません。というのも、一見予想外のポテンシャルが発揮されるケースも実際に多いからです。例えば、Coral Capitalの投資先であるHR系スタートアップのSmartHRの創業者たちも、人事系のバックグラウンドもなければ、学歴がすごいわけでも、有名企業に勤めた経験があるわけでもありませんでした。世界有数の決済サービス企業であるStripeの創業者たちも、金融サービスの経験ゼロからスタートしています。Elon Musk氏だって、NASA
Mark Richards, Neal Ford 著, 島田 浩二 訳ソフトウェアアーキテクチャの基礎 Fundamentals of Software Architecture 日本語版は紙、英語版はKindleで読みました。Kindle版は図がカラーで見れます。 本書を読んだ感想を書いていきます。 Chapter 1. IntroductionSoftware ArchitectureとはSoftware Architectureの定義が業界でよく定まっているわけではないところから話が始まります。 その理由として、Microserviceような新しいArchitectの台頭によってsoftware architectの役割が拡大していることが挙げられています。 また、本書はsoftware architectを一度作ればその後は変更の対象にならない静的なものではなく常に漸進的に変化して
こんにちは、sumirenです。 この記事は2023年3月末でCIerを辞める筆者の退職エントリとなります！ はじめにCIerとはクラウドインテグレーターの略称で、以下のような傾向のあるSIerのことです。有名どころだと、クラスメソッドさんがわかりやすいと思います。 クラウドを組み合わせたアーキテクチャを提案する 上流工程〜下流工程まで自社でやる 上記の特徴から、大手SIerより短納期で柔軟性のある開発ができる 中小企業の割にエンプラから仕事を請けている この記事の要約要約すると次のようなことです。 CIerで幅広い技術を触れて、フルスタックエンジニアやアーキテクトとしての経験が積めた。プロジェクトマネージャや管理職も経験でき、ソフトスキルやビジネススキルも大きく高まった。CIerに入ってよかった 一方、4年間働いて、社会に役立っている実感がなかった。エンジニアリングのレベルも、フリーラン
第2章では、OKRを設定する具体的な流れを解説しました。OKRを設定する際の考え方や、注意すべき落とし穴を知ることで、適切に個人のOKRが設定できるようになりました。しかし、チームにOKRを導入するとなると、OKRを設定する知識だけでなく、強いリーダーシップが求められます。 そこで第3章では、新規プロジェクトのチームリーダーを主人公に設定し、「チームにOKRを導入する」という具体的なシナリオを通じて、OKRの導入の流れを解説します。 あなたは新規プロジェクトのチームリーダー あなたの会社では、チョコレート販売のECサイト『チョコショップ』の開発、運営を行っています（チョコショップは架空のECサイトです）。あなたは会社でベテランの開発者で、チョコショップの開発にも長らく携わってきました。 新規プロジェクトの発足 チョコショップは、一般消費者向けに順調に売上を伸ばしてきました。しかし、最
チーム開発はじめました - エムスリーテックブログ
コンシューマーチームのブログリレー3日目です。 コンシューマーチームで行ったアスクドクターズ開発の開発体制変更についてご紹介したいと思います。 はじめまして。エムスリーエンジニアリングG コンシューマーチームで主にアスクドクターズ開発のスクラムマスターの甲村と申します。 すっかり寒くなり紅葉の季節ですね。 六義園の紅葉です アスクドクターズ開発の守備範囲 元々の開発体制 体制変更と工夫した点 変更したら何が起きたか 体制変更後の失敗談 まとめ We are hiring!! アスクドクターズ開発の守備範囲 オンライン医師相談サービスのアスクドクターズは15年以上続いているサービスです。 このサービスの技術基盤はStripe、AmazonPay、 携帯キャリア決済関連にiOS決済、ネイティブアプリ（iOS/Android）やメール決済など。機能としてもコアとなる医師相談の他、企業従業員向けに
『More Effective Agile』：私のお気に入りなエンジニア向け書籍 | IIJ Engineers Blog
35年かそれ以上にわたってソフトウェア業界に携わってきた中で、一番の難題は、「コード&フィックス開発」を避けることだった。コード&フィックス開発とは、事前の見通しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである。 (中略) アジャイル開発には、見るからに短期集中型でコード中心であるために、チームがアジャイル開発のプラクティスを実践しているのか、それともコード&フィックスを行っているのかますます見分けがつかなくなる、という課題がある。壁に付箋紙がベタベタ貼ってあるからといって、チームがその作業に組織的かつ効果的に取り組んでいるとは限らない。 ――『More Effective Agile ―― “ソフトウェアリーダー”になるための28の道標』 「第4章 より効果的なアジャイルの始まり: スクラム」より IIJイノベーションインスティテュートの四谷です。普段はサー
株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week1に登壇したのは、デジタル庁CTO 兼 グリーCTOの藤本真樹氏。CTOという役職との向き合い方や求められる能力について語りました。全3回。3回目は、DXの文脈から考える、CTOの役割について。前回はこちら。 藤本氏がCTOとして当たり前に置いている基準 大谷旅人氏（以下、大谷）：CTOとしてのいろいろなトークを期待しているところもあって、その一番上のところで来ている中だと、これはどういうこと？ 「当たり前として置いている基準」。 藤本真樹氏（以下、藤本）：「当たり前として置いている基準」。当たり前、何の基準なんだろうな。「CTOとしてそのぐらいできるよねー」的な基準ですかね。 大谷：足切り基準？ （一同笑） 藤本：あぁ、そうかもしれない。 大谷：「CT
デジタルガバナンス・コード2.0 2020 年 11 ⽉ 9 ⽇ 策定 2022 年 9 ⽉ 13 ⽇ 改訂 － 1 － デジタルガバナンス・コードについて あらゆる要素がデジタル化されていく Society5.0 に向けて、ビジネス モデルを抜本的に変革（DX1 ：デジタルトランスフォーメーション）し、 新たな成長を実現する企業が現れてきている。一方、グローバルな競争 の中で、競合する新たなビジネスモデルにより既存ビジネスが破壊され る事例（デジタルディスラプション）も現れてきている。 こうした時代変化の中で、持続的な企業価値の向上を図っていくために は、 ① IT システムとビジネスを一体的に捉え、新たな価値創造に向けた 戦略を描いていくこと ② デジタルの力を、効率化・省力化を目指したITによる既存ビジネ スの改善にとどまらず、新たな収益につながる既存ビジネスの付 加価値向上
コロケーション
これは、Kent C. Dodds 氏のブログ記事であるColocationを日本語訳してみたものです。 誤訳などあればIssueや PR を頂けると幸いです。 誰もがコードベースをメンテナンスしやすい状態に保ちたいので、コードベース（もしくはその一角）をメンテナンスしやすく理解しやすくなるように最善の努力を持って始めます。 時が経って、コードベースが大きくなるにつれて、依存関係（JS、CSS、画像など）を管理するのは、より一層難しくなります。 プロジェクトが大きくなるにつれて、コードベースが”チーム固有の知識”（あなたや他の数名に限られた知識）になってしまうことは往々にしてあり、 このような知識が”技術的負債”（言葉の正確性はともかく）の原因となります。 私は、コードベースを私自身（筆者）だけではなくチームメンバー、未来のメンテナー、そして半年後の自分自身にも扱いやすい状態に保ちたいです
概要 この記事では、システムが全体停止するような致命的な障害を減らして可用性を高める事を目指して、 エラーやバグによる故障は、実績をベースに算数（算盤）で統計的に計算できる（ある程度は。） 作業量・アウトプットを増やすとエラー・バグは自然に増える 自然に増えるエラー・バグの影響は設計である程度抑えられる アプリケーションの設計には独立性や冗長性といった概念もある ビジネス（算盤）の継続性において、こうした設計の考え方が重要である というような話をします。 一般論として、全く障害のないシステムを構築運用するのは難しいと思いますが、それでも様々なエラーが発生する中でもできる限り致命的な障害を回避するのは重要です。そこでこの記事では、単一障害点の概念を通して、機能数が増えると特別な対策をしなければ自然と障害が増えることと、システム全体が停止するのを避けるような設計について、入門的な考え方を記載し
DevOpsで開発とデプロイのサイクルを高速化し、テストや監視で事前に障害を潰す。「オペレーショナルエクセレンス」実現のポイント - Qiita Zine
タイアップ トピックス DevOpsで開発とデプロイのサイクルを高速化し、テストや監視で事前に障害を潰す。「オペレーショナルエクセレンス」実現のポイント 自社のビジネスを効率化し、新たな価値を創造していくデジタルトランスフォーメーション（DX）を推進する際に欠かせないのがクラウドの力です。今やMicrosoft Azureをはじめとするさまざまなクラウドサービスが、顧客のニーズに応えるべく次々と最新技術を反映したサービスを投入し、進化を続けています。こうしたクラウドサービスをうまく活用することで、自社の価値をさらに高めていくことができるでしょう。 ただ、多くの成功例が現れている一方で、従来からオンプレミスで構築してきたインフラをそのままクラウドに持っていくだけではどうも思うような効果が実感できない、という悩みの声も聞こえてきます。こうしたときにリファレンスとして活用したいのが、クラウド戦略
オレ流プログラマー腹立つ 何で公式で用意したものをすぐぶっ壊してオレ流にするの？ 一緒にやるプログラマーは迷惑極まりないんだよ 協調性なさすぎるだろ 公式を尊重しろよ https://anond.hatelabo.jp/20190903144842 うーん，それは公式とか協調性の問題じゃないと思う． 得てしてそういう人はスキルが低いだけなんだよね．だから他の人が書いたコードを理解できないし，学習しない，デバッグもできない．そのせいで一度覚えた自分のやり方を変えられない． もちろんその逆で，その人の方がスキルが高いから，古い良くないやり方をよりよいやり方に修正してる場合もある．*1 「我がコードは我流。我流は無形。故に誰にも読めぬ・・・」 論よりコードに似ているようで全然違います、コチラの方はコードの可読性が限りなく低い！一体誰に保守させるつもりでしょうか。我流で書けるのは分かりましたから、
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 35 週目の記事です！ 1 年間連続達成まで 残り 18 週 となりました！ ログラスのQAのコタツです。今年もよろしくお願いします（2024年スタートからもう3ヶ月過ぎましたが） この前、以下のイベントに登壇させて頂きました。人生初パネルディスカッションでした...わざわざご来場いただいた方、オンラインで見守ってくれた方、設営していただいたウィングアークさん、パネラーの方々、モデレーターの大平さん、ログラスのスタッフなどなど、関係者の皆さん本当にありがとうございました！ ATN#20 BtoBプロダクトQA集合 Loglass×WingArc1st×テストの街「葛飾」 (2024/02/15 19:00〜) 今回登壇させていただいたイベントはBtoBプロダクトのQAの面白さを語るというテー
最近、ある企業が「AIイニシアチブは大成功だった」と話してくれました。3年間、プロジェクトの失敗は「ゼロ」で、7人からなるデータサイエンティストチームが毎年2つのAIユースケースを本番稼動させているとのことです。この失敗率は低すぎると思いませんか？ 仮に、あなたの組織に1000のAIユースケース候補があり、そのうちの25％はROIが大きくプラスになる可能性があるとしましょう。適切なコストで、良いユースケースを見つけるにはどうすればよいでしょう？多くの企業は、成功を確信できる少数のユースケースから始めますが、その確信を正当化するためには経験が不足しています。その結果、少数のユースケースに全リソースを注ぎ込み、ROIを見出すのに何年もかかっています。 一方、AIに成功している多くの企業では、リーンで（無駄を省いた）フェイルファストな（早く失敗する）別のアプローチをとっています。興味深い例として
『チームトポロジー』の見どころ - Qiita
背景 この記事はLIFULL社内で共有された感想文を少し書き換えたものです。 社内でもプロダクトマネジメントやそれを支える組織の話の議論が進んできつつあるように感じる。 そして私も「 『EMPOWERED』の見どころ」でまとめた内容の通り、「ソフトウェア開発チームに制度や体制が必要だ」と思いつつ、それを支える考え方を整理する必要を感じていた。 そこでちょうど『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が発売され、うまく整理するフレームワークやデザインパターンを用意してくれているように思えたので紹介してみる。 この要約では役割分担の話を重視してまとめて、全体設計やチームの分割みたいな話はごっそり抜けているので、興味ある人は自分の目で確かめてほしい👀 この本はどういう趣旨なのか？ ソフトウェア企業で働いている人は、「コンウェイの法則」というものを耳にしたことがある
医療ビッグデータを活かした事業を幅広く展開しているJMDCには、魅力的な経歴や豊富な経験を持ったメンバーが所属しています。今回は、Pep Upのバックエンドチームでテックリードを務める野田さんにインタビューを実施しました。複雑なデータを扱いながら、事業スケールをエンジニアリングの側から支えてきた野田さんに、JMDCで開発に携わる魅力を聞きました。 ＜プロフィール＞ 野田 実（のだ みのる）プロダクト開発部 ユーザープラットフォームグループ バックエンドチーム テックリード 新卒でSEとしてのキャリアをスタートし、その後スタートアップの一人目エンジニアを経験。ヘルスケア業界に興味を持ち、2018年7月にJMDCに入社。PHRサービス「Pep Up」の開発に携わり、現在はバックエンドエンジニアチームのテックリードとして従事。 Pep Upのバックエンドが注力する3つのポイント ――ご経歴を含め
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアは書き直すべきなのか｜sakuraya | CTO的な何か｜note
GWに読みたい！コロプラのサーバーエンジニアがおすすめする技術書14選 - COLOPL Tech Blog
さまざまな恩恵を得るための技術発信術 - Qiita
crowdworks.jp のフロントエンド活動を振り返る 2021 - Qiita
JSTQB-SyllabusFoundation_Version2018.J03
すべてのエンジニアが持つべきプロダクト思考とは - STEAM PLACE
Object-Oriented Conference参加メモ - Qiita
「エンジニア採用で最低限やるべきことは？」「EMはどうやって育成する？」 スタートアップから大企業まで経験したCTOがアドバイス
ArchUnitでアーキテクチャをテストする - mtx2s’s blog
フロント エンド用バックエンドのパターン - Azure Architecture Center
Spek やめました - Tabelog Tech Blog
転職会議のエンジニアリングマネージャーのおしごと - LIVESENSE ENGINEER BLOG
JSTQB-SyllabusFoundation_Version2018.J03
角谷さんと考える「アジャイルってなんだっけ？」に参加してきた - 天の月
成功するスタートアップチームの共通点 | Coral Capital
📗 ソフトウェアアーキテクチャの基礎を読んだ感想 | Happy developing
SIer(CIer)を退職して真のエンジニアリングをやります｜sumiren
第3章 チームにOKRを導入する ～メンバー内の整合性を保ち、設定と評価を繰り返す | gihyo.jp
「DXは“CTOだけが”がんばれば済む話ではない」 不要なコストをかけずに「えいや！」といくために大事なこと
Microsoft Word - デジタルガバナンス・コード2.0ｒ.docx
致命的な障害を減らすための可用な設計入門 - 設計と算盤 - Qiita
我がコードは我流。我流は無形。故に誰にも読めぬ。 - カレーなる辛口Javaな加齢日記
QAエンジニアから見た、ログラスの品質文化のユニークさを言語化できた
フェイルファスト - 面倒な技術負債を負わずに素早く失敗する話 - Qiita
約400万IDを発行するヘルスケアサービスの更なるスケールアップに向けた取り組みとは - JMDC VOICE