マネーフォワードでは、THE GUILD代表の深津貴之さんをアドバイザリとして招き、日頃からサービスデザインに関する助言をいただいております。 先日は、社内のサービス開発力の底上げを目的とし、フィッシュボーン図を使った課題整理のワークショップを行っていただきました。 PM、デザイナー、ビジネスのメンバーを中心に、100名近くが参加しています。 今回はそこで学んだ内容をご紹介します。 表面的に対処してしまう問題 プロダクト開発の現場には、日々さまざまな要望が届きます。 それらに対処する際に気をつけたいのが「表面的に対処してしまう問題」です。 例えば次のようなケースです。 ユーザーが「検索機能を強化してほしい」と言ったので、パワフルな検索オプションを搭載しました。ユーザーの声にそのまま従っており、その背景にある課題は分からないままです。 機能は追加したが効果がでなかった、効果がよくわからない、

最近は ECMAScript 自身の機能も豊富になってきて lodash のユーティリティ関数の出番はだいぶ少なってきたけど、debounce と throttle だけは未だに使う機会がまあまあある。 しかし、lodash は何も考えずに使うとバンドルサイズが肥大化するのでいい感じに Tree Shaking するために lodash-es を使う必用があったり、自分が使っている機能とは全然関係ないアップデートが Dependabot から大量に降ってきたりしてしんどかったりする。 lodash は lodash.debounce のように個別のモジュールも提供されているけど、Last Published が 5 years ago になっていたりして、あまり継続的にメンテされてない様子が伺える。これに関する Issue は探すといっぱいあって、対応したいけど手が回ってないみたいな様子ら

フロントエンドエキスパートチームのlacolacoです。 この記事ではアプリケーション監視プラットフォームのSentryをClassiの中でどのように活用しているかを少し紹介します。Sentryの運用に悩んでいる方の参考になれば幸いです。 Sentryの用途 Classiでは大きく2つの目的でSentryを利用しています。ひとつはアプリケーションのエラーの監視（以後エラー監視と呼びます）、もうひとつはWebフロントエンドのパフォーマンスの監視（以後パフォーマンス監視と呼びます）です。 Sentryは多くのプログラミング言語用にSDKがあり、Classiでは主にJavaScriptとRubyのSDKを利用してフロントエンド・バックエンド両方のエラー監視を行っています。パフォーマンス監視は最近利用しはじめたのですが、バックエンドではもともとDatadogによる監視をしていたので、Sentryの

以下の記事を読んで思った事「サービス提供主体自体が廃業するならばともかく、存続するのに掲載記事を削除するのか」 news.yahoo.co.jp Yahoo!ニュース 個人では、オーサーとの契約が終了した際には、記事の掲載もあわせて終了することとしています。これは、契約終了後の記事の問い合わせ対応において、Yahoo!ニュース 個人側では事実確認をすることができない、時間の経過によって状況が変わった際などに追加の記事の配信をお願いすることができないなどの理由によります。ただし、例外的に、契約終了後も記事掲載を継続する場合があり、今回の山本一郎氏のケースにおいても、掲載継続のご要望があり、訴訟に関わる記事もあることも踏まえ、契約終了後も掲載を継続しておりました。 そもそも、新聞や雑誌、本など、物理媒体での出版物は、いちど出版したものをなかったことにするのは難しい（当該出版物の保管の責任がその

巣ごもり需要で、「置き配」が広がる中、配達員の信じられない行動が明らかに。 一部始終を、防犯カメラがとらえていた。 FNNが独自に入手した、防犯カメラの映像。 映っていたのは、アマゾンの配達員の目を疑う行動だった。 客の荷物を地面にたたきつけたかと思えば、自ら拾った。 さらに、荷物を投げるように、玄関先へ置き配。 すると...。 利用者「おい! 俺のところでドンって鳴ったよな? ここから」 アマゾン配達員「何がですか?」 利用者「今、そこに放り投げていたやろ?」 アマゾン配達員「してないです」 コロナ禍の巣ごもりで、配送業務が急増しているアマゾン。 その配達員の驚きの行動が明らかになった。 24日午後7時半ごろの京都府内の団地に、1台の車が現れた。 荷物を届けにやってきた、アマゾンの配達の車とみられる。 突然、「ドン」という物音が響き渡ってきた。 音が次第に大きくなった次の瞬間、配達員は手

『データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用』 Laine Campbell, Charity Majors　著、八木 和生　訳 2021年4月16日発売予定 308ページ ISBN978-4-87311-940-3 定価3,740円（税込） テクノロジーの進化に合わせて、データベースもまた進化しています。従来のパフォーマンス、スケーラビリティが重要なことはもちろん、今日ではセキュリティ、インフラのコード化、CI/CD、クラウド活用といったタスクにも取り組んでいかなければなりません。 データベースの本質は、長期的に安定していること。つまりリライアビリティ（信頼性）です。時代とともにアーキテクチャやツールが変わってもこの原則は変わりません。本書はデータベースのリライアビリティを実現するための考え方を「データベースリライアビリティエンジニアリン

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

Front-End Study #5 の発表資料です。 https://forkwell.connpass.com/event/205227/ フィードバックはこちら： https://koibu.me/events/14/talks/wQQs0pbvMZHcnZ8TawAi

基本はdfコマンドだが Linuxサーバは基本的にさまざまな操作をターミナルで行えるようになっている。WindowsプラットフォームのようにGUIが必須ではないというのが特徴だ。しかし、GUIに慣れたユーザーからすると、コマンドの出力はいささかシンプルすぎて直感性に欠けると感じるかもしれない。 また、サーバ管理において、ディスクストレージの空き容量の管理は重要だ。空き容量が足りなくなるとソフトウェアが正常に動作しなくなる。ストレージの空き容量は典型的にはdfというコマンドで確認できるが、GUIに慣れていると、dfコマンドの出力は多少物足りないかもしれない。 dfコマンドの実行サンプル そんな場合はdufコマンドを試してみるとよいだろう。It's FOSSが「Check Your Disk Usage Using 'duf' Terminal Tool in Linux」において、dufコマ

はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが

前書き はじめまして、ANDPADでフロントエンド開発を担当している小泉です。入社から2年弱ですが、ここ1年の社員数の増えるペースが速すぎてすっかり古株になりつつあります。 自分は入社当初からVue.js・Nuxt.jsを使って開発を行っているのですが、2020年7月頃よりスタートしたプロジェクトで、Vueの新しい記法であるVue Composition APIを全面的に採用しています。 この記事では、Composition APIを実際に製品開発に導入するまでの流れから、9ヶ月ほど使っていく中で気づいたComposition APIのメリットとデメリットなどをまとめています。 昨年秋にVue 3.0が正式リリースされ、今年はNuxt 3.0も控えており、これからVue 3.0やComposition APIを本格導入するチームや会社も多いと思いますので、その際の参考になれば幸いです。 技

リファクタリングの PR、見るのツラい内容になりがち PR(PullReqeust)を作成してレビューを受け、Approve を受けたらマージする..という開発スタイルはよくあるパターンで、新たな機能追加や修正では観点が明確で動作確認も実施しやすいのですが、これがリファクタリングがテーマになると、途端にレビューが大変になることがあります。 個人的な経験則もありますが、何も意識せずに PR を作ると、次のような問題が発生しやすいように感じます。 １テーマに関する修正が一気に詰め込まれていて物量が多い 何を確認したらよいのかわからない 複数 PR に分けている場合に、後続の PR だけを見ても理解できない など... リファクタリングの PR は内容も淡々としたものになることが多く、確認もリグレッションテストが中心で、レビュアーはそこそこ心を削られます。そのうえ上記のような問題を抱えていると、

SCSKは松井証券の証券取引システムの開発・運用を受託しており、元社員はプロジェクトリーダー（PL）を担当していた。同システムの本番環境と開発環境の両方にアクセスできる権限を持っていた元社員は、本番環境で顧客情報を含むバックアップファイルを作成して開発用システムに転送。開発用システムで210人分の顧客情報を抽出して私用のメールアドレスに転送することで、IDやパスワード、取引暗証番号など取引に必要な情報を不正に入手した。 この情報を基に元社員は証券口座にログインして株式を売却。さらに偽造した本人確認書類で松井証券の顧客と同姓同名の銀行口座を開設し、株式の売却代金や預かり金を計15回送金した。