タグ

関連タグで絞り込む (21)

タグの絞り込みを解除

技術に関するbraitomのブックマーク (23)

  • CTOに求められる3つの能力 ～EMやTLとの違いとは？～｜MIDAS Technology Review


    今回は、ZOZOテクノロジーズ︵現ZOZO︶でCTOを務め、現在はバイセルテクノロジーズ 取締役CTOの今村さんの﹁CTO論﹂を伺いました。 今村さんは、12年間のCTO経験があり、その間﹁エンジニア組織づくり﹂﹁技術広報﹂﹁情報システムの整備﹂﹁技術戦略策定﹂﹁人事制度策定﹂など、様々なCTO経験をお持ちの方です。 それらの経験を元に﹁CTOに求められること﹂特に﹁CTOと、EM︵エンジニアリングマネージャー︶やTL︵テックリード︶との違いは何か﹂について伺いました。 参考︶ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る ① ﹁登る山﹂を決める判断力と、中長期的な課題解決を行う実行力 ■ CTOとEMやTLとの違い まず、CTOがEMやTLと違う大きな点は、より広範囲・より長期的な課題解決を行う点です。 EMやTLは短期的︵半年程度先︶、そして事業やプロジェクト単位
    CTOに求められる3つの能力 ～EMやTLとの違いとは？～｜MIDAS Technology Review

  • 第5回　開発組織におけるブランディング | gihyo.jp


    マネージャーの成果向上のためのブランディング エンジニア採用を進めていくと、ブランディングの課題がよく話題にあがります。 多くの採用候補者に認知され興味を持ってもらうためブランディングを見つめなおし社内制度も見なおすことを、過去に採用責任者をやっていた会社で行いました。最近でも筆者がCTO︵Chief Technology Officer、最高技術責任者︶を務めるサイカや、顧問先でも、採用活動をする前に同様のことを行うケースが多いです。それは、ブランディングが採用活動において採用候補者の認知獲得やアトラクト[1]をするために不可欠なことだからです。 またブランディングにつながるような制度整備や社内のルール／しくみを見なおすことが、社員全員のやりがい向上やロイヤリティの向上につながってきます。社外の方へ影響を与えるだけではなく、組織に属するメンバーに対してもポジティブな影響を与えマネージャー
    第5回　開発組織におけるブランディング | gihyo.jp

  • エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと


    こんにちは、株式会社エウレカでCTOをしている kaneshin です。 この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。 はじめに株式会社エウレカは、恋活・婚活マッチングアプリ﹁Pairs﹂の運用とオンライン結婚相談所﹁Pairsエンゲージ﹂の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。︵Pairsは以下﹁ペアーズ﹂と表記します︶ 入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世
    エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
    braitom
    braitom 2020/12/25
    Technical BreadthとTechnical Depthでのキャリアの考え方面白いな。使えそう。
    リンク

  • 技術的負債の優先順位について論文を読んでみた


    はじめに POLプロダクト Advent Calendar 2020の8日目のバトンを受け取りましたので、技術的負債の優先度について考えてみます。 技術的負債の認識とその対策が非常に重要であることは、エンジニア以外の方々にとっても、認識されつつあると思います。 技術的負債と呼ばれるものは非常に多岐に渡り、どのような会社においても大量に存在するでしょう。 私自身もエンジニアとして大量の技術的負債を作ってきた自覚があり、またどなたかの技術的負債に向き合ってきた経験があります。 しかしながら、ではどの負債から返すべきなのかということは、私の中にも確固たるロジックがありませんでした。 今回はこの問題を掘り下げるべく、ある文献レビュー論文を追いかけ、その中で紹介されていたわかりやすい方法を紹介します。 技術負債とはなにか？ 技術的負債はWard Cunninghamさんが1992年に国際カンファレン
    技術的負債の優先順位について論文を読んでみた
    braitom
    braitom 2020/12/09
    技術的負債の優先順位付けについて書かれた論文「A Systematic Literature Review of Technical Debt Prioritization」の紹介と、その中で提案されている技術的周匝の特定方法について書かれている。
    リンク

  • 褒めるラジオ quipper.fm - スタディサプリ Product Team Blog


    こんにちは。quipper.fm メインパーソナリティの @chaspy です。 今回、一緒に働く仲間をただひたすらに"褒める"社内企画をはじめてみました。好評により続いているので、その取り組みについて紹介します。quipper.fm とは何か なぜはじめようと思ったのか 褒めることの重要性 1. "褒め"によるフィードバックが個人の振る舞いを強化する 2. "褒め"による振る舞いが言語化されることはそれ自体が貴重な学びの機会になる 褒める技術 褒められたひとからの言葉 おわりにquipper.fm とは何か 名前に深い意味はないんですが、ラジオっぽい"雰囲気"でゆるく聞いてもらえたら、という想いで .fm をつけています。実際は社内 Google Hangouts で行っているので、音声だけでなく映像も映ります。 この番組は隔週30分で行われています。各回に1名﹁褒められるひと﹂が選
    褒めるラジオ quipper.fm - スタディサプリ Product Team Blog
    braitom
    braitom 2020/08/18
    褒め合う文化を作るための取り組みについて。褒めることの重要性、褒める技術について、行っている取り組みについて書かれている。めっちゃいい取り組みだ。
    リンク

  • 事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck

    Transcript 事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1 自己紹介 ▪伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP, Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me! 今日のテーマ「技術選定」 4 何故、技術選定は難しいのか？ ▪正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい 難しいからこそ向き合う価値がある ▪今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然

    事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck
    braitom
    braitom 2020/06/06
    技術選定を行うときの考え方について。判断軸を整理する、方針と詳細を分ける、方針を組織に浸透し定着させていくなど。
    リンク

  • 技術ごとのスペシャリスト制度に関して - Adwaysエンジニアブログ


    どうも、大曲です。 リモートワークにも慣れて来ました。 今回は技術に特化した人材のための﹁技術ごとのスペシャリスト制度﹂の背景や責任部分を紹介します。 初めはコントリビューターという名前にしていたのですが、浸透しなかったりしてこの名前になりました。 ※アドウェイズ全体の制度ではありません。あくまで自分が管轄している組織の話です。 この制度が出来るまでのタイムライン 最初は自分一人で動きや成果を検証しつつ作っていきました。 徐々に関わる人を増やしていき最終的に2020/04に制度として確立させました。 そのため、この制度にたどり着くまで1年以上かかりました。 この制度に関わった人の人数の変化。 各技術ごとの取り組みの動き。 現在はScala、Vue.js(TypeScriptも含む)、Ansibleの3つの言語でこの制度に基づいて改善などを行なっています。 目的 特定の技術︵主に言語︶に特化
    技術ごとのスペシャリスト制度に関して - Adwaysエンジニアブログ
    braitom
    braitom 2020/06/05
    アドウェイズが導入したスペシャリスト制度に関して。技術ごとにスペシャリストをおき、展開責任、知見蓄積責任、教育責任を持つ。なるほどなー。
    リンク

  • 技術力があるとは？2019年振り返り - アルパカログ


    ﹁あなたたちは技術力がない﹂ 2019年を振り返って真っ先に思い浮かぶのは、普段一緒に働いてない人に、面と向かってこう言われたことだ。 みなさんはそんな経験あるだろうか？ エンジニアの中でも特に優れたエンジニアのことをスーパーエンジニアという。スーパーエンジニアとは抜きん出て﹁技術力がある﹂エンジニアのことだ。 ﹁技術力がある﹂って言葉、わかってるつもりでつい使っちゃうんだけど、みなさんはどうだろう？ 例えば最近Twitterで話題になっていたこちらのツイート。 スーパーエンジニアが通った跡には誰もメンテできない超絶コードが残ったりするので、チームでパフォーマンス出せないスーパーエンジニアをありがたがるのって、ミーハーな経営者くらいしかそもそもいないのでは。— 大岡由佳﹃りあクト!第3版﹄技術書典9までに刊行 (@oukayuka) 2019年12月25日 私の知っているスーパーエンジニ
    技術力があるとは？2019年振り返り - アルパカログ
    braitom
    braitom 2019/12/31
    ごもっともだ。なので企業ではうちの会社ではこういうことができると技術力があると考えられますってある程度定義するのが大事だと思う。“人によって技術力の定義が違うのだ”
    リンク

  • プロダクトカンパニーの技術戦略 - freee Developers Hub


    こんにちは、freee株式会社 CTO の横路です。 この記事はfreee developers Advent Calendar 2019の最終日です。 昨年のアドベントカレンダーでは新卒で入ってくる君たちへというお題で、freeeの新卒の期待値は﹁3年でスモールチームのCTO﹂であるという話をしました。今年は次のステップとして、100名を超えるような﹁大きなチームのCTO﹂になるとどんなことを考えているのか？なかでも恐らくイメージしにくい技術戦略の考え方について、freeeの事例を振り返りながら、わかりやすくお伝えしたいと思います。 技術トップの役割の全体像と技術戦略の位置づけ プロダクトマネジメントのバイブルである﹁INSPIRED 第2版﹂に、大きなチームの技術トップの責務がよくまとまっています。 組織 従業員の採用とスキル向上に全力を注ぐ強力なマネジメントチームづくり リーダーシッ
    プロダクトカンパニーの技術戦略 - freee Developers Hub
    braitom
    braitom 2019/12/27
    プロダクトカンパニーの技術戦略の考え方について。技術による付加価値の連鎖イメージ、技術投資のステップについてなどが書かれている。これは参考になる。
    リンク

  • Engineering Managerとしての技術ブランディングへの取り組み方 - itohiro73’s blog


    本記事はEngineering Manager Advent Calendar 2019の23日目の記事です。 自己紹介 2019年10月からREADYFORというクラウドファンディングの会社でVP of Engineeringを務めております、伊藤と申します。﹁いとひろ﹂と呼ばれることが多いです。2005年から12年ほど外資系金融の会社でソフトウェアエンジニアを務めたのち、FinTech系のスタートアップ2社を経て現職に就いております。 Engineering Managerと技術ブランディング Engineering Manager︵以降EM︶が取り組むひとつの課題として、エンジニア組織をいかに成長させていくかという課題があると思います。そのためにも採用数を伸ばしていかないといけなかったり、人材流出を防ぐためにリテンション施策をとらないといけないと思います。その中のひとつの施策として技
    Engineering Managerとしての技術ブランディングへの取り組み方 - itohiro73’s blog
    braitom
    braitom 2019/12/24
    技術ブランディングについて。技術ブランディングを醸成するのに大切なポイント、明確に強みである領域とこうありたいという想いがあるがまだ達していない領域それぞれのブランディング方法について。
    リンク

  • "技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita


    はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、﹁技術的負債﹂と言う言葉です。一般には、﹁早さ﹂を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても﹁古くなってしまったコード﹂や﹁わかりにくコード﹂全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
    "技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita

  • Web 技術をキャリアの中心にしない


    うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その
    Web 技術をキャリアの中心にしない
    braitom
    braitom 2019/03/05
    ふむ。“Web 技術がいくら進化しても、本当のところ、インフラはなくならないし、サーバーはなくならないし、Linux も当面はなくならない ”
    リンク

  • 技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ


    反省文。 tl;dr・﹁後から改善すれば良い﹂のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの1つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
    技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
    braitom
    braitom 2019/01/29
    技術的負債を生んでしまう要因の分析、返済コストの理想と現実について、継続的リファクタリングの効用について。これなー。“スピード優先"を盾に、技術的負債を貯めることを良しとしたこと”
    リンク

  • 新しい技術の導入時に大切にしていること - Gunosy Tech Blog


    こんにちは、koidです。こちらは Gunosy Advent Calendar 2018 、25日目の記事です。昨日の記事は @hoshitocat さんの Swaggerでインタフェースの共有をしつつ社内管理画面を作る でした。 早いもので、Advent Calendarもあっという間に最終回となりました。この記事を持って、今年も無事(?)完走となります。 さて、本題です。 今年も弊社では、様々な技術*1や手法にトライし、プロダクションへの導入を行ってきました。 そんな中で、そういった新しい技術を導入していくにあたり、どんなことを大切に考えているのか、先日 IVS CTO Night というイベントでLTをする機会があったので、その際にお話ししたことを書きたいと思います。 技術は目的ではなく、課題解決のための手段である どんな課題を解決したいのかを明確にする 良くない例︵課題が明確にな
    新しい技術の導入時に大切にしていること - Gunosy Tech Blog
    braitom
    braitom 2018/12/28
    大事。“技術は目的ではなく、課題解決のための手段である”
    リンク

  • 社内に情報発信する文化を根付かせ 定期的に更新可能な体制にする方法

    2016年10月08日に開催されたUX、デザイン思考、サービスデザインのための「チームで使える共感ペルソナ™入門 」での資料です。 ■■■イベントページ■■■ http://uxd-hcd-waiwai-cafe.connpass.com/event/40552/ ■■■運営協力■■■ GMOインターネット株式会社 https://www.gmo.jp/ 株式会社スタンダード http://www.standardinc.jp/ ■■■主催■■■ 株式会社アイ・エム・ジェイ http://www.imjp.co.jp/

    社内に情報発信する文化を根付かせ 定期的に更新可能な体制にする方法
    braitom
    braitom 2018/11/05
    LINE社の情報発信を根付かせるための取り組みについて。情報発信する理由、根付かせるための仕組みが書かれている。
    リンク

  • ミクシィグループのサービスと利用技術(技術スタック)についてまとめてみた｜ミクシル


    ミクシィグループではこちらで説明している通り、様々な事業領域にてサービスを展開しています。運営しているプロダクトには10年以上稼働しているシステムもあれば、リリースしたばかりのものまで多岐にわたっているため、様々な技術が各所で採用されています。 多数のサービスを展開していることもあり、改めてミクシィグループの各サービスや事業部が現在どのような技術を採用しているか、技術スタックをまとめてみました。開発言語やインフラ環境、デプロイツールなどをサービス/事業部ごとにまとめています。 ︻サービスおよび、技術スタック一覧︼ ※サービスやプロダクトに該当しないケースは、各事業部で採用している技術を紹介します。 ※2018年8月30日時点での情報です。 ※8月30日に実施された社内イベントの内容を元に作成しています。 その2はこちら スマートヘルス 事業部の取り組み スマートヘルス事業部は、超高齢社会を
    ミクシィグループのサービスと利用技術(技術スタック)についてまとめてみた｜ミクシル
    braitom
    braitom 2018/10/14
    ミクシィグループの各サービスなどで利用している技術スタックのまとめ。こういうまとめ面白いな。
    リンク

  • AWS をどう使わずにおくか - portal shit!


    ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し︵レガシーシステムで SQS を使っている︶、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
    AWS をどう使わずにおくか - portal shit!
    braitom
    braitom 2018/10/03
    技術選定のプロセスの一例としてよい。色々考えさせられた
    リンク

  • スタートアップの技術選定とアプリケーションプラットフォーム - laiso

    photo by pexels.com *1 この記事を書いたきっかけ niconegoto.hatenadiary.jp 「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。 アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。— sadakoa (@sadako_a_) August 16, 2018 (Twitter上で多くの共感を集めた投稿) 例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点

    スタートアップの技術選定とアプリケーションプラットフォーム - laiso
    braitom
    braitom 2018/08/26
    ふむ。“「隣の芝生は青い」を乗り越えるにはプロトタイプを作り続けるのが重要”
    リンク

  • Redashを0から布教して社員全員に効果検証の文化を根付かせた話 - BASE開発チームブログ


    (BASEオフィス内の光景) 初めに こんにちは！BASEでBack-end Engineer Groupに所属している菊地陽介です！ 今年度からBASEでは世のエンジニアに興味を持ってもらおうと、積極的に技術ブログを発信していこうという運びとなりました。本記事を読んで少しでも興味を持って頂けましたらぜひ私までご連絡ください！ さて、私はRedashエヴァンジェリストとしてRedashを社内に普及させましたので、その話について書こうと思います。﹁Redashって何？﹂、﹁Redashサーバってどうやって立てるの？﹂、﹁Redashの便利機能は？﹂などの疑問については先に素晴らしい記事がたくさんありますので、そちらを参考にされてください。 この記事では、Redashをどのように社内に普及させたのかということについて述べたいと思います。 背景 私がBASEに入社したのは、今からちょうど一年前の
    Redashを0から布教して社員全員に効果検証の文化を根付かせた話 - BASE開発チームブログ
    braitom
    braitom 2018/04/25
    キャズム理論を元に技術を普及する戦略を立てるのいいな
    リンク

  • TechCrunch | Startup and Technology News

    Hello and welcome back to TechCrunch Space. What a week! In the same seven-day period, we watched Boeing’s Starliner launch astronauts to space for the first time, and then we…

    TechCrunch | Startup and Technology News
    braitom
    braitom 2017/02/14
    なんかすごいこと言い出したな。これ実用化されるとかなりすごいのでは？
    リンク
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.