ruby2.6.0-preview3からbundlerが標準添付されるらしいぜ
開発プロジェクトふりかえり会 失敗事例集
はじめに
- 3,4年くらい業務でプロジェクト反省会番長をやっていたので、情報整理も兼ねて「反省会でやらかしたNG集」を作成した。
- 我々は効率よく業務改善をしたいのであって、ふりかえり会をやりたい訳ではないので、発生しがちなつまらないトラブルはサッと潰しておきたいよね。
- ふりかえり自体の方法については書かない。
- KPT法
- YWT法
NG集
議題編
発生した問題を忘れる
- NG
- 反省会までのスパンが長いほどありがちで、「何かProblemが起きたはずだがメンバーが誰一人詳細を憶えていない」事態が発生する。
- 「喉元過ぎれば熱さを忘れる」というやつ。
- お前らさぁ…感はあるが人間そういうもの。
- 反省会までのスパンが長いほどありがちで、「何かProblemが起きたはずだがメンバーが誰一人詳細を憶えていない」事態が発生する。
- 対策
- 「ふりかえり議題置き場」を作って即座に書き残してもらうようにした。
- GitLab,GitBucketなどのIssueを課題管理表として活用。
- そのうち、即座に書き残す文化が定着する…はず。
- そもそも、短いスパンでふりかえりを実施するのがよいのだが…
- チーム/プロジェクト状況によっては難しいよね(ヽ´ω`)
- 「ふりかえり議題置き場」を作って即座に書き残してもらうようにした。
問題の詳細を忘れる
- NG
- 「ふりかえり議題置き場」を運用しはじめた所、「リリース作業がゴタついた」「マージ時にトチった」といったふんわりとした議題がたまに記載されるようになった。
- 案の定、翌週には記載した本人が詳細を思い出せなくなった。
- お前らさぁ…感はあるが人間そういうｍ（ｒｙ。
- 対策
- 議題としてのざっくりしたテンプレを用意して書いてもらうようにした。
- 簡潔なタイトル
- 具体的なProblem / Keep
- 今思いつくTry
- そもそも、短いスパンでふり（ｒｙ
- 議題としてのざっくりしたテンプレを用意して書いてもらうようにした。
書き残すのを後回しにして忘れる
- NG
- 課題事項テンプレにあれこれ足した結果記載コストが高くなると、後回しにして議題を忘れる事態が発生する。
- お前らさ（ｒｙ
- 課題事項テンプレにあれこれ足した結果記載コストが高くなると、後回しにして議題を忘れる事態が発生する。
- 対策
- 記載事項に優先度をつけ、最低限の事項を書けば起票していい雑な課題置き場として運用されるように周知した。
- そもそも、短（ｒｙ
会議運営編
事前準備せず開催
- NG
- ふらっとメンバーを集めて口頭で議題を集めても、話題が発散して収集がつかなくなる。
- 対策
- ふりかえり会の開催前にある程度議題を準備した。
- メンバーに議題を書き出してもらう。
- キーマンに事情聴取して書き出しておく。などなど
- ふりかえり会の開催前にある程度議題を準備した。
タイムキープをしない
- NG
- 1つの議題の討論に集中してしまうと、他の議題の話し合いができない事態が発生する。
- タイムボックスを定めないと、いつまでたっても会が終わらない。
- 対策
- 議題ごとに使える時間の目安を決めておき、長くかかるようなら別途関係者を集めて相談するよう指示し、次の議題へ移行するように促すようにした。
発言を議事として残さない
- NG
- ふりかえり会にも慣れてくると活発な議論が行われるのだが、空中戦になり議事を残せなくなった場合、「あれどうなったっけ」が発生する。
- 対策
- 「議論内容は必ず文字に起こす」を徹底して会議を進めるようにした。
- 議事録をプロジェクターで表示しつつ議論を進めてもらう。
- 全員が書き込める議事録ページを作成する。
- そのうち、結論をまとめる文化が定着してくる…はず。
- 「議論内容は必ず文字に起こす」を徹底して会議を進めるようにした。
対人攻撃
- NG
- 「○○さんのミスにより〜」 「◆◆さんが〜〜してくれず〜〜」といった議論をしてしまうと心理的負荷が上がるだけの吊し上げ会になってしまう。
- 対策
- 個人攻撃はせず、チームの課題として議論をするように徹底した。
- 業務の成果物に問題があったならそれは個人の問題はなくチームの問題である。
- 部署間の連携にトラブルがあったならそれは渡す側/受ける側双方に問題がある。
- もちろん、個人として反省すべき点が見つかったならそれは改善を進めてほしいが、参加者で寄ってたかって攻撃してよいものではない。
- 溜まった鬱憤は閉じた飲み会とかで発散しよう。
- あんまり良い行いではないけど、お互い聖人君子ではないし仕方ない。適度なガス抜きが必要。
- 個人攻撃はせず、チームの課題として議論をするように徹底した。
荒れる
- NG
- メンバーがヒートアップして会の収集がつかなくなる。
- 対策
- 建設的な議論ができていれば問題ないが、議論が平行線をたどるようであれば一度中断する。
問題解決編
問題点/原因の認識がズレる
- NG
- 立場や役割、信念の違いによって、問題の原因と捉えていること/解決策として考えていることがズレてしまう。
- 対策
- そこの認識をすり合わせるのが「反省会」
- ①問題発見->②原因分析->③改善策の試行 の①〜②の方向性をメンバー間で合意してもらうようにした。
Tryに期限を切らない
- NG
- ふりかえり会を実施してProblemに対するTryを決めたが、Tryがいつまでも実施されないと再度同じ問題が発生する。
- 対策
- そのTryが次に必要なのはどのタイミングか？ を元に期限を切るようにした。
Tryを全てやりきろうとする
- NG
- わんさか出たTryを全てやりきろうとすると達成できなくなる。
- 対策
- 優先度をつけて効果の大きそうなTryから対処することとした。
根本解決にこだわる
- NG
- 問題解決策として時間のかかる根本対策にこだわってしまうと、未達/期限切れが大量発生する。
- 対策
- Tryは所要時間や解決度合別にいくつか用意するようにした。
- 今週できるその場しのぎ対策
- 来月までにできそうなそこそこ良い対策
- 将来できたらみんなとってもハッピーな根本対策
- Tryは所要時間や解決度合別にいくつか用意するようにした。
解決アクションがルールを増やすものばかり
- NG
- 「Tryとして作業ルールを増やそう」「チェックリストを作ろう」「フローを厳重にしよう」
- などとやっている内にルールにがんじがらめになり所要時間の増加を招いてしまう。
- 対策
- 不要になったルールは見直しをかけて撤廃しようとした。(あんまりできてない)
- ルール増加ではなく、自動化/知見の共有/フローの整理などで正確性と速度の両立を図った。
- 脳の処理速度/キャッシュ量には限界があるので、ルールが増えるとコストがかかることは常日頃啓蒙しておくのが吉。
モチベ編
- カイゼン主催者の天敵、モチベーションダウン。
- モチベが下がって何も実施しなくなると、結果的に成果0になってしまう。何よりまずは自分のモチベ維持が優先。
改善する気がない人がいる
- NG
- 毎度トラブルを起こしており、指導したとしても全く改善されない人がいて萎える。
- 対策
いつまでも解決できない問題がある
- NG
- たびたび問題が発生して毎回どうしようもない…で課題だけ積もっていって萎える。
- 対策
- 現場の力だけでは解決できない問題である可能性あり。一旦、他の課題に取り組む。
他人からの「それ意味あるの？」に対して
- 外野から「反省会とかやってるけど…こんなケアレスミスも防げないってどうなの？ やり方ちゃんと考えたら？」とか言われて萎える。
- 対策
- 「うっせだまれ 簡単にできたら苦労せんわ」
- ↑叫んでゲームして飯食って寝る
自分からの「これ意味あるのか？」に対して
- 「ふりかえりとか業務改善とか始めたけど、これに意味はあるのか…？」とか考え出して萎える。
- 具体的な効果を計測しづらいこともあり、自信が揺らぎがち。
- 対策
- 人事評価時にアピールして給与UPを狙おう。給与はどのチームで働いてても使えるものさし。
- 給与と査定が上がれば会社も「意味がある」と判定してくれたということ。
- 特に査定が上がらなければ会社に対してあまり刺さってない。やり方を変えるか勤め先を変えるかしよう。
- 人事評価時にアピールして給与UPを狙おう。給与はどのチームで働いてても使えるものさし。
おわりに
- というわけで、社内ブログに投げたポエムを自ブログに転記した。
- Qiitaに投げようかと思ったけどあんまりにもポエムだったのでやめといた。
- 働いてるとげんなりするトラブル多いけど、ひとつずつ原因を潰していこうな。
参考ページ
彼女の転職を支える技術 〜テクニカルサポート編〜
はじめに
- メンタリング編だけだとエンジニアっぽくないので、技術的なサポートについても記載
目的
- デザイナーの転職にはやはり「ポートフォリオ」が必要らしい。
- ということでサポートしていく
前提条件
- 彼女の技術レベル
- まとめ
対応内容
概要
- GitLab Pagesの使い方を教える
- 以上！
流れ
- GitLabにアカウント作ってもらう
- 自分のアカウントとグループを作る
- サンプルページをforkしたリポジトリを作る
- gitlab.com
- readmeに記載の通り、fork後に
remove the forking relationshipしておくこと
- 適当なリポジトリ名,URLに変更する
- gitlabにファイルがホストされたことを確認
- 「public配下にファイルコミットしたら反映されるよ〜」と伝える
- 見守る
評価
- 「デザイナーの人、有料のレンタルサーバ借りて苦労してサイト作ってる人多いのに、これ簡単な上に無料だと…」とのこと
- 高評価でなにより
おわりに
- ぶっちゃけほとんど技術的なサポートする必要がなかった。さみしい。
彼女の転職を支える技術 〜メンタリング編〜
はじめに
この度同棲中の彼女が転職することになったので、
彼女が疲労困憊状態(ヽ´ω`) 〜 復活&転職(｀･ω･´) するまでの間で
自分が気をつけていたことのまとめを作成。
実施アクション
まず休ませる
- 仕事を休ませる
- 仕事でストレス抱えたまま次のアクションを起こすのはなかなか大変なので可能な限り長めに休ませる
- まずは気力の回復から
- 今回は旅行へ行くという名目で2人で1週間休暇を決行した
- 関西旅行を実施
- 大義名分があれば休みやすいので能動的に遊びに行くこと
- 休んだ際に「会社行けなかった…」とどんよりしていると全く精神力が回復しないので意識的にそれは回避させること
睡眠時間確保
- 経験上、悩みが多かったりストレスマッハになると夜中遊びたくなって寝れなくなるので、そうなってる所を捕まえて布団へ放り投げる
- ほうっておくと、寝不足 -> 業務効率down -> 残業 -> ストレス のループにハマるので早めに断ち切る
- 日常の家事は自分がなるべく早く帰宅してやっておく
外へ連れ出す
- 休日はインドアでもアウトドアでもいいので強制的に連れ出して気分転換する
- 可能な限り内容は自分でプランニングした方がよい(相手の精神力を削らなくて済む)
ぼやきは聞く
- ぼやき/愚痴はちゃんと聞く
- 睡眠時間を失うと元も子もないので、週末以外は少し聞いたら適宜切り上げる
- だいたいストレスが溜まるのは残業モリモリの日なので、タイムキープがかなり重要になる。
- 風呂に入れるなどで話を切っていくとよい
次の行動へ意識を向ける
- 基本的に出てくるのは現状への愚痴なので、たまには将来のアクションを考えさせるとよい
- 「転職サイトの話題出す」「近い状況の知人は居ないか聞く」など
- 毎回これやるの無理なので愚痴の何割かはちゃんと聞くこと
自分のコンディション維持
- 多分これが一番大事
- 2日にいっぺんの頻度で愚痴を聞いてると自分も暗い気分になるので、自分の精神状況に要注意
- 共倒れ厳禁
- 心理カウンセラーでもなんでもないので、自身の精神状況的に愚痴を受けきれない場合はやんわり拒否することが重要
- 自分もイライラしての八つ当たりしてしまう などが最悪ルート
結果
- 施策に効果があったかは不明だが、無事に転職が完了した模様
- 我が家の重い空気も払拭された(転職前がかなりキツかった)
さいごに
- 本記事はこちらの記事を無断でリスペクトしています。
マイナンバーカードが初めて役に立った話
概要
- マイナンバーカードを使用する。あなたは任意の枚数の住民票を得る。
内容
数年住んだ住処を離れて別の街に引っ越すことになった次第のルニ君
新しい部屋の物件契約時に住民票が必要に
平日はおしごと、土日は夕方まで寝てるマ ンで役所に行くのが大の苦手なルニ君は困り果てていたわけだが
この度便利な方法が見つかったのでメモ
こちら、マイナンバーカードを掲げることでコンビニで住民票の写しが手に入るというもの。
実際の感想
セブンイレブンで試してみた。
コンビニコピー機にマイナンバーカードのIC読み取らせてパスワード入力すればそのまま住民票が取得できる感じ。
おわりに
マイナンバー、こんな風に人間の手を介さず認証できれば便利そうだったんだが…どうしてこうなった…
まだ人間に認証認可は早すぎたのだろうか…
とりあえず役所の人はゼロ知識証明のページをチラッと読んで欲しい
ちなみに転出・転入届もマイナンバーカードがあれば書類を発行せずに役所の職員がシステムに入力にすれば完結するらしい。そのシステムWebに公開してくれ頼む。
名探偵コナン から紅の恋歌 感想【ネタバレ有り】
はじめに
見てきた #名探偵コナン pic.twitter.com/04wb5eaLns
— ルニ@IkaDB! (@lni_T) 2017年5月1日
劇場版名探偵コナン 見てきました。
コナンに登場する女の子の中で誰が一番好きかっていうと和葉ねーちゃんなので、こりゃあ見に行かねばなとなって行ってきた次第。
LANねーちゃんは頭トゲトゲだし園子はデコ助やし灰原さんは悪女やし和葉一択やろ
— ルニ@IkaDB! (@lni_T) 2017年4月7日
というわけで、ネタバレ有り感想をTwitterに書くのは外道のすることなので、こっちを活用していきましょう。 百人一首がキーワードになっている映画ですが、授業で習っただけで全然分からんので、そっちと絡めた感想はないです。
ちなみにネタバレ無し感想は↓
名探偵コナン から紅の恋歌 スペック表(ネタバレ無し)
— ルニ@IkaDB! (@lni_T) 2017年5月1日
推理:有り
アクション:有り
戦闘:無し
爆発:有り
蘭ーーーー！:無し(※和葉有り)
博士クイズ:有り(いらない)
ネタバレ有り感想は「続きを読む」から
続きを読むJenkinsの「シェルの実行」でgrepやdiffを使った際途中でジョブが失敗してしまう問題の解決法
問題の現象
- Jenkinsのビルド手順の「シェルの実行」でgrepコマンドやdiffコマンドを使った際、実行結果が"不一致"だった場合のみジョブが中断され失敗扱いになってしまう問題が起きたので困っていた
- すんなり解決できたのでメモ
解決方法
- 「シェルの実行」先頭に以下を記載する
#!/bin/sh
- 詳細は下に記載
詳細
原因
- Jenkinsのシェル実行はデフォルトでは
/bin/sh -xeで実行される(実行結果参照) - それぞれのオプションの意味は以下
- このeオプションが原因となって発生している
grepの検索やdiffの比較は、一致しなかった場合0以外の終了コードを返す仕様になっているため、スクリプトがexitしてジョブが失敗してしまう
解決方法
- 「シェルの実行」先頭に以下を記載する
#!/bin/sh -x
- これを記載することで、
-eオプションを指定しないシェルでコマンドが実行されるため、途中で0以外の終了コードが返っても続けて実行することができるようになる- シバン (Unix) - Wikipedia
- Jenkinsのジョブは最後のコマンドの終了コードで成功/失敗を判定するようになる
リスク
- 当然他のコマンドが0以外の終了コードを返しても処理が続くため、本当に予期せず失敗したコマンドがあってもジョブが中断されず処理が進んでしまう。成功/失敗検知を正しく行わないととJenkinsは「成功」と判定してしまうため事故の元になる
