魅惑の駅近不動産【りき大監視役員】 @hy2pfte59093 「井戸掘ったらアフリカ人に余計なことするなって怒られた。川まで水を汲みに行く2時間だけ労働から開放されてたのに」 と。 これに似たような事って雇われ会社員でもあったりするよね。いやあるよ笑。 2024-05-13 08:57:41
はじめに ◆この記事は何? 社内Wikiの改善方法について紹介する記事です。 ◆この記事のねらい 社内Wikiを改善することで、チームの生産性や品質を向上させ、開発体験をより良くするのがねらいです。 先に結論 「ルール」ではなく「ポリシー」を設ける 「Working集」と「アーカイブ集」をつくる ページごとに目的を書く 大切な思考法 「中途半端なドキュメントは中途半端な文化を生む」 「誰でもできるは誰もやらなくなる」 社内Wikiのよくある課題 皆さんの社内Wikiで次のような課題を感じたことはありませんか。 情報が散乱 更新中のページがそのまま メンテナンスされていない構造 多くの人が作成・編集できる社内Wikiは、改善の意志がないと上記のような状態になりがちです。 最悪の場合、開発体験の低下につながります。 良い社内Wikiとは 良い社内Wikiの必要条件は以下の通りです。 開発体験を
はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ナンモワカラン ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には3つのレベルがあることを知る な
NeWork 開発チームでは開発時間の 20%を主体的にプロダクトの改善に当てています。この取り組みの導入の背景や 1 年間運用して見えてきた良かったことや課題などをご紹介します。 目次 目次 はじめに NeWork とは 開発チーム改善活動 背景 活動内容 導入して良かったことと課題 良かったこと スプリントに積んだバックログアイテムが基本的に消化できるようになった エンジニアのモチベーション向上 インタラクションの改善もプロトタイプを通して納得感を与えられる コードの品質が上がる 課題 新機能を作った場合に他チームとの連携が難しい 新機能が放置されがち コンフリクトが起きる おわりに はじめに こんにちは。NeWork 開発チームの 2 年目エンジニアの中里です。普段はアジャイル開発エンジニアとしてフロントエンド・バックエンドを問わず、機能開発や改善を行っています。 この記事では、Ne
少子高齢化や都市部への人口流出によって、地方自治体は人口減少の問題を抱えています。業務は増えていくのに、職員は減っていく……。本イベントでは、そんな状況を打開するために、広島県の三原市役所が行った取り組みについて語られました。本記事では、三原市 デジタル化戦略監の増田剛洋氏と三原市 デジタル化戦略監 デジタル化戦略課の中谷祐基氏をゲストに迎え、自治体のデジタル化を進めるためのポイントを語ります。 行政機関や自治体で進む、業務の効率化と情報の共有化 髙野諄氏(以下、髙野):それでは、このセッションでは「kintoneをみんなで使い倒せ! ― 全職員が内製で挑む "みはらカイゼン塾" ―」ということでスタートさせていただければと思います。「Cybozu Days」2日目になりましたが、みなさん楽しんでいただいておりますでしょうか? この時間では、三原市役所のお二人をゲストにお招きしました。 近
メルカリで値段の「¥マーク」を小さくしたら購入率が伸びた理由、ペイディがサービス名を「カタカナ表記」にする理由など、プロダクトのマーケ施策まとめ30(2023) 2023年に取材した記事から、長く参考になりそうな施策をまとめました。※ 数値等はあくまで取材当時のものです。 1、商品ページの「¥マーク」を小さくしたら購入率アップ(メルカリ)メルカリでは、商品詳細ページの「値段の¥マーク」を小さくしたところ、購入率が大きく上昇した。 理由としては、¥マークを小さくしたほうが、心理的な「価格の圧迫感」が減って、心理的にすこし安く感じるためと考えられている。例えば、¥マークが大きいと桁数が多く感じたり、価格を高めに感じやすい。 この案があがったときには、社内でも懐疑的だったそうだが、テストすると小さな開発コストで大きなリターンを得られる施策になった。 元記事:https://markelabo.c
このnoteでは、僕らが2021年から2022年にかけておこなった「オペレーション改善」についてまとめています。 当時は1年間かけて、とにかく全力でオペレーションを作り込みました。そのときあった仕組みやルールのほぼすべてを、ゼロベースで見直して変えていきました。 その結果、単月の売上を1年で「6.75倍」まで伸ばすことができたのです。 数千万円だった売上は、数億円規模になりました。 なぜ、短期間でそれほどの成果を出すことができたのか? 今回はノウハウの棚卸しも兼ねて、オペレーション改善のポイントを振り返ってみたいと思います。当社のメンバーはもちろん、事業責任者やマネジメント職の方にとっても役に立つ内容になっていればうれしいです! なお、ここから書く内容はオペレーション改善にフォーカスしていますが、6倍という期待以上の結果を残せたのはそこに「メンバーの頑張り」がかけ合わさったからだと思ってい
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理(Quality Control)、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです: 法規制対応、標準化対応、その他公的なガバナンス要求へ
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか?」「なぜこれをやってるんだっけ?」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
はじめに こんにちは!10 月から株式会社ログラスでエンジニアをやっています、Kyosuke です! ログラスでは、エクセルファイルをプログラムから操作する処理が一部存在しており、Apache POIというライブラリを使用しています。(以後POIと呼びます) しかし、POI には処理方式によってはメモリを多量に使用してしまうという問題があります。 今回はその対応として、まずエクセルファイルの読み込みをFastExcelというライブラリに置き換えた話を振り返っていきます。 TL;DR POIのXSSFWorkbookは、ファイルをメモリ内に読み込んで操作するため、大きなエクセルファイルを処理する際にファイルサイズ以上のメモリを必要とすることがある POI の公式ドキュメントより FastExcelは、POIより機能は劣る代わりに、読み書きともにパフォーマンスは大幅に上回る 書き込み Fast
# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-application-tuning-guildline - https://speakerdeck.com/soudai/basic-of-rdb - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726 - https://fortee.jp/phperkaigi-2021/proposal/1d
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX(デジタルトランスフォーメー
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
あれこれ 備忘録的な書き殴りな文書です。あしからず。 オシャンティーな技術スタックで、大きな組織でやるのも面白いと思うけど、小さな会社でレガシーなシステムやメンバーと向き合うのも悪く無いよ!ってことを伝えたいのだけど、これが楽しめる人いるかな?私は楽しいよ! ジョインした時点の状況 開発体制 開発エンジニア(入社半年) インフラエンジニア(5年前後、QA兼ねる) 主力サービスの協力会社 0.5人月程度 会社の屋台骨の 主力事業のSaaSサービスがあるが、業務委託の0.5人月程度の工数の範囲でできる改修を行っていた。 開発エンジニアは新規機能を開発していた。 課題感 一度作られたシステムは、表(UI/UX)も、裏(システム)もレガシーな状況であった。 限られたエンジニアのリソースは、営業視点で、あったら売りやすい機能開発に費やされており、負債返却や、使い心地の改善には充てられていなかった。
こんにちは、MackerelチームでSREをしている id:heleeen です。 2023年3月に実施したMackerelのメンテナンスでは、データベースをAmazon RDSからAmazon Auroraに移行しました。この記事ではAuroraを選択した背景や、移行で考慮したことについてお伝えします。 データベースのアップグレードを機に検討 Auroraへ移行することによるメリット パフォーマンスの改善 マイナーバージョンアップのダウンタイムが短く サイジングを適切にできリソース活用も効率的に リードレプリカの運用負荷も改善 Auroraのリードレプリカを利用した移行 RDSにAuroraのリードレプリカを作成する リードレプリカの昇格と切り替え 本番のAurora移行に向けて準備したこと 検証環境で移行して課題を確認 本番メンテナンス時のバックアッププランを用意 Mackerelのメ
社会人として数年間働いている方でも「分かりやすい資料作りには自信がない」と言う方は多くおられます。体系的に資料の作り方を学ぶ機会が少ない上、資料を使った提案力は何年もかけて少しずつ磨かれるため、実は自信が持てなくて当たり前なのです。 私も働き始めの頃、先輩が分かりやすく美しい資料を作り、お客さまの心を動かしてコンペに勝ったり、お客さまから大きな信頼・共感を得たりする姿を見て、とても羨ましく思った記憶があります。 そんな20年以上前の自分を思い起こすと、経験が少ないがゆえに、資料作りで「つい、やってしまう表現」が沢山あったと感じます。この無意識のうちに「つい、やってしまう表現」は、資料の分かりやすさや見た目の美しさを阻害します。 この記事ではまず、なぜ人は資料を分かりにくくする手法を「つい、やってしまう」のか?という理由を探ります。その上で、ありがちな「つい」の事例と共に、ビフォー・アフター
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
選んだのはKumho PORTRAN KC-53「Tire Hood」などの口コミで「軟らかい」「乗り心地がよい」と評価を得ていた「Kumho PORTRAN」は、値段も割安でコスパもかなりよいタイヤです。 最初、正直「韓国製」ということで不安がありましたが、Kumhoというメーカーはあまり聞き馴染みがありませんが、国内外の有名自動車メーカーの新車装着タイヤに採用されるなど、企業規模はかなり大きいことを知って「まあ大丈夫だろう」と思えたので購入に踏み切りました。 画像出典:Tire Hood↑のユーザー評価にもあるように、「ブランド・デザイン」の項目以外はまずまず高得点です(わずか2票ですけれど)。 でも、そもそも商用タイヤの評価自体がさほど多くないので、たった2件でも「乗り心地」や「騒音」の口コミがあることを評価しました。 前回記事でも書きましたが、インチアップして「OPEN COUNT
昨日(もう日付余裕で回ってるので一昨日だな)Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ|ばんくし|note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性(いろいろある*1)の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
2023年現在、スタートアップ・SaaS領域周辺では、ZoomやSlackを急成長させたといわれる「PLG※」への注目が集まっています。 しかし、現時点で、国内のPLG型SaaSのマーケティングに関する取り組み事例は、あまり公開されていません。 本記事では、国内PLG型SaaSとして例に挙げられることも多い、中小企業向け業務管理システム「board」での約5年間にわたるマーケティング支援の取り組みの一部と得られた学びを紹介します。 結論としては、これまで筆者が取り組んできたBtoBマーケティングにおける定石が通用せず、全く異なる施策が有効となりました。 「board」というプロダクト固有の文脈に依存する部分も多いため、どこまで参考になるものか疑問も残りますが、少しでも役立つ部分があれば幸いです。 ※PLGとは:Product-Led Growth(プロダクト・レッド・グロース)、「プロダク
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい!」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
テックタッチアドベントカレンダー 22 日目を担当する、フロントエンドエンジニアの shoko です。クリスマスが大好きで、12 月に入ってからは毎日うきうきしています! 本日のテーマは「アクセシビリティ」です。 アクセシビリティとは? アクセシビリティとは、Web システムやサイトを可能な限り多くの人が利用できるようにすることを意味します。 「可能な限り多くの人」というのは、ハンディキャップを持つ人々だけではなく、さまざまな状況や環境も含まれます。例えば、モバイルデバイスや回線の遅いネットワークを利用する場合、屋外の光が眩しい場所でデバイスを利用する場合、機械の故障でマウスが使えずキーボードで操作する場合…などです。このような状況や環境になることは誰でも考えられることであり、アクセシビリティを改善することは多くの人にとってメリットがあります。 しかし、アクセシビリティに興味を持っても、「
はじめに 私はGCPのCloud Runがお気に入りのサーバレス環境なのですが、一番得意な言語であるJavaを使った場合のスピンアップタイムの悪さには頭を悩ませています。 ローカルでは1,2秒で起動する場合でも、何故かCloud Runに持って行くと他の言語と比べても劇的に遅くなるのですよね... GraalVMのネイティブイメージを使えばGoなどと遜色無く瞬時に起動するのですが、ネイティブイメージへの変換は癖も強いため通常のJVMでも改善できないかとチューニングを試してみました。 TL;DR 最終的に60%程起動速度を改善 9秒台が3秒台になっているので体感としては結構変わる native-imageが使え無いケースでもこのくらいなら許容出来そう もちろん完全停止状態以外のレスポンスは3秒とか言わずミリ秒オーダー 準備と基礎値の計測 まずはアプリケーションを準備する必要があります。今回は
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022 の 15日目の記事です。 qiita.com 筆者は過去に、中〜小規模のWebアプリケーションでレガシーフロントエンドの改善作業を業務でやっていた。その経験を元に技術同人誌を作成し、それがきっかけで「レガシーフロントエンド安全改善ガイド」という書籍を出した。 初版から数年経ってしまい、詳細な利用技術などの説明は少し古くなってしまっているのだが、ベースとなる考え方の部分は今でも変わっていないと思う。 一方で自分自身は、その経験が他の環境でも通用するのかを試してみたくなり、転職して一年強ほど大規模なフロントエンド刷新に関わっていた。 あまりにも規模が大きいため完遂を見届けたわけでもないが、現段階でも学びや得られたものは
OPENLOGI Advent Calendar 2022 5日目の記事です。 おはこんばんちは!! 尾藤 a.k.a. BTOです。 今年の8月にオープンロジという物流テックの会社に入社しました。入社してから4ヶ月経ち、無事に試用期間が終了したということでほっとしております。 今までウノウ、UUUM、Reproという会社でCTOを歴任してきました。立場や経験上、開発組織の立ち上げや改善に携わることが多いです。今まで自分がやってきて、開発組織を改善するために気をつけていることを書いていきます。 既存のシステムをリスペクトするあなたがこの瞬間のシステムを切り取って見た時に、仕組みがぐちゃぐちゃだったり、意味不明な処理をしていたり、不合理な仕組みになっていることは大いにあると思います。しかしながらこれまでの会社を支えて売上を作ってきたのは、紛れもない今のシステムなのです。過去の経緯もいろいろあ
肝臓に脂肪がたまり“フォアグラ”状態になる「脂肪肝」。自覚症状がないまま肝機能が落ちていく生活習慣病で、近年は飲酒量が少ない人の脂肪肝「非アルコール性脂肪性肝疾患(NAFLD)」が急増している。NASHという慢性肝炎から肝硬変や肝臓がんに至るリスクがある。 「脂肪肝はなかなか治りにくいのでは…」と思う人もいるかもしれない。しかし、ベストセラー『専門医が教える 肝臓から脂肪を落とす食事術』(KADOKAWA)の著者である佐久市立国保浅間総合病院外科部長の尾形哲氏は「食事を改善すれば脂肪肝は3カ月で良くなる」と言い切る。尾形氏が2017年に開設した肥満・脂肪肝専門外来「スマート外来」では、尾形氏の食事指導によって8割以上もの患者が脂肪肝が改善しているという。その貴重なメソッドを前・後編の2回に分けてお届けしよう。
はじめに DBが遅い原因の多くはインデックスの作り忘れです。 サーバーの性能アップやパラメータ変更の効果も大きいですが、まず最初に検討するべきはインデックスでしょう。 EXPLAINの結果をにらみながら、効果のありそうな場所を探します。 ただ、厄介なのはEXPLAINの結果が読みづらいことです。 EXPLAINの読み方を説明している本やサイトはいくつもありますが、EXPLAINを使う機会が少ないため、読める人が限られた、職人芸に近い技術になっています。 なので、EXPLAINを読まなくてもインデックスを作れるツールをGoとSvelteで作りました。 GravityRを使うと、下のようにEXPLAINをタイムライン形式にした図やインデックスの効果を表示したHTMLが作成されます。 紹介 GravityRはHasura、PostgreSQL、MySQLに対応しています。 実行ファイルをgith
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く