タグ

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

タグの絞り込みを解除

developmentに関するmaricar9710のブックマーク (148)

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

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

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

  • 無駄にGAFAの逆をいくな…というお話｜深津 貴之 (fladdict)


    先週、電通さんのスタートアップのアクセラレーションと、W venturesさんの投資先メンタリングをやりました。その両方で話したことの補足。 GAFAの作法に無駄に逆らってはいけないよ。GAFA級の複数企業が同じ施策・設計をしていたら、よほどのファクトがない限りは従うのがオススメ。 GAFAってのは、Google, Apple, Facebook, Amazonのことですね。 ここ数年、スタートアップ支援のお手伝いをすることが増えてます。去年は単発の相談も含めると50社ちかくで、サービス設計やグロースのメンタリングをしました。 で、ちょいちょい思うんですが… みんなオリジナリティのあるサービス設計をしすぎ！しかも、必要ないところで！ みなさん、すごい真剣にサービスを作ってるのはわかります。でも、頑張らなくてよいところで、頑張りすぎてる。決済ボタンの位置とか、リンクの色とか、ログインフローと
    無駄にGAFAの逆をいくな…というお話｜深津 貴之 (fladdict)

  • やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

    2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ

    やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

  • 管理画面に汎用的で便利すぎる機能追加はもしかすると危険かもしれない - ぷぎがぽぎ


    以前、PHPカンファレンスで運用しやすい気づける管理画面という発表*1しましたが、今もこの考え方を大事にしながら日々サービスの運用、開発をしています。 その中で、最近思ったことがあったのを社内kibelaにポエムってあったのですが、普通に公開できる内容だったのでここにちょっと加筆して投下しておきます。 サービスに大きく影響与えるような大事な情報ってありますよね。たとえば広告配信サービスだと広告の単価設定です。そのような項目の設定作業を画面からぽちぽち1つずつ変更するのは大変なのでCSVで一括で変更できる機能をいい感じに開発すると喜ばれるという場面は管理画面を開発している人にはよくある話だと思います。そして、﹁この項目も設定できるようにしたい﹂という声がでてきて、CSVからいろんな項目が設定できる便利機能へと発展していったりすることも。 しかし人間はミスをするものです。一括変更のため変更され
    管理画面に汎用的で便利すぎる機能追加はもしかすると危険かもしれない - ぷぎがぽぎ

  • エンジニアドリブンでユーザー体験を約250％改善した話 - トクバイ テックブログ


    こんにちは、技術部の@k0uhashi👻です。最近の休日の過ごし方はVRChatを朝から次の日の朝までやることです。一瞬で月曜日が来るのでオススメです。業務では主にトクバイiOSアプリの開発をしています。 トクバイAndroid/iOSアプリはおトクな体験をより身近にし、もっと買い物をかしこく、たのしくできるようにアップデートを日々重ねています。 みなさんは、サービス開発を進めるにあたってどんな施策をやっていますか？それってどうやって考えてますか？さらにはどうやって進めていますか？アプリの体験を良くするための施策を考える中で、アプリ内で提供するコンテンツを増やしたり、UIを変えてA/BテストしてよりよいUIに変えるーーー。といった目で見てわかりやすい変化をつけることに目を向けがちですが、それ以外にも体験を良くする方法ってたくさんあるはずです。例えば、次のようなものとか。 読み込み待ち時間
    エンジニアドリブンでユーザー体験を約250％改善した話 - トクバイ テックブログ

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


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

  • コードレビューは「コードの欠点を指摘する行為」ではない - id:anatooのブログ


    コードレビューを﹁コードの欠点を指摘する行為﹂だと無意識に思っている人を見かけるけども、そういうふうに認識しないほうがチームにとって良いですよ、という話。理由は以下。 レビュワーの方がレビュイーよりも実力が無いといけない、という認識と結びつきがち チームの若いメンバーがレビュワーになりづらくなる 古株のメンバーやリーダーの書いたコードがレビューされなくなる レビューで指摘された項目がない = (指摘された欠点が無いということなので)良いコードという図式になりやすい レビュワーが欠点を指摘するあまり攻撃的なレビューをしてしまうことがある 逆にレビュワーがレビュイーに遠慮してあまりレビューしなかったりする レビュワーが誰でもわかる間違いしか指摘できなくなり、建設的な議論が起こらなくなる コードレビューが機能不全に陥る原因の一つが、コードレビューに対する基本的な認識がずれていることだと思う。 じ

  • ソフトウェア設計が重要である理由 | POSTD


    新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”︵出典‥ Trent Erwin ／ Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存
    ソフトウェア設計が重要である理由 | POSTD

  • システム更新の見積もりが億単位？　ならば自分たちの手で　信州ハムはどうやって9カ月で基幹システムを内製したのか (1/2) - ITmedia エンタープライズ


    信州ハムもかつては、基幹システムの構築、保守を外部のIT専門企業に任せていたが、20年以上運用してきたシステムが老朽化したため、新規システムの見積もりを依頼したところ、出てきたのは﹁億単位の提案﹂だったという。持続的成長に向けた投資も検討しなければならない中、﹁これではとうてい手が出ない﹂――。やむにやまれぬ状況で対応策を探す中、ある展示会で目にしたのが﹁FileMaker﹂のプラットフォーム上でカスタムAppを構築する方法だった。 当時、情報収集に当たっていた信州ハムサービス 取締役開発本部長の土屋光弘氏は﹁2014年のFileMakerカンファレンスで実際に食品メーカーで活用している例があることを耳にして、﹃これならできそうだ﹄という感触をつかみました﹂と振り返る。 土屋氏と一緒にカスタムAppの開発に当たったのが、信州ハムの生産管理部 生産管理課で係長を務める織部航氏だ。デザイン思考
    システム更新の見積もりが億単位？　ならば自分たちの手で　信州ハムはどうやって9カ月で基幹システムを内製したのか (1/2) - ITmedia エンタープライズ

  • 個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。 - フロントエンドの地獄


    運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて﹁モチベーションが続かない﹂﹁いつの間にか辛くなってくる﹂という個人開発あるあるについて話していました。 個人開発は﹁自分の作りたいもの﹂を﹁自分の使いたい技術﹂で﹁自分の好き﹂に作れる最高の舞台です。クリエイターならやらない手はないでしょう。 しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。 仕事でもなく﹁自分が作りたくて作っていた﹂はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで﹁え、なにこのクソコード﹂と毒づいてしまうほど荒れ果てたmas
    個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。 - フロントエンドの地獄
    maricar9710
    maricar9710 2018/11/21
    やっていき
    リンク

  • ツールは解決策ではない | POSTD


    最近、﹃The Atlantic﹄に掲載された非常に重苦しい 記事 ﹁The Coming Software Apocalypse﹂︵きたるソフトウェア大惨事︶を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。 同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。 私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは﹁大惨事﹂に対する解決策ではありません。 著者は
    ツールは解決策ではない | POSTD

  • たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba


    ﹁プロダクトオーナーとしてやることはしっかりやってるんです﹂ ﹁もちろんバックログがあります。そして、ストーリーが優先順にならべられています﹂ ﹁MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています﹂ ﹁そしてこのMVPをこの日までにリリースしたいと考えているんです﹂ いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 ﹁そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？﹂ そうですね・・・。まずは、実現できないということを受け止めましょう。 ﹁え？﹂ そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 ﹁もう自分のできることは全てやっていますよ
    たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba

  • 無理をしないコードレビュー - クックパッド開発者ブログ


    会員事業部の三吉︵@sankichi92︶です。 クックパッドでは、GitHub Enterprise の Pull Request を使ったコードレビューを広く実施しています。 この記事では、私がコードレビューすることに対する苦手意識をなくすために意識したことを紹介します。 クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。 チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PRを出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。 私は、昨年2017年に新卒入社したのですが、それまでは個人開発や研究用のコードしか書いたことがなく、短期インターンシップを除くチーム開発の経験がありませんでした。 配属当
    無理をしないコードレビュー - クックパッド開発者ブログ

  • MENTA作者の入江さんと個人開発談義をしたら色々と気付きがあった - 丁寧に手を抜く


    どうもTAKUYAです。 自分のように個人開発で実際にマネタイズをしている人は少ない。 入江さんは、自分と同じフリーランスで、最近受託を完全にやめて自分のサービスだけで食おうとしている人。 スキルセットも似ていて、デザインも自分でやる。 最近ローンチしたMENTAというスキルシェアリングのサービスも、デザインがしっかりしていて完成度が高い。 ちょうど入江さんが福岡から東京に来るとツイートしていたのでお茶に誘って、個人開発談義をしてきた。 うろ覚えではあるけど、印象に残った話を議事録形式でシェアしたい(本人許可取得済)。 入江さんの話 受託開発の話 顧問契約で毎月定額形式で契約して、工数を絞って長期的に関わると、新規プロジェクトでも関わりやすい 自分のブログで受託の仕事を手伝ってくれる人を募集した 人を雇うときは、いきなりガッツリ依頼するのではなく、例えば月単価二万円など小規模な単位で始めて
    MENTA作者の入江さんと個人開発談義をしたら色々と気付きがあった - 丁寧に手を抜く

  • プログラマが知るべき97のこと

    プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず

    プログラマが知るべき97のこと

  • デスマーチが起きる理由 - ３つの指標


    鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。﹁高い金を払ってコンサルタントを雇った極めて重要なミーティングだ﹂と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は﹁テスト工程を削ってでも早く納品しろ﹂とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 ﹁遅れてすまない﹂ そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
    デスマーチが起きる理由 - ３つの指標

  • 「ディレクターがいないゲーム開発」を経験した話 - ゲームプランナーの技術ブログ

    ディレクターがいない現場で仕事をするという貴重な経験をした。 今回は、ディレクターがいない開発現場のヤバさを共有したい。 そして、そういった現場が生まれる悲劇をくいとめることに貢献したく思う。 どういた開発体制だったのか ヤバさ１:全体的な方針が立てられない ヤバさ2：情報を管理する人がいない ヤバさ3：会議をしきる人間がいない ヤバさ4：揉めた時に間に立つ人がいない まとめ どういた開発体制だったのか 会社が特定されるといりいろとこまるので、ざっくりいうと、 ・30～40名ほどの開発体制 ・受託開発 ・エンジニアとデザイナー中心 といったところだ。 ディレクターがいなくても成立する様な小さなプロジェクトというわけではない。 ヤバさ１:全体的な方針が立てられない 受託開発なので、クライアントがいるわけだが、このクライアントに対して、各担当者が思い思いのやり方で対応することとなった。 その結

    「ディレクターがいないゲーム開発」を経験した話 - ゲームプランナーの技術ブログ

  • 人月単価で80万円ぐらいの仕事 - terurouメモ


    Twitterでこういうことを書いたら、そこそこ反応があった。 今のご時世、技術難易度が並ぐらい︵一人でWebシステムが構築できる程度︶で、2‐3人月ぐらいの小さなシステムを一人でヒアリング～実装～運用引き渡しができて、説明責任ちゃんと果たせれば、人月単価換算で80万円ぐらいは一杯転がってる︵常にあるとは言ってない︶し、その他要因で単価はもっと上がる— てるろー (@terurou) 2018年4月17日 意図通りには伝わらないだろうなぁと思いつつ、所詮Twitterだしなーと思いぶん投げたんだけど、想定してた範疇の誤解が広まってきたので、一応補足する。 ﹁人月単価で80万円ぐらいの仕事﹂の難易度 ちゃんと書いてないから伝わらなくて当然といえば当然なんだけど、行間をちゃんと補うと、 エンドユーザー直案件 技術難易度的には、いわゆるマスタメンテナンス機能に毛の生えた程度のもの 一覧/詳細/編
    人月単価で80万円ぐらいの仕事 - terurouメモ

  • あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える - エンジニアHub｜若手Webエンジニアのキャリアを考える！


    あるエンジニアが﹁Kibela﹂というサービスを考え、リリースするまでのフローを全部教える エンジニアがサービスのアイデアを思いつき、それをリリースするまでにはどのような過程があるのでしょうか。情報共有ツール﹁Kibela﹂が世に出るまでのフローを、起業した井原正博さんが詳細に振り返ります。 ヤフーやクックパッドでの開発を経て、ビットジャーニーで代表を務める井原正博︵いはら・まさひろ／@ihara2525︶です。プライベートで超長距離のランを楽しむかたわら、情報共有ツール﹁Kibela﹂の開発・運営を手がけています。 Kibela - 個人の発信を組織の力にする情報共有ツール ﹁Kibela﹂は僕自身が2015年に起業して立ち上げたサービスですが、この記事では、僕がサービスをいかに開発したか、その方法からリリースまでの過程を振り返りつつ、サービスの現在の状況までお伝えします。 ﹁自分でもサ
    あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える - エンジニアHub｜若手Webエンジニアのキャリアを考える！

  • 真面目な人を本気にさせる方法


    先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに﹁本気︵マジ︶と真面目︵マジメ︶﹂の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。
    真面目な人を本気にさせる方法
  • 1 2 3 4 5 6 7 8 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

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

  • @hatebu

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

はてなブックマーク

公式Twitter

はてなのサービス

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