タグ

ブックマーク / medium.com (13)

  • PdM/EMが気づくべき「技術負債」の異変

    技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。(特に、1.と3.) 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般

    PdM/EMが気づくべき「技術負債」の異変
    onk
    onk 2024/07/10
  • 昨今の規制に伴う予防的措置実施のお知らせ

    いつもSkebをご利用いただきありがとうございます。 この告知はリクエストの内容やユーザーのみなさんの行動に制限を設けるものではありません。まずは安心して、そして最後までお読みいただければ幸いです。 昨今複数のWebサービスにおいて、特定の商品の取り扱いが停止したり、特定の決済手段の利用が停止する事態がニュースとなっています。 Skeb2022年より動向を注視しており、Skeb CoinやSkebポイントなど決済手段の拡充を進めておりましたが、今回過去最大級の規制強化の波が国内に到来したと危惧しています。 Skebは、クリエイターとクライアントが、日の法令とSkebの規約とポリシーの範囲内で、自由にリクエストできることを最優先事項としています。 連日、複数のWebサービスで発生している事態は、Skebとしても決して他人事ではなく、この最優先事項を保全するため、この度、予防的措置を実施さ

    onk
    onk 2024/04/05
  • The end of third-party cookies and its impact on Miro apps and integrations

    In this blog post, we discuss the phasing out of third-party cookies, the impact (if any) these changes will have on Miro app developers, and possible solutions to address these issues. Why are third-party cookies going away?Privacy on the web is a major concern these days. Every day users share their data on websites that they trust but if that data were to fall into the wrong hands, it could be

    The end of third-party cookies and its impact on Miro apps and integrations
    onk
    onk 2024/01/03
  • Good Tech Lead, Bad Tech Lead

    A brief guide to tech leadership at Foursquare, inspired by Ben Horowitz’s Good Product Manager, Bad Product Manager. TeamworkGood tech leads act as a member of the team, and consider themselves successful when the team is successful. They take their share of unsexy grungy work and clear roadblocks so their team can operate at 100%. They work to broaden the technical capabilities of their team, ma

    Good Tech Lead, Bad Tech Lead
    onk
    onk 2023/08/23
  • エンジニアリングマネージャーになって1年がたった

    私は,あるスタートアップ企業でエンジニアリングマネージャー(の,1人)をしている。toB向けSaaSを提供している数百名規模の会社で,社名が少しずつ世の中に知られるようになってきたくらいのフェーズ。会社からはDirectorという肩書をもらっていて,トラディショナルな日企業だといわゆる部門長の層にあたる。中間管理職の中では上のほうで,執行役員の下あたり,というと伝わりやすいだろうか。 様々な事情(会社が大きくなった,比較的社歴が長い,そこそこの業界経験値がある,自分の専門領域(*1)に社内のフォーカスがあたるようになり,チームをスケールする必要が出てきた,etc.)から,半ば必要にかられて,重い腰を上げてエンジニアリングマネージャーとして活動を始めたのがちょうど1年ほど前。 決してマネージャーとして早咲きのほうではなく,IT業界でのキャリアは15年くらいで,これまではずっとプレイヤー,ま

    onk
    onk 2023/08/22
  • 社外の人とSlack でコミュニケーションする時は、こんな思想で運用すると完璧じゃないかな。

    Slackが会社の中に浸透してくると、協業先、ベンダー、パートナー等社外のコラボレーターとのコミュニケーションもSlackでやりとりしたくなりますよね。 「Slackコネクト」がローンチされて、相互にSlackを契約している場合は、基的に「共有チャンネル」を作成して、相互のSlackオーガナイゼーションが連携され、そのチャンネルに双方の関係者を招待することで、コミュニケーションできる様になります。 ただし、Slackコネクトは双方共にSlackを契約している必要がありますので、先方がSlackを契約していない等の時は、自社のオーガナイゼーションにゲストとして招待する運用をしています。 Slackコネクトを推奨する あくまでもゲストアカウントとして招待するのは、Slackコネクトが利用できない時に限り許可しています。それは以下に挙げられる利点及びセキュリティ上の懸念があるためです。 会話履

    社外の人とSlack でコミュニケーションする時は、こんな思想で運用すると完璧じゃないかな。
    onk
    onk 2022/10/22
  • TechBlog運用の難しさとHERPでの考えについて(TechHub公開に寄せて)

    HERPの技術発信の場として、HERP TechHubをリリースしました。会社のドメイン上ではなく、個人のブログのHubとしてのページを作成する形をとっています。 それに至った背景について書いてみたいと思います。 TechBlogのあり方を考えてみるTechBlogの目的と内包している問題について、エウレカでTechBlogの開設・運用をリードした経験から得られた課題も踏まえて考えてみる。 TechBlogの目的 従来のTechBlogの開設・運用の目的は以下の3つにまとめられると思う。 ブランディングを通じた採用力の向上エンジニアの個人ブランディングエンジニア全体・技術貢献ブランディングを通じた採用力の向上 エンジニア採用においては情報発信は欠かせない。もちろん一番大事なのは良いUXを提供できるプロダクトを作り、その品質を上げていくことだが、それだけでは社外の人間からして技術への考え方や

    TechBlog運用の難しさとHERPでの考えについて(TechHub公開に寄せて)
    onk
    onk 2021/12/17
  • LAPRAS株式会社を退職しました

    2021年10月末でLAPRAS株式会社を退職しました。創業間もない2016年11月から参画していたので、5年間働いたことになります。1社目が1.5年だったのでその3倍強働いたことになりますが、そんなに長くいたかなと思うほどあっという間な5年間でした。 5年間やってきたこと2020年夏までにやってきたことは「LAPRAS CTOを交代します」の記事に書かれているので割愛して、最後の1年間SREとしての活動を少しまとめておきます。 上の記事で触れていた SREに専念できるようになったらエラーレートやレスポンスタイムのサマリをサービスのステータスページで公開したりと、品質も定量的な形でユーザの皆さんにお見せしたいと考えています。 については(自分でも忘れていたのですが…)簡易的なものですが https://status.lapras.com/ に誕生しました。エラーレートやレスポンスタイムなど

    LAPRAS株式会社を退職しました
    onk
    onk 2021/11/01
  • GKE + Istio + FlaggerによるProgressive Delivery

    サービスの信頼性をあげるため用いられる前衛的なデプロイメントパターンの一つであるProgressive Deliveryについて説明します。 来週からのKubecon 2019 North Americaでもこれに関するセッションがあり、注目に値すると思いますので興味があれば一読お願い致します。 KubeCon + CloudNativeCon North America 2019: Leveling Up Your CD: Unlocking Progressi... Speakers Principal Engineer, Intuit Jesse is a Principal Engineer at Intuit and a core contributor and technical lead… 記事ではGKE + Istio + Flaggerを使ったProgressive D

    GKE + Istio + FlaggerによるProgressive Delivery
    onk
    onk 2021/10/18
  • 心理的安全性が高くアジャイルな組織設計

    心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例:リーダーが超ベテランでメンバーが超若い

    心理的安全性が高くアジャイルな組織設計
    onk
    onk 2021/08/07
  • 競技プログラミング、ソフトウェア・エンジニア、コミュニティ

    なんか言及もされたのでアンサー的に書いてみたけど、アンサーには大してなってないな? ってやつです。一部で言及された、競技プログラミング (競プロ) 関係の話。 その前に、「プログラミングの競技」っていろいろあります。 短時間で問題に解答していく型 (ICPC / 情報オリンピック / AtCoder Regular / TopCoder とか)最適解が容易に求まらない問題のスコアを競う型 (SuperCon / AtCoder Heuristic / ISUCON / ゴルフ / ICFP Programming Contest の一部とか)対戦型 (ICFP Programming Contest の一部とか、最近のはあんまり知らないですが RoboCode / Imagine Cup とか)謎解き型 (ICFP Programming Contest で何回かありましたね。 UMIX

    onk
    onk 2021/04/04
  • ”地上最強”の技術情報収集サービス、TechFeed “Pro”をリリースしました🎉

    大変ご無沙汰しております。テックフィードの白石です。 2020/01/28、6ヶ月に渡って開発を行っていたTechFeed “Pro”をリリースしました🎉 TechFeedとは、ぼくらが開発・運営していた、技術情報収集サービスです。世界中の技術情報を、アルゴリズムが自動的に収集します。 そしてTechFeed Proとは、その名の通りTechFeedの「上位版」です😊これまでのTechFeedが初〜中級者をターゲットにしていたのに対し、Proはバリバリエキスパートの方向けに使っていただくことを想定しています。 まずは限定公開、クローズドβでのリリースで、ご利用には招待が必要です(招待を受ける方法については後述します)。 URL: https://beta.techfeed.io (招待が必要です) また、順次テクノロジー分野を開拓していく予定で、現在はweb/フロントエンドが中心となっ

    ”地上最強”の技術情報収集サービス、TechFeed “Pro”をリリースしました🎉
    onk
    onk 2020/02/01
  • Standard practice

    The Q149 Signal Selector by synthesizers.comThe Slack Web API’s catalog of methods and operations now numbers nearly 150 reads, writes, rights, and wrongs. Its earliest documentation, much still preserved on api.slack.com today, often originated as hastily written notes left from one Slack engineer to another, in a kind of institutional shorthand. Still, it was enough to get by for a small team an

    Standard practice
  • 1