ログインなしで無料で誰でも使えるガントチャートサービスを作った話｜ガッシー｜Repsona
宣言します。「ガントチャート 無料」のSEOを倒しにいこうと思っています。「無料で使えるおすすめガントチャート13選」ではなく、ログインなしですぐに使える無料のガントチャートサービスを1位に持っていきます（作ります）。僕だけの力ではできません。力を貸してください。 — ガッシー｜Repsona (@GussieTech) January 12, 2024 「ガントチャート 無料」の検索1位を目指しています。「無料で使えるおすすめガントチャート○○選」よりも、その場で無料ですぐに利用開始できるガンチャートサービスの方が有用だと信じています。ガントチャートサービスは意外に少なくて、無料で使えるものだとさらに選択肢が減ってしまいます。 会員登録やログインをしないでガントチャートを作る時の最初の選択肢は「エクセル（スプレッドシート）」ではないでしょうか。Google DriveやShare Poi
GitHub Projects を利用したタスク管理 - 一休.com Developers Blog
宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法
【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画
1. はじめよう! 要件定義 ~ビギナーからベテランまで（難度：★☆☆） 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級～上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた
曖昧なタスクへの耐性が下がってしまった、一時期の話
この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖
意識すべきは「事業開発」と「プロダクト開発」の分離 PdM・PO兼任者はプロダクトバックログをどう構成したのか
Jira SoftwareやTrelloなどを中心としたPMが経験してきたプロダクト管理ツールの失敗や改善を語る「本当に使いこなせてる？プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】」。ここで株式会社クライドのSuyama氏が登壇。「PdMのプロダクトバックログ」と「POのプロダクトバックログ」の分離をどのように行ったのかについて話します。 Suyama氏の自己紹介 Daiki Suyama氏：もともとあったタイトルと若干異なるのですが、今回は「事業とプロダクト間のインターフェース作り」というところでお話しできればと思います。 軽く自己紹介をすると、2022年4月に現在の株式会社クライドに入社して、フルサイクルエンジニアとして働いていました。2022年11月にそこに加えてDevOpsの部分やイベントの企画、新卒採用など、いろいろな業務に携わり始め、2023年4月
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
プロジェクトフィットなテスト計画をたてよう - トレタ開発者ブログ
本記事はトレタ Advent Calendar 2020 の 17 日目の記事です。 はじめまして。トレタでQAエンジニアをしています、福富（フクトミ）と申します。 3年ほど第三者検証を生業とする会社にてスクラムチーム内QAやQAチームリーダーを経験しまして、今年の7月にトレタに入社しました。 今回は「プロジェクトフィットなテスト計画をたてよう」というテーマでしゃべってみたいと思います。 テックブログに寄稿するのは人生で初めてなので、お手柔らかに見ていただけると嬉しいです。 はじめに プロジェクトフィットなテスト計画をたてよう プロジェクトの温度感を知ろう スケジュールを知ろう 「なぜやるのか」を確認しよう なにを作るのか確認しよう まとめ キックオフミーティングには必ず参加しよう 品質はみんなで高めるもの 終わりに はじめに 早速ですがQAエンジニアのみなさん、こんな経験はありませんか？
知識不足、無茶ぶり、属人化──プロジェクトマネージャーが直面する3つの課題を乗りきるスキルセットと考え方
IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』（翔泳社）。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章 プロジェクトマネジメントのスキルの全体像」と「第1章 プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載
大規模システムのリプレイスを2度経験したPMが語るシステム移行プロジェクトで重要なこと - JMDC TECH BLOG
JMDCの開発本部データ基盤開発部の新倉です。JMDCには大型案件に自由度高く取り組める環境があります。今回は私が実際に経験したDWHシステムの2度のリプレイスの事例をお伝えします。1度目はPL（プロジェクトリーダー）、2度目はPM（プロジェクトマネージャー）としてプロジェクトに参画。その経験からシステム移行プロジェクトを成功に導くポイントを解説します。 ＜プロフィール＞※執筆当時 新倉 裕一郎（にいくら ゆういちろう）データウェアハウス開発部 データレイクグループ グループリーダー 新卒でソフトウェア会社に入社。大手ベンダー企業の介護パッケージソフト製造などの開発業務に従事。その後、SaaS型CRMサービスを展開するベンチャー企業に転職し、2015年5月に日本医療データセンター（現JMDC）入社。レセプトDWHシステムを担当し、2度のリプレイスを経験。現在はレセプトDWHシステムの保守開
1億円を投資した、プロダクトリニューアルが失敗に終わった理由｜山田修 | Osamu Yamada
こんにちは。Micoworks代表の山田と申します。 私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。 その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。 2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。 当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。 この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。 そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。 ※テッ
ヌーラボ上場へ プロジェクト管理「backlog」などSaaS運営
東京証券取引所は5月24日、プロジェクト管理ツール「Backlog」などを運営するヌーラボのグロース市場上場を承認した。上場予定は6月28日。 2004年創業。06年にサービスインしたBacklogの他、作図共有ツール「Cacoo」、チャットツール「Typetalk」などSaaSを提供しする。日本の本社の他、米ニューヨーク、シンガポール、オランダ・アムステルダムに開発・マーケティング拠点を置いている 有価証券報告書によると、2021年3月期の連結業績は、売上高が19億3864万円、経常損益が852万円の赤字。連結従業員数は146人。 関連記事 にじさんじ運営のANYCOLOR、東証グロースに上場 創業から約5年で バーチャルYouTuber（VTuber）グループ「にじさんじ」を運営するANYCOLORは、東京証券取引所グロース市場へ新規上場が承認されたと発表した。上場日は6月8日予定。
プロジェクトに浅瀬を作る
はじめに プロジェクトに参加しているメンバーがうまく環境に適用できずに離脱することがあり、ともすれば、身体を壊してしまうケースもあります。これは新規メンバーに限定されず、既存のメンバーでも、プロジェクトや本人の状況、その役割が変われば発生し得ると思っています。 そういったことを回避できた状態を想像した時にプロジェクトに浅瀬があったら良いのではというイメージからこの言葉が浮かんだのだと思います。2年ほど前のメモ書きにこのタイトルが残されていて、今見直した時にすごくしっくり来ました。 メモ書きを発見したツイート この「プロジェクトに浅瀬を作る」とは、どういうことなのか、改めて深堀したいと思います。 どういうこと？ 溺れないようにするのが目的 監視員が必要のない状態が理想 溺れないようにするのが目的 溺れるというのは、闇雲に時間がかかってしまい心身ともに疲弊してしまうイメージです。不慣れなため必
動的型付き言語は素早くプロジェクトを立ち上げるのに向いており、静的型付き言語は長期間の保守にむいているという仮説 - kmizuの日記
注：誤解されないように最初にこの記事の意図を書いておくと、古典的な静的型付き言語VS.動的型付き言語の論争をするつもりはありません。これまで色々なプロジェクトを観察（風聞も含む）して来たところ、そういう傾向があるのではないかという仮説です。それと、文脈として主にWebアプリケーション開発する時のことを想定しており、それ以外のケースはいったん脇に置いています。WebアプリケーションだとPHP（動的型付き言語）の方が圧倒的に事例多いのではという感想もありそうですが、その辺りを考え出すと話がこんがらがるので、これもいったん脇においています。 たとえば、色々な事例を見聞きするに、スタートアップ企業において動的型付き言語であるRubyのWebアプリケーションフレームワークであるRuby on Rails（RoR）は好まれる傾向にあります。近年のPythonの動向はさておき、未だにRoRの求人がかなり
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
タスクばらし入門
プロジェクトが本当にうまくいかない時はとにかく集合してほしい「『リモートワークの限界』を知った」
林業におけるRedmine活用
