もう6月も終わりかぁ。
プロジェクトは相変わらず不透明。(´・ω・`)
と言うのも、既に一度は実装は終わらせたはずなんだけど、週2回ある会議毎に仕様が増えていくのよね。
仕様変更が発生する度に修正、を繰り返している。
ならば、いつ仕様は終息するんだ?
まあ、いつかは終息するんだけど、プロマネではない人はこの進め方の問題点が分からんのよね。
このやり方は、リスクは3つあるんだよね。
一つ目、修正は間に合うのか?
均衡の問題でさ、このやり方は仕様変更の規模よりも修正する方が速くなければ成立しないわけよ。
何かのキッカケにこの均衡が崩れると、即時崩壊する。
例えば、予想外に巨大な仕様変更が発生してしまう、とか。コロナに感染して倒れる、とか。誰か辞めちゃう、とか。
一応、今のところはどれも発生しなさそうという見通しがあるからリスクを取ってるんだけど、あくまでリスクは低いと読んでいるだけで、爆弾抱えていることには変わらんよね。
低確率であっても、長く続けているといつか爆死するから、慢性化してはマズい。
二つ目、コスト
もう一つの問題は、金だ。
上述のとおり、いつどのように仕様変更が発生するか分からん以上、エンジニアを確保し続けないといけない。
この調子だと、8月頃には「仕事はもう無さそうだけど、万が一があるからキープしておく」という名目になるだろう。
これは金をドブに捨てているのと同じだ。
僕はSES側だから問題無いんだけど、逆に僕がプロパーの立場だったら、コストの面で問題視するだろう。
三つ目、納期と品質
最後に、この仕様変更っていつ終わるん?
リリース日の前日に仕様変更とかもあり得る。
となると、慌てて修正してリリースになるから、品質にもリスクが出て来るよね。
とまあ、こんな状態で7月を迎える。
まあ、感覚としてはこのまま行けそうな気もするんだけど、とにかく不透明だよね。
ここが分からん人には分からんのだけど、不透明であることは問題なのよね。
不透明ってことは、
(´・ω・`)「今は大丈夫だけど、明日は大丈夫なのだろうか?」
という可能性を常に気を付けなきゃいけないわけだから、少しでも不透明さを解消してリスクを下げていく必要がある。
ところが、分からん人は、
( ゚Д゚)「どっちにしたって明日のことは分からん!!」
って感覚。
そりゃどんなプロジェクトだって不測の事態は常に起きうるけど、「可能な限りで透明化しておこう」とは思わない。
何故かと言うと、不透明であることがリスクだと思ってないから。
( ゚Д゚)「プロジェクトなんてそんなもんや」
って感覚。だからやれることもやらない。
そして不必要にリスクを割り増しで抱えて、いつか爆死する。
と、こういう頭の人が、プロパーさんの中にいるっぽいんだよなぁ。
まあ、だからSESなんだけどね。
この会社ってSESは沢山いるけど、請負企業は見た事無ぇ。
こんな状態では請負なんてとんでもないからね。
プロパーさんも今は安定しているけど、いつか爆死して経営が傾いて解雇、とかになったりしないか心配だわい。
「巨大なリスクを抱えた会社の正社員」なんて安定でも何でもないな。気を付けて生き延びないと。(´・ω・`)
- 2020年6月30日火曜日
- 2020年6月29日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
休養
疲れが溜まっていたから、土日はご飯食べて酒飲んで昼寝、を決め込んで休養。
やっぱり昼寝が一番効果が高い。
これで日曜の夜にはすっかり元気になっていたんだけど、ちょっと暴飲暴食が過ぎたらしく、月曜の朝になったら胃痛になっとる。
次は胃を休めないとイカンか。(´・ω・`)
やっぱり昼寝が一番効果が高い。
これで日曜の夜にはすっかり元気になっていたんだけど、ちょっと暴飲暴食が過ぎたらしく、月曜の朝になったら胃痛になっとる。
次は胃を休めないとイカンか。(´・ω・`)
- 2020年6月27日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
グロッキー
今週は仕事の忙しさと暑さのダブルアタックで大変だったな。
金曜日の夜はグロッキーだった。(´×ω×`)
まあ、頑張った甲斐あって、進捗は問題無い。
この辺りで少しゆっくりしたいんだけど、何か他の連中が遅れているみたいだから、表向きには存在しないHELP作業で来週は忙しくなるかも。
なかなか楽させて貰えんわい。(´・ω・`)
金曜日の夜はグロッキーだった。(´×ω×`)
まあ、頑張った甲斐あって、進捗は問題無い。
この辺りで少しゆっくりしたいんだけど、何か他の連中が遅れているみたいだから、表向きには存在しないHELP作業で来週は忙しくなるかも。
なかなか楽させて貰えんわい。(´・ω・`)
- 2020年6月24日水曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ウズマスの野望~SE風雲録~
色々やることあって忙しいのだが、新しくゲームを買ってしまった。(;´・ω・`)
信長の野望3DS。
「信長の野望~武将風雲録~」という名前の方が有名だろう。
僕って信長の野望をプレイするのは初めてでね。
三國志が面白かったから、その繋がりで買ってしまった。
3日ほどプレイしてシステムは理解できてきた感があるが、寝る間を惜しんでプレイしていたら疲れてきてしまった。
そんなに慌ててやるもんでもないし、ゆっくりプレイしていきたい。(´・ω・`)
信長の野望3DS。
「信長の野望~武将風雲録~」という名前の方が有名だろう。
僕って信長の野望をプレイするのは初めてでね。
三國志が面白かったから、その繋がりで買ってしまった。
3日ほどプレイしてシステムは理解できてきた感があるが、寝る間を惜しんでプレイしていたら疲れてきてしまった。
そんなに慌ててやるもんでもないし、ゆっくりプレイしていきたい。(´・ω・`)
- 2020年6月21日日曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
始まらん
実装第一フェーズは6/19(金)で終わり。
第二フェーズは6/22(月)から始まる。
第一フェーズと第二フェーズの違いは何かと言うと、このプロジェクトは要件が固まらんし、設計も間に合わん。
でも納期は短いから、僕の嗅覚で好きに実装しておいてくれ、というのが第一フェーズ。
嗅覚と言っても、仕様とは関係無いプログラムとしての基盤部は作れるし、仕様も大体、察しが付く。
「契約結んだら契約レコードをインサートする」とか、当たり前や。
抜けてるのは、「契約レコードをインサートする一歩手前でデータの整合性チェックを行い、不適合な条件のものは除外する」とか、そういう細かい部分だ。
第二フェーズは、ようやく仕様と設計が追い付いてくるから、次こそは設計書と突合するようにソースを完成させていく、というものだが……。
これは間に合わんな。(´・ω・`)
土日返上で若い衆が今頑張って設計書を書いてる。その途中進行を今ちょっと覗いてみたが……。無理無理無理無理。
こんなペースで間に合うわけが無い。
総量で言えば、明日の朝の時点で執筆されているのは7割が限度だろう。
しかもそれは無レビューのシロモノ。
無レビューで書くだけ書いた設計書が7割、白紙が3割。
これくらいで明日を迎える。
これは若い衆の作業が遅いというより、金曜日の時点であれだけ残っていた以上、もう無理ぽなことは明らかだった。
時間が一週間足らん。無茶振りされてカワイソス。(´・ω・`)
さて、この状況で、来週はどうすっかなぁ。
これね、立場が逆だったらスケジュール調整に動いている状況だなぁ。
と、スケジュール上はそうなっているかもしれないけど、無理なもんは無理ってことは明確にしなきゃいけないし、
また実際のところ、設計書の全てが完成しておらずとも、6/22(月)から製造は開始出来るじゃない?
五月雨式に「設計が完成している部分」から製造を始めて、製造の後半くらいまでに全量が揃えば、最後には辻褄が合うでしょ?
つまり、
( ゚Д゚)「設計書は全く間に合いません。が、機能1~10のうち、1,2だけなら6/22(月)に間に合います。とりあえず機能1、2から製造を始めて頂き、3~は完成次第、という進行で実装して頂けませんでしょうか?」
(´・ω・`)「了解~」
という調整を金曜日のうちに済ませておくのが本来の筋だが、若い衆にそんな調整を要求するのは無理過ぎるだろう。
若い衆の現在の精神状況を推察するに、たぶん今、必死になって少しでも設計書を多く書こうとしている。
と言っても、全然間に合わないことは既に明らかで。
そのまま鬱な気持ちで明日の朝を迎えるだろう。
カワイソス。(´・ω・`)
と考えると、来週は僕の方からその話を持ち出したらなアカンか。
機能1~10のうち、「完成度の高いもの」と「低いもの」があるはずなのよ。
「完成度の高いもの」を引き取って、実装者の僕がレビューも兼ねる、とすれば、作業は進むでしょ?
そうやって時間を稼いでいる間に「完成度の低いもの」を揉んで貰う。
という風にロードマップを整備すれば、進捗遅延で鬱になっている若い衆の気も晴れて作業に集中できるだろう。
やっぱプログラマーであってもマネージメントの概念は必要や。(´・ω・`)
第二フェーズは6/22(月)から始まる。
第一フェーズと第二フェーズの違いは何かと言うと、このプロジェクトは要件が固まらんし、設計も間に合わん。
でも納期は短いから、僕の嗅覚で好きに実装しておいてくれ、というのが第一フェーズ。
嗅覚と言っても、仕様とは関係無いプログラムとしての基盤部は作れるし、仕様も大体、察しが付く。
「契約結んだら契約レコードをインサートする」とか、当たり前や。
抜けてるのは、「契約レコードをインサートする一歩手前でデータの整合性チェックを行い、不適合な条件のものは除外する」とか、そういう細かい部分だ。
第二フェーズは、ようやく仕様と設計が追い付いてくるから、次こそは設計書と突合するようにソースを完成させていく、というものだが……。
これは間に合わんな。(´・ω・`)
土日返上で若い衆が今頑張って設計書を書いてる。その途中進行を今ちょっと覗いてみたが……。無理無理無理無理。
こんなペースで間に合うわけが無い。
総量で言えば、明日の朝の時点で執筆されているのは7割が限度だろう。
しかもそれは無レビューのシロモノ。
無レビューで書くだけ書いた設計書が7割、白紙が3割。
これくらいで明日を迎える。
これは若い衆の作業が遅いというより、金曜日の時点であれだけ残っていた以上、もう無理ぽなことは明らかだった。
時間が一週間足らん。無茶振りされてカワイソス。(´・ω・`)
さて、この状況で、来週はどうすっかなぁ。
これね、立場が逆だったらスケジュール調整に動いている状況だなぁ。
- 6/19(金):設計完了
- 6/22(月):製造第二フェーズ開始
と、スケジュール上はそうなっているかもしれないけど、無理なもんは無理ってことは明確にしなきゃいけないし、
また実際のところ、設計書の全てが完成しておらずとも、6/22(月)から製造は開始出来るじゃない?
五月雨式に「設計が完成している部分」から製造を始めて、製造の後半くらいまでに全量が揃えば、最後には辻褄が合うでしょ?
つまり、
( ゚Д゚)「設計書は全く間に合いません。が、機能1~10のうち、1,2だけなら6/22(月)に間に合います。とりあえず機能1、2から製造を始めて頂き、3~は完成次第、という進行で実装して頂けませんでしょうか?」
(´・ω・`)「了解~」
という調整を金曜日のうちに済ませておくのが本来の筋だが、若い衆にそんな調整を要求するのは無理過ぎるだろう。
若い衆の現在の精神状況を推察するに、たぶん今、必死になって少しでも設計書を多く書こうとしている。
と言っても、全然間に合わないことは既に明らかで。
そのまま鬱な気持ちで明日の朝を迎えるだろう。
カワイソス。(´・ω・`)
と考えると、来週は僕の方からその話を持ち出したらなアカンか。
機能1~10のうち、「完成度の高いもの」と「低いもの」があるはずなのよ。
「完成度の高いもの」を引き取って、実装者の僕がレビューも兼ねる、とすれば、作業は進むでしょ?
そうやって時間を稼いでいる間に「完成度の低いもの」を揉んで貰う。
という風にロードマップを整備すれば、進捗遅延で鬱になっている若い衆の気も晴れて作業に集中できるだろう。
やっぱプログラマーであってもマネージメントの概念は必要や。(´・ω・`)
- 2020年6月19日金曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ぼかし表現
一応、第一フェーズの仮実装完了の目標日。
かつ、後追いで仕様書も作られているので、その読み合わせを行った。
その仕様書も完成していなんだけど、一応の区切りの段階だということで見せて貰ったが……。
やっぱ、特に明確に拠り所となる資料が不足した空中戦だから人に依って理解度に差が出てるね。(´・ω・`)
同じ間違いでも、
これって全然違うもので、文面から伝わってくるんだよね。(;´・ω・`)
前者、「そこそこ理解した上で間違えている」のパターンだと、少なくともドキュメントの日本語は明確だし、本人の意識も鮮明なのよ。
だから、
( ゚Д゚)「ここでこういう条件でテーブルを検索します」
(´・ω・`)「あれ? その条件だと一意にならんような?」
( ゚Д゚)「えっ? そうでしたっけ?」
(´・ω・`)「ステータスが1であること、を条件に追加しないといけないような」
( ゚Д゚)「確かに、修正します」
って感じに、凸凹しつつも議論が進んでいくのよね。
修正箇所が多いか少ないか、程度の問題でしか無い。
無論、間違いは少ないに越したことは無いけど、間違いが2倍あれば2倍修正すれば終わる。
叩き台なんだから、どれだけ間違っていても構わん。
ゴールまでの道筋は見えている。
ヤバいのは後者「そもそも理解不足を放置したまま資料を書いている」で、
( ゚Д゚)「ここで取得します」
(´・ω・`)「何を取得するんでしょう?」
( ゚Д゚)「データベースを」
(´・ω・`)「テーブルはどれでしょう?」
( ゚Д゚)「えっと……。契約テーブル?」
(´・ω・`)「契約テーブルをどういう条件で検索するのでしょう?」
( ゚Д゚)「会員ID?」
(´・ω・`)「その会員IDはどこから出てきたものですか?」
( ゚Д゚)「えっと……」
(´・ω・`)「この処理は会員IDで検索するものではなく、ステータスが1であるものを全件取得するものだと思うんですよ」
( ゚Д゚)「確かに」
(´・ω・`)「だから、以降の処理はループ処理です。また、この処理は大量件数になる可能性があるので、負荷についても考慮しておく必要があって……」
って感じ。
本人の意識が混濁してるのよね。
だから資料も「取得する」とは書いているけど、「何をどこからどういう条件で取得する」とは書いてない。
混濁している部分は省略したり、ぼやかした表現にして、次の作業へ。
だからドキュメントの数は揃ってるんだけど、中身はどこから直せば良いのやら、という状況。
これは「間違っている」のではなく、何も書いていないのと同じ。
遭難している。これでは丸1日会議やっても何も進まない。
「間違い」と「意識混濁」は次元が違うのよ。
なかなか厳しいなぁ。(;´・ω・`)
まあ、進めようと思えば、
(´・ω・`)「貴方はこういうことが言いたいんですよね」
と僕からフォローすることで進めることも可能なんだけど、こんなことを繰り返しておっては相手の顔が潰れるでな。(;´・ω・`)
会議の場まで出てきちゃう前に気付いてフォローしてあげたいんだけど、
この手のドキュメントは「執筆途中」にも見えるのよね。
執筆中のドキュメントを指してNGを出すのは失礼だし。
相手の脳内を読むのが難しい。(;´・ω・`)
かつ、後追いで仕様書も作られているので、その読み合わせを行った。
その仕様書も完成していなんだけど、一応の区切りの段階だということで見せて貰ったが……。
やっぱ、特に明確に拠り所となる資料が不足した空中戦だから人に依って理解度に差が出てるね。(´・ω・`)
同じ間違いでも、
- そこそこ理解した上で間違えている
- そもそも理解不足を放置したまま資料を書いている
これって全然違うもので、文面から伝わってくるんだよね。(;´・ω・`)
前者、「そこそこ理解した上で間違えている」のパターンだと、少なくともドキュメントの日本語は明確だし、本人の意識も鮮明なのよ。
だから、
( ゚Д゚)「ここでこういう条件でテーブルを検索します」
(´・ω・`)「あれ? その条件だと一意にならんような?」
( ゚Д゚)「えっ? そうでしたっけ?」
(´・ω・`)「ステータスが1であること、を条件に追加しないといけないような」
( ゚Д゚)「確かに、修正します」
って感じに、凸凹しつつも議論が進んでいくのよね。
修正箇所が多いか少ないか、程度の問題でしか無い。
無論、間違いは少ないに越したことは無いけど、間違いが2倍あれば2倍修正すれば終わる。
叩き台なんだから、どれだけ間違っていても構わん。
ゴールまでの道筋は見えている。
ヤバいのは後者「そもそも理解不足を放置したまま資料を書いている」で、
( ゚Д゚)「ここで取得します」
(´・ω・`)「何を取得するんでしょう?」
( ゚Д゚)「データベースを」
(´・ω・`)「テーブルはどれでしょう?」
( ゚Д゚)「えっと……。契約テーブル?」
(´・ω・`)「契約テーブルをどういう条件で検索するのでしょう?」
( ゚Д゚)「会員ID?」
(´・ω・`)「その会員IDはどこから出てきたものですか?」
( ゚Д゚)「えっと……」
(´・ω・`)「この処理は会員IDで検索するものではなく、ステータスが1であるものを全件取得するものだと思うんですよ」
( ゚Д゚)「確かに」
(´・ω・`)「だから、以降の処理はループ処理です。また、この処理は大量件数になる可能性があるので、負荷についても考慮しておく必要があって……」
って感じ。
本人の意識が混濁してるのよね。
だから資料も「取得する」とは書いているけど、「何をどこからどういう条件で取得する」とは書いてない。
混濁している部分は省略したり、ぼやかした表現にして、次の作業へ。
だからドキュメントの数は揃ってるんだけど、中身はどこから直せば良いのやら、という状況。
これは「間違っている」のではなく、何も書いていないのと同じ。
遭難している。これでは丸1日会議やっても何も進まない。
「間違い」と「意識混濁」は次元が違うのよ。
なかなか厳しいなぁ。(;´・ω・`)
まあ、進めようと思えば、
(´・ω・`)「貴方はこういうことが言いたいんですよね」
と僕からフォローすることで進めることも可能なんだけど、こんなことを繰り返しておっては相手の顔が潰れるでな。(;´・ω・`)
会議の場まで出てきちゃう前に気付いてフォローしてあげたいんだけど、
この手のドキュメントは「執筆途中」にも見えるのよね。
執筆中のドキュメントを指してNGを出すのは失礼だし。
相手の脳内を読むのが難しい。(;´・ω・`)
- 2020年6月16日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
余力
そろそろ余裕が出てきたな~。(´・ω・`)
まだやることは残っているけど、パワーが必要な作業は終わった。
今後は要件定義チームから資料が出され次第、中身をチェックして認識差異を修正していくわけだが、要件定義チームは忙しいみたいだから資料が出てくるのも遅いだろう。
ま、休憩フェーズや。
先週頑張って前倒ししたからな。
16:30だけど、もうハイボール飲んどる。
前半は電撃戦で自作業を前倒しで進め、後半は余力を持って優雅に過ごすのが僕のスタイルや。(´・ω・`)
まだやることは残っているけど、パワーが必要な作業は終わった。
今後は要件定義チームから資料が出され次第、中身をチェックして認識差異を修正していくわけだが、要件定義チームは忙しいみたいだから資料が出てくるのも遅いだろう。
ま、休憩フェーズや。
先週頑張って前倒ししたからな。
16:30だけど、もうハイボール飲んどる。
前半は電撃戦で自作業を前倒しで進め、後半は余力を持って優雅に過ごすのが僕のスタイルや。(´・ω・`)
- 2020年6月15日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
今日から頭脳労働
ふぃ~。(´・ω・`)
先週で肉体労働は終わらせたから、今日から頭脳労働に入れる予定だ。
と言うのも、IT業界にはITドカタという言葉があるくらい、肉体労働的な側面の強い仕事があるのよ。
例えば、このシステムってDBの項目で200~300、CSVの項目も200~300。
と、ただそれだけの処理でも、この項目数だと変数を定義したり、ゲットしてセットするだけでも凄い重労働で、手が腱鞘炎になるくらいキツい。(;´・ω・`)
が、そのようなパワー労働は先週で一通り終わったことだし、今日からはもうちょっと知的な頭脳労働に移行し、肉体負担は減らせることを期待したい。
今来ている話だと、日付だな。
僕が荒っぽく作ったバッチは、
なんだけど、来ている話を見ると、
に修正しなきゃいけないっぽい。
「っぽい」ってのは何かって言うと、上の話は値を取得する時の話でしょ?
「その日付項目は、いつどこで値をセットするんだ?」って話が来てない。
つまり、僕の所には情報が50%しか届いていないってことだ。
この話、取得処理の修正はSQLのWhere句を1つ増やすだけだから、修正は2分で終わる。
でも、取得処理だけ修正しても辻褄が合わんし、辻褄が合わんって事に気付いて、整理し、問い合わせしたり、チャットしたり、Web会議したり……、というのに時間を要する。
これが頭脳労働だ。
まあ、システム開発の正論を言えば、本来はその辺の辻褄合わせが終わってから実装に入るべきなんだけど、このプロジェクトは逆で、とにかく粗方の実装が終わってから、上記みたいな話が増えて修正していく、というスタイル。
とは言え、「修正」とは「Where句を1つ増やすこと」とかそういうレベルの話。
バッチ全体を修正しなきゃいけないような根こそぎの仕様変更にはならない、という程度の見通しがあるから見切り発車してるねん。
何とかなるやろ。
ともかく、肉体負荷は軽減の見通しや。
返事が来るまでの待ち時間も増えてくるだろう。
少しは楽したいのう。(´・ω・`)
先週で肉体労働は終わらせたから、今日から頭脳労働に入れる予定だ。
と言うのも、IT業界にはITドカタという言葉があるくらい、肉体労働的な側面の強い仕事があるのよ。
例えば、このシステムってDBの項目で200~300、CSVの項目も200~300。
- CSVから値を取得し、DBにセットする。
と、ただそれだけの処理でも、この項目数だと変数を定義したり、ゲットしてセットするだけでも凄い重労働で、手が腱鞘炎になるくらいキツい。(;´・ω・`)
が、そのようなパワー労働は先週で一通り終わったことだし、今日からはもうちょっと知的な頭脳労働に移行し、肉体負担は減らせることを期待したい。
今来ている話だと、日付だな。
僕が荒っぽく作ったバッチは、
- フラグが1であるものを更新する。
なんだけど、来ている話を見ると、
- フラグが1であり、かつ日付が過去であるものを更新する。
に修正しなきゃいけないっぽい。
「っぽい」ってのは何かって言うと、上の話は値を取得する時の話でしょ?
「その日付項目は、いつどこで値をセットするんだ?」って話が来てない。
つまり、僕の所には情報が50%しか届いていないってことだ。
この話、取得処理の修正はSQLのWhere句を1つ増やすだけだから、修正は2分で終わる。
でも、取得処理だけ修正しても辻褄が合わんし、辻褄が合わんって事に気付いて、整理し、問い合わせしたり、チャットしたり、Web会議したり……、というのに時間を要する。
これが頭脳労働だ。
まあ、システム開発の正論を言えば、本来はその辺の辻褄合わせが終わってから実装に入るべきなんだけど、このプロジェクトは逆で、とにかく粗方の実装が終わってから、上記みたいな話が増えて修正していく、というスタイル。
とは言え、「修正」とは「Where句を1つ増やすこと」とかそういうレベルの話。
バッチ全体を修正しなきゃいけないような根こそぎの仕様変更にはならない、という程度の見通しがあるから見切り発車してるねん。
何とかなるやろ。
ともかく、肉体負荷は軽減の見通しや。
返事が来るまでの待ち時間も増えてくるだろう。
少しは楽したいのう。(´・ω・`)
- 2020年6月13日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
但し書き
仕様書
バカヤロ~。
それは入力必須項目とは言わんのや。(´・ω・`)
それに、「契約が成立していない時」は契約日なんて入力禁止ちゃうんか?
「入力禁止」と「必須ではない」をゴッチャにすんな。(´・ω・`)
そもそも、「但し」って何や? 「但し」なんて言葉はシステムに存在せんのや。
- 契約日:入力必須項目。但し、契約が成立していない時は必須ではない。
バカヤロ~。
それは入力必須項目とは言わんのや。(´・ω・`)
それに、「契約が成立していない時」は契約日なんて入力禁止ちゃうんか?
「入力禁止」と「必須ではない」をゴッチャにすんな。(´・ω・`)
そもそも、「但し」って何や? 「但し」なんて言葉はシステムに存在せんのや。
- 契約日:①契約済の場合、入力必須とする。②未契約の場合、入力禁止とする。
と書かんかい。
システムはif else if else で成り立ってるってことが骨身で分かってないからこんな日本語を使うことになるんや。
システム抜きでも普通にこの方が分かり易いやろ。
日本語どうなっとるんや。
あと、条件に応じてCSVの構成が微妙に変わるのは、それはフォーマットが2つあるのと同じや。
殆どの項目が重複しているからと言って、2つあるフォーマットを1つの表で書くのはやめろ。(´・ω・`)
システムはif else if else で成り立ってるってことが骨身で分かってないからこんな日本語を使うことになるんや。
システム抜きでも普通にこの方が分かり易いやろ。
日本語どうなっとるんや。
あと、条件に応じてCSVの構成が微妙に変わるのは、それはフォーマットが2つあるのと同じや。
殆どの項目が重複しているからと言って、2つあるフォーマットを1つの表で書くのはやめろ。(´・ω・`)
- 2020年6月12日金曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
インターフェース不足
とりあえず出来る範囲でざ~っと作成したが、ここから先は仕様の様子を伺ってみないと作り辛いなぁ。(´・ω・`)
一番痛いのが、連結先システムのインターフェースが空っぽであること。
例えば、この会員の住所をAPI通信で取得する。
一番痛いのが、連結先システムのインターフェースが空っぽであること。
例えば、この会員の住所をAPI通信で取得する。
- 都道府県
- 市区町村
- 番地
- ビル名等
これらをAPI通信で取得する。
そういうAPIが存在するってことは資料見れば分かるんだけど、物理名とか全然無いやんけ。
どういう構造のXMLで届くのか、そこが空っぽなのよ。
XMLパラメータが「ken」だったら、こっちのソースの変数名も「ken」、というように物理名を一致させなきゃいけない部分だから、そこが無いと仮実装にも限界がある。
何で無いかと言うと、他チームの方はDBスキーマすら作ってないから。
そりゃ先に会員住所テーブルを定義して、それと一致する命名でAPIを作るに決まってるんだから、DB設計も未着手なのにAPIインターフェースなんか定義出来るわけないわな。(´・ω・`)
とまあ、こんな感じで、ひとまず一端ピークは越えたかな?
仕様が決まるか、他チームの作業が進むか、それが無いと僕もやりようが無いって状況だから、何かあれば作業し、無ければ待ち状態。
少し待ってから「急いでやってくれ!!」みたいな話が来る、の繰り返しで固めていくような進行になりそうである。
ともかく土日はゆっくりするか。(´・ω・`)
- 2020年6月11日木曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
23時
突貫工事していたらもう23時か。(; ・`д・´)
これ以上は明日の集中力に支障が出る。
明日に備えて寝なければ。(; ・`д・´)
これ以上は明日の集中力に支障が出る。
明日に備えて寝なければ。(; ・`д・´)
- 2020年6月10日水曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
仮実装
ひとまず、僕の理解で仮実装を進行中。
「仮実装」って何なのかと言うと、例えば、DBのその項目が一意キーかどうか分かんないんだよね。(; ・`д・´)
そういう時は周囲の雰囲気で推し量る。
(´・ω・`)「知らんけど、ネーミングセンスが『管理ID』なんだから、一意キーとして使われるイメージとちゃうんか?」
くらいの僕の感覚でとりあえず進めていく。
これが「仮実装」だ。
その間にマネージャー率いる仕様策定チームで細かいことを調査して貰って、
( ゚Д゚)「いや、管理IDだけでは一意にならん。『ステータスが有効であること』を付け加えて一意になる」
ということが判明したら、その部分を修正する。
仕様策定チームの調査が間に合った範囲で終わらせるのが6月20日という目標である。
だから、修正する時に修正し易いよう実装しなきゃいけないんだよね。
どこを修正することになるかは分からんけど。
分からんけど、機能を部品化するとか、パラメータを外部定義するとか、そういうのを念入れてやっておけば、大体はカバー出来るんとちゃうか?
みたいな。
まあ、嗅覚として、このシステムは「えっ? そんな仕様があるの!?」みたいな部分は少なそうに見えるから、たぶんそれなりに着地可能なんじゃないかって感じ。
そんな感じで進行。
何だかんだでエンジニアには勘ってものがあって、「見えてないけど、自分達の勘は概ね正しそうだ」みたいな感覚はチームの総意としてあるのよ。
この勘が成り立つのは、結局は小規模だからだな。
僕と若い衆の2人しかプログラマーがおらん。
ITプロジェクトの難易度って、結局は規模で決まっちゃう所があって、小規模だったらこんな進行でも何とかなるのよ。
マネージメントだの開発モデルだの、そういうのは大きいプロジェクトを何とか纏めようと苦心する話であって、小規模プロジェクトは小手先のマネージメントよりもプログラマーゴリ押しの方が圧倒的に強い。
泥仕合に強いヤツが強いのが現実。
勘で冒険してバッタバタで解決。
IT業界のインディ=ジョーンズ。(; ・`д・´)
「仮実装」って何なのかと言うと、例えば、DBのその項目が一意キーかどうか分かんないんだよね。(; ・`д・´)
そういう時は周囲の雰囲気で推し量る。
(´・ω・`)「知らんけど、ネーミングセンスが『管理ID』なんだから、一意キーとして使われるイメージとちゃうんか?」
くらいの僕の感覚でとりあえず進めていく。
これが「仮実装」だ。
その間にマネージャー率いる仕様策定チームで細かいことを調査して貰って、
( ゚Д゚)「いや、管理IDだけでは一意にならん。『ステータスが有効であること』を付け加えて一意になる」
ということが判明したら、その部分を修正する。
仕様策定チームの調査が間に合った範囲で終わらせるのが6月20日という目標である。
だから、修正する時に修正し易いよう実装しなきゃいけないんだよね。
どこを修正することになるかは分からんけど。
分からんけど、機能を部品化するとか、パラメータを外部定義するとか、そういうのを念入れてやっておけば、大体はカバー出来るんとちゃうか?
みたいな。
まあ、嗅覚として、このシステムは「えっ? そんな仕様があるの!?」みたいな部分は少なそうに見えるから、たぶんそれなりに着地可能なんじゃないかって感じ。
そんな感じで進行。
何だかんだでエンジニアには勘ってものがあって、「見えてないけど、自分達の勘は概ね正しそうだ」みたいな感覚はチームの総意としてあるのよ。
この勘が成り立つのは、結局は小規模だからだな。
僕と若い衆の2人しかプログラマーがおらん。
ITプロジェクトの難易度って、結局は規模で決まっちゃう所があって、小規模だったらこんな進行でも何とかなるのよ。
マネージメントだの開発モデルだの、そういうのは大きいプロジェクトを何とか纏めようと苦心する話であって、小規模プロジェクトは小手先のマネージメントよりもプログラマーゴリ押しの方が圧倒的に強い。
泥仕合に強いヤツが強いのが現実。
勘で冒険してバッタバタで解決。
IT業界のインディ=ジョーンズ。(; ・`д・´)
- 2020年6月9日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
とんでもナス
しかし、聞けば聞くほど、このプロジェクトはとんでもねぇなぁ。
何か、6月20日までに実装を終わらせて欲しいって言われているんだけど、現時点で仕様未確定。
ドキュメントも打ち合わせで使った資料が転がっている程度。
残る期間はあと10日。
無理やろ。(;´・ω・`)
たぶん、締め切りである6月20日の時点でもまだ要件定まってない。
まあ、その辺は皆まで言わずとも汲んでやるのがエンジニアの人情っつーもので、要件も決まって無ければ資料も足らんのは承知の上で、分かる範囲で作っておいてくれ、と。
例えば、「ファイルのFTP送信バッチが必要」というキーワードさえ聞いていれば、
みたいなものは分からなくても送信機構自体は作れるし、分からない部分も判明した際に修正し易いように実装しておいて欲しい。
csvファイル処理も、csvファイルフォーマットがどこまで正しいか怪しいんだけど、少なくとも主キーとなる項目だけは分かれば、作れる部分も多いだろう。
そんなくらいの温度感で「6月20日までに実装を終わらせて欲しい」という話だ。
「何を以て完了と定義するのか?」は敢えてハッキリ決めず、マネージャーと僕の阿吽の呼吸を上手く合わせて乗り切っていく、というニュアンスで暗に合意して進行。
とんでもねぇなぁ。(;´・ω・`)
まあ、どこまでとんでもなくても、所詮は小規模プロジェクトだから、凸凹していても最終的には押し込める見通しなんだよね。
やったるっきゃないな。(´・ω・`)
何か、6月20日までに実装を終わらせて欲しいって言われているんだけど、現時点で仕様未確定。
ドキュメントも打ち合わせで使った資料が転がっている程度。
残る期間はあと10日。
無理やろ。(;´・ω・`)
たぶん、締め切りである6月20日の時点でもまだ要件定まってない。
まあ、その辺は皆まで言わずとも汲んでやるのがエンジニアの人情っつーもので、要件も決まって無ければ資料も足らんのは承知の上で、分かる範囲で作っておいてくれ、と。
例えば、「ファイルのFTP送信バッチが必要」というキーワードさえ聞いていれば、
- その送信先サーバはどこにあるのか?
- サーバ内のどのパスにファイルを置いて欲しいのか?
- 送る際のファイルの命名規則は?
みたいなものは分からなくても送信機構自体は作れるし、分からない部分も判明した際に修正し易いように実装しておいて欲しい。
csvファイル処理も、csvファイルフォーマットがどこまで正しいか怪しいんだけど、少なくとも主キーとなる項目だけは分かれば、作れる部分も多いだろう。
そんなくらいの温度感で「6月20日までに実装を終わらせて欲しい」という話だ。
「何を以て完了と定義するのか?」は敢えてハッキリ決めず、マネージャーと僕の阿吽の呼吸を上手く合わせて乗り切っていく、というニュアンスで暗に合意して進行。
とんでもねぇなぁ。(;´・ω・`)
まあ、どこまでとんでもなくても、所詮は小規模プロジェクトだから、凸凹していても最終的には押し込める見通しなんだよね。
やったるっきゃないな。(´・ω・`)
- 2020年6月8日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
Webデザイナー募集
この現場、Webデザインまで僕の双肩に掛ってきておるぞ。(;´・ω・`)
僕はBootStrapを忠実に使っているだけでしかなく、BootStrapの範囲を超えたものは専門外なのだが。(;´・ω・`)
何とかやってみるが、一般ユーザにウケるかどうかは知らん。(;´・ω・`)
僕はBootStrapを忠実に使っているだけでしかなく、BootStrapの範囲を超えたものは専門外なのだが。(;´・ω・`)
何とかやってみるが、一般ユーザにウケるかどうかは知らん。(;´・ω・`)
- 2020年6月7日日曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
休息徹底
今週は平日が突貫工事、休日も家事で激忙しだったな。(;´・ω・`)
日曜日の今日も午前中は市場に大量買い出しに行ってきたが、午後は余暇と言える時間になった。
さて、余暇の時間を使って仕事を少しでも前倒し……とも思ったが、自分の体調を考えると明らかに疲れていた。
その為、午後は睡眠として、物理的な体力回復に努めた。
お陰で随分楽になった。
平日に高い集中力と反射神経を出せるよう、体調管理も重要な仕事だからな。
本当はイラストの練習もしたかったんだけど、あれも非常に集中力を消費してしまうからな。
プロジェクトの前半のうちに頑張っておけば、後半は時間が余るだろうから、その時間でイラストの練習も出来るだろう。
とにかく、前半である今は電撃戦が第一。
スピーディーに行動することの価値がモノを言うタイミングだ。
とは言え、流石に次の一週間で落ち着くだろう。
どうせ他の人間がボトルネックになるに決まっているんだから。
ボトルネックという名の罪を他人に擦り付ける為にも、今ここで頑張らなアカンのや。
世の中は先行している人間が正義や。(´・ω・`)
日曜日の今日も午前中は市場に大量買い出しに行ってきたが、午後は余暇と言える時間になった。
さて、余暇の時間を使って仕事を少しでも前倒し……とも思ったが、自分の体調を考えると明らかに疲れていた。
その為、午後は睡眠として、物理的な体力回復に努めた。
お陰で随分楽になった。
平日に高い集中力と反射神経を出せるよう、体調管理も重要な仕事だからな。
本当はイラストの練習もしたかったんだけど、あれも非常に集中力を消費してしまうからな。
プロジェクトの前半のうちに頑張っておけば、後半は時間が余るだろうから、その時間でイラストの練習も出来るだろう。
とにかく、前半である今は電撃戦が第一。
スピーディーに行動することの価値がモノを言うタイミングだ。
とは言え、流石に次の一週間で落ち着くだろう。
どうせ他の人間がボトルネックになるに決まっているんだから。
ボトルネックという名の罪を他人に擦り付ける為にも、今ここで頑張らなアカンのや。
世の中は先行している人間が正義や。(´・ω・`)
- 2020年6月6日土曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
総菜製造
明日は業務用スーパーに買い出しに行く予定でのう。
今日のうちに冷蔵庫内に残っている食材を総菜化して綺麗にした方が良いから頑張ったわい。(´・ω・`)
日持ちがするようなメニューにしなければならんな。
今日のうちに冷蔵庫内に残っている食材を総菜化して綺麗にした方が良いから頑張ったわい。(´・ω・`)
日持ちがするようなメニューにしなければならんな。
- 2020年6月5日金曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ビルドアップ崩し
やれやれ。今週ず~っと突貫工事を頑張ったおかげて、何とかプロジェクトが形になったわい。一段落や。(´・ω・`)
これで若い衆の動員が可能となる。
やっぱりソースの品質って初動で決まるよね。
最初のソースが「サンプル」みたいな状態で若い衆を動員するとグジャグジャになってしまう。
最初にバシッと「これしかない!!」という万全の状態にすれば、後から若い衆が来ても右に倣えで自然と良い感じになってくれるものなのよ。
難しいのは、
と、敢えて崩しを入れる温度感だな。
全域が原理原則主義だと、ソース管理が凄く煩雑になってしまう。
小規模プロジェクトであることを踏まえると、原理原則を少し崩した方が生産性が上がる局面もあるから、そういうのを僕が見極めてデザイン。
実装は美的センスみたいなものも大きいからね。
作り込みが大変だったが、出来上がったこれは中々美しいと思う。
さて、これで一段落着いたし、土日はゆっくりと休みたい……んだけど、雇い主の社長は土日も働いていることが多いからなぁ。
偶にチャット見て新情報があって対応することがあれば土日もやるか。
臨機応変と荒業の極地。(´・ω・`)
まあ、とにかくプロジェクトは立ち上がりが勝負だからな。
もし余裕が生まれるようであれば、プロジェクト終盤に休みを取れるように頑張りたい。(´・ω・`)
これで若い衆の動員が可能となる。
やっぱりソースの品質って初動で決まるよね。
最初のソースが「サンプル」みたいな状態で若い衆を動員するとグジャグジャになってしまう。
最初にバシッと「これしかない!!」という万全の状態にすれば、後から若い衆が来ても右に倣えで自然と良い感じになってくれるものなのよ。
難しいのは、
- ソースを共有するべきもの
- 同じ処理でもコピペで増殖しておいた方が良いもの
と、敢えて崩しを入れる温度感だな。
全域が原理原則主義だと、ソース管理が凄く煩雑になってしまう。
小規模プロジェクトであることを踏まえると、原理原則を少し崩した方が生産性が上がる局面もあるから、そういうのを僕が見極めてデザイン。
実装は美的センスみたいなものも大きいからね。
作り込みが大変だったが、出来上がったこれは中々美しいと思う。
さて、これで一段落着いたし、土日はゆっくりと休みたい……んだけど、雇い主の社長は土日も働いていることが多いからなぁ。
偶にチャット見て新情報があって対応することがあれば土日もやるか。
臨機応変と荒業の極地。(´・ω・`)
まあ、とにかくプロジェクトは立ち上がりが勝負だからな。
もし余裕が生まれるようであれば、プロジェクト終盤に休みを取れるように頑張りたい。(´・ω・`)
- 2020年6月3日水曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
突貫工事
プロジェクトソースの土台部分の構築を急いでいる。(;´・ω・`)
どんなプロジェクトでもここだけは完璧を期さないと。
正直、DBに「1」って入って欲しいところに「0」って入っちゃってるとか、そういうのは最後までバタバタしていると思う。(;´^ω^`)
しかし、土台が腐ってるとバグを直すことも碌に出来なくなっちまうからな。
「処理階層」という概念を持ってないヤツが最初に実装を始めてしまうと、
(´・ω・`)「このソースって、ローカルDBとAPI通信先の整合性と取らないと動かせないんですよ」
(´・ω・`)「だからバグを調査するにも、まずAPI通信先をバグが再現する条件を満たして貰った状態にしてからじゃないと、ローカル環境をバグが再現する状態にできない」
(´・ω・`)「1コしか無い検証環境のAPI通信先をバグらせるので、一端みんなに作業を止めて貰うよう時間調整を……」
とか、こんなことになったらマジ何ともならんからな!!
今、僕がやっているのは、そういう切り分けだな。
みたいなデザインを頑張っている。
ここだけは技術力がモノを言うから、何としても今、ここで僕が頑張らねば。
ここさえ乗り切ってしまえば、後は物量戦や人海戦術の世界に倒せる。
頑張り時や。(´・ω・`)
どんなプロジェクトでもここだけは完璧を期さないと。
正直、DBに「1」って入って欲しいところに「0」って入っちゃってるとか、そういうのは最後までバタバタしていると思う。(;´^ω^`)
しかし、土台が腐ってるとバグを直すことも碌に出来なくなっちまうからな。
- API通信する処理はクラスを切り離す、とか。
- ファイル読み込み処理はクラスを切り離す、とか。
「処理階層」という概念を持ってないヤツが最初に実装を始めてしまうと、
(´・ω・`)「このソースって、ローカルDBとAPI通信先の整合性と取らないと動かせないんですよ」
(´・ω・`)「だからバグを調査するにも、まずAPI通信先をバグが再現する条件を満たして貰った状態にしてからじゃないと、ローカル環境をバグが再現する状態にできない」
(´・ω・`)「1コしか無い検証環境のAPI通信先をバグらせるので、一端みんなに作業を止めて貰うよう時間調整を……」
とか、こんなことになったらマジ何ともならんからな!!
今、僕がやっているのは、そういう切り分けだな。
- この処理はクラスを別にする。
- この処理は役割をパッケージに移動。
- こういう処理はJavaで頑張り、こういう処理はSQLで頑張る。
みたいなデザインを頑張っている。
ここだけは技術力がモノを言うから、何としても今、ここで僕が頑張らねば。
ここさえ乗り切ってしまえば、後は物量戦や人海戦術の世界に倒せる。
頑張り時や。(´・ω・`)
- 2020年6月2日火曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
ハイパー本気モード
昨日から着手した新案件なんだけど、これアカン。(; ・`д・´)
7月末リリースと聞いているけど、納期が2倍足りない。(; ・`д・´)
僕が所属しているチームって、
みたいな構成なのよ。
若い衆は状況に気付いてないやろ。(; ・`д・´)
ヤバいで、これは。(; ・`д・´)
マネージャーには政治的な調整や要件の取り纏めでプロジェクトの土台を整えて貰うとしても、開発班の手が全然足らない。
率直に言うと、僕が大慌てで実装し、若い衆で結合テストを半分終わった程度でリリースとなりかねない勢い。
テストする時間が無いから、最初からバグってない状態で実装頑張って欲しい、とかそんなレベル。
軽微なバグは目を瞑るから、クリティカルなバグは出さないように上手い事やるという嗅覚のプロジェクトになると思う。
何にせよ、ヤバいで、これは。(; ・`д・´)
実装担当の僕としては、早い所ソースの土台を整えないと。
「システムエラーで落ちない」って程度はやりきれると思うけど、DBのカラムに入れるパラメータの値までは見切れん。
落ちないことだけ確認して、細かいことはテストチームに丸投げ。
そんな感じになる。(; ・`д・´)
久々の本気モード。(; ・`д・´)
7月末リリースと聞いているけど、納期が2倍足りない。(; ・`д・´)
僕が所属しているチームって、
- ( ゚Д゚):マネージャー。40代
- (´・ω・`):ウズ。37歳
- ('ω'):若い衆
- (*^▽^*):若い衆
- (#^.^#):若い衆
みたいな構成なのよ。
若い衆は状況に気付いてないやろ。(; ・`д・´)
ヤバいで、これは。(; ・`д・´)
マネージャーには政治的な調整や要件の取り纏めでプロジェクトの土台を整えて貰うとしても、開発班の手が全然足らない。
率直に言うと、僕が大慌てで実装し、若い衆で結合テストを半分終わった程度でリリースとなりかねない勢い。
テストする時間が無いから、最初からバグってない状態で実装頑張って欲しい、とかそんなレベル。
軽微なバグは目を瞑るから、クリティカルなバグは出さないように上手い事やるという嗅覚のプロジェクトになると思う。
何にせよ、ヤバいで、これは。(; ・`д・´)
実装担当の僕としては、早い所ソースの土台を整えないと。
「システムエラーで落ちない」って程度はやりきれると思うけど、DBのカラムに入れるパラメータの値までは見切れん。
落ちないことだけ確認して、細かいことはテストチームに丸投げ。
そんな感じになる。(; ・`д・´)
久々の本気モード。(; ・`д・´)
- 2020年6月1日月曜日
ウズマスターの日々
http://bloggerspice.appspot.com/postimage/https://blog.uzumax.org/2018/06/blog-post_38.html
前職社長から電話
社長から電話が!!(; ・`д・´)
まあ、今日の午前中付けで社長宅に祝電を贈ったから、そのお礼なんだけどね。
「今までお疲れ様でした」、と。
喜んでた。
やれやれ、上手くいって良かったわい。
社長が退任した直後の5月に送ったのではバタバタしているだろう、1ヵ月経てば気持ちも落ち着いているのではないか、と考えてこのタイミングの祝電決行とした。
ただ、引継ぎが上手く回って無くて、6月になってもまだゴタゴタの真っ最中という可能性も十分あると懸念していたが。(;´・ω・`)
まあ、電話の様子だと心穏やかな雰囲気だったし、杞憂だったようだ。
もう社長はこれで人生上がりか。
お疲れ様でしたお。(´・ω・`)
78歳まで続けた会社経営も最後はガタガタだったからな。
晩節を汚したってのが実態なんだけど、そんなバッドエンドをされては僕の方が鬱になる。
だから元社員の僕から花と感謝の手紙を贈って、「有終の美を飾った」という体裁が整えたった。
これで「(会社の経営はボロボロかもしれんが)縁のあった人間は社長に感謝しているから、社長の経営者人生は意味のあるものだった」と言う為の名目が立つやろ。
これが僕の思いやりや。(´・ω・`)
まあ、今日の午前中付けで社長宅に祝電を贈ったから、そのお礼なんだけどね。
「今までお疲れ様でした」、と。
喜んでた。
やれやれ、上手くいって良かったわい。
社長が退任した直後の5月に送ったのではバタバタしているだろう、1ヵ月経てば気持ちも落ち着いているのではないか、と考えてこのタイミングの祝電決行とした。
ただ、引継ぎが上手く回って無くて、6月になってもまだゴタゴタの真っ最中という可能性も十分あると懸念していたが。(;´・ω・`)
まあ、電話の様子だと心穏やかな雰囲気だったし、杞憂だったようだ。
もう社長はこれで人生上がりか。
お疲れ様でしたお。(´・ω・`)
78歳まで続けた会社経営も最後はガタガタだったからな。
晩節を汚したってのが実態なんだけど、そんなバッドエンドをされては僕の方が鬱になる。
だから元社員の僕から花と感謝の手紙を贈って、「有終の美を飾った」という体裁が整えたった。
これで「(会社の経営はボロボロかもしれんが)縁のあった人間は社長に感謝しているから、社長の経営者人生は意味のあるものだった」と言う為の名目が立つやろ。
これが僕の思いやりや。(´・ω・`)
登録:
投稿 (Atom)