  |
はてなキーワード: Redmineとは
結論を最初に書くと、作家がやりたいのは「小説のバージョン管理」ではなく「出版プロジェクトのタスク管理」と「成果物の品質管理」なのである。
数年前に「家事をRedmineで管理すると捗る」という記事が流行ったように、それと同じことが作家界隈でも散発的に起きていると考えたほうが実情に近い。
「WordやG Suiteの校正機能じゃダメなの？」に対する返答は「WordやG Suiteにはタスク管理ツールが付いてないからダメ」。
本当はGitHubである必要はなく、RedmineやTracとWordを組み合わせてもいいのだが、「ハンマーを持つ人にはすべてが釘に見える」のでGitHubのためにGitを使おうという本末転倒な議論になりがちな印象がある。
逆に「バージョン管理はあるがタスク管理と品質管理がない」環境の例としてはウィキペディア（MediaWiki）がある。
MediaWikiはすべての版をバージョン管理しており、差分も履歴も見られるが校正にはあまり向いていない。ウィキペディアの文章があまり洗練されないのは支援ツールの不在による部分が実は大きい。
の2つで、それを下支えするためにバージョン管理システムは必要だがGitほど多機能である必要はない。むしろRCSくらいシンプルなほうが理解されやすいのではないかと思う。
弊社、偶然にもオリンピックのために通勤制御しようとしてリモートワークを推進していたらコロナ騒ぎで役にたった
IT系の職場で、ちょうど製品をクラウド上に展開してサービスを売っていこうとしていたところなので
開発物件はあらかたGithubに乗っててAzureで運用されてる。会議はSlack
3月から半分以上リモートワークしてたんだけど、非常事態宣言以降は管理職承認がなければ出社してはいけないルールになった
やってみた感想としては、今までわざわざ出社して作業する必要はなかったのでは？と思うくらい快適
社内のRedmineが利用しづらくなって問い合わせ管理が難しくなったけど、Azure上に新しいの構築すればいいからそのうち対応できるだろ
営業部隊は苦戦してるっぽいけど
そもそも打ち合わせそのものがリモートで行われることが多くなったようなので
徐々にみんなこの状況に慣れるだろ
食堂で昼飯とれないことから昼休みの時間が実質短くなったのが唯一の欠点
コロナ騒ぎ以降、うちらのようなIT系企業は基本的に出社しない方向になるのではないだろうか
その方が本当に必要な人たちに公共交通機関をあけわたせるし、変な病気も広めないので合理的だ
みんな、ひきこもろうぜ
年明けから新しい職場に配属されたのだけど、早々に病みかけているので現状を整理するために書いておく。
ここから先、さっきから書いたり消したりして全く進まないので適当に書く。思考力も落ちている気がする。
自社はソフトウェア開発子会社的な立ち位置で、現状でも自分で名乗るなら職種としてはソフトウェアエンジニアリングだけど、新しい職場では管理系のことを中心にやってほしいと言われている。
職場の配置転換は10年以上いた同じ部署から自ら希望を出して、1年後ようやく叶ったもので仕事の内容的にはモチベーションの高いはずのものだった。
この先、思考力の低下とここは書いたらまずいんじゃないかという常識のせめぎあいにより全く筆が進まないので個条書きしておく。
いままで、忙しいとかクソ環境とか割合経験してきたので、覿面にやられている現状に戸惑っている。
たったの2週間だし、客観的に見ると早すぎるのかもしれないけど、自己診断で考えるとだいぶまずい気がする。
これから先、社会人人生もそこそこあるのでメンタルをやられて長期離脱というのは避けたい。
スマホでTwi見てさらに目が覚めて、PC起動して増田に書こうとしてるしアホやん。
7時前には起きないと駄目だというのに。寝れなくて焦って更に眠れんしどうかしてる。
こんな生活続けて体調不良で休日使っているし先週なんか当欠してるし。
別に何かあったわけでもなし、仕事の状況は大していつもと変わらず。
誰かの仮初の安心を作るだけのやらなくてもいい仕事を毎日やっているだけ。
時間が刻々と過ぎるのが本当に怖い。
試しに10秒数えていたら14秒過ぎていた。
時計の針ってこんなに早く動くもんなんかよ。
昔誰かから聞いた寝れないときは布団の上で横になっているだけで良い、って言葉守れてねえ。
まあ守る気もないんだろう自分は。
というか同期が辞めてからなんとも寂しいというか、遠い部署にいても心の支えだったり頑張る仲間意識があったんやろうな。
相談できる人もいないし精神蝕みだした自分を助けてくれそうにもない。
30代の中堅社員が悉くいないのは会社の風土が悪いんやろうなあ。
残っているのは頼りになるんかならんのか分からん、悪く言えば年数経った人ばっかりってところやし。
人の扱いが悪いというか、マンパワーだけでなんとかしようとしてるというか。
田舎だから情報システムというか、ISO関連で文書の改訂履歴残さな遺憾のに
別のエクセルファイルに記録残しますとかそれ最新版の担保と改訂内容の担保ないやろって思いながら会議聞いてたけど
まあ出身処からしての畑が違うからそういう発想に至らんというのは仕方ないんやろなあ。自分も畑が違うと分からんことばかりやろうし。
最近は機器の稼働状況調べるようなラズパイIoTみたいなのやってみたいけど、
なんか暇が出来そうにないな。家で酒飲んでないでラズパイ弄ってろってことかな。
それよりも先に内線規程ベース基本仕様についての文書も整備せないかんなあ。
細かい機器の略語辞典とかもあれば便利やろうし、なんせ自分の勉強にもなるやろし。
言うてWiki弄ってたら遊んでる扱いされてたのムカつくわ。
Redmineとかもサーバ建ててるみてるんやって趣味やけど、いつかこれ役立つとき来るんやないかなあおもてやってるんやで、はあー
愚痴です。
ざっくりいうと、
という話です。詳しく書きすぎて身バレしそう。
私は、昨年とある小さい企業に入社し、入社後10ヶ月ほどで管理職となった。入社直後の配属先は5名前後の開発チームで、タイトルの「元リーダーの部下」とはそのときにチームリーダーを務めていた人物である。
入社先の会社自体は設立から10年程度経過しているが、当初は社長のツテなどで社員を雇っていたようで、開発チームにはいわゆるプログラマとして働く人のみで開発のマネジメント経験のある人はひとりもいなかった。ちょうど数年前から事業をちゃんと収益化しようとしているところだったが、これまで社長自身の旗振りによって動かしていた開発チームも、社長が多忙となり直接見られないことから一応リーダーとして立っていたようだった。
私は前職ではそれなりの規模の企業で、受託案件のプロマネを数年間やっていたこともあり、今の会社の面接の際はそのマネジメント経験を非常に買ってもらえた。そういう経緯もあり内定をもらい入社したので、最初はやってる業務内容を教えてもらいながらこちらもチーム運営をヒアリングしたりして状況把握につとめた。初っ端、タスク管理方法について聞いてRedmineを見たところ更新されているチケットがほとんどなく、営業チームからの要求がたまに書かれるだけのものになっていて「おぁ・・・」となったが、そういうところから運用ルールを決めて周知して回して…と地道に進めてきた。
2〜3ヶ月もすると、開発チームのメンバーとしてマネジメントの会議に私が参加するようになり、他部署との依頼や業務調整など、すべて私を通してやってくれるようになった（それまでは、営業部門の人が開発メンバーに個別に聞きに行く、という形で情報共有もされていなかった）。
それでも、名目上、チームリーダーとしては彼を立ててはいた。もはや彼のリーダーとしての仕事は進捗確認するためにチームメンバーを招集すること（進捗確認の自体は私がやっていた）と、全社会議で開発チームの進捗をみんなに報告することだけであったが、私が管理職になったことを機にその仕事も私が引き取り、他のプログラマたちと全く同じ立ち位置になった。
話は変わってチーム全体のことだが、開発チームにはさまざまな勤務形態で働く人がいることと、私の前職ではデスマーチ的な働き方が横行していた反省から、チームメンバーには極力割り込み業務をさせない・会社全体の状況はできるだけこまめに共有する・定期的にメンバー個別に話を聞ける時間を作る、などメンバーが安心して働ける環境づくりを心がけてきた。また、開発プロセスや品質についてそもそも知識がないメンバーもいたので、個人個人が能力の底上げができるよう、タスクの洗い出し方から設計書の書き方、テスト項目の作り方など教えながら一緒にやってきた。実装やインフラ設定などは逆に私よりも知識・能力がある人たちだったので、道筋を作ってあげることでこれまで「それなりに動く程度に作って終わり、バグが報告されたら手が空いたときにやる（結局できない）」みたいな感じだったのが徐々に改善されてきたと感じている。
ただ、彼だけは例外だった。最初の数ヶ月で、彼自身にハンドリングさせる仕事を振ってはいけないと分かってはいたため、彼にアサインする仕事は必ず私が最初に介入し、進め方・タスクの洗い出し方・スケジュール…とすべて打ち合わせで明確にし「いつまでに何をする」をきっちり決めて（スケジュールは彼の見積りにさらにバッファを山積みして）あとはやるだけ…な状態に持っていく。また、彼は誰かに頼まれごとをするとそちらが最優先になる自分のタスク管理をできない人なので、一切他のタスクを振らないようにしていた。それでも期日になると、成果物が出てこないか、終わってないものが出てくるか、そもそもタスクがなかったことになっている。終わったと本人が言っていても、当初やることに合意したはずのものが実装されていなかったり、適当な実装だったり。リリースすると客から指摘が来て、それの対処にまた数週間かけるのである（次の開発を開始できないためまた遅延する）。
そんな状態なので、開発工程ど真ん中でも頻繁に介入して立て直しをする必要が出てくる。立て直しをするときにはできるだけ彼の心を折らないよう、「このまま進めても遅延するリスクが大きいので」と伝え、振り返りの体で「ここでもう少し見積りのための調査を詳細にやっておくべきだったね」「次はこうやってみよう」と立て直しのために必要な作業を一部実際に自分でやってみせ、他の部分を明日いっぱいぐらいで作ってね、作ったら一緒にレビューしようね、という風に毎回新人教育のような気分になりながら進めるのである。当然私自身が持っている仕事に支障が出るので週末にやるのである。
長くなってしまったが、ここまでは日常の業務の光景であり、組織作りや案件が炎上しないための立ち回りなどは私の仕事だと認識しているので努めて冷静に対処しているつもりである。怒鳴ったことは一度もない。
発言が、仕事を茶化すようなものだったり、自分のタスクを他人事のように言ったりする。そしてそれは状況がシリアス（彼の能力不足に起因する遅延が発生している状況など）になっても変わらないため、非常に癪に障る。
これまでのことをすべて列挙するときりがないが、直近に行った、彼が進めているプロジェクトの仕切り直しのための打ち合わせ（私と彼の一対一）での発言が特にひどく、タイトルの通り怒りが収まらない状態が続いている。
よくブチ切れずに済んだなと思いながら、このように調子に乗ったままだと彼は負債の再生産を繰り返して会社に害為す存在になることがわかっているため、きっちり〆ておく必要があるのかなとも思う。反射的にそういうアクションをとれない自分が恨めしい。とはいえ、過去に就業規則を全然守らないことに対して説教したときもヘラヘラしてたし、金銭的な処分をする権限はないし、自分には彼をどうにかするのは荷が重いな…と迷いに迷っている週末。
人手不足の折、やるべきタスクはたくさんある中で、彼の手もまた人手だと思いながらやってきたけど、私の負担だけが増えてモノができないなら思い切って切る判断もあるのかなと思う。結論が出てこないけど、直近指示したことが予定通り出てこないならまたそれに対して立て直しをしないといけないと思うと心が重い。彼を担当から外すにしても今他に空いている人はいないし、彼にさせる仕事も思いつかない。担当から外したら外したで「身軽になった〜」と喜ぶのだろうか。それを想像してしまいまた怒りがこみ上げ無限ループに陥るのやめたい。
昨今流行りのNTTの退職エントリの大半において、NTTの評価は
・福利厚生は良い
・人も良い
・待遇も悪くはない
・的外れなセキュリティ対策にガチガチに縛られていて作業効率最悪
という感じなのだが、まさにその通りなので、退職する気はないが、現役社員として実例を示しておく。
私が所属する組織では、ここ数年で情報セキュリティインシデントが多発している。
具体的には、取引先のベンダーA社の情報が、B社に開示されてしまうという情報漏洩だ。
その大半が、弊社の独自システム（以降「システムX」と呼ぶ）上、あるいはその周辺で発生している。
システムXは、弊社と多種多様なジャンルのベンダーが仕様書やソースコード、バグ票やQAコメントのやりとりなどを行うためのプラットフォームなのだが、その歴史は古く、運用開始は2000年代前半。
運用当初から現在に至るまで無秩序な機能の追加や他システムとの統合を繰り返した結果、その全貌を知るものは最早いないのではないかという複雑怪奇なシステムとなっている。
それゆえに情報管理・権限管理の仕組みは非常に難解で、「どうぞヒューマンエラーを引き起こしてください」と言わんばかりの罠が方々に散りばめられている。
「A社宛の起票のつもりだったが、なぜか権限設定に不備があり、B社も閲覧可能になっている」といった具合だ。
さらにシステムXへのユーザアカウント追加／削除や権限設定は、これまた極めて複雑かつ前時代的なエクセルフォーマットに記入してメールで申請しなければならず、この申請方法に起因したヒューマンエラーによる情報漏洩も後を絶たない。
日本語の読み書きとITパスポートレベルの知識があれば、わが組織で発生している情報セキュリティインシデントの癌はシステムXだということがわかるはずだ。
システムXの問題点を洗い出し、別のシステムでの代用を考えるのが筋道であろう。
現に、開発プロジェクト単位でシステムXを使わずにbacklogやJIRAといった権限の管理が容易かつ確実に行えるシステムへの移管が進んでいる。
問題。情報セキュリティインシデントの多発に伴い、社長や直属役員からお叱りを受けた組織長が取った対応策は何か。
もちろん本日記のタイトルからお察しの通り的外れなのだが、その度合いがヤバい。心して聞いてほしい。
・メールやシステム（システムX以外も含む）で社外に添付ファイルを送信する際は、課長職以上の管理職から送ることとする。
・具体的には、係長以下の社員が添付ファイルの所在および送信方法の下書き（メールやチケット）をメールで管理職に送り、管理職が先方に送信する。
・・・え？
システムXが糞過ぎてヒューマンエラー多発してるだけなのに、全てのファイル送信を管理職が送ることで何か解決するの？
というかメール／JIRA／backlog／Redmine etc・・・で日に何十も何百もファイル送信が行われるのに、全部管理職を経由させるの？
ログファイル1件、スクリーンショット1枚送るのに課長にメールで依頼して、対応を待たなきゃいけないの？
働き方改革だ、業務効率化だと言っていたのはどこの誰でしたっけ？
もうね、怒りを通り越して笑いがこみ上げてきたよ。
この対策（笑）が意味を成さないこと、むしろ無駄に人手をかければ更にヒューマンエラーが発生する確率が上がることくらい、ちょっと賢い小学生でも理解できる。
気づいてる管理職も大勢いるはずなのに、誰も異論を唱えず、淡々と部下に"ルール"として周知する。
多くの部下を抱え、毎日大量のファイル送信が必要な管理職は、ノートPCを持ち帰り、帰宅後だろうと年休中だろうと遠隔でファイル送信の対応に追われている。
わが組織に「ボトルネック生成によるヒューマンエラー促進法」が施行されて数日後、めでたく情報セキュリティインシデントが発生した。
具体的な内容と原因については知らされていないが、推して知るべしといったところ。
いっそのこと、ファイルは全部組織長が送信したらどうっすかね？むしろ、社長にしますか？いや、それでも危ないから、全部手渡しにしましょうか？（鼻ホジ）
こんな感じ
フリーランスで仕事してるけど今月で配属されたがバックレるつもりです
いきなり客先に呼ばれたり突然何もわからない会議に呼ばれるのはちょっときつい
事前にどのような経緯を説明してくれたらいいなあと
協力会社(この人は現場の保守運用をある程度知っている)からも指示を受けるので
仮に作業手順書があったとしても属人性が非常に高いので1から作業手順書を作成せねばならん
・協力会社A(6月から入ったが昨年あたりから仕事を知っている)
・俺(ポンコツ)
要は前述の協力会社Aとのウマが合わないところがあるんですわ
ダメな小学校教師みたいに「こんなのも出来ないの」「以前言ったよね」みたいなところはまあ我慢できるけど
Redmineでチケット書いたにもかかわらずその旨をメールで送らないとならない
勤怠報告は社内のLINEでサクッと出来ると思ったがメールで送らないとならない、しかも件名だけはフォーマットが決まっててうざい
定時後に仕事振るなボケカス、こっちはスケジューラーに「定時で帰る」と書いているんだぞボケカス
個人事業主なのでこんなクソ案件はポイーしようと思っています。
コンソールは使えなくても、AdobeのXdとかRedmineのようなGUIがあるツールならまだハードルが低いとは思う。
まあ、使ってくれと言って使ってくれる人は少数しかないと思うけどね。
Google docsなら履歴も管理できるからそれから始めても良いかも。
ともかく、どっちが良い悪いじゃなくて、
仕事しずらいなら、こちらが技術で武装して言い逃れできないように相手を詰めれば良いんじゃないかな。
修正指示が雑なら雑って、口すっぱく指摘しても良いと思うよ。
「こんなんじゃ仕事にならねえよ…」ってニッコリしてやんわりと言うだけで、指示出す方には効果があると思うけど。
なんなら、引き受けず納得いかないって突っぱねても良いと思う。
株式会社アイビスは、お絵描きアプリのアイビスペイント出しています。
私は、株式会社アイビスで2年ほど働いていましたが、精神的肉体的に社会復帰できなくなってしまったので退職しました。
1つ目は、営業の人が案件とエンジニアの技術力を考えないで、プロジェクトに任命させることです。
私は、言語としては、C++を基本的に触っていましたが、営業の方から案件がないからGo言語でもいい？というか、それしかないからお願い、と頼まれました。案件は水ものだししょうがないよねと、営業の方自信が自分にいいきかけせている感じでした。それでプロジェクトに入りましたが、現場ではめちゃくちゃ怒られる毎日でした。そもそものお作法（変数の型宣言が後置である）も知らないからです。
このことでプロジェクトに合っていないと営業の人に言って離任を申し出ますが、うちではみんなこんな感じだから我慢してと言われるだけでした。そのまま、3ヶ月が過ぎたら10キロ以上も痩せて、配属先の会社から離任を申し出てきました。
離任後は、自社に戻ると営業の人は、顔も合わせず次のプロジェクト先をメールで伝えるだけでした。
もちろん次も経験のないJavaとAWSの環境でインフラ設計、製造です。しかも、プロジェクト先が都内から1時間30分以上もある厚木です。対応できなくものすごく怒られ1ヶ月でお客さんから離任を告げられました。
このことで、求人に書いてあることは自分の得意な言語で仕事出来るはずじゃないですかと営業の方（採用も担当していた）に問い詰めますが、仕方ないじゃん、案件は水ものなんだしと。そんなことなら、もっと遠方に行かせるか炎上案件に行かせるよと言われました。その後も、同じような案件で数か月で終了する感じで2年続けて精神的肉体的にまいりました。
2つ目は、1つ目と似ていますが、求人内容と書いてあることが全く違います。
私は、C++でモバイルのアプリが少しつくれる程度で会社の人とチームを組んで、開発がしたいがためにこの会社に入りました。
求人に研修では、あなたに合わせた研修とありますが、基本は放置です。
ワードのドキュメントにテトリスをつくってください。仕様は○○ですとA4の1ページにも満たない、仕様書があるだけです。更新日も5年以上前になっています。
基本誰とも話さずググって下さいと。質問してもググって下さいと言われるだけです。Redmineを使って質問ができますが、一日一回だけです。しかも、研修用で使えるPCはメモリは2GBで、2つ以上アプリを開いたら、フリーズします。
研修は、4ステップありますが、ほとんどの人がステップ1も終わらないで、現場に行くことになります。
現場に行く時は、もちろん営業としての単価がいい案件なので、炎上か高難易度の案件です。未経験の人でも大丈夫で4割が未経験でチームでプロジェクトに入りますと求人表に書いてありますが、一人で案件に行かされます。チームで行くことはたまにありますが、みな個人プレーで自社の人とは関わりません。フォローもなく、むしろ出来なかった時だけに怒鳴られます。平成終りなのに、やっていることは昭和初期の根性論のような会社です。
最後に、会社のトップの人は自社開発のアプリしかしていなく、全く経営をしていません。
例えばですが、今だに、派遣先での勤怠を自社に提出する際は紙ですし、社内システムは10年以上前のものを使用しています。
社長はめんどくさい事は、管理職に丸投げをして、暇さえあればツイッターをしているような人です。そんな暇があるならば、社内インフラを少しでも良くしてほしいですが、それも気づいてないです。
さらに、今後上場を考えています。上場したら優秀な人材が集まり、今いる人と競わせて、優秀な人だけ残すと言っているのです。社員をただのお金としてしか、考えていないので非常に残念な経営者です。
ちなみに私は、中途で入り手取り20万円で入社しました。しかも一年目はボーナスなし。年収300万円も行かなかったです。しかし、今転職した会社では、月給は32万で、手取りは28万円になりました。やっている事は変わっていないのにです。年収も400万円までいきました。これでも、他の会社と比べたら少ない方ですが、株式会社アイビスがいかに低賃金で働かせていることか身に染みました。
エンジニアを安く買い叩かれることがないように、間違えて自分と同じようなミスをして欲しくないために今回記事を書きました。
※色々とコメントありがとうございます。
今回の記事は株式会社アイビスが都合のいい人だけ集めていること、SES（システムエンジニアサービス。エンジニアの派遣です。）に問題があることをもう少し説明します。
株式会社アイビスは、都合のいいエンジニアだけ集めて、後は切り捨てるという考えです。プロジェクトにマッチしない人でも、辛抱強く続けられる人は会社としては利益になる。優秀でなんでもできる人ならマッチしなくてもどのプロジェクトでも活躍できる人が残っている人の2パターン。仮にマッチしなくてもやめる人のケースの場合でも、責任は営業とエンジニアになりますが、実質エンジニア（話し合っても、普段話しなれていなエンジニアは、丸め込まれる。または、受け流されて、変わらないことに気付いてやめる）になる。会社としての損害はほぼなく、利益は減るが、新たなプロジェクトを探し出せることになっている。常に求人をしているので、そんなことを知らない人が同じようなループに入ります。そこで、続けられる人が見つかれば会社としてはラッキーという感じです。そして、そこに残っている人はすごい低賃金で歯を食いしばってやっている人か、ものすごい技術力がある優秀な人かの両極端になります。自分がどちらか気付いたときは、そのポジションの言動をとるようになっています。歯を食いしばるか、サクサクコードモンキーになるか。
https://tenshoku.mynavi.jp/jobinfo-214515-2-3-1/?ty=kyujin&src=ssS
もう一つ、SESの問題点は上記であるように派遣でプロジェクトに入るところです。チームで何かしらをつくりますが、この時に株式会社アイビスの営業、会社、エンジニア、お客さん（1次受け、2次受けで責任者が複数にいる状態）いますが、そもそもプロジェクト自体が炎上していて、失敗したら責任はお客にあり、エンジニアは地獄をみます。営業と会社は「しかたないでしょ」となります。もちろん、成功したら「よかったよかった」になります。ほとんどの場合は、微妙に燃えています。そこでカギになっているのがエンジニアの力量ですが、プロジェクトによって使う技術が決まっていないので、地頭力か歯を食いしばる力（お客は求めていないが、自社は求めている。派遣するだけで利益になるのだから）が求められる。結果的に優秀な人は、機械学習（Python）であったり、Reactであったり、クラウドの（AWS、AZURE、Google Cloud Platform）にも対応できます。お客さんもエンジニア便りになって、正しくプロジェクトが成功できるかは、優秀な人を揃えられるかどうかです。歯を食いしばったところで意味がないのに、会社というポジションでそれをやらせる会社はどうかなと思います。しかし、会社も利益を出さないいけないということで、目先のお金（SES）で稼ぐのです。
