社内Wikiを改善して、開発体験をより良くする - Qiita
はじめに ◆この記事は何？ 社内Wikiの改善方法について紹介する記事です。 ◆この記事のねらい 社内Wikiを改善することで、チームの生産性や品質を向上させ、開発体験をより良くするのがねらいです。 先に結論 「ルール」ではなく「ポリシー」を設ける 「Working集」と「アーカイブ集」をつくる ページごとに目的を書く 大切な思考法 「中途半端なドキュメントは中途半端な文化を生む」 「誰でもできるは誰もやらなくなる」 社内Wikiのよくある課題 皆さんの社内Wikiで次のような課題を感じたことはありませんか。 情報が散乱 更新中のページがそのまま メンテナンスされていない構造 多くの人が作成・編集できる社内Wikiは、改善の意志がないと上記のような状態になりがちです。 最悪の場合、開発体験の低下につながります。 良い社内Wikiとは 良い社内Wikiの必要条件は以下の通りです。 開発体験を
エクセル読み込みをPOIからFastExcelに置き換えてパフォーマンスを改善する
はじめに こんにちは！10 月から株式会社ログラスでエンジニアをやっています、Kyosuke です！ ログラスでは、エクセルファイルをプログラムから操作する処理が一部存在しており、Apache POIというライブラリを使用しています。（以後POIと呼びます） しかし、POI には処理方式によってはメモリを多量に使用してしまうという問題があります。 今回はその対応として、まずエクセルファイルの読み込みをFastExcelというライブラリに置き換えた話を振り返っていきます。 TL;DR POIのXSSFWorkbookは、ファイルをメモリ内に読み込んで操作するため、大きなエクセルファイルを処理する際にファイルサイズ以上のメモリを必要とすることがある POI の公式ドキュメントより FastExcelは、POIより機能は劣る代わりに、読み書きともにパフォーマンスは大幅に上回る 書き込み Fast
「要件定義をやめよう」の真意、普通にやると金と時間が無駄になるだけ
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX（デジタルトランスフォーメー
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感 - id:onk のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
データ活用が事業貢献していることを示すための取り組み
2023年2月16日開催、サイバーエージェント メディア事業部主催のデータ活用に関する勉強会「メディアサービスにおけるデータ・AIの活用事例 #2」登壇資料です。 https://cyberagent.connpass.com/event/270224/
PLG型SaaSのマーケティング事例 BtoBの「定石」が通用しないケースへの適応 | LISKUL
2023年現在、スタートアップ・SaaS領域周辺では、ZoomやSlackを急成長させたといわれる「PLG※」への注目が集まっています。 しかし、現時点で、国内のPLG型SaaSのマーケティングに関する取り組み事例は、あまり公開されていません。 本記事では、国内PLG型SaaSとして例に挙げられることも多い、中小企業向け業務管理システム「board」での約5年間にわたるマーケティング支援の取り組みの一部と得られた学びを紹介します。 結論としては、これまで筆者が取り組んできたBtoBマーケティングにおける定石が通用せず、全く異なる施策が有効となりました。 「board」というプロダクト固有の文脈に依存する部分も多いため、どこまで参考になるものか疑問も残りますが、少しでも役立つ部分があれば幸いです。 ※PLGとは：Product-Led Growth（プロダクト・レッド・グロース）、「プロダク
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
プロダクトの非機能的な改善の工数をどう確保するか - yigarashiのブログ
プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。 前提 まず非機能改善について議論する上で、重要な前提がふたつあると思っています。 ひとつは、我々は常に共通の目標を持っているということです。プロダクトのミッションや期の目標のことです。ビジネスサイドの人もエンジニアも、そうした目標を達成するためにそこにいることに違いはありません。機能開発も非機能的な改善も、見ている時間軸が多少違うことはあれど、この目標を達成するための手段です。それらが一見対立するように見えるのは影響を与える指標が違うからです。 もうひとつは、非機能改善に「やらない」という選択肢はないということです。システムにはデフォルトで滅びる方向に力が加わっていま
30分でわかるFour Keysの基礎と重要性
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
腰痛をストレッチで改善した人の話→「結局ストレッチが一番効くんよ」「水泳も良いぞ」
クオ【咖喱】リア@⛩️🐚🍆🇯🇵Ｐ @JaponesqualiaP @chamere0n なるほど腕を後ろで組むストレッチはこんな感じで改変できるのですね…（やってみた） 確かになにか剥がれる音がしましたw 少し続けてみますありがとうございました。 2023-01-03 23:31:05
Cloud RunのJavaの起動速度を60%改善した
はじめに 私はGCPのCloud Runがお気に入りのサーバレス環境なのですが、一番得意な言語であるJavaを使った場合のスピンアップタイムの悪さには頭を悩ませています。 ローカルでは1,2秒で起動する場合でも、何故かCloud Runに持って行くと他の言語と比べても劇的に遅くなるのですよね... GraalVMのネイティブイメージを使えばGoなどと遜色無く瞬時に起動するのですが、ネイティブイメージへの変換は癖も強いため通常のJVMでも改善できないかとチューニングを試してみました。 TL;DR 最終的に60%程起動速度を改善 9秒台が3秒台になっているので体感としては結構変わる native-imageが使え無いケースでもこのくらいなら許容出来そう もちろん完全停止状態以外のレスポンスは3秒とか言わずミリ秒オーダー 準備と基礎値の計測 まずはアプリケーションを準備する必要があります。今回は
開発組織を改善していくための技術｜BTO
OPENLOGI Advent Calendar 2022 5日目の記事です。 おはこんばんちは!! 尾藤 a.k.a. BTOです。 今年の8月にオープンロジという物流テックの会社に入社しました。入社してから4ヶ月経ち、無事に試用期間が終了したということでほっとしております。 今までウノウ、UUUM、Reproという会社でCTOを歴任してきました。立場や経験上、開発組織の立ち上げや改善に携わることが多いです。今まで自分がやってきて、開発組織を改善するために気をつけていることを書いていきます。 既存のシステムをリスペクトするあなたがこの瞬間のシステムを切り取って見た時に、仕組みがぐちゃぐちゃだったり、意味不明な処理をしていたり、不合理な仕組みになっていることは大いにあると思います。しかしながらこれまでの会社を支えて売上を作ってきたのは、紛れもない今のシステムなのです。過去の経緯もいろいろあ
Hasura, PostgreSQL, MySQL対応の速度改善ツールを作りました - GravityR
はじめに DBが遅い原因の多くはインデックスの作り忘れです。 サーバーの性能アップやパラメータ変更の効果も大きいですが、まず最初に検討するべきはインデックスでしょう。 EXPLAINの結果をにらみながら、効果のありそうな場所を探します。 ただ、厄介なのはEXPLAINの結果が読みづらいことです。 EXPLAINの読み方を説明している本やサイトはいくつもありますが、EXPLAINを使う機会が少ないため、読める人が限られた、職人芸に近い技術になっています。 なので、EXPLAINを読まなくてもインデックスを作れるツールをGoとSvelteで作りました。 GravityRを使うと、下のようにEXPLAINをタイムライン形式にした図やインデックスの効果を表示したHTMLが作成されます。 紹介 GravityRはHasura、PostgreSQL、MySQLに対応しています。 実行ファイルをgith
日本は生産年齢人口に対する就業者数がもう9割に達しているので、今「人が足りない」と言ってるところに改善の余地はない？
atsushi_noguchi🌗 @fujimicho 考古学者。日本・南アジア、旧石器時代。3D計測。考古グラメトリスト。モバイルモバイルスキャン協会理事。#考古学情報処理 A Japanese archaeologist, S. Asia and Japan, Palaeolithic, 3D, morphometrics, etc. #JASPAR #3DLM https://t.co/dZWvpgFZh7 atsushi_noguchi🌗 @fujimicho 身も蓋もないことですが統計上、生産年齢人口に対する就業者数はもう9割に達しているのでいま人足りないと言ってるところは今後改善の余地はほぼ無いし足りてるところも早晩不足に傾く。ミクロに「ウチは採れた」はあるかもだけど全体のパイは減る。人件費とか組織の理解とかじゃなくて（続く） pic.twitter.com/Bb7Wh38
CoC が苦手な奴、認知資源が乏しいだけ説 - Neo's World
CoC が苦手な奴、認知資源が乏しいだけ説 「設定より規約」「CoC (Convention over Configuration)」と呼ばれる設計思想がある。 参考：設定より規約 - Wikipedia フレームワークやライブラリ側で、ベストプラクティスなデフォルト設定を規約として決めておくから、利用する開発者はイチイチ考えなくていいよ、というワケだ。 コレは、ともすれば、「Opinionated (自己主張的)」なフレームワークやライブラリだとみなすこともできるだろう。 参考：Opinionatedなライブラリとチーム開発 - Runner in the High 僕は CoC が割と好きだし、CoC か否かに関わらず、Opinionated なツールも好きである。だが、自分の回りでは「CoC が苦手」とか「柔軟性のないフレームワークは嫌い」といった人が多く、疑問を持っていた。 今回、
サクっと作った英語学習サービスがバズって1週間以内にやったこと - Qiita
要約 Qiita記事がトレンドインすると、瞬間的にWebサービスへのアクセス数が急増するが、数日でアクセス数は元に戻ってしまう。 そこで以下の施策を速攻で打ってバズっているうちに有益な学びを得るべきと考え、本記事はそれを実践した結果を実データと合わせて説明している。 事前登録フォームを作って興味を持ってくれた人と繋がる Twitterやはてぶのコメントからどうして興味を持ってくれたのか考察する 有料機能を作って単なるバズなのか、本当にニーズがあるのか判断できるようにする バズる１週間前にやっていたこと 3日でツールをサクッと作った 英語面接や仕事で海外の人とやりとりをするときに「ちょっと難しい質問」をされると、途端に5歳児になってしまう自分が恥ずかしくなり、DeepLで英語の勉強をするツールを作った。 自分が使うだけのつもりだったので、アカウント機能などはなく、コアな機能１つを実装しただけ
10min勉強会の導入と、運用改善をふり返る。 - Gaudiy Tech Blog
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでフロントエンドエンジニアをしているkodai（@r34b26）です。 色んなアドベントカレンダーをみながら、もう2021年が終わるのか…という実感が湧いてきました。 今回は、約2ヶ月前から開発チームで取り入れた「10min勉強会」について、その運用と改善の道のりを振り返ってみたいと思います。 勉強会がなかなか続かなかったり、チーム間のコラボレーションを促したい方にかなりオススメなので、よければご参考ください！ 1. 10min勉強会を導入した背景 2. 運用のはじまり 3. つまずいたポイントと改善プロセス 3-1. 発表用の資料をつくらず、書記を立てる 3-2. ネタぎれ防止とkaizenをセットにする 4. 10min勉強会を運用してみての変化 5. さいごに 1. 10min勉強会を導入した背景 元
開発組織にゆとり時間を導入した話
この記事は カオナビ Advent Calendar 2021 １日目です。 はじめに はじめまして、カオナビCTOの松下( @matsukaz )です。 今年はカオナビとして初めて Advent Calendar をやることになりました！ メンバーが集まるか不安でしたが、プロダクト開発を担っているプロダクト本部全体に声をかけた結果、 エンジニア EM マネージャー ディレクター デザイナー QA と、幅広い職種のメンバーが参加してくれることに！ どんな内容を書いてくれるのか、今からとても楽しみです😆 Advent Calendarを通して、少しでもカオナビの雰囲気や取り組みが伝わると嬉しいです。 というわけで1日目、タイトルの通り「開発組織にゆとり時間を導入した話」をしていきます。 ゆとり時間とは 皆さんはエラスティックリーダーシップというリーダーシップモデルをご存知でしょうか？ チー
EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
