運用技術者組織の設計と運用 / Design and operation of operational engineer organization
こんにちは。モノタロウで開発を担当している河本です。2021年7月から2022年2月に技術評論社様で発刊されている Software Design にモノタロウにおけるPython大規模開発に関する取り組みを連載させていただきました。そして無事に8か月分の雑誌連載を完遂することができました。ここでは、雑誌連載プロジェクトの体制やスケジュール、成功させるために取り組んだことについてご紹介します。 Software Designの記事の再紹介 連載のきっかけと狙い プロジェクト体制 スケジュール プロジェクトを成功させるために取り組んだこと さいごに Software Designの記事の再紹介 全8回の連載のテーマは「Python」、「大規模」、「レガシー」の3本柱でした。 連載してきた記事は以下になります。 第1回 Software Design連載 2021年8月号 Python製のレガ
新年あけましておめでとうございます。モノタロウでエンジニアをしております大西です。本年もよろしくお願いいたします。 本年もMonotaRO Tech Blogでは社内の様々な取り組みを定期的に更新して参りますので、お時間の空いた際にお読み頂けると嬉しく思います。皆様のお役に少しでも立つことができれば幸いです。 今回は、リリースにかかる時間の増加や、リリースに関する作業の属人化を体制変更によって解消した経緯と、大規模な開発体制におけるリリース作業や監視業務でのエラーやアラートの管理方法についてご紹介します。 本記事の初出は、 Software Design2021年12月号「Pythonモダン化計画(第5回)」になります。 過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか
こんにちは、辰巳です。 第3回は「スナップショットテスト」をテーマにお送りします! 「組織が拡大する中で、十分な設計情報がない状況でも、複雑に改修が積み重なったソフトウェアをいかに安全かつ正確に変更できるか?」 本記事では、数多くの大幅なシステム変更の経験を経て、この課題に対してモノタロウがいま実践しているグッドプラクティスを紹介します。 本記事の初出は、 Software Design2021年10月号「Pythonモダン化計画(第3回)」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 スナップショットテストの可能性を追求する モノタロウは、事業者向けの間接資材を販売
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
VSCodeを使ってHTML/CSS/JavaScriptなどを使ったWeb制作、Webコーディングを行っている人も多いのではないでしょうか。 VSCodeは様々な拡張機能が公開されていて、それらを活用するとさらにWeb制作の作業効率が向上したり、使い勝手が良くなったりします。 今回は、Web制作者、WebコーダーにおすすめのVSCode拡張機能をご紹介したいと思います。 VSCodeとは VSCodeとは、Microsoftが提供するテキストエディタ「Visual Studio Code」のことです。つい数年前までは、人によって使っているテキストエディタが違うことも多かったのですが、最近ではVSCodeを使ってコーディングやプログラミングを行っている人がかなり多くなってきました。 VSCodeは、設定や拡張機能の追加など、マウス操作で行うことができ、初めてコーディングやプログラミングをす
なぜ日本語UIキットを公開するのか? デザインチームの研究活動のひとつとして、体験設計やUIデザインの品質を高めたり、デザインチーム内の協働を円滑に行うために、汎用的なデザインテンプレートやデザインアセットを作成し、体験デザインプロセスの仕組み化と共有を行っています。 UIデザインにおいても、Figma Communityをはじめとした様々な媒体でUIキットが共有・配布されており、UIキットを参考にデザインワークを行うというケースが増えてきているかと思います。 一方でUIキットの多くが欧文フォントで構成されているため、日本語フォントに変換する必要があり、場合によってはサイズやレイアウトを微調整しなくてはなりませんでした。 このUIキットも、単にAppleやGoogleのUIコンポーネントを日本語化しているだけと言えばそうかもしれませんが、これを活用することでデザイナーやプロダクト開発に携わ
Web上でアニメーションを表示するなら「Lottie」がおすすめ!特徴と使い方など Webサイト上でアニメーションを実装する場合、簡易なアニメーションはCSSやJavaScriptで手軽に作ることができますが、リッチなアニメーションを作ろうと思ったらコード量も結構なボリュームになってしまいます。 そんな時におすすめなのが「Lottie」です。LottieはAfter Effectsで作成したアニメーションを簡単にWebやアプリで表示することができ、パフォーマンスにも優れています。 今回は、Lottieの特徴や使用するメリット、使い方などをご紹介したいと思います。 Lottieとは LottieはAirbnbが公開しているアニメーションを表示するためのライブラリです。スマホなどのネイティブアプリがメインのようですが、Webサイト上でも高クオリティのアニメーションを簡単に表示することができ、非
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図(視覚情報)」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
Web開発の歴史の復習の仕方 悲報: WEB+DB PRESSが休刊 22年以上続いていたWEB+DB PRESSが休刊するそうです。Software Design、WEB+DB PRESS共に年間購読していたのですが、とても残念です。 日本語と英語、少し中国語の技術書を普段から読み漁っているのですが、本ほどガッツリでなく、ブログよりはちゃんとバリデートされた上でトレンドをおさえた雑誌文化は割合日本的で、他の言語圏だとあまりない文化だとも感じています。 技術評論社からでているSoftware Design、WEB+DB PRESSなのですが、Software Designの創刊が1990年11月で、WEB+DB PRESS Vol.1が2000年12月で10年の差があります。 どちらかというとSoftware Designがインフラ&バックエンドでWEB+DB PRESSがバックエンド&ク
リブセンスでデータエンジニアをしている富士谷です。 Software Designのデータベースに関連する特集記事を再構成した「データベース速攻入門 ~モデリングからSQLの書き方まで」が、2023年3月に発売されました。 gihyo.jp リブセンスがSoftware Design 2017年11月号に寄稿した「データ分析に効くSQL50本ノック」が、内容を更新して再掲載されました。 今回、再掲載にあたって、「SQL50本ノック」の内容の更新を私が担当しましたので、簡単に紹介します。 SQL50本ノック 「SQL50本ノック」は、SQL、特にSELECT文の演習問題集です。 PostgreSQLをDockerで立ち上げて、もっともシンプルな例から実行し、WHERE句、LIMIT句などを一つ一つ体験し、最後には、移動平均といった高度な文法を習得する事ができます。 これを読めば、SQLを使っ
この記事の初出は、Software Design2022年3月号「設計方針から変えていく、モノリシックなアプリの過去と未来(最終回)」で、加筆修正されています。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog 第3回 Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog 第4回 Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Te
本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。 目次 本書への推薦の言葉 日本語版序文 序文 はじめに 第Ⅰ部 ソフトウェアアーキテクチャ入門 1章
OGPは、WebサイトのSNSからの流入を増やすためには欠かせない存在ですが、意外とWebサイト公開時に忘れがちになってしまいます。 ただしくOGPが設定されていないと、せっかくSNSでURLがシェアされてもアクセス数が伸びず、大きな機会損失に繋がってしまう可能性があります。 今回は、WebサイトにおけるOGPの正しい設定方法や、適切な画像サイズ、OGPが正しく設定されているかの確認方法をご紹介したいと思います。 OGPとは? OGPとは、「Open Graph Protcol(オープングラフプロトコル)」の略称で、TwitterやFacebook、LINEやSlackなどでWebサイトをシェアした時に表示されるタイトルや画像を設定するためのものです。 例えば、TwitterでWebサイトをシェアすると上記の画像のようにリンクがカードで表示されますね。 このように、OGPが正しく設定されて
Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う!多様で面白い!!」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ
Atomic Design は難しい Webフロントエンド開発をしている人で Atomic Design を用いた経験がある方に会った時は、必ず 『Atomic Designどうですか?』と聞くようにしています。 大体の方はちょっと苦笑いをしながら『やっぱり難しいですねぇ』とか『試行錯誤しながらで...』みたいなことを教えてくれます。 私もメインの開発をする際に Atomic Design という枠組みを用いています。そして、同様に色々と悩んだのですが、このあたりについて納得がいく解釈ができたと思っています。 そこで、私の思う Atomic Design の難しさや、そう思う原因、どうやってそれを解消するかという点について、https://atomicdesign.bradfrost.com/ を適宜参照しながら共有したいなと思います。 そもそも Atomic Design 何やねん。な方
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
※ 2020年 9月 3日 追記 デザインシステム「SmartHR Design」がお引越し&アップデートしたため、最新情報はこちらからご覧ください。 おつかれさまです。コミュニケーションデザイングループのさめまる(@samemaru_saxo)です。 このたび、だれでも!効率よく!SmartHRらしく!表現できるのを目標とした、デザインガイドラインができました! ▶️ SmartHR Design https://smarthr.design (2020年9月3日更新) 社外の方でもどなたでも読めるように一般公開しています。 SmartHR Design とは SmartHRでは、資料やスライド、オウンドメディア、このオープン社内報など、日々どのメンバーもばしばしアウトプットしています。中には見た目のデザインが必要なものもありますが、どれもデザイナーに依頼して作る余裕があるとは限りません
2020年のグラフィックデザインはどんなスタイルがトレンドとなるのか気になっている方も多いのではないでしょうか。 様々な角度から調査を行い、人気が高まっているグラフィックデザインのスタイルをまとめました。 今回は、2020年に流行する13個のグラフィックデザインのトレンドをご紹介したいと思います。 2022年に流行するWebデザインの最新トレンド10個まとめ 2021年のミニマリズムを中心としたトレンドが注目されていましたが、2022年は鮮やかで、奇抜で、記憶に強く残るようなデザインを中心としたトレンドが注目されています。 今回は、2022年に流行するWe... Web Design Trends
API excellence made easy.All of the benefits of innovation without the headaches. Create a Successful API ProgramTake a proactive approach with your API programs to efficiently create consistent productivity and avoid the underbelly of delays and overages. Reduce Risk and Improve ROIConnected Software is mandatory for today’s consumers. Avoid disorganized development efforts that cause significant
tl;dr 前半をサイバー脅威インテリジェンスの理論、後半をハンズオンの形式で全6回の連載をしてきました 連載は現実のインテリジェンス業務をなるべく反映させたものであり、戦術脅威インテリジェンスがアウトプットの中心になります 実態のよくわからないバズワードに飛びつかず、企業は自組織の体制と世の中の脅威を正しく理解するところからはじめましょう はじめに 本稿は前回の記事「無名のセキュリティエンジニアがたった2本のブログ記事からSoftware Designで連載をすることになった (非技術編)」の技術的内容部分を抜き出したものです。未読の方は先にそちらの記事を参考にしていただいた方が、内容を理解しやすいと思います。 blog.nflabs.jp 前回に引き続き @strinsert1Na です。事業推進部の Defensive チームで脅威インテリジェンスの生成やソフトウェアの開発をしていま
概要 ・現代Webフロントエンドにおける難しさは何によってもたらされるのか ・Webフロントエンドと「ドメイン」の関係について ・Webフロントエンドを「設計」することについて ・Webフロントエンドにおけるアーキテクチャ考察 参考資料(スライドにも記載) ・エリック・エヴァンスのドメイン駆動設計 ・Eric Evans(著)今関 剛(監訳)和智 右桂、牧野祐子(訳) ・Clean Architecture 達人に学ぶソフトウェアの構造と設計 ・Robert C. Martin(著)角 征典、高木 正弘(訳) ・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明 ・Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳) ・オブジェクト指向のハードコア ・https://www.zerobase.jp/salon/2019/05/25/
この記事は、Mercari Bold Challenge Monthの1日目の記事です。 こんにちは、MercariのArchitectチームでDesign Systemに取り組んでいる@usagi-fです。 Design Systemはただのスタイルガイドラインではなく、会社として保持するデザインフィロソフィーから実装コードに落とし込まれたUIコンポーネントまで、広い範囲をさす言葉として認知されてきています。 現在私たちは本格的に構築へ着手しており、少しずつ進捗が見えてきました。この記事では主にDesign Systemにおける「UIコンポーネントの定義と実装」の部分に焦点をあて、私が担当しているWeb Frontendの事例を紹介していきます。 MercariにおけるDesign System Mercariでは将来的な組織規模の拡大に向けて様々な取り組みを行っていますが、Design
5/20(月)開催のAWSプロフェッショナルサービス勉強会での発表資料です。 (注意) 現時点での総まとめ的な資料なので250ページ超あります。あらかじめご了承ください。 # 発表の概要 多くの運用現場において、経営・マネジメント層からの「運用自動化」要求や、業務の多様化や業務量増大により、「運用自動化」を進めざるを得ない状況に追い込まれてきています。 しかし、運用自動化には多くの不都合や副作用があり、意図に全く反した結果をもたらすことの方がむしろ多いのが現実です。 今回は、比較的大きな組織の中で、(運用業務の自動化を含めて)「変化に強く、スケールおよび持続可能な運用」を実現するために、どのような取り組みが必要なのか解説します。 # アジェンダ 1. 運用自動化、不都合な真実 2. 運用業務の「構造化」という大前提 3. 「運用業務」構造化の例 3.1. 「運用」の定義 3.2. 「運用価
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Hello Web Design teaches design principles, handy shortcuts, and quick solutions to common problems, so you can learn the fundamentals of design and get ahead in your career. Using rea
SmartHRに頻出する、表形式で一覧表示するUIのパターンまとめています。 SmartHRでは、表形式で一覧表示するUIを「よくあるテーブル」と呼びます。 OOUIにおけるコレクションと、コレクションに関連するアクションやフォームをまとめた総称を指します。 構成よくあるテーブルは、次の要素で構成されています。必須項目以外は任意の表示項目です。 テーブルオブジェクト名(必須)オブジェクトの情報オブジェクトの操作タイトルエリアテーブル操作エリア一時操作エリア 1. テーブルよくあるテーブルは、多くの場合「1項目1行の1次元リスト」のテーブルを含みます。 オブジェクト名オブジェクトの名前を指します。行を識別するために必須要素として設定します。 移動リンクのスタイルオブジェクトの詳細ビューへ移動する場合、オブジェクト名にリンクを設定します。 テキストリンクによる移動は「オブジェクトの操作」にはあ
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く