タグ

仕事とdevelopmentに関するCherenkovのブックマーク (12)

  • クレディセゾンでDXを進めてきた5年間を振り返る|小野 和俊

    はじめにクレディセゾンに来てちょうど5年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない!」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません! 2019年:ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか?」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答

    クレディセゾンでDXを進めてきた5年間を振り返る|小野 和俊
    Cherenkov
    Cherenkov 2024/03/28
    クレディセゾン クレジットカード
  • ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary

    早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントやがあるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基的にそのためにやることは3つしかないと

    ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
  • わかりやすいシステム構成図の書き方 - Qiita

    わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか? このシステム構成図のわかりにくい点が3つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の3つです。 わかりやすいシステム構成図 これら3つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

    わかりやすいシステム構成図の書き方 - Qiita
  • できないエンジニアの特徴 - Qiita

    エンジニア単価表の記事はこちら! はじめに 社会人になってから数年。数々の失敗を目撃 & 体験をしてきました。 その教訓で、改善すればより仕事も人間関係も円滑に進み、エンジニアとしても成長できるだろうなというネガティブな点をまとめてみました。 僕も過去できていなかったり、今もできていないところはありますが、反面教師として伝えられたらと思います。 特徴 1.納期に間に合わない時、自分から報告してこない 明確に期日が共有できているのにも関わらず、直前もしくは遅れる旨を報告してこないパターンです。 責任感がない人に多い気がします。実力不足であったり、実装していくうちにタスクの見積もりがずれることもあるので勇気を持って報告しましょう! 2.タスク分解しないで、仕事し始める 機能実装のような中規模以上のタスクは、DB変更など下のレイヤーが間違っているとその上位の実装も全て修正しなくてはいけなくなりま

    できないエンジニアの特徴 - Qiita
  • 炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance

    最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ!!経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要!やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ!— 代表取締役 岩元仁@株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクト炎上

    炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
    Cherenkov
    Cherenkov 2021/08/30
    わかる >与えられた仕様をなぞって書いても漢字の書き取りと変わらない
  • みずほ銀行システム障害に学ぶ

    みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては(

    みずほ銀行システム障害に学ぶ
  • シリコンバレーで働いてわかった「日本人がお金持ちになれない」納得の理由

    自分の生涯年収を考えたことはあるだろうか? 「一般的なサラリーマンの場合、一生働き続けてもせいぜい1億円」などと言われる。だがじつは、働き方について少し考えを変えるだけで生涯稼げる額はガラッと変わる。 プログラマーの酒井潤氏は文系でありながら独学でプログラミングを学び、現在は、全米給与ランキング4位の米国Splunk,Incでソフトウェアエンジニアとして勤務。また、副業Udemyのプログラミング講師も務め、年収1億円を実現した。 稿は、酒井氏の著書『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』(PHP研究所)より、シリコンバレーの事案に見る「稼ぐ人の条件」を紹介する。 ※稿は、『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』 (PHP研究所)の内容を抜粋・編集したものです。 年収4000万円では足りない 「シリコンバレーでは年収4000万円でも中流階級」とよ

    シリコンバレーで働いてわかった「日本人がお金持ちになれない」納得の理由
  • 『ふりかえり』が開発チームを強くする|あっきー

    ハンズシェアでは2週間のスプリントを切りスクラムを組んで開発をし、スプリントの終わりにふりかえりをしています。『アジャイルレトロスペクティブ』を読んでふりかえり手法を改善した取り組みを紹介します。 これまでの『ふりかえり』これまでスプリントレトロスペクティブ(ふりかえり)をKPTのフレームワークを使い改善を行ってました。 KPTとは、Keep/Problem/Tryの頭文字を取ったもの 1.Keep(良かったこと、続けたいこと)を出す 2.Problem(問題、開発の妨げになったこと)を出す 3.Try(Keepを更に良くする案、Problemを改善する案)を出す 4.Tryに投票し改善していくことを決めるKPTでのふりかえりをしている中で下記のような問題を感じていました。 ・KPTが形骸化 ・スプリントでやったことをそんなに覚えてない ・チームの問題発見・改善に対してクリティカルなものが

    『ふりかえり』が開発チームを強くする|あっきー
  • Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう

    Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、

    Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
  • プログラミングに関するあまり知られていない7つの真実

  • エンジニアが求める職場環境まとめ(暫定)

    津田大介 @tsuda なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件/環境/待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 2010-10-06 18:32:35

    エンジニアが求める職場環境まとめ(暫定)
    Cherenkov
    Cherenkov 2010/10/07
    #engineerenv 株式会社ディー・エヌ・エー(DeNA)のオフィシャルリクルーターに就任した@tsudaが世のエンジニアに「金銭」以外の条件で職場に求める条件を呼びかけ
  • 派遣PG時代の思い出

    @vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06

    派遣PG時代の思い出
  • 1