タグ

タスクに関するpoginのブックマーク (19)

  • タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt

    先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが

    タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
  • タスク処理のコツは「考える」を事前に済ませておくこと。

    この記事で書きたいことは下記のようなことです。 ・私が知っている中で一番「整理整頓」「片付け」が上手い人は、昔居候していたバーのマスターです ・マスターに「片付けのコツ」を聞いてみたところ、「頭と手を同時に動かそうとするな」と言われて、以下のようなことを教わりました ・片付けというのは要は「カテゴライズ」であって、単純化すると物品を分類するだけの行為 ・人間は複数のことを同時にやるのが苦手であって、「考えながら手を動かす」のは高いコストを要求される ・だから、「考えておけることは事前に考えておく」だけで片付けのハードルが下がる ・お前は片付けの時、手を動かしながら分類まで考えようとしているので全然片付けが出来ない、先に考えるべきことを考えろ ・その教えを後から思い出して、だいぶ(片付けに限らず)タスク処理が上手くなりましたので、片付けが苦手なひとはご参考まで 以上です。よろしくお願いします

    タスク処理のコツは「考える」を事前に済ませておくこと。
  • スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;

    会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると

    スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
  • エンジニアのための自己管理入門 - Qiita

    はじめに 社内でTodo管理の勉強会を実施した際に作成した資料があったのですが、今回自分の中の考えをまとめるせっかくの機会だと思い、字面で書き起こすことにしました。 意外と世の中では語られることのなく、『あたりまえ』として扱われてしまう『自己管理』について自分が半年間運用し、週ごとにカイゼンを続けたどり着いた、現時点でのHowを多くの人に伝えられればなと思っています。 もちろん最適解がこの形とは言いませんし、自己管理は人の数分だけ最適解はあると思っています。「みんな正しい、ただし部分的に」ということを念頭に、楽しんで読んでいただければ幸いです。 タイトルを付けた理由としては、かなりシステマチックな内容になってしまっていると感じてしまったため、「運用レベルが高い」人物を想定した結果、このタイトルになりました。 概念篇 『自己管理』を行っていく上で、確実に「ここは飛ばしてはいけない」と思ったた

    エンジニアのための自己管理入門 - Qiita
  • 曖昧なタスクへの耐性が下がってしまった、一時期の話

    この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖

    曖昧なタスクへの耐性が下がってしまった、一時期の話
  • 不確実性が高いタスクは“不安量を可視化する” 広木大地氏に聞く、モヤモヤへの向き合い方

    エンジニアとして経験を積んでいくと、「技術に深く潜っていくこと」と「開発をうまく進めること」はイコールではないとぼんやりと感じ、モヤモヤする時があります。「Meets Professional #5」のゲストは、『エンジニアリング組織論への招待』の広木大地氏。モヤモヤの原因となる「不確実性」への向き合い方について語りました。全3回。3回目は、視聴者からの質問に答えました。前回はこちら。 マイクロマネジメント型で最適化されたチームは、どうエンパワーメントしていくべきか? 篭橋裕紀氏(以下、篭橋):では何個か質問もきているので、まくっていけたらなと思っています。 まず、ヨシノさんから「マイクロマネジメント型のチームをエンパワーメント型へ切り替えていくことに対して難しさを感じています。例えば、チーム状況に合わせてマイクロマネジメントをあえて選択したプロジェクトがあったとします。その中でチームは経

    不確実性が高いタスクは“不安量を可視化する” 広木大地氏に聞く、モヤモヤへの向き合い方
  • どうやったら「自走できる人」になれるのか|nacam403

    近年、何かと自走、自走って言いますよね。「自走力」とか、「自走できる人が必要」とか。すごく抽象度の高い言葉ではありつつ、社会人生活においてとても求められる力、価値のある力なのは確かなようです。 となると「そもそも自走とは」「自走できるとは」という話になります。これに関して先日、Engineering Manager Meetupというオンラインイベントで、同業の人々と話す機会がありました(Engineering Managerとは、ざっくり言うと、エンジニア組織においてピープルマネジメントを含むマネジメントをやっている人です)。 そこで挙がった「自走できる」とは、端的に言うと以下の通りでした。 総じて、「指示が必要」の反対である。 自走できる人は、 ・粒度の大きいゴールを目指して行動できる。 ・完了状態を自分で定義できる。 ・自分で勝手に成長できる。「確かになー」と。マネージャーからすると

    どうやったら「自走できる人」になれるのか|nacam403
  • 『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ

    デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。 2時間スプリント? みなさん、すでにスクラムで開発してますよね! ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。 2時間スプリントとは、その期間を2時間にするという話です。 スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに家の情報がまとまっています。 kyon-mm.hatenablog.com 2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。家ではのちのち15分スプリントになっていったらしいんですが、うちはうち

    『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ
  • 締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;

    これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクト

    締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
  • 『計画の科学』を読んでPERT図について学んだ / PERT図を出せるツールを作成した - Lambdaカクテル

    id:hitode909におすすめされてはいたものの読んでなかったので、休日を使って読むことにしたのが『計画の科学』である。技術読書の贅沢二立て。 成果物 成果物1 あたまがよくなりました 成果物2 PERT図(をGraphVizで出力するためのDOTドキュメント)を出力するScalaのプログラムを書きました。 github.com CSVから直接指定はまだできません(直にコードを書く必要があります)が、工程を短縮したい場合にどこから短縮すればよいかを表示する機能があります。実際の図は記事の下らへんにあります。 計画の科学 1965年と比較的古いでありながら、依存関係を含んでいる複雑なタスクをいかに科学的に処理していくかについて、アメリカで開発されたPERTと呼ばれる技法を紹介して説明していく。 あまり分量も多くなく、物理も新書サイズでKindle版もあるのですぐ読み終わる。 計

    『計画の科学』を読んでPERT図について学んだ / PERT図を出せるツールを作成した - Lambdaカクテル
  • コード書く以外の仕事上暗黙的に必要とされている様々なスキルについてブレストしてみる - stefafafan の fa は3つです

    前提 僕は新卒からいまの会社に入って以来ずっとWeb系アプリケーションエンジニアとして仕事してきました 自分がWeb系のエンジニアとして成長するにあたって必要なスキルについて考えたときに、ただコードが書けるだけでは評価されないだろうなということだけ何となくわかっているつもりだけど、言語化しないとどういうスキルがあるのか何が自分に足りないのかがわからない気がするので一旦ブレストしてみる 出来上がったリストを元に次にどこを集中的に伸ばすべきかというのがわかるのではないか ここでいう暗黙的とは、僕が学生の頃「Web系のアプリケーションエンジニアに必要なスキルはこれだろうな」と考えたときにきっと思い浮かばなかったもののことですが、人によってはこんなこと当たり前だろうと思うかもしれません ブレスト結果 いくつかブレストした結果をグループごとにわけてみた。(ブレストといってもただパソコンに向かって箇条

    コード書く以外の仕事上暗黙的に必要とされている様々なスキルについてブレストしてみる - stefafafan の fa は3つです
  • やるべきことに集中して生産性を上げるための科学的戦略3つ

    夢や目標を実現させるためには目の前のことに集中して生産性を上げる必要がありますが、そんな時に重要になるのがやみくもに集中しようと試みることではなく、戦略です。「意識を変える」といった抽象的なものではなく、「寝る前にToDoリストを作成する」といった、すぐに実行できる具体的な戦略を海外メディアのInverseが挙げています。 3 psychological strategies to be more focused at work https://www.inverse.com/mind-body/3-ways-to-maximize-your-to-do-list-to-boost-productivity-at-work ◆1:皿洗いや散歩などで「息抜き」を行う やるべきことに集中するには、適切に頭を休める必要があります。ジョギング、料理、皿洗いなど、どのようなことでもいいので、1日のう

    やるべきことに集中して生産性を上げるための科学的戦略3つ
  • 最強の手帳「バレットジャーナル」を作ってみたら先延ばし癖が治った。 - STUDY HACKER(スタディーハッカー)|社会人の勉強法&英語学習

    皆さんは、いま使っている手帳に満足していますか? 今や手帳は、レイアウトやデザインのみならず、さまざまな点で多様化が進んでいます。その中から、自分にとって理想的な手帳を見つけるのはなかなか難しいですよね。 いま使っている手帳に何となく物足りなさを感じている方は、「バレットジャーナル」を試してみてはいかがでしょうか。バレットジャーナルとは、好きなノートとペンだけで始められる、カスタマイズ性の高い手帳です。 今回は、筆者が実際に試してみたバレットジャーナルの作り方と、その使用感をご紹介します。 バレットジャーナルとは? バレットジャーナルとは、ライダー・キャロル氏によって発案された「箇条書きの手帳」のこと。コアコレクションと呼ばれる次の4つの要素が基要素です。 インデックス:どのページに何が書いてあるのかを示す目次のページ フューチャーログ:半年〜1年ほどの将来の予定を記入・一覧するページ

    最強の手帳「バレットジャーナル」を作ってみたら先延ばし癖が治った。 - STUDY HACKER(スタディーハッカー)|社会人の勉強法&英語学習
  • 専門家が教える、「思ったより時間がかかって終わらない! 」をなくすタイムマネジメント術 | BUSINESS INSIDER JAPAN

    ToDoリスト(やることリスト)に書いた項目を消化するには、思うより時間がかかるものだ。 1つの1つのタスク完了にかかる時間を計算するときは、想定の3倍はかかると見ておいた方がいい。 これはリーダーシップの専門家グレッグ・マキューン氏が、ニューヨーク・タイムズで強調したことだ。 大半の人が「計画倒れ」に終わるのはそのせいだ。 今の仕事を始めてから数年。わたしは記事を書き終えるのにどのくらい時間がかかるのか、いまだに見通しがうまく立てられない。 運良く直感が当たって、思ったより早く仕事を終えられることもある。でも、大抵は予想を大きく超えてしまう。 ただ、計画通りに物事が進まないと頭を悩ませているのはわたしだけではないはず。そして、ニューヨーク・タイムズの「Smarter Living」というシリーズで最近紹介されたアドバイスに感激するのも、わたしだけではないはずだ。 同紙が紹介したのは、リー

    専門家が教える、「思ったより時間がかかって終わらない! 」をなくすタイムマネジメント術 | BUSINESS INSIDER JAPAN
  • プロジェクトの成功率を上げるために、チームリーダーができること・やるべきこと - ログミーTech

    スマホアプリの分析プラットフォーム「F.O.X」が主催する、スタートアップで働くエンジニア向けコミュニティイベント「F.O.X Meetup」の第3回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としているイベント。今回は、「スタートアップのチームビルド」をテーマに、経験豊富なプロジェクトリーダー達が自身の知見を披露します。株式会社マクアケの吉田慶章氏は、「さぁ!今すぐプロジェクトリーダーに立候補しよう」というテーマでプレゼンテーションを行いました。チームの特性に合わせたチームビルディングやマネジメント手法について、自身のノウハウを明かします。 プロジェクトをリードする技術 吉田慶章氏(以下、吉田):こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思い

    プロジェクトの成功率を上げるために、チームリーダーができること・やるべきこと - ログミーTech
  • リモートユーザーテストをWeb担で実施したら、なんと発見点126個。重要課題13個すべて見せます! | やってみました! リモートユーザーテスト

    Web担編集部では、今回Web担当者Forumのサイトで「リモート・ユーザーテスト」をやってみました。それを2回に分けてレポートします。今回は、リモートユーザーテストの実施前の準備編と重要課題13個をすべて紹介します。 リモートユーザーテストとは何なのか、どのように行われて、そこから何がわかるのか――今回、Web担編集部がリモートユーザーテストを実施するにあたって、ポップインサイトのオーダーメイド調査を提供いただき、実施してもらいました。 サービス提供側が裏でどんなことをしているのかをポップインサイトの池田氏に執筆いただき、依頼側としてWeb担編集部がどんなことを行い調査を通じて何を得られたのか、2つの視点で紹介していきます。 なんと発見点126個! うち重要課題は13個リモートユーザーテストの流れを解説する前に、まずはWeb担サイトでどんな改善点がリモートユーザーテストで発見されたのか紹

    リモートユーザーテストをWeb担で実施したら、なんと発見点126個。重要課題13個すべて見せます! | やってみました! リモートユーザーテスト
  • 新社会人にオススメする1日の生産性をあげるタスク消化6個のコツ - Gunosy Tech Blog

    序 こんにちは、新規事業開発室の渡辺(@k6nta)です。女性向けアプリ「ルクラ」の事業責任者をやっています。Gunosy Tech Blogでは主に開発に関する記事を出していますが、この記事では私が普段実践している「タスク消化のコツ」に関して紹介したいと思います。また、この記事ではチーム単位のタスク消化ではなく、個人のタスク消化にフォーカスを当てた内容となっております。 皆さんは普段どのようにタスク管理を行っていますか?自分のタスクを適切に優先付し、スケジューリングを行い実行していく作業は、組織・チームの中で働く際にはとても重要だと思います。タスク管理ができておらず、何かのタスクが期限までに完了できていなかったり、共有が遅れたりした場合、その後の作業者全員の作業が遅れるため、チーム全体の作業効率は低下してしまいます。逆に個人のタスク消化効率を高めることで、同じタスク量をこなした場合でも、

    新社会人にオススメする1日の生産性をあげるタスク消化6個のコツ - Gunosy Tech Blog
  • 私が日報を書く8つの理由 - Architect's Log

    私は特に指示がなくても、毎日日報を書いてプロジェクトメンバーにメールで送信しています。 それはプロジェクトメンバーのためでもプロジェクトリーダーのためでもありません。自分のためになるからです。 理由を書く前に、日報のテンプレートを晒しておきます。 テンプレート お疲れ様です。○○です。 日の作業を報告します。 <連絡事項> ・・・ <問題点> ・・・ <日の作業> 【プロジェクト名】 ■タスク名 →完了。 【プロジェクト名】 ■タスク名 →仕掛かり中。 <明日の作業予定> 【プロジェクト名】 ■タスク名 <明後日以降の作業予定> 【プロジェクト名】 ■タスク名 <日の作業時間> 8.0h 日報を書く理由 タスクの棚卸し 日報を書くことにより、必然的に残タスクを把握することになります。 問題報告の判断のプロセス自体をなくす 若い頃は、問題が発生すると冷静な判断ができず、報告が遅れ叱責さ

    私が日報を書く8つの理由 - Architect's Log
  • 決断のコストと先送りの問題の話 - 発達障害就労日誌

    決断してますか? 人生色々ありますので皆さんも大体厳しい感じで生きてると思うんですけど、日々を生きていくうえで最近非常にキツいなぁと思うものがあって、「決断」なんですよね。いくつかの選択肢があってそのうちひとつを選ぶという人生において避けては通れないあれは、非常に厳しい。 経営をやっている時なんかは毎日が決断の連続で、この判断トチってたらアウトの可能性もあるなぁ、なんてのが日常だったので改めて考えることもなく、ウォーって叫びながら決断を繰り返してきたわけなんですけど。そういう戦場フェイズも終わって新しい生活をしていると、当に「決断」というのはエネルギーのいる作業だなぁと改めて思うわけです。 で、会社経営の話からまずすると、僕は「決断をする」人間と「決断に必要な情報を収集する人間」は可能な限り分けるべきだと思っていて、しかも情報収集をする人間は決断に対して予断を持たず、ただひたすらに情報を

    決断のコストと先送りの問題の話 - 発達障害就労日誌
  • 1