  |
はてなキーワード: redMineとは
何かない？
これが一番大きいのでは。パソコンにデフォルトで入っているソフトというアドバンテージは大きい。Webが普及した理由である「パソコンに元々入っているブラウザで見れる」点と同じだ。
これはもう説明不要だろう。例えばレイアウト調整のしやすさはRedmineとかJIRAとかのWebベースのツールとは比べものにならない。
神Excelを非難する連中が何故かスルーしているポイント。アウトプットはそれを読んで評価する人が居るから価値があるのだ。
評価する人にとっても、特別なソフトや特別な操作（ログイン等）が要らず、慣れ親しんだフォーマットと操作感でアウトプットを扱えるというのは、ビジネスにおける必須条件だ。
この話をすると必ず「評価する側も変わるべき」と言う奴が出てくるが、評価する人は同じ職場の人だけではない。「監査法人」もいるのだ。その監査法人は監査の正当性確保を理由に、監査手段を極端に変えない傾向がある。Excelじゃないと監査を受け付けてもくれないのだ。監査してもらえなかった暁にはみんな東芝状態になる。
もしそれが嫌なら、そこらへんでブログでも書いてるほうが良いだろう。
最近は神Excelの代わりにクラウドを使おうと言ってる人が居るが、コストに加え、このリスクが上乗せされることをスルーしている。
つまり、神Excelを無くすには、Windowsが無くなるか、Excelに代わるクライアントソフトをマイクロソフトがExcelの後継として出してくるのを待つしかないだろう。
そして後継ソフトがまた「神○○」と叩かれる未来が来るのである。
追記。redmineだけwww-dataユーザーで手動展開してwww-dataとして必要gemをredmineディレクトリ内に（必要なdevをaptで入れて）インストールしたら動いた。
やっぱりあちこちのディレクトリに分散させたredmineのdebが俺には繊細過ぎたのだ（rubyとrailsとnginxとphusionpassengerはdebのまま）。作業ディレクトリいっこ万歳
「無知と無理解にプロジェクトが殺されそうだ」の元増田です。
みなさんのトラックバックを読みました。やはり「つける薬はない」「うまく逃げおおせるべし」ということですよね……。
昨日の夕方、喧嘩も辞さない覚悟で、しかしあくまでも対話重視でレビューに臨みました。
Redmine に書いたキャッシュの仕組みの解説を事前にちゃんと読んでいたのは PM の V さんと、その程度の知識は当然ある W さんだけでした。いちばん理解していない PL の Z さんに至っては見てもいない。予想どおりとはいえ、徒労感が募ります。
PM の V さん曰く、「誤解しているかもしれないけれど、増田さんの提案するキャッシュバスターを入れたくないとは言っていないんですよ。ただ、リリース直前だったので時間との兼ね合いを考えて、とりあえずいちばん工数のかからない方法を採りたかったんです」。いやいや、ほかの方法では効果がないと何度も何度も伝えたでしょう。私の主張するちゃんとした対応を取るのに必要な時間の数倍かけて、無意味な「影響範囲の調査」をして「ほかの方法」を模索していたのですよ。そう言いたかったのですが、もうあまり事を荒立てたくなかったので、「対策を考える時には必ず技術者を含めた話し合いをしてほしい。そうでないと、結論が明後日の方向に進んでプロジェクトの費用をドブに捨てることになりかねません」と伝えるに留めました。でも分かってもらえないんだろうな。
作業方針となぜその方針で解決するのかという説明に留まらず、実装方法まで聞いてくるので、「率直に申し上げて、ここ最近、技術者の作業領分に踏み込みすぎだと思います。必要以上に説明を求められ、毎回こうして 6 人の時間を拘束して説明会を開くのは時間と予算の無駄ですし、作業のスピード感を落とします」と言ったところ、今回のレビューでは珍しく無口だった PL の Z さんが「そこまで言うなら、バグを出さずにきちっと作りなさいということです」とひとこと。ムッときてバトルを始めようかと思ったのですが、早く切り上げてトイレに行きたかったのでスルーしましたｗ
「増田さんはバグが多い」と言われている話は「無知と無理解にプロジェクトが殺されそうだ おまけ」のエントリーに書いたとおりです。
W さんが時折助け船を出してくれたり、私の説明に無言でうなずいてくれたりしたおかげで、理性を失わずに済みました。
レビュー中はみなさんのトラックバックを思い出し、「もうどうしようもないんだ、あまりやり合うなよ」と自分に言い聞かせていました。本当に感謝します。ありがとうございました。
文字数制限に引っかかって下のほうが切れたので、こちらに追記します。
システム P の Web 側をひとりで開発している私がここまで信頼されていないのには、以下のような理由があります。
Git で機能単位でフィーチャーを切って(注: その機能のためだけにソースコードを枝分かれさせて他の機能に影響が出ないようにすること)開発を行い、私が機能を実装してコミット(提出)すると、X さんと Y さんがテストをして、不具合が出たら Redmine に登録して私がフィードバックを受け、私が修正し、それをまた X さんと Y さんがテストをして……という流れで開発をしています。
この X さんと Y さんによるテストを、なぜか「受入試験」と呼びます。ふつう、受入試験と言えば、開発元で最終テストまで済ませたものを発注元に納品した時に発注元が行うテストのことです。
実は、XYZ の 3 氏は、システム P の契約の上では「A 社の契約社員」ということらしいのです。私の所属は B 社なので、他社(下請け)が作ったものを自社で試験することになり、「受入試験」という工程になるとの由。
システム開発の理屈など分からない A 社の上層部から見ると、受入試験でたくさん不具合が出ている、何だ B 社は品質が悪いじゃないか、ということになります。品質を高めるためにテストを入念にすればするほど報告される不具合の数が増え、なおさら「品質が悪い」と言われてしまいます。
そして、複数のフィーチャーをマージ(結合)したソースコードの試験は、私にはできません(させてもらえません)。一般に言う単体試験も結合試験も、この現場ではみな「受入試験」です。
A 社の上層部だけでなく、プロジェクトマネージャーの V さん、プロジェクトリーダーの Z さんもこの仕組みがおかしいことを理解しておらず、「増田さんはバグが多い、信用できない」と本気で思っています。そりゃあポカミスは多いですがね……。
それ、たぶん私です。多くの方から意見をいただきたく、増田デビューしました。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
最近の回転寿司はどこもタブレットで注文して専用レーンで運ばれてくる
この前行った寿司屋も同じだったんだが，注文してから１０分とか２０分経っても全然来ない
一応，嫁が食べるあら汁と息子が食べるうどんは来たんだけど，俺が頼んだあおさ汁と１０皿ほど頼んだ寿司が全く来ない
「どの注文が来てませんか？」
と逆に聞かれてビックリした
そんなもん，テーブルの番号があるんだからそっちで把握できるんじゃないの？と思ったが
しばらくしたら帰って来て
「すぐにお持ちします」
とのことだったのでしばらく待ったら寿司が続々とやってきた
ただ，あおさ汁は来ないで代わりにあら汁とうどんを持ってきたので
「あら汁とうどんは来ていて，あおさ汁が来ていない」
っていうのを伝えた
このときはまだ「ああ，否定表現で伝えたのが良くなかったかな」とか思ったけど
次にしじみ汁とあおさ汁持ってきて流石にちょっとあきれてしまった
（ついでに言うと寿司も2種類ほど来なかったので再度店員に伝えたりした）
ここで，普通にiPadを導入しているような店舗のシステムを想像すると
ところがそこの店はそういうシステムではなさそうだ
そういうシステムならテーブル番号を伝えれば握っていないタスクをこなせばいいだけだからだ
そしてiPad上に「タスク完了」を示す何らかのフィードバックがあっても良い
しかしiPadの注文履歴を確認したがそういったステータスの確認はできなかった
2. タスクとしては管理されておらずただ画面にテーブルと注文が表示され
3. 他の注文が入ってくると表示している画面からは追い出されてしまう
つまりタスクがどこまで完了したかどうかは握る寿司職人の頭の中だけで管理されている
だから「注文が来ていない」というクレームに対してはiPadを持って行って「これとこれが来ていない」と伝えないといけないし
あおさ汁が来ていないのに平気であら汁とうどんを持ってくる
昔のように回転寿司の中にいる職人さんに口頭で注文を伝えていた方式を
ただiPadを使ってバックヤードに伝えているだけに過ぎないわけだ
この手の中途半端なシステム化がこの国には本当に多いと実感する
皿を回収口に投入するとカウントアップされ
現状の「仕事のやり方」をできるだけ変えずに
ほんの少しだけ便利に（ときには不便になるが）するためにIT化が行われる
この理由は明白で論理的な思考や状態遷移・管理に関する考え方に乏しいからだ
一番苦労したのは「タスク」という考え方の浸透だった
そういった考え方がそもそも無いからタスク管理ツールの導入にはえらく手間取った
こうした教育コストを払わずにIT化を行うからこの手の中途半端なシステムが導入されるんだと痛感している
中学生の頃、発達障害の人達が集まる２ちゃんねるのスレを見て自分は発達障害であることを知った。
そこに書かれていたのは社会に出た後の発達障害の心の叫び、阿鼻叫喚の図だった。
そしてそれは恐らく自分も今後否応なしに同じ道を辿るであろう、自分の人生のネタバレ。
これから自分は彼らと同じ地獄の道を辿り、最後には社会に捨てられ惨めに首を括るのか、そんな未来予想を想像するのは中高生のクソガキの精神的には少しきつすぎた。
心療内科に行くと発達障害の副作用的な抑うつ症状だと診断された。
なんやかんやで口からでまかせ言って就活はなんとかなった。趣味でプログラミングをやっていたのがよかった。
頭が悪い上学歴もないので大手とかはそもそも諦めていたが、なんとか地方の小さなIT企業に入れた。
まあこんな茶番みたいな就職したところで2週間くらいで首になるか首を括るかするものかと思っていた。
しかし予想に反して、なんやかんやで4年くらい続いてしまった。今年度で社会人5年目。思ったよりなんとかなってしまったのだ。
更に社会の中でいろんな人と触れ合う中で、いつの間にか希死念慮とかも心から小さくなっていることに気づいた。
・間に挟まってる社会的意義が全くない（むしろ社会悪に近い）3次請け案件の某2次請け企業
・3年目でずっとWeb系の下流工程にいるはずなのにJOIN句も知らなかった先輩社員
・ドキュメントのバージョン管理どころかRedmineすら使いこなせないSIer共
・etc
自分が死んだ方が良い社会のゴミであることは今でも間違いないと確信している。
でもよかった。
遅い昼時、流行っていない定食屋に入ると客はただ一人自分だけであった。ぼーとしていると、涙がぽろぽろ流れてきて驚いた。
何の涙かわからないが、ともかく原因はわかっている。
部下が鬱で休職した。手塩にかけたといっていいほどの部下だ。
うちの会社（IT系）の立ち上げからの創設メンバーで、つい先日までバリバリとコードを書いて、客との交渉、要件定義をし、見積りに必要な工数計算までできる部下だ。
先日、突然ちょっとした言い合いから感情が爆抜したようになった後、「辛い」とだけ書かれたメールがきて休職となった。
なぜ、このようになったのか、何が起きたのかわからなかった。つい先日まで同じ部屋で同じ空気を吸っていたのだ。今年は確かに仕事の量は多かったかもしれないが過去これ以上の修羅場はいくつもあったし、乗り越えてきた。
しかし、数通のメールのやり取りと「辛い」メールの後、一回した面談で分かったのは典型的な鬱の症状だった。会社の最寄り駅の階段を上るときに動悸がする、手が震える、いっぱいたまったメール、slackやredmineが自分を押しつぶそうとする、これらを泣きながら話す姿を見ていると鬱と思うしかない。
自分もこの会社の創設メンバーの一人だ。創設からずっと一緒だった。正直、ブラックな時もあった、いやこの春もそうだったのかもしれない。
しかし、できるだけ仕事を共有し、負担を軽減し、状況もみて「辛そうだったら、俺にふるんだぞ」と言い続けてきた。過去はくじけそうになる僕を部下が叱咤激励することさえあった。その叱咤で頑張れた。その後は社員の質の向上を会社が掲げ、仕事環境もずいぶんと向上しているはずだった。メンバー全員がよい職場づくりを考えて改善してきた。今年は例年と比べて仕事量を減らしたつもりだった。
思い当たるところはある。
一人前になるにしたがって部下に任せきりになり、安心していた。一エンジニアの立場からマネージメントまでするようになって、僕の知らないところで客との交渉や調整で苦労がたまっていたのだと思う。忙しいときほどよく話すのがいつもだったが、今年は忙しくなって２人で話すことが少なくなっていった。
なぜ気が付いてやれなかったのか、どんなに辛かったのか、そんなことばかり思い浮かぶ。
電車の中、スターバックスでコーヒーを飲んでいるとき、帰宅途中の道で、ふと頭を空っぽにしたり気持ちが緩んだ時につい考えてしまう。そしてなぜか涙が出てくる。どうして、どうして、という思いと、こんなつらい気持ち以上に、当の本人が辛いと思うとやるせない気持ちになる。
相談してほしかった。力になれない自分が情けなかった。気がつけなかった自分が情けなかった。
周りは、直接の上司である僕がコンタクトはしないほうがよいという。だから今はメールも電話もしていない。
僕はその部下にとって「過労を象徴する」者で、辛い会社を代表する「悪の権化」となっているかもしれない。
今は部下が元気になれるように、休職制度の手続き、場合によっては転職によって仕事場環境を変えるときに不利にならないように交渉している。
定食屋の親父がこちらを見ていた。人前でいい歳の男が泣くなど自分でも思っていなかった。
僕でさえこんなに辛いのだ。僕以上に彼女はつらいだろう。そう思うとまた涙があふれてくる。どうしたらよいのだろう。
こんなことを匿名で書いていて、なんになるのだろうと思いながらも匿名ダイアリーに吐露するしかない。
4/28 2回目の追記）
8時間ほど前に追記と誤字の修正をしたのだけど、後で見てなんとよい子で優等生的な追記だろうと自己嫌悪になったのでこの追記を編集する。
増田のコメントに優等生な追記をしてどこまで僕は馬鹿真面目なんだろう。
僕もそろそろ心療内科にいかねばならない頃のようだ。いろいろなものを見直す時期だと思う。
今日、元社員に「〇〇さん（僕の名）はいいかっこばかりするんですよ」と言われた。かっこいい仕事ばかり取って金になる仕事をとらないのだという。
投資家やVCの顔色を気にして、会社の業績としてぴかぴかのプロジェクトばかりとっていたのだ。金儲けする泥臭いプロジェクトを避けていたのだと思う。
ベンチャーとして頑張らなければという気持ちが強かったのだが、それは言い訳だろう。僕の頑張りは僕の自己満足でそれで他のメンバーに犠牲を強いていたのだろう。
彼女は信頼できる友人、あるいは妹のような存在だと思っていた。そんな部下を犠牲にしてまでどんな業績があるというのだ。
