ITの隊長のブログ

ITの隊長のブログです。Rubyを使って仕事しています。最近も色々やっているお(^ω^ = ^ω^)

依頼者と作業者の気持ちを理解する

ひさびさにブログ書く

出来事の学び(個人的なまとめ)

  • アンガーマネジメントを学びたくなった
  • 依頼者・作業者それぞれを経験して気持ちを理解したい
  • 大変なときこそ共有しよう。って気持ちになった

最近家を建てようとしている

無事住宅ローンも降りて、間取りはあーで、オプションはこーで、外構工事はそーで、ってやりとりを数ヶ月続けてると事件はおきた。

「すみません、、、ここのこの見積もりまだ高くなりそうで。。。」

ぼくらとしては「えーっ!なんでいまさら???」である。

それから週が立つごとに、見積もりがあがるー。オプションできんかもー。と連絡がある一方で、土地を定期的に見に行くとなんと工事が開始しているようにみえる。なぬ???って思って担当へ電話かけると「はじまっていますね。。。」とのこと

見積もり決まっていないのに工事は始まるのか????といろいろと不安になる状況となった。

そして、よくわからんから見積もりでき次第、場を設けて説明をもらおうかと夫婦でお願いしようと考えてたところ、なんとまた見積もりが〜の連絡である。

