１年以上インボイス制度対応をして、業務とシステムを踏まえて法整備がされるべきだと思った - SaaSベンチャーで働くエンタープライズ部長のブログ
受取請求書処理SaaSのプロダクトマネージャーとして、この1年以上プロダクトのインボイス制度対応を行ってきました。 請求書の受け取り、仕訳処理、支払処理などを行うB2BSaaSだったのですが、インボイス制度自体が非常に複雑で対応方法に非常に頭を悩まされてきました。 法制度自体が過度に複雑なため、業務もプロダクトの設計もユーザー体験も複雑にならざるを得ない点を感じました。 インボイス制度は増税観点で批判されることも多いのですが、業務自体の生産性やエンジニアの開発生産性にも影響を及ぼすと感じ、今回は法制度の複雑性に焦点を当てていきます。政治的な内容はあまり書くつもりはないのですが、昨今あまりに業務をおざなりにして法制度が作られることが気になるので課題意識を書いてみたいと思います。 インボイス制度とは インボイス制度によって業務負担が増える 適格請求書を逐一確認する業務負担が増える 適格請求書か
組織に対してSREを適用するとどうなるか
どのようなシステムもそれを作るのも運用するのも人であり（SREが目指すのが運用をなくすことだとしても）、大抵の場合、一人ではなく組織としてシステムを作っていますが、信頼性の低い組織からは信頼性の高いシステムは生まれることは考えにくいです。 SRE NEXT 2022で提起した組織に対してSREを適用する…
マネジメントをはじめて1年経っての所感 - STORES Product Blog
山陰の日本酒がすきな内立（@b1a9idps）です。2023年1月から STORES 決済 の開発部門のシニアマネジャーを担うことになりました。 マネジメント業務をはじめて1年が経ったので、やってきたことや自分自身の心情について思い出せるように書き残しておこうと思います。はじめたての頃に思っていたことはこちらにあります。 note.com 経歴 かんたんに自分の経歴を説明します。現在、STORESではマネジメント業務が中心ですが、副業ではがっつりJavaを書いています。 入社して4年7ヶ月 入社~3年半：STORES 決済 のバックエンドエンジニアとして開発業務を行う 3年半~4年半：バックエンドチームのプレイングマネジャーを担う マネジメントをはじめて1年経っての所感 マネジメントをはじめて1年の間の、チームの課題の洗い出しから解決に向けて実行したことや自分がマネジャー・シニアマネジャー
デバイスの種類ごとに表示の異なるサイトにCloudFrontを導入した話 - ロコガイド テックブログ
はじめに こんにちは、サービス基盤グループのfukajunです。各種サービスのインフラ全般を担当しています。 先日、弊社で運営するメディアサイトにCloudFrontを導入しました。 対象のサイトは、PC/スマホ/アプリそれぞれに表示が異なるものでした。 導入にあたっての導入前の振る舞い、CloudFrontでの実現方法、あわせて進めるにあたってのTIPSについて書きたいと思います。 デバイスごとの出し分け PC/スマホ まずはデバイスの種類ごとの表示の出しわけです。もともとはアプリケーション側で PC/スマホ/アプリぞれぞれのuser-agentごとに表示を切り替えていました。 CloudFrontでは、デバイスを判定した結果として以下のような特定のヘッダーを設定してくれます。 このヘッダーをCloudFrontのキャッシュキーとして追加することでPC/スマホのキャッシュを わけることが
みなさん1on1のときくらいカメラオンにしてますか？そうでもない？ - hitode909の日記
身の回りではチームのMTGとかは普段カメラオフでも、1on1のときくらいはオンにしている人が多い気がする。たぶん1年以上顔見てない人もいるけどとくに困ってないので、僕はどちらでもいいのだけどみなさんはどうだろう。 僕はある日、手荒れ対策でMacをクラムシェルモードにしたらカメラが畳まれてしまい使えなくなってしまった、という事情である日カメラオフにして過ごしていた。 さっき一念発起してMacのフタをあけてカメラオンにしてみたけど、ケーブル（高額なケーブルなので長さにゆとりのあるものは買えない）が短いので、ひきちぎれそう。 普段はカメラオフだけど、1on1のときくらいはカメラを— 趣味はマリンスポーツです (@hitode909) 2023年8月21日 この日記が、カメラオンにするのが当然、みたいな押し付けを推し進める記事にはならないようにしたい。 むしろ、1on1だからといってMacのフタ開
オープンソースの定義にこだわるのはもう無意味なのか？ - YAMDAS現更新履歴
[2023年8月22日追記]：松尾研究室の投稿にあるように、問題のプレスリリースは修正がなされ、「オープンソース」の記述は削除されている。 weblab.t.u-tokyo.ac.jp 東京大学松尾研究室が大規模言語モデル（LLM）を公開というニュースが先週話題となったが、「商用利用不可のオープンソース」という記述に「商業利用できない」のであれば、オープンソースではないという突っ込みがすかさずあがり、佐渡秀治さんも「座視することが難しい」と意見表明している。 ワタシもこれらの意見に賛成である（事実そうした声を受けて、ITmedia などは記事の記述を改めている）。ただ、この話題にすっぽり重なる文章を少し前に見て、居心地が悪い思いをしていたので、それを紹介しておきたい。 www.infoworld.com 「オープンソースのライセンス戦争は終わった」というタイトルだが、どういう文章なのか？
近況報告：無職になりました - IT戦記
みなさんお元気ですか？僕は少しだけ元気ではありません。じんわりとした夏の暑さを感じながらブログを書いています。 実は、数ヶ月前にスマートニュースという会社を退職しました。 しばらく無職 しばらくは就職せずに無職でいようかなと思っています。 すぐに再就職した方がいいんだろうな〜。とは思うのですが少し疲れたかも。 いい時代になったものだ 最近は AI の進化も素晴らしく、昔ソフトウェアで出来なかったことがどんどんできるようになってるなって感じます。 Rust とか、ちょうど欲しかった感じのプログラミング言語もあるし、 ChatGPT は完璧ではないけど何か新しいことを始めるときに素晴らしい洞察を与えてくれる。 時代は確実に良くなってる。そんな時代に「自分は働いていないくていいのか」と少し不安になるけれど、自由気ままにコードを書く、そんな時間が今あってのもいいのかなって思ってます。 オフトピック
【追記 2023/06/26】 テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
定量評価疲弊しませんか？～Well-beingと生産性指標を組み合わせた エンジニアリングメトリクスプログラムについて～