事業計画を立てる上で必要なプロセスをシステム化し改善した話 - pixiv inside
こんにちは。プラットフォーム開発部兼財務データ企画部のshigeniiと申します。 普段はデータ基盤の運用保守、および、全社的なデータ活用やデータ駆動推進を担当しています。 今回は、財務に関する情報の収集からその可視化までの過程をシステム化することで、事業計画や予算策定のプロセス改善に結び付けた我々の取り組みについて、システム化に焦点を当てながら書き綴りたいと思います。 この記事がバックオフィス業務において、同じような課題を抱えている方に少しでもご参考になれば幸いです。 経緯 財務レポート可視化プロジェクト システム化にあたっての具体的な取り組み Before After システム化にあたっての課題 今回の対応 全体的なシステム構成 財務レポートを作るまでのながれ 説明1．各業務システムのデータを取得 説明2．マスタ情報の取得・作成 説明3．データの加工・突合機能 説明4．データに対するセ
食べログの実践事例に学ぶ：プロジェクト進行におけるスピードと品質を保つ段取り - Tabelog Tech Blog
はじめに こんにちは。食べログ開発本部 ウェブ開発1部の大橋と中村です。 私たちは食べログのサーバーサイドの開発を担当しており、今回食べログで利用している決済システムの機能拡張に伴うリプレイスを行いました。 今回のプロジェクトを進めていて特に感じたのが「ステークホルダーが多いプロジェクトほどスピードと品質が手を動かす前の段取りの良さによって決まる」ということです。 本記事では実際に行った決済システムのリプレイスを事例に段取りがプロジェクトの品質および開発スピードにいかに寄与するのかを紹介します。 段取りの重要性 この章からは段取りの内容についてお話しします。 段取りができているとは下記3つの状態だと考えています。 業務や要件、実際の利用シーンが決まっている アサインするチーム・ステークホルダーが決まっている チームの間でシステムやデータの責務が明確になっている 段取りは序章でお話しした通り
メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング
こんにちは。メルカリ ハロのSoftware Engineer (Engineering Head)の@napoliです。連載：Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の2回目を担当させていただきます。 2024年3月上旬にメルカリ ハロという新しいサービスが公開されました。メルカリ ハロは好きな時間に最短1時間から働ける「空き時間おしごとアプリ」です。 この記事ではメルカリ ハロを作るにあたり、どういった技術スタックやアーキテクチャを選定したのか、さらにその背景と意思決定をご紹介したいと思います。 この記事で得られること メルカリ ハロで採用されている技術スタックやアーキテクチャの全体像 その意思決定の理由とプロセス これから新規サービスを立ち上げるうえでのヒント 主な技術スタック メルカリ ハロで利用されている主な技術スタックは以下のとおりです。 バッ
pixivというシステムはどんな形をしているのか、それはなぜか。 - pixiv inside
こんにちは。pixivのnamazuです。 先日開催されたPIXIV DEV MEETUP 2024にて、『pixivというシステムはどんな形をしているのか、それはなぜか。』というテーマで発表をさせていただきました。当日、セッションにご参加いただいた皆さま、そしてフィードバックをいただいた方々に、改めて感謝申し上げます。 Webサービス開発において面白い点の一つは、どのサービスもその要件や状況に応じて異なる選択がなされることです。結果として、類似点がある場合もありますが、細部において同じものはなく、すべてがユニークです。弊社内でもさまざまな違いが見られますが、業界全体を見渡すとさらに多様性が広がっていることでしょう。 今回の発表では、pixivのシステムに関する重要な要件や状況をいくつか取り上げ、現時点でどのような構造になっているかを、インフラストラクチャ、バックエンドアプリケーション、開
システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog
こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上
食べログの大規模販売管理システムを財務会計SaaSシステムに置き換えた話 - Tabelog Tech Blog
目次 目次 はじめに 1章 課題の認識とZuora導入の決断まで 販売管理システムの課題 何を最初にやるべきか 実情を知る 理想像を固める 何を作り、何を作らないか どのSaaSを使うか 2章 Zuora導入設計 Zuoraプロジェクトチーム体制 Zuoraを知ろう！ Zuoraプロジェクトにおいて何を開発するのか Zuoraの管理画面を使うか、それとも内製で作るか 新設機能のモック作成 食べログとのマッピング 3章 Zuora移行 データ移行 データ検証 突合バッチによる検証 データプールの副産物 最終的なシステム構成 データ切り替え 4章 Zuora運用 財務突合 Zuoraへの切り替え Zuoraでの運用開始 5章 結論 最後に はじめに こんにちは！ 食べログ開発本部飲食店システム開発部でマネージャーをしている新井です。 2018年に食べログに入社し現在は販売管理チームに所属してお
エンジニアの作業負荷やシステム障害などの弊害も目立つ、「うるう秒」とは？
うるう秒は地球の自転などに基づく「天文時」と、原子時計を基にした「原子時」の時刻の差を0.9秒以内に収めるため、原子時の時刻に不定期に追加または削除する秒のことです。うるう秒で調整した時刻が世界の標準時である「協定世界時」です。これらは国際電気通信連合（ITU）の無線通信部門が最初に定義しました。 最近はうるう秒を見直す議論が盛んです。2022年夏に米メタ（旧フェイスブック）が廃止を訴える声明を出しました。同年11月には原子時や協定世界時を維持する国際度量衡局が事務局を務める国際度量衡総会で、少なくとも100年間は時刻を調整しないと提案する決議を出しました。実質的な廃止論です。 背景にはIT機器の普及があります。うるう秒に対応するエンジニアの作業負荷やシステム障害などの弊害が目立つようになりました。さらに2022年途中から地球の自転が速まっています。従来は自転速度が協定世界時よりも遅く、追
index.html
Webページが見つかりません 可能性のある原因 ・アドレスに入力の間違いがある可能性がある。 ・リンクをクリックした場合には、リンクが古い場合があります。 アドレスを再入力するか、前のページに戻る、 またはメインのサイトに移動して必要な情報を探してください。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