さすがに僕もピキピキ(#^ω^)となったが、その隣で妻がもっと怒ってたのでクールダウンした。

それからはお互い睡眠を削って、妻のイライラを聞くだけの旦那となっている状態で、半額セールで購入したつまみのワカメを半分も食べることができずその日は終戦した。

これは消費者庁案件では????とか、詐欺では????とか、担当者なにやっているのかー????とか色々と話したと思う。

ただ、ここまでぼくらはまだ担当者に確認はしていないので、すべて想像でのイライラなのである。っていうことをあとから思い出したら面白くなったので記しておく。

ネタバレすると、結果担当者とは話し合えて、且つ説明ももらい、色々と丸く収まったんですが、その怒りのままメールしてたらどうなってたのか。と想像すると肝が冷える。多分余計な仕事をふやしていたんじゃなかろうかなーって思った。

こういうときは、「なんでぼくらはイライラするのか」を文章にすると良い。今回の場合は「見積もりがあとから上がるのはなぜ?」と、「確定していないのに工事が始まっているのはなぜ?」である。メインテーマみたいなイライラする原因の言語化が済んだらあとは質問を並べれば良い。それをメールだったり、チャットだったり、はたまた対面だったりの質問リストして返答次第では納得できるのかできないのかはその時考えてやればいいよな。って気持ちになった。

こういうのってなんかあったよなー?とか思って、ちょっと調べたら「アンガーマネジメント」だった

こういうルールでやるのかわからないが、とりあえず「怒り」をぶつけても建設的になりづらいみたいな話は記憶しており、やっぱり落ち着いてまとめてから臨んだほうがいいよなって気持ちになった。

妻も最初はガチギレだったが、日が立ち打ち合わせ前までにはだいぶ落ち着いていたので、結果よかったなと思った。

依頼者・作業者側の気持ちを理解する

全然話違うけど、今年はプロジェクトを燃やしてしまい、その火中でめっちゃ仕事しました。いい感じの結果にはなったなと思っていますが、それに対しての工数やヘルプ、また妻へのダメージ(ワンオペを長らくお願いしてしまった)ので、とてつも猛省をしています。

家を立ててもらう側としては、発注者なので、「どうしてこうなったのか」を今回問いましたが、そういえば数ヶ月前は「どうしてこうなったのか」を逆に言われる方だったな。と思いました。

で、そう思われる共通点がいくつかあって、「なぜそうなったのか」が伝わっていないのが問題なんだろうなって思いました。

火中の人は急ぎ終わらせないと色々なことに迷惑がかかる、または遅れてしまうということになっているので、気が気でない状況になっています(少なくとも僕がそうだった)。ただ、ヘルプするにも状況を理解するにも情報が伝わらないため、周りの人や発注者はなかなか理解できず、下手するとクレームにつながっちゃうなって思いました。

これまた、たまたまの飲み会にて多くのプロジェクトマネージャーを務める人と話しになったのですが、コツは「全部伝える」って言っていました。↑の背景もあり、個人的なこれまでの経験もあり「なるほどなー」と思い、「ストーン!!!」って音が聞こえる感じで腑に落ち、納得しました。

自分で手を動かしているとなかなか発注側の気持ちを考える余裕があんまりないなーと思いつつ、意識はしたいが、やっぱりだめそうだってなりそうな場合に誰かに進捗を管理してもらうのでもいいなと思いました。進捗を伝えるということはプロジェクトの「背景」と「ゴール」があって、それが「いつ」完了するのか、また今は「誰」が「どこ」にいるのかを伝えないといけないので、依頼者へ自分から伝えるというよりは、誰か別の人へすべて共有を行い(それが壁打ちになるはず)、その上で依頼者へ説明する。のほうが準備もできてわかりやすいのかなって思いました。

大変なときこと、こういうことやらないと振り返ることもできないので(バタバタし続けて結果間に合いませんでしたーを繰り返すと地獄)頑張りましょう(戒め)

また、逆に僕がヘルプする側だとして、「多分、作業者は余裕がないだろうな」ってことを想像して、怒りはありつつも建設的に話し合えるように、「なぜイライラ・モヤモヤしているのか」を書き出して、共有すると良いなと思った。あとテキストだと圧が強くなりそうで、余計にプレッシャーかけるだろうから、対面だったり電話だったりをあとからテキストでログ残しする。が良いだろうなって思いました。

Railsで悲しみのmigrateエラー

$ rails db:migrate

と、実行すると

Caused by:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
...

に、悩まされていましたが、マイグレーションファイルを作ったときに

20240601110111_${テーブル名}.rb

こういうファイル名でした。

色々中身ガチャガチャしてもうわからん!!!!ってなったときに、ファイル名他と違くない?ってなったので

20240601110111_add_${テーブル名}.rb

こうしてみたらできました。1時間。。。。。

RSpecのmatcherについて軽いメモ

雑メモです。

あるモデルにデータを追加したか確認するテスト

expect { subject }.to change { ModelA.count }

変更しているなら change でおk

もし、変更なしを確認したい場合は、 not_change を用意すると良い

RSpec::Matchers.define_negated_matcher :not_change, :change

zenn.dev

subjectがExceptionを返すので検証できない

実際はExceptionが発生する前にデータを追加しているが、テスト時にはExceptionで落ちるので確認できない

なので、andで繋げてあげる

expect { subject }.to raise_error(HogeHogeException).and change { ModelA.count }

おk

qiita.com

PHPカンファレンス沖縄2023に参加&登壇しました

登壇資料はこれ

speakerdeck.com

様子はこれ

togetter.com

ぼくの発表の様子はこれ

なんでコスプレしたの?

  • 今回のイベントは結局ギュッとタイムテーブル組んでいるのを事前に知ってた & カンファレンスで聞く方は結構疲れる(色々学びになり楽しいんだけど)と思うので、合間になんかこう、目が覚めるようなことをやろうかなって考えてました
  • ちょうど沖縄だし、僕の発表は琉球だし(?)、僕はチョンダラーだし、ということでチョンダラーになりました
  • 当日、緊張もあって全く説明もせずWordPressの話をしたので、僕のことを全く知らない人たちはほぼ確定で「あいつなんなんだ・・・・?」ということになっていると思うので、今更ながらこのブログで補足させてください。はい
  • そもそもチョンダラーってなんですか?そうだね

kotobank.jp

  • 僕の出身の島では(というか沖縄本島全域で)、若い青年さんたちが地元で集まってエイサーを踊る会というものがあり、僕は 半強制的に 所属していたので、チョンダラーの経験がございます
  • ちなみに変身するために化粧道具を急いで買いに行ったんですが、中部にしかないだろうなーと思ってましたが、なんと那覇にありました。チョンダラーになりたい人はぜひ(?)

www.ryukyujima.net

発表内容について

  • 実は最近そんなにWordPressに触れてはいないのですが、去年ぐらいまでは1 ~ 3回/年ぐらい「助けて〜」をもらっていました
  • なので、年々やられたWordPressを掃除する力はついていき、せっかくだから発表しちゃえ〜が今回でした
    • あと5年早ければCakePHPの話とかしたかったな。最近は全くキャッチアップしていませんが
  • 久々に最近のWordPressの情報をキャッチアップしたり、コミュニティやスクールを過去開いてた人にインタビューしたりなど、やっぱりWordPressは手っ取り早く公開できるので、兎にも角にもビジネスするにはさっさとリリースすることを行う分にはとても良いですが、運用し続ける必要があり、できないとセキュリティリスクがあるので、ちゃんと運用できないとあかんな〜と 戒めました 思いました

感想

楽しかった!!!!!!!!!!!!!!

いつもだいたい直前まで資料作成に追われていましたが、今回は80%ぐらい準備できてたので、他の方の発表がみれたので満足してます(といっても、変身の準備があったのでやっぱりがっつり見ることはできなかった)

この方の発表が個人的にはよかった(もちろん比べることではないので他の方々もよかったです!)

自分の発表の感想は、いつもお世話になっている知り合いさんや妻もYoutube Liveで見てたらしいんですが、揃って「早口すぎ」って言われました。。。もっと発表上手になりたい。。。

また、X(旧Twitter)上で知っている人、過去購入して勉強させてもらった技術書の著者さんたちが何名かいらっしゃって、そういう意味でだいぶお世話になった人たちや、前職の方々の知り合いだったり、互いに初めてお会いした方々と懇親会で技術の話でワイワイしたりなどなど、いろーんな人たちと関われたのでとても楽しかったです!

あと、過去のブログ記事を読んでくれていた人がいて、ちと恥ずかしい気持ちを顔に出してましたが、内心とても嬉しかったです。プログラマになって本当よかった〜〜〜〜〜〜〜〜って気持ちになりました

企画やイベント運営してくれた主催者さんたちに感謝感激&お疲れ様でした!

来年は県外のPHPカンファレンスにも参加したいな〜〜〜〜〜〜と思ったのと、個人的にはPHPに関しての弾がなくなったので、次回はスタッフでの参加で運営お手伝いしようかなと思いました

「エンジニアのためのドキュメントライティング」読書メモ

ドキュメントの書き方とか見やすさのテクニックなのかなと思い読み進めていましたが、ペルソナとかカスタマージャーニーマップとかでてくるので、なるほど???って気持ちになりました。ドキュメントの読み手の調査をしっかり行うことであったり、ドキュメントを持って適切にプロダクトを操作、やりたいことが達成できるのか、などの検証を行うべきとあり、結構しっかりしているのなと思いました(全然意識してなかった。。。)

僕個人としては、ドキュメントはあくまでコード読まずとも書いてある内容を実施できたらインストールできるよ。とか、コードだけじゃわからないなぜこの選択をしたのかとかの意味合いで書き残すことが多かったので、その前後を事前調査・検証するということはやってこなかった。そのため、ドキュメントの良し悪しのような物差しも持ってなかったので、あまりテンションもあがらなかった気持ちでした

この本を読むことで良いドキュメントとは?が定義できそうなので、レビューもできるようになれそう

読書メモ

  • ユーザーがドキュメントを読んで達成したいこと、ゴールを定義する
  • ユーザーの特徴をリストアップする
  • ドキュメント書く前にドキュメントのタイトルとゴールとアウトラインを用意する
    • ドキュメントのタイトルはドキュメントを読むことで達成できるゴールの要約したものにすべき
  • 完璧主義からの脱却
  • コンテンツはできる限り短くして要点を絞る
  • ドキュメントをセルフレビューする。チェックリストがあるのはよかった(参考になる)
  • ドキュメントの品質を測る物差しがあることを知れた

ドキュメントもソフトウェアなのだ!メンテしなきゃ!って気持ちになった。良いドキュメント書いていくぞ