はてなキーワード: 進捗管理とは
漢字で表記すると「渡邉」であり、ああ難しい方のね、と認識されている方も多いだろう。
わたなべの表記は「渡辺」「渡邊」「渡邉」の3パターンに大別されるかと思う。
私が最近フラストレーションを溜めているのは、苗字の漢字表記をまったく気にしないタイプの人間がいるということだ。
かく言う私のわたなべ歴は浅い。
以前の苗字もごく普通のものであったが、わたなべは全国6位だったか、非常に多い。
そんな平々凡々の苗字に対しての思い入れは全くと言っていいほどない。
しかし、何度も何度も表記を間違えられると、こちらとしてもイラッとくるものだ。
学生時代、「さいとう」の漢字を間違えられてぶつぶつ文句を言っていた友人の気持ちも、今なら理解できる(そんな彼女も今は結婚して苗字が変わってしまったが)。
だが「渡邊」と間違えられるのは腹が立つ。
難しい方、とまで認識できているのに、なぜ最後の二択まで気を回せないのか。
会社の中には、表記違いを防ぐためか、苗字を敢えて平仮名表記でしてくる人もいる。
いっそその方が気持ちがいい。
私がこだわりすぎているだけ?
私は漢字というものへの関心が昔から高く、それ故に人の名前の表記間違いには厳しい。
同じ会社にそれこそ複数いる「わたなべさん」の漢字だけは間違えないようにと気を付けているし、「さいとうさん」だって漢字を社員名簿で調べてから書くくらいの気概はある。
「間違えられた時に訂正すればいいじゃん」
それはそう。
最初に訂正しておけばよかった。
でも細かいところに煩い奴だと思われたくなかったし、いつか間違いに気づくかと安易な考えをもっていたのだ。
そのツケが回ってきて、今でも毎回「渡邊」と書かれる。いや、複数名にではなく特定の一人にのみだけれど。
進捗管理の担当者欄を、一括置換で「渡邉」に変換するなどのみみっちい努力をしている。
仕方がない。PCの漢字変換が直近のものをサジェストとして一番上に出してくるからだ。
別に夫婦別姓派でもなんでもないけど、姓が変わってのフラストレーションは思わぬ形で降りかかってきている。
繰り返すが、新姓に思い入れは全くない。
全国のワタナベさん、サイトウさん、イトウさん、そのほか漢字間違えられ苗字の方々。
私もやっと気持ちがわかりました。
弊社、リモートワークとは名ばかりで上司が進捗管理ソフトを通話ソフトも使いこなせない管理放棄ワークで、
それをいいことにエネマグラいれて、乳首責め催眠射精ASMRをBGMに、チクニーしながら仕事していた。
結果として、チクニーだけで射精してしまうくらいには感度が高まったんだが、
コロナ禍の収束にともなってリモートワークが廃止になって出社体制となってしまった。
スーツを着て電車に揺られる訳だが、スーツの布擦れと電車の振動で乳首が刺激されるだけ出てしまう。
とりあえず、乳首に絆創膏はって擦れないようにした上で、万が一に備えて老人用おむつを履いて出社しているが、
購買部の仕事内容は 1.社内の発注を相手方に送る 2.問い合わせの仲介をする
おっさんBは30~40代でいっつもオドオドしてるし何聞いても「後で折り返します(折り返さない)」しか言わない
まず共通して発注の把握漏れがバカほど多い、こっちから進捗聞かないと9割返事帰ってこない
この間なんておっさんAから1カ月も返事帰ってこないから問い合わせたら「あー忘れてた、操作画面が見ずらいね」とかぬかしてる
おっさんBは合計4度も進捗聞いたのに「今忙しいので折り返します!」とか毎回同じセリフ吐いて逃げるくせして着手しない
https://anond.hatelabo.jp/20230712112116
この「完全にお局様と化してつらい」って話で思い出した事がある。
はてブで『管理職でも無いのに部員の進捗管理したり仕切ったりするな。』っていう、例によって、はてブらしい優しくも厳しすぎるコメントに星が大量についていたが、これについてだ。
話はこうだ。うちの娘はアメリカで小学校に通っている。幼子の頃からいるのでコミュニケーションの問題等はないのだが、娘からすると教室でちょくちょく他の生徒がうるさ過ぎると感じるらしい。(はっきり言って娘だってめちゃくちゃうるさい方なのだが)
それほど時には凄い騒ぎになるようだ。それが気になるらしく娘は皆に先生の話を聞こうなどと注意していたらしい。
これを聞いて皆さんはどう思いますかね?創作に良く出てくる委員長タイプの人間なんだなとか思う人も居るかもしれないが、基本的には娘は「良い子」だねって事になると思う。
ところが娘はこれを先生に怒られたそうなのである。曰く、「子どもを注意するのは先生の仕事なので、あなたはやってはいけない」ということであった。
これを聞いて俺はすごく教えられたと思いましてね。まだ大学を出たばかりのような若い先生だったけど、ここまでビシッと言えるのは凄いと思った。そんな騒がしくなるくらいなので、先生もあまりやる気がないのかと思っていたんだけど線引きが違っただけのようだった。
それ以来、俺も同僚や職場のことには意識して世話を焼きすぎないようにしている。皆で助け合うことは良いことだけど、職場やあるいは教育現場の中にはまず第一に根底に契約や役割がある。
なので先のブコメに今は同意なんだけど、俺のようになかなかそこから抜けれないことは多いと思う。それは元を正せば、一般的な日本の教育現場の中では色々な責任が曖昧になっているから。
日本の初等教育、中等教育は素晴らしいんだが、その辺りの責任関係の曖昧さは先生の過剰負担とかにも繋がってくる課題だと思う。
https://anond.hatelabo.jp/20230712112116
この「完全にお局様と化してつらい」って話で思い出した事がある。
はてブで『管理職でも無いのに部員の進捗管理したり仕切ったりするな。』っていう、例によって、はてブらしい優しくも厳しすぎるコメントに星が大量についていたが、これについてだ。
話はこうだ。うちの娘はアメリカで小学校に通っている。幼子の頃からいるのでコミュニケーションの問題等はないのだが、娘からすると教室でちょくちょく他の生徒がうるさ過ぎると感じるらしい。(はっきり言って娘だってめちゃくちゃうるさい方なのだが)
それほど時には凄い騒ぎになるようだ。それが気になるらしく娘は皆に先生の話を聞こうなどと注意していたらしい。
これを聞いて皆さんはどう思いますかね?創作に良く出てくる委員長タイプの人間なんだなとか思う人も居るかもしれないが、基本的には娘は「良い子」だねって事になると思う。
ところが娘はこれを先生に怒られたそうなのである。曰く、「子どもを注意するのは先生の仕事なので、あなたはやってはいけない」ということであった。
これを聞いて俺はすごく教えられたと思いましてね。まだ大学を出たばかりのような若い先生だったけど、ここまでビシッと言えるのは凄いと思った。そんな騒がしくなるくらいなので、先生もあまりやる気がないのかと思っていたんだけど線引きが違っただけの違ったようだった。
それ以来、同僚や職場のことには意識して世話を焼きすぎないようにしている。皆で助け合うことは良いことだけど、職場やあるいは教育現場の中にはまず第一に根底に契約や役割がある。
なので先のブコメに今は同意なんだけど、俺のようになかなかそこから抜けれないことは多いと思う。それは元を正せば、一般的な日本の教育現場の中では色々な責任が曖昧になっているから。
日本の初等教育、中等教育は素晴らしいんだが、その辺りの責任関係の曖昧さは先生の過剰負担とかにも繋がってくる課題だと思う。
よくある話でコード書けなくて紙芝居しかできないくせに高い給料もらって…っていうのがあるけど、
SI業界のベンダーだと、コード書ける人でなおかつクライアントとの折衝(あなたはこれがやりたいと言うが技術的にこうだからこっちの方が合理的だという交渉)とか、進捗管理、工程管理がまともにできる人がほぼいないと思っている。
まあいるにはいるが各ベンダーで本当に卓越したエースだけができて他はダメダメという印象。
ユーザとの会話とか進捗、工程の話って技術文書そのまま出すのでは足りない場面が多々あって紙芝居必要じゃないか?
紙芝居(とその前提となる知識や現状分析)とかファシリテーションとかそれなりに技術体系があって、それができる人が非常に少ないから高い単価がついてると思ってるんだが…
多分はてなにいるコンサル嫌いな人たちってベンダーの人だと思うんだけど、コンサルなしで遂行可能なプロジェクトばかりor無能なコンサルばかりだから叩いてるんだろうか。教えてほしい
※上記はベンダーと関わりのあるコンサルの仕事っていう観点で出したけど、戦略とか企画とかベンダーがいない段階の仕事ももちろんある。ここではベンダーの人から見たコンサルのイメージを知りたいのでそれらは無視してほしい
※あと、俺個人は前職が不夜城でコード書きまくる会社だったからコード書けるけど、コード書けない同僚も多いしコード書けるかどうかはコンサルの能力に決定的な影響はないと思ってる
追記:
プロジェクト上の役割の要否や現実の振る舞いについて聞きたかったんだけど個人の性格に関する話が多いな…それって仕事で関わった人の話?それともプライベートの知り合い?
という説を支持するコメントに見える。。。
フィジビリティを考慮せずに客の言うことをはいはい聞いて最終的にベンダーに尻拭いさせるのがいかんという指摘だね。納得がいく原因だ。ありがとう。
未熟なコンサルだとよくある話だし、それなりのベテランでもうまく客とベンダーの折り合いをつけられずベンダーが見積もりを何回も繰り返して工数を無駄にするケースも多いね。
本当のことは載せられないので
仮に嘘っぱちな適当な例を出すと
■入力がこれだと
■出力はこれになる
私は飲食店の予約システムの新規構築を担当し、要件定義から製造まで関わってきました。設計にも携わり、チームリーダーとして進捗管理を行いました。また、UI/UXデザインも担当し、ユーザビリティの向上に努めました。
要件定義の段階では、飲食店にとって必要な機能や予約の流れなどを考慮し、基本設計書を作成しました。次に、画面遷移図やER図を作成するなどして、詳細設計に取り組みました。製造フェーズでは、チームリーダーとして進捗管理を行い、納期や品質に配慮しながら開発を進めました。
UI/UXについては、シンプルでわかりやすいUIを実現するために、ユーザビリティに関する情報を収集し、ユーザーテストを実施しました。その結果、より使いやすく、直感的なUI/UXを提供することができました。
私は、開発プロジェクト全体を通して、チームと協力し、品質の高いシステムを提供することに注力してきました。今後も、開発に携わることでスキルアップを図り、より良いシステムの実現に貢献したいと考えています。
こんな感じ。
増田を全削除するのであればPower Automation DesktopかSelenium IDEあたりでも使えば可能ですが、中にはブクマを集めた珠玉の増田やブクマは付かなくても割と気に入ってる増田もあるので全削除はしたくありませんでした。
Masuda Deleter
https://github.com/oribeolive/masuda-deleter/
Masuda DeleterはDockerコンテナに環境を作って動くのでDockerが必要です。
M1 Macで動作していますがWindowsは検証できるマシンが手元にないので動作未確認です。
インストールはGitHubのREADMEに書かれたコマンドを実行すればできると思います。
Masuda Deleterははてラボにログインして指定されたページ分の自分の増田の投稿をスクレイピングしてローカルのDBに保存します。
取得された投稿のリストがブラウザで見られるので、そこで削除するものを選んで実行すると、またログインして投稿を削除しにいきます。
ページのアクセスごとに読み込みと遠慮のために1秒から数秒sleepするので少し時間がかかります。
一旦投稿をローカルに保存するという過程があるため副作用として自分の投稿を検索できます。
これにより
が容易になります。
増田にはAPIがないので、IDとパスワードを使ってログインして、表示されている文章をスクレイピングしてくるという原始的なやり方になります。
(2回目からはcookieがある場合はcookieを復元してログイン状態になります。)
ユーザーが知らない外部サイトにクレデンシャルを渡すのは危険であり、サービス運営側としてもパスワードを平文で持ちたくないので、Webサービスとして実装せずセルフサービスとしております。
ユーザーによってローカルの.envファイルに書かれたIDとパスワードを使用する形です。
ソースをオープンしておりますので怪しいことをしていないかも確認ができるかと思います。
一応下にプログレスバーが出ますが、ページ遷移すると見られなくなります。進捗は進捗管理でも確認できます。
取得された投稿はリアルタイムで画面に反映されないのでブラウザをリロードしてください。
増田のID、タイトル、本文の省略、投稿日時、ブクマ数、トラバ数が表示されます。
「あとで消す」投稿をチェックし、「あとで消す」記事をついに消すボタンで削除を実行します。
チェックは別のページに遷移しても有効です。
こちらは実行した時点で表示されているページのみリアルタイムに画面に反映されます。
投稿の全文を見られます。タグ等は取得しないのでテキストのみになります。
投稿を個別に取得してローカルの文章とブクマ数とトラバ数を更新します。
対象の投稿のタイトルを空に、本文をスペース1文字にしにいきます。
処理の進捗(何件中何件処理済みか)を見ることと、処理を停止させることができます。
排他処理(取込と取込、特定IDの削除と同じIDの削除等)にしているので動いていなそうな処理を停止して再度処理を実行するときに使います。
停止する場合は停止ボタンを押すか、それでも停止しそうにない場合は強制停止ボタンを押してください。
「停止」は今行っている最中の処理ではなく次以降の処理を停止するという形になります。
停止ボタンを押したときに4ページ目を取得している場合は、5ページ目の取得を始める前に処理を終了することになります。
そのためプロセスそのものが止まっている場合は停止されません。
「強制停止」はプロセスをkillします。スクリプト名とプロセスIDでプロセスを検索して子プロセスも含めてkillします。
おまけとして、投稿日とブクマ数、投稿日と3ブクマ以上の投稿の件数、投稿時間(hour)ごとの1ブクマ以上の投稿の件数のグラフが見られます。
ブクマが付いた瞬間ではなく投稿日時なので、いつの時期に投稿した、何時に投稿した増田が活きが良いのかを見られる程度です。
集計データを別に持っていないので増田を削除するとグラフに使用されるデータも消えます。
私はこれで多いときには4000件程度あった増田を3000件程度に減らしました。
これを開発する前からも増え続ける増田の削除に日々勤しんでいたので総数はもっと多いはず。
まだまだ削除したいです。
たまに
Message: unknown error: net::ERR_CONNECTION_CLOSED
というSeleniumのエラーが出て処理が実行されないことがあります。再度実行してください。
フロントエンドがレガシーなのでMasuda Deleterの開発に飽きていなければもう少しモダンにリプレースしようと思っています。
使用していないDjango REST frameworkがrequirements.txtに入っているのはその名残です。