イネーブリングチームの考え方と実践例 — 組織の価値提供能力をいかに高めるか
はじめに 弊社マイベストでは、エンドツーエンドの機能開発チームとは別で、組織の価値提供能力を高めることを目的としたイネーブリングチームがあります。（と言ってもまだ他チームとの兼任メンバーがほとんどですが） イネーブリングチームは、バックエンドやフロントエンドなど、領域ごとに技術課題を解決すべく活動していて、自分はフロントエンド領域を担当しています。 これまで様々な活動を行ってきたので、その考え方を整理しつつ、フロントエンドイネーブリングの実践例をご紹介したいと思います。 参考：マイベストのチーム構成イメージ（記載は一部のみ・名称は仮です） 「イネーブリングチーム」とは イネーブリングは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』、通称チートポから持ってきた名称なので、まずはチートポをベースにその役割を説明します。 https://amazon.co.jp/dp/
デッドコード撲滅のためにエンドポイントの棚卸し機能を作ってフロントエンドでの権限チェックに応用した話
導入 CloudbaseではAPIサーバにExpressを、フロントエンドにNext.jsを使用し、SWRをデータ取得ライブラリとして用いています。また、バックエンド、フロントエンドともにTypeScriptを使用しています。さらに、モノレポを採用しており、バックエンドとフロントエンドのコードに加えて、ORMのPrismaのコードやESLintのカスタムルールなどを一つのリポジトリで管理しています。Primsaといえば、弊社のエンジニアが書いたPrisma ORMを使いこなす ~歴史と対RDB運用の知見を添えて~に、Prismaを運用する中で得た知見がまとめられているので、興味がある方はぜひご覧ください。 本記事では、エンドポイント棚卸し機能を作った話と、その機能をフロントエンドでの権限チェックにうまく活用できた話について述べます。最終的には、以下に示すように、フロントエンドから呼び出され
フロントエンドの移り変わりは早すぎるのか
インターネットでは毎日のように言われることですが、私はそこまでではないと考えています。 ネットでよくそう言われる理由として考えられるものと、それを踏まえてどう向き合っていくとよさそうか、個人的な考えをまとめてみます。 なぜ言われるのか 言語が実質的にJavaScript一択 バックエンド、というかサーバサイドでは技術選定に「言語の選択」が入りますが、フロントエンドでは実質的にはJavaScriptにほぼ固定されます（TypeScriptも別言語ではないので、ここではJavaScriptに含めます） サーバサイドと比較して「技術の移り変わりが早すぎる」と評される場合、多くはその人の使用しているとある言語と比較されているように思われます。 実質的に言語が固定なので、比較するならすべてのサーバサイドの変化の総量と比較するのが妥当でしょう。 PHP + Python + Ruby + go + J
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
フロントエンドの爆速な開発サーバを実現する Vite を試してみた - SMARTCAMP Engineer Blog
こんにちは！スマートキャンプでエンジニアをしている中川です。 先日Twitterを何気なく眺めていたところ、Vue.js 生みの親の Evan You氏が何やら興味深いツイートをしているのが目に止まりました。 As I was going to bed, I had an idea about a no-bundler dev setup (using native browser ES imports), but with support for Vue SFCs **with hot reload**. Now it's almost 6AM and I have PoC working. The hot reload is so fast it's near instant.— Evan You (@youyuxi) 2020年4月20日 ...なるほど。これまでReactやVueを
なぜ default export を使うべきではないのか？
プロジェクトで使われている技術と ESModule の状況について UIT では、 SPA 開発のプロジェクトにおいて Vue.js と React が多く利用されており、既存の多くは Babel を利用した JavaScript で、新規のプロジェクトでは TypeScript を利用して開発が行われています。 FYI: 【LINE DEV DAY 2019 番外編】UIT Front-end Tooling Survey 2019 技術選定は勿論、プロジェクトにおける細かなコーディングルールについては、プロジェクトのコードオーナーに委ねられており、プロジェクトごとに裁量を持った意思決定を行っています。 その上で、私が携わるプロジェクトにおいては、 default export を可能な限り避けるように心がけています。 import 側の裁量で対象を自由に命名できてしまう 今回は「『Da
はてなエンジニア世論調査: 開発環境のフォントなに使ってますか？ - Hatena Developer Blog
こんにちは、スマートフォンアプリケーションエンジニアの id:yutailang0119 です。 突然ですが、ターミナルを毎日使っていますよね？エディタと触れ合わない日はないですよね？ ということで、今回は "はてなエンジニア世論調査" と題して、開発環境のフォントになにを使っているかのアンケートを取ってみました！ ちなみに自分はiTerm2では Monaco 14pt、1番使うエディタのXcodeでは SF Mono Regular 11pt です。 エディタではシンタックスハイライトが効き、小さい文字でも大体読めるので、iTerm2よりも小さいのです。 (Xcode Themeは自作しています。) 調査結果 フォントの種類 Monaco: 21.2% SF Mono Regular: 11.5% Menlo Regular: 5.8% Ricty Discord Regular: 5.
突撃！在宅の開発環境 2020年春 - Mobile Factory Tech Blog
こんにちは。エンジニア組織開発責任者の id:kfly8 です。 はじめに 最近、COVID-19の影響で、在宅で勤務している方が増えているかと思います。モバイルファクトリーでは2月中旬から原則在宅勤務になり、家の開発環境をこの機に整えている声などを聞きます。 そこで、今回は弊社のメンバーに在宅の開発環境のこだわりなどを聞いてみました*1 尚、この記事はGunosyさんのこの記事にインスパイアされた記事です。 tech.gunosy.io 1人目 1人目は、デザイナーの@momoyagiです。 普段はMBP本体＋ディスプレイ2枚で開発していますが、自宅環境はMBP+ディスプレイ＋気分転換用にipadになっています。デザイナー職のため、会社支給のwacom ペンタブレットを持ち帰ってます。デバイスが少し多いので配線管理がつらい。 在宅開発環境の良い点 周りがうるさいと集中できないので、一人の
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
2019年版 最先端のフロントエンド開発者になるために学ぶべきこと - Qiita
こちらの記事は、『Learn to become a modern Frontend Developer in 2019』の和訳になります。 本投稿は転載であり、本記事はこちらになります。 はじめに 新年になって以前書いた記事を少し簡潔にして理解しやすいように書き直してみました。この文章に以前私が書いた文章と違ったことが書いてあったり、少し矛盾する内容が見つかってもあまり気にする必要はありません。 昨年私が書いた記事はGitHubで公開しています。 Web開発は絶えず変化する分野です - 今日私たちがWebサイトを構築する方法は、2～3年前のやり方とは全く違ってきています。利用できるツールが沢山あり、新しいツールも毎日出てくるので、ウェブ開発者はいつもどのツールを使えばよいのか迷ってしまいます。 私は、ウェブ開発に係るフロントエンド、バックエンド、または運用を学びたいと思う人を対象にしたツ
Vue.js＋Vuex＋TypeScriptのWebフロントエンド開発現場を前向きに改善した話 - ZOZO TECH BLOG
こんにちは。Webフロントエンドエンジニアの松井菜穂子です。 ZOZOテクノロジーズに入社して一年ほど経ちます。 あるサービスの立ち上げから運用まで、Webフロントエンドのチームリーダー・開発メンバーとして関わってきました。 当記事では、当社のWebフロントエンド開発現場にあった問題と、それぞれの課題に対して堅実に積み重ねた技術的な改善方法についてご紹介します。 はじめに モダンな技術でも負債は生まれる 負債を何故改善するのか 要因 その1: Vueコンポーネントを綺麗に分割する テンプレート コンポーネントクラス 使用例 解決策 テンプレート コンポーネントクラス 使用例テンプレート 使用例コンポーネントクラス コンポーネントカタログで汎用化を促す コード テンプレート（atoms.vue） コンポーネントクラス（atoms.vue） サンプル その2: Vuexをシンプルにする Sta
新卒エンジニアが配属後３ヶ月間で学んだこと ~ 開発・ユーザ・ビジネス の理解 ~ | リクルートテクノロジーズ メンバーズブログ
このエントリは全9回を予定する18卒新人ブログリレーの第5回です。 はじめまして。リクルートテクノロジーズ新卒１年目の西野拓馬です！ 入社後の研修を経て、７月からリクルートテクノロジーズのプロダクト開発のチームに配属されました。 今回は、新卒エンジニアとしてプロダクト開発現場に配属され約３ヶ月の間何に取り組み、そこから何を学んだかについて紹介したいと思います。 リクルートテクノロジーズの新卒エンジニアは何を経験し、何を学ぶのか？ 新人はチームにジョインした時にどういうことを感じ、何に苦戦するのか？ こういった問いを持つ読者に、少しでも参考になれば幸いです。 以下が本記事の構成になります。 はじめに 私がプロダクト開発者として参考にしているものの１つに「プロダクトマネジメントトライアングル」と呼ばれるグラフィックモデルがあります。 出典：https://productlogic.org/20
「運用でカバー」では、プロジェクトが崩壊する！運用者よ、上流工程に参画せよ！―『運用☆ちゃん』Incident 008 - リクナビNEXTジャーナル
「運用でカバー」では、プロジェクトが崩壊する！運用者よ、上流工程に参画せよ！―『運用☆ちゃん』Incident 008 いつもサービスを支えてくれているシステム運用の「中の人」たち。企画や開発が作ったシステムを言われたままに守り、何かトラブルが起きたら「運用でカバー」などと丸投げされがちですが、海外では運用責任者の承認がないと、プロジェクトは次工程に進めないのだとか！ 妖精「運用☆ちゃん」との出会いがきっかけで、自分の仕事＝システム運用の価値がだんだんと分かってきた2年目システム運用担当者 海野 遥子（うんの ようこ）が、体当たりでお伝えします。 海外では運用責任者の承認がないと、次工程に進めない！？ い、いま、なんておっしゃいましたっ！？ ハイ。運用責任者の承認なしに、プロジェクトは次工程には進めませんって言いました。 開発に運用が口を挟む。そんなのって、あり得るんですか！？ てっきり、
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
'The human scalability of “DevOps”' by Matt Klein の日本語訳 - Qiita
この記事はEnvoyの作者であるMatt Kleinさんの以下の記事を The human scalability of “DevOps” 本人の許可をえて日本語訳したものになります。 Sure! — Matt Klein (@mattklein123) 2018年9月7日 アメリカにはたくさんの急成長するスタートアップ企業があって、そういう所って、システム的/組織的な所の両面で、破綻させずにどうやってスケーリングしていくんかな〜と日々疑問に思っていて、この記事では主に組織的な所に関して色々と示唆があり、その内容から、やっぱアメリカ凄い(小並)ってのを感じたので、自分の中での腹落ち度合いを深めるためと、より多くの人の目に触れるといいなと思い、翻訳してみました。 以下、翻訳になります。 "DevOps" の人的なスケーラビリティ 最近Twitterに書いたように、"DevOps" の人的スケ
土日で作るWebサービス入門 - toyoshiの日記
先週日曜日に総額480円、プログラムコード200行、作業時間8時間で「給与明細.net」(http://www.給与明細.net)というWebサービスを作ってリリースをしました。これは給与支払明細書のPDFをWebで簡単に作れるWebサービスです。 シンプルな内容なので開発を開始してから8時間以内の作業でリリースできました。このエントリではサクッとサービスを開発してリリースするまでの僕なりの方法を紹介します。 特長 無料 会員登録不要 Excelから一括作成できる（CSVではない） オープンソース（MITライセンス） 目次 解決したい課題を見つける ドメインを取得する サイトマップとURLを決定する よいツールを集める まずデプロイ（公開）する そこそこのデザインにする 最低の機能をつけたらリリースする 広めるための準備をする おまけ：コードをかく 解決したい課題を見つける これがないとそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FigmaとPHPで作る1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
フロントエンドでフロントエンドをビルドする
What is and isn't lean startup
