はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
ブラウザで動くサービスを作るときの技術選定
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます（サービスに必要なのはもちろん、運用する自分が楽だから）。 前提 エンジニ
初めての技術選定を頼まれた時に大事だったのは俯瞰的・相対的な考え方だった - MonotaRO Tech Blog
背景 お題 技術の差別化 差別化から分かること 情報資産からToBeを考える 俯瞰的・相対的な技術選定 これまでの話から学んだこと 最後に はじめまして、MonotaROでデータエンジニアをやっています、芝本です。 エンジニアのみなさん、技術を使って何か作ってみるのって楽しいですよね。 私は、公私ともに日々物作りに励んでいます。プライベートだと、最近はマイクロフロントエンドについて学んでいます。 技術を使うためには、技術を学ばなければいけません。 プライベートにおいては、好奇心に従って自由に学びますよね。 とりあえずgit cloneして動かしてみたり、書籍を購入して読んでみたりします。 というようにプライベートでは主に次のような選択肢があると思います。 書籍を読んで好きなものを選ぶ 実際に手を動かしてみて好きなものを選ぶ 人に教えてもらって好きなものを選ぶ 基本的にプライベートの場合は何
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
September 15, 2021 @ iCARE Dev Meetup #25
積極的な技術選定と消極的な技術選定 - uhyo/blog
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck
Transcript 事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1 自己紹介 ▪伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP, Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me! 今日のテーマ「技術選定」 4 何故、技術選定は難しいのか？ ▪正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい 難しいからこそ向き合う価値がある ▪今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
新規事業開発での技術選定の意思と意図 (フロントエンド編) - Sansan Tech Blog
こんにちは、関西支店で新規事業開発室に所属するソフトウェアエンジニアの加藤です。Bill Oneという新規サービスの開発に携わっています。 バックエンド編の続きとして、フロントエンドで私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきます。 Bill Oneは今年の1月ごろにピボットし、それまで開発してきたフロントエンドを全て捨て、1から作り直しました。ピボットの際に改めて技術選定を行い、それまで使っていたライブラリ等を見直したので、本稿ではピボット前後で変化した箇所を中心にフロントエンドの技術選定を紹介します。 前提 改めて前提です。私たちのチームで開発しているBill Oneは今年の5月にローンチしたばかりのサービスで、チームのエンジニアは5名です。開発しているアプリケーションはSingle Page Application (SPA) で、エンジ
【AWS】大規模なバッチ処理を支える技術選定
ここから、表で挙げた内容をそれぞれ解説していきます。 構築難度に関しては、関数を実装するだけで済むLambdaが最も簡単で、バッチ専用に特化されたサービスであるBatchに関しては比較的バッチ構築はしやすい印象ですが、ECSに関してはバッチに特化していないため、バッチ処理を行うようにカスタマイズする必要があります。 タイムアウト制約に関して留意すべきは、Lambdaの実行時間は15分までなので、それ以上を超える処理時間のバッチは実装できないことです。 起動•実行上のオーバーヘッドに関しては、Lambdaにはコールドスタートがあるため起動時にオーバーヘッドを考える必要があり、Batchではジョブをキューに送信して、最適化のために、ある程度のジョブがキューイングしてから実行しようするので、即時性を求める処理には不向きです。 既存バッチを移行したいケースがあると思いますが、Lambdaで動かせる
まぼろしのJS勉強会 #2 「細かすぎて伝わらないUI実装選手権」『使えそうで使えないけど使いたい IntersectionObserver』
業務システム SPA のフロントエンド技術選定（2023年版） - KAKEHASHI Tech Blog
本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。
Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition / Worse Is Better - Understanding the Spiral of Technologies 2019 edition
2019年5月17日（金）@ Oracle Code Tokyo 2019 https://www.oracle.co.jp/events/code/2019/
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
kintoneマイクロサービス化検証プロジェクトのWebフロントエンドにおける技術選定 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームのsakitoです。 本記事ではkintoneをマイクロサービス化するためのPoCプロジェクトにおけるWebフロントエンドの技術選定について紹介します。 プロジェクト背景 本記事で扱うプロジェクトは「kintoneマイクロサービス化Proof of concept(PoC)プロジェクト」です。 現在サイボウズの主力製品であるkintoneは大きなモノリシックなアーキテクチャになっています。 モノリシックなサービスに関わる人数が増えるに伴って、意思決定や開発速度の低下が課題となってきています。 モノリシックなアーキテクチャや組織によって起こる課題を、マイクロサービスとして切り離して小さくすることで解決ができるのではないかと考えました。マイクロサービス化にあたって、まずはPoCとして一部の機能をマイクロサービス化するプロジェクトを発足し、kinton
プログラミングが好きなエンジニアの渡辺です。 先日 TechMTG という社内のエンジニアミーティングの場でお話させて頂いたことを書いてみようと思います。 表題の「正解にする力」というのは様々な意思決定に適用出来るものとして考えていますが、今回は技術選定という観点でお話します。 技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。 選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。 これらは重要であり、検討、準備することは必要ですが、それに加えて「正解にする力」というのも重要なのではないか？という提案です。 まず、組織における技術選定とは「正解を選ぶ」ことではないと思っています。 これはその技術選定結果はその人個人についてまわるのではなく、組織として
これは、k8sクラスタを個人で運用する際に行った構成要素の技術選定の記録である。 技術選定の理由を書くのも見るのも楽しい、という心情のもとにここに公開する。 前提知識 以前、こんなエントリを書いた。 bitcoinのfull nodeをAWSでなるべく安く運用してみる - でこてっくろぐ ねお 上記の通り、個人でbitcoinのfull nodeという、状態をバリバリもつサービスを、AWSでのコスト面で最安を狙って作り運用を行っていた。 しかしその後、Oracle Cloudで運用したほうが安くなることに気づいたため引っ越した。 Oracle CloudではARMのVMが4台無料で使えて複数台構成が組め、AWSやGCP同様k8sのマネージドサービスもあり、また仕事でk8sを扱う部署に異動したのもあり、勉強のためk8sクラスタ上で運用することにした。 構成要素 以下の構成要素を選択している。
Kotlinエバンジェリストとして、ガッカリしょんぼり…！？ Ubieが、KotlinをやめてGoとNode.jsへの転換を決定したことについて、私がこれをどう受け止めたのか… こんにちは。私はたろうと言います。 Ubie株式会社 Ubie Discoveryに勤めるソフトウェアエンジニアです。 業務外では、Kotlinエバンジェリストとして講演や執筆を行なったり、技術カンファレンス「Kotlin Fest」の運営代表を務めたりしています。 先日「Ubie は Go と Node.js の会社になります」という記事が、同じくUbie Discoveryのyukuというソフトウェアエンジニアにより発信されました。 新しいアプリケーションを立ち上げる際には、その役割に応じてGoで書くかNode.jsで書くかの2択となり、今後はKotlinを使わない。記事の内容を噛み砕くと、そんな感じです。 私
はじめに 今回の記事では、私が実践しているWebアプリを開発するための技術選定のポイントを徹底解説する。一概には言えないが、同時に私が普段個人開発で扱っている技術を中心に紹介する。 今回の記事がプロダクトの技術選定で迷っているプログラマーに届けば幸いである。 技術選定の原則 技術選定する上で重要なポイントは、その技術を学ぶことで得られるメリットや効率化できる部分を徹底的に調べることである。この行為は単なる時間の無駄ではなく、プロジェクトの技術選定の際にもよく実施される。言い換えれば、メリットがない技術は今学ぶべきではないということだ。 調べる方法はQiitaやZennで「技術選定」と検索して、評価の高い記事(Qiitaの場合は「LGTM」が多い記事、Zennの場合は「♡」が多い記事)を中心に調べることを強くオススメする。まずは先人の知恵を徹底的に模倣することから始めよう。 時間は有限で、か
API設計が楽でコア業務に集中できるように。GraphQLで開発がどう変わったか？タクシーアプリGOの中の人に聞きました【技術選定の裏側：GraphQL編 vol.1】 | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
ハイクラスエンジニア向け転職・求人サイト。自社開発のWeb企業の求人多数！GitHub登録をすると、IT/Web企業とマッチングします。ユーザーサクセス (キャリア)面談も実施。
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
技術選定と、組織のかたちと、セキュリティ
技術選定について最近の私生活や労働を通して考えたことを、つらつらと書き下した文章（ポエム）です。 他者に伝えることではなく、頭の中におぼろげに存在する考えを言語化して客観視することを目的に書いた雑記なので、 誰かにとっては当たり前なことも、誰にも当てはまらないことも書いてあるかと思います。 またここで述べることは、こうやって書き下した時点での僕の考えに過ぎないので、明日僕は全く別の考えを持って行動しているかもしれません。 いわばこれは僕の思考のスナップショットです。 諸々、ご容赦ください。 技術選定そのもの ソフトウェアの開発においては、どこからが開発者の作るものの責務であり、どこからがその下のレイヤの責務であるかを（あるときには能動的な思考より、またあるときには受動的な思考により）明確にする、という知的活動を繰り返していくことになります。 この営みは、開発するソフトウェアに関する前提を定
新規事業開発での技術選定の意思と意図 (バックエンド編) - Sansan Tech Blog
こんにちは、新規事業開発室に所属するソフトウェアエンジニアの加藤です。私は関西支店でBill Oneという新規サービスの開発に携わっています。 弊社にはSansanのカタチという企業理念があり、働く人々が体現すべきValuesの1つに「意思と意図をもって判断する」があります。ソフトウェアエンジニアとして、意志と意図をもって利用する技術を選定することは当然かもしれませんが、細部までそれを徹底するのは難しいこともあります。本稿では、私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきたいと思います。 などと硬めのことを書きましたが、他所のチームでは普通に使われているライブラリを意外と知らなかったりするので、似たような記事を読みたいなと思って、技術選定を公開してみる次第です。まずはバックエンド編です。 前提 私たちのチームで開発しているBill Oneは今年の
ZOZOTOWN Webフロントエンドリプレイスにおける CSS in JS の技術選定で Emotion を選定した話 - ZOZO TECH BLOG
はじめに こんにちは。ZOZOTOWN開発本部フロントエンドの菊地（@hiro0218）です。 現在、ZOZOTOWNではWebフロントエンド技術のリプレイスプロジェクトが進行しています1。本記事では、WebフロントエンドのリプレイスでCSS in JSの技術選定をした際の背景や課題についてご紹介します。 既存技術スタックの課題 リプレイス以前の環境は、Classic ASPのテンプレートエンジンに依存したUI実装が多く存在しており、新規開発や変更のタイミングで実装をReact + CSS Modulesへ改修しています。そのため、レガシーな実装とモダンな実装が共存した状態です。 こういった背景から、リプレイス以前のUI開発では以下のような課題がありました。 グローバルなCSSが多く、CSSの変更がどこへ影響するのか予測しづらい Classic ASPのテンプレートエンジンに依存したUI実
この1年くらいでgolangとGCPを使ったWebアプリケーションをフルスクラッチで開発したので、その際の技術選定の理由だったりを言語化して残しておきたいと思い、HHKBを手に取りました。 少し長くなってしまいましたが、どなたかの参考になればと思います。 どんな人が書いてるの？ 立ち上げ期のスタートアップCTOをしています。雑に言うとフルスタックエンジニアです。 開発歴はざっくり、Androidアプリの開発歴が一番長くて3年、バックエンド開発（Elixir × GCP）に転身して1年ほど担当、その後、これから言語化するプロジェクトを1年くらいかけてgolangで構築したところです。 今回の範囲からは外れますが、並行してNuxt.js×TypeScriptで書かれたフロントエンド開発も行っていたので、今はその辺りも一通り習得しています。 1. 方針 表題にもある通り、少人数での爆速開発を目指
インクリメンタルに新しい技術を取り入れる方法 [/karte-blocks-incremental-development/]では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。
NestJSでスケーラブルなBFFを構築。メルカリShopsエンジニアがGraphQL活用のリアルを語る【技術選定の裏側：GraphQL編 vol.2】 | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
ハイクラスエンジニア向け転職・求人サイト。自社開発のWeb企業の求人多数！GitHub登録をすると、IT/Web企業とマッチングします。ユーザーサクセス (キャリア)面談も実施。
Webアプリケーション開発は専業化が進んできている 清野隼史氏（以下、清野）：今、リプレイスの話や、こういうところを作っていくのならRails以外使ってもいいかもという話が出たので、そのままテーマ2「今後のWebアプリケーションはどうなっていくか」にいきたいと思います。そもそもRailsだけではうまく立ち行かなくなってきているのは、Webアプリケーション自体の環境の変化が大きいのかなと。 テーマに「今後」と書いていますが、これからWebアプリケーションの開発の現場や環境はどうなっていくのかを整理したいと思います。変化として大きいのは開発体制だと感じているのですが、いかがでしょうか？ 櫻庭洋之氏（以下、櫻庭）：弊社では、サーバーサイドもフロントも、時にはインフラも含めて全般をやるタイプのエンジニアが多い。昔からWeb界隈は1人でなんでもやる人が多かったと思いますが、採用活動をしていると、サー
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
atama plus の osuzu です。 atama plus では、これから段階的に Web ベースプロダクトのフロントエンド開発で React を用いて SPA(Single Page Application) へリプレイスしていきます。 参考: 技術課題のないプロダクトなんてものはない！Django→React リプレイスの意思決定に至る atama plus 流の軌跡 この記事では SPA の技術選定にあたって考えたことを共有します。 プロダクトについて 技術選定はプロダクトの置かれた状況によって意思決定が変わると考えているので、リプレイスするプロダクトについて補足します。 atama plus は塾などで利用可能な学習アプリ「atama＋」を提供していますが、一連のプロダクトの中に塾本部の方が管理のために用いる業務アプリがあります。 今回リプレイスするのはこちらの業務アプリで
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study パフォーマンスに苦労している並列処理システムを改善するために Stackdriver Traceを導入して動作の可視化を行った結果、 ボトルネックの存在が判明してパフォーマンスを改善できた事例について紹介します。 この事例でStackdriver Traceを選定した過程や OpenTelemetry へコントリビュートした経緯についても共有します。 また、新規開発のGraphQLサーバへ導入して REST APIサーバと通信をまたいだ可視化を行った事例についても紹介します。
Next.js App Router を例に考える、技術選定・技術との距離感 #技術選定_findy / findy 2024-01-24
https://findy.connpass.com/event/306714/
技術選定に理由を書く仕草｜izm｜pixivFANBOX
エッセイです。全体公開しておきます。 エンジニア稼業をやっていると、技術選択をする機会は幾度となく訪れます。 「なぜこの言語を？」「なぜこのフレームワークを選んだの？」みたいな大きな技術選定ばかりを指して「若いうちは技術選定をさせてもらえない」「アーキテクトの人が全部決めてしまう」みたいなことを思...
フロントエンド未経験のSREエンジニアが挑んだ技術選定のリアル体験 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは！株式会社ラクスの@kzak_24と申します。 インフラ開発部 SRE課に所属しております。 さて今回は、現在アサインされている新規システムの開発プロジェクトにて、フロントエンドの技術選定を担当した時の経験をまとめようと思います。 フロントエンドは未経験だった為、色々と試行錯誤を行いました。 未経験なりにどのような基準を設けて技術選定を行なったか、皆さまの意思決定の参考になれば幸いです。 目次 SREチームの紹介 前提 チームの背景 検討内容と採用理由 言語 / FW 状態管理 スタイル テスト まとめ 最後に SREチームの紹介 まず始めに、少しだけSREチームについて紹介させてください。 ラクスのSREチームは2021年に発足した比較的新しい組織であり、下記の2つのチームに分かれています。 BP(Business Platform)チーム 社内業務システムの開発/保守/運用を
フロントエンドの技術選定
ある製品開発で管理画面を作ることになりました。その際にフロントエンドの技術に疎いプロジェクトマネージャーが技術選定から始める必要がありました。基本的に誰がやっても技術選定は難しいです。選定の成否は決めた時点では分からないからです。フロントエンドに詳しいメンバーがチームにいれば委譲したり、メンバーがなんらかの技術に精通していればその技術を選択するという考え方もあります。しかし、残念ながら、私たちのチームではそういう状況にありませんでした。そこで覚悟を決めて、分からないなら分からないなりに1から調査して技術選定を行うことにしました。 本稿では、主に次の内容について説明します。 どのように技術選定を進めたか どのような調査を行ったか 最終的にどういう視点で技術を選定したか 昔ながらのテンプレートを使ったサーバーサイドレンダリングは生き残れるか 私が引き継ぎをうけたとき、前任者がプロトタイプとして
こんにちは、Web チームの井手です。 この度 NIKKEI Professional Media（通称 Promedia） という新媒体をリリースしました。各トピックに特化したメディアで、現在は 日経モビリティ、日経GX、日経テックフォーサイトが展開されています。 これまで日経 Web チームでは特定のFWを利用せず、長年JSXをテンプレートエンジンとした独自FWを開発して、モノレポとして運用していました。これはチューニングの余地を自分で確保することや、自分たちのチームにあった規約を作りやすくするための選択です。しかし Promedia の開発は電子版本体のリリースサイクルと外れるためにモノレポの中に入れたくないことや、長年の開発の負債を引き継ぎたくないこと、なによりNextJSエコシステムの発達によって僕たちの要求をカバーできつつあることから、試験的にNextJSを採用して開発してみま
こんにちは、多様な食を多様に届け、「まいにちの食事」を、おいしく笑顔にしたい @yagitatsu です。 (ちょっと長い？w) 息を吸うように仕事のことを発信できるようになりたいな、ということで仕事でも、noteを再開しようと企んでおります。 会社の近く。秋の目黒川も良きですね🍂本日はCTOらしく、今まで行ってきた技術的な意思決定について、成功と失敗について自分の言葉で語ってみようと思います。 注意点なのですが、前提として、環境やチームによって何を成功とするかは違うと思うので、「へー、こういう考え方なんだね〜」という感じで、軽い気持ちで読んでもらえればうれしいです 😃 技術選定の成功/失敗とはどういう状態かそもそも、技術選定について、成功とはどういう状態で、失敗とはどういう状態か、言語化してみようと思います。 まず、技術選定の成功とは、「この技術を選んでよかった。今後も続けていきたい
Chatwork のプロダクトフェーズと技術選定の流れ - Chatwork Creator's Note
こんにちは！ Chatwork 株式会社のプロダクトマネージャー (PM)、宮下 (@ryugoo_) です。 2013 年にモバイルアプリエンジニアとして入社し、 2014 年に Android 専任になり、 2019 年からは PM に転向してそろそろ 2 年になろうとしています。 さて、今回はエンジニアから PM になった私から見た、 Chatwork の技術選定の流れの変化について話してみようと思います。 技術選定の歴史 2013 年 - PMF を目指すために 2014 〜 2016 年 - 技術的課題を解決するために 2017 〜 2020 年 - ユーザー影響を最小化するために これから - 攻めた技術選定を、ユーザーのために 2013 年 - PMF を目指すために 2013 年当時の Chatwork は PMF (Product Market Fit) を目指すフェーズ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
フロントエンドの技術選定
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
技術選定で失敗しない、正解にする力 - クックパッド開発者ブログ
個人運用k8sクラスタの構成要素の技術選定 - でこてっくろぐ ねお
Ubie創業期にKotlinを導入した私が、社の技術選定の転換について思うこと｜たろう｜note
Webアプリを開発する際に必要な技術選定のポイント
技術選定とアーキテクトの育成について - NRIネットコムBlog
Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog
少人数での爆速開発を目指してgolang×GCPの技術選定をした話
CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
エンジニアの傾向は“なんでもやる人”から“スペシャリスト”に Webアプリ開発の体制変化で生まれた技術選定の課題
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
React SPA の技術選定で考えたこと（atama plus のケーススタディ）
日経の新媒体における、既存資産を活かすフロントエンド技術選定 — HACK The Nikkei
Chompy創業3年間の、技術選定の成功と失敗を振り返る｜yagitatsu