この記事はSmartBank Advent Calendar 2024 6日目の記事です。 昨日は kassy さんの「成長するスタートアップ労務の醍醐味と挑戦をUXリサーチャーが聞いてみた！」という記事でした。 はじめに サーバーサイドエンジニアの mokuo です。普段は、カード決済やあとばらいチャージに関連する機能の開発や運用を行っております。 本日は、サーバーサイドエンジニア向けの記事になります。 本記事でお話しすること システムには断続的に行われる一連の処理、というものがあります。この中で非同期処理を行うこともあるでしょう。 例) EC サイトにおける注文処理のワークフロー このような機能を開発・運用していると、以下のような課題に直面することがあります。 処理の流れが把握し辛い 変更を行うのが困難 データの整合性を担保するのが難しい しかし、適切に設計を行うことで、これらの課題を
Last week, I did a Q&A session for a friend's security class. One of the students asked a question that I loved. They asked something like, "As a principal engineer, how do you make sure your company stays at the forefront of innovation?" There are two reasons I love this question. The first is that it's a good and natural one, which I had early on too. The second is that it's unintentionally lead
こんにちは、スマートバンクでアプリエンジニアをしている ロクネム です。 弊社では B/43という家計簿プリカアプリ を提供しており、つい先日サブスクリプションサービス「B/43プラス」をリリースしました。 このようなサブスクリプションを提供するサービスにおいては、そのサブスクリプションを利用しているユーザーのみが特定の “機能” を使用できるように “制御” する必要があるかと思います。 このサブスクリプションの機能制御を実装するにあたって、「サブスクリプションが有効ではない場合は機能を制限する」という設計では実は不十分で、その他にもさまざまな要件を考慮した上でより柔軟な設計を行う必要があります。 本記事では、このようなサブスクリプション機能制御の設計における勘所について、B/43プラスを例にご紹介します。 ※ 本記事は B/43 Tech Talk 〜 Fintech×サブスクリプショ
こんにちは、株式会社スマートバンクでサーバーサイドエンジニアをしている mitani です。 この記事は2022/10/21~22に開催されたKaigi on Railsでお話した内容を記事にしたものです。当日の発表はYouTubeからご覧いただくことができますが、まだご覧になっていない方で動画よりも文字で見たいという方向けに、特にお伝えしたかったポイントに絞りながらご紹介したいと思います。 www.youtube.com 外部サービスと状態管理 サービスを作る際、状態管理は至るところで実装する必要のある機能です。例えばログイン状態、会員の登録状態等のどのようなサービスでも共通的に実装するものから、商品の購入状態、決裁フローの現在状態などサービスによって異なるものまで様々な状態管理があります。状態管理の設計方法はその機能の要件によって大きく変わってくるものではありますが、正確に状態を記録し
こんにちは、株式会社スマートバンクでアプリエンジニアをしているロクネムです。 みなさんはDynamic colorという機能をご存知でしょうか？ Dynamic colorとは、ユーザーの設定した壁紙における優位な色を元にパーソナライズされた配色を生成してアプリへ適用することができる、Android 12から提供を開始した機能です。 色という非常に主観的な要素をカスタマイズ可能にすることによって、ユーザーの嗜好をより尊重するデザインの提供を実現しています。 https://material.io/blog/start-building-with-material-you 本記事では、このDynamic colorという機能について、どのようなアルゴリズムをもとに優位な色を抽出し、そこからいかにして調和の取れたカラースキームを生成するのか、内部の仕組みを徹底解剖しながら説明していきます。 そ
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
私が一番最初にAndroid アプリをデザインしたのが2016年の初夏頃で、その頃はまだiOS・Android とデザインが違うのが主流でしたが、2021年現在のアプリはiOS もAndroid もプラットフォームごとの細かな違いはあれどほぼ同じデザインが主流となっています。 これは2016年の10月にAndroid APIがBottomNavigationView に対応してからじわじわ浸透していった変化だと考えているのですが、その辺の歴史の話は省略します。プラットフォームは違えどスマートフォンアプリである以上デザインは同じ方が楽なので、共通化されていったのは自然な流れだと思います。実際両者が全然違うUI・デザインだと大変ですしね……。 とはいえ、プラットフォームが違うので全て同じというわけにもいきません。iOS にはHuman Interface Guidelines、Android
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
こんにちは。デザインチームの八嶋です。2021年3月22日、SMBCのホームページが大幅にリニューアルされました。このホームページリニューアルは、約5年ぶりの大幅リニューアルでページ数は約1500ページにも及ぶ大プロジェクトでした。このプロジェクトはインハウスデザイナーによるホームページのデザインディレクションとデザインチームが作ったデザインシステムによる連携で作られています。ホームページの役割からUIの設計までコアとなる部分をインハウスデザイナーが設計し、多数のパートナー様にもご協力いただき完成させています。（特にトランスコスモス様、ありがとうございます。） 今回のnoteは、ホームページリニューアルチームの一員でもある八嶋が、デザイナーの大塚とプロジェクトマネージャーの髙橋、そして、デザインシステムを担当したデザイナーの金澤にインタビューをしました！ ホームページリニューアルを通して、
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
こんにちは、freeeのUXチームでデザインシステム “Vibes” を作っている id:ymrl です。 ダークモード流行ってますよね。私は最初はしっくりこないなと思っていたんですが、食わず嫌いは良くないと思って試しているうちに、いつの間にかダークモードのほうが落ち着くようになってしまいました。 そしてそうなってくると、だんだん「自分たちの作っているWebサービスもダークモードに対応するべきなのか？」という気持ちになってきてしまい、最近はずっとダークモードのことを考えています。ということで今回はダークモードをやるべきなのか、実現する方法はどうなっているのか、UIデザインで気をつけるべき点何かというのを考える記事を書いてみます。 ※「ダークモード」はApple製品で使われている呼び方で、Androidでは「ダークテーマ」と呼ばれていて、Windowsでは「ダーク○○」のような呼び方をしてい
週刊少年ジャンプ・ジャンプSQ.・少年ジャンプ＋編集部は、2020年度より、漫画家を対象とした創作講座「ジャンプの漫画学校」を開講しています。 第1期の全10回の講義より、一部を抜粋し、本ブログで順に公開していきます。 今回は「作家編①」から松井優征先生の講義の一部を紹介いたします。 松井先生が語って下さったノウハウや考え方が、クリエイターの皆様の漫画制作の一助になれば幸いです。 【講師】 必ず身に着くテクニック「防御力」！ 松井 漫画では「面白さとは何だろう？」といった問題が常に付きまといます。一昔前の編集さんは「面白ければ何でもいい」と言い、では面白いとは何かと聞くと「人それぞれだよ」という人が多かったです。皆さんはそういう人の言うことを聞いてはいけません。「面白い」とは何なのか、それは作家も編集も本人なりに言語化できないといけません。 そこでまず説明したいのが「防御力」です。 松井
2017年〜2020年（+α）に取材した記事から、今でも参考になりそうな施策などまとめてみました。※ 数値等はあくまで取材当時のものです。 1、フリマアプリの検索結果に、あえて「売り切れ商品」を表示している理由（メルカリ）フリマアプリの「メルカリ」では、検索をかけると販売済みになっている、「売り切れ品」も表示されるようになっている。 あるとき邪魔ではないかと、検索結果から「売り切れ品」を消してみたら、あらゆる数値（継続率・購入率など）が悪化してしまった。 実は「売り切れ品」を置いておくことが、ユーザーに「これ買いたかった」「マメにチェックしとこう」と思ってもらう、うまい演出として機能していたのが理由。 2、コメント欄のタイムラグを小さくすると、コメント率が改善されて荒れにくくなる（ミラティブ）配信アプリの「ミラティブ」では、コメント欄のタイムラグを小さくしたところ、コメント率が改善されたと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
