Slack 俺俺チートシート
Slack を使い始めて便利だなと感じたショートカットキーをメモ。
今のところはナビゲーションとファイル・スニペット関連のショートカットのみ。
書くこと
- 環境
- よく使うショートカットキー
- 参考にしたページ
- ToDo
よく使うショートカットキー
ナビゲーション
キー | アクション |
---|---|
Command + / | ショートカットキー一覧を表示 |
Command + K | クイックスイッチャー |
Option + ↑ | 前のチャンネルや DM に移動 |
Option + ↓ | 次のチャンネルや DM に移動 |
Option + Shift + ↑ | 前の未読のチャンネルや DM に移動 |
Option + Shift + ↓ | 次の未読のチャンネルや DM に移動 |
Command + [ | 前のチャンネルや DM に戻る |
Command + ] | 次のチャンネルや DM に進む |
↑ | メッセージの入力エリアにフォーカスがあるときに↑キーで自分の最後のメッセージへ移動 & 編集 |
表示関連
キー | アクション |
---|---|
Command + + | ズームイン |
Command + - | ズームアウト |
fn + ↑ | スクロールアップ |
fn + ↓ | スクロールダウン |
ToDo
- スラッシュコマンドを使ってみる
- ナビゲーション以外のショートカットキーを使ってみる
TDDBC Tokyo 2017-09 に参加してきました #tddbc
TDDBC Tokyo 2017-09 - connpass に参加することができたのでメモ。
TDDBC ってなに?
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
実際に参加してみた感想としては、以下の要素がギュッと詰まった濃厚なイベントでした。
- 座学
- 実践
- ペアプログラミング
- コードレビュー
- 意見・情報交換会
個人的には、ペアプログラミングを組み込んでいるのが素晴らしいと思いました。何事もそうですが、実践では座学どおりに進むことはめったになく、少なからず失敗しながら身につけていきます。1人よりも学習効果が高いペアプログラミングを組み込んだのは、2時間という限られた時間のなかで一定以上の成果を得るためのベストプラクティスかもしれません *1
基調講演
せとあず (Twitter ID: @setoazusa) さん
TDD のエッセンスがギュッと詰まったフルスペック感漂う重量級の講演でした! スライドを見るだけでも大いに勉強になると思いましたが、熱いトークを聞くことができたのは参加した人の特権じゃないでしょうか :)
ペアプロデモ
ペアプロデモをFizzBuzzで#tddbc pic.twitter.com/IG8NpnPIcu
— すーくん (@su_kun_1899) 2017年9月30日
ペアプログラミング実践の前に、YASUI Tsutomu (Twitter ID: @yattom) さんと よこち (Twitter ID: @chiiia12) さんによる、ペアプログラミングしながらテスト駆動開発するデモンストレーションがありました。
参加者はテスト駆動開発の経験がないのはもちろん、ペアプログラミングの経験もない人が多いです *2 そこで、実際にテスト駆動開発 + ペアプログラミングをライブで見ることができるのは、TDDBC に参加する大きなメリットだと感じました。特に引っかかることもなく淡々と進むのですが、とても丁寧かつ原則に忠実で、すごく分かりやすかったです。
ペアプロ
ペアプロのお題は セマンティック・バージョニング でした。
自分たちのペアは、ざっくりと相談して以下のような戦略をとることにしました。
- テスト駆動開発を体験することを一義的な目標にする
- 意見やアドバイスはためらわず言う
- 今やる演習問題だけに集中する (先の演習問題は見ない)
- 詰まったらペア交代 (第2ラウンドは5分のタイムボックスに変更)
第1ラウンドは、お互いの呼吸やベースとなるスキル・好みが分からずかなり苦戦した印象です。しかし、第2ラウンドでは第1ラウンドの経験が生き、お互いの呼吸が分かってくるにつれてリズムがよくなっていくのを感じることができました :)
また、「今やる演習問題だけに集中する (先の演習問題は見ない)」という戦略のおかげで、ついつい考えすぎてしまう落とし穴にはまることもなく、目の前のことに集中できたのは良かったと思います。特に、当初は「2.0.1a とかあるかもしれないし、バージョンはとりあえず文字列型で持っておこ〜」としていたのが、問題3で「ゼロ、または正の整数です」となったところで整数型として保持するように変更したときなど、「テスト書いておいてよかったよね〜」と、2人でニヤニヤしちゃいました。
コードレビュー
各ラウンド2ペア ✕ 2ラウンド = 4ペアがコードと戦略、実際の進み方を話して、他の参加者や TA さんがそれをレビューしました。
プログラミング言語やフレームワークによって観点や戦略がまったく異なるものになってしまうのはもちろんですが、*3 同じプログラミング言語でもまったく異なる戦略で進めているペアもおり、「こんないいやり方もあるんだなあ」と知見を広められるのは、とてもよい体験でした。
懇親会
懇親会!ピザだ!#tddbc pic.twitter.com/LruYf33MbK
— すーくん (@su_kun_1899) 2017年9月30日
メインスケジュールが終わったあとは懇親会へ。
.@gaopin1534 さんのLT! #tddbc pic.twitter.com/2sHYEKMebl
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
恒例 (らしいです) の LT 大会がすごい盛り上がりでした。個人的には、主催者の1人である PoohSunny (Twitter ID: @PoohSunny) さんがガチのマサカリ勢だと知ることができたのが大きな収穫でした。以後、態度にはよりいっそう気をつけたいと思います。
感想
参加者のレベルが高い
TDDBC Tokyo 2017-09 https://t.co/WZh4lVFnut #tddbc
— いきすぎステーキ (@a_suenami) 2017年8月26日
参加者一覧にbootする必要のない方々が見えるぞ
参加された方のレベルがすごく高かったです。ガチでレベルが高すぎて「本当に新兵?」「むしろ教官側では……」と感じることも何度となくありました。
まとめ
本当に久しぶりとなる勉強会への参加でしたが、朝の受付から懇親会までフルに楽しかったです!
自分はまだブートしたてですが、少なくとも前に進むキッカケをいただくことができたので、今後は新兵以外の形で TDDBC に関わっていくことを考えてみたいな、と思いました。
みなさんお疲れ様でした!!! #tddbc pic.twitter.com/ftomcuBZsL
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
1人で始めた職場での改善活動1年間を振り返ってみたメモ
職場で勝手にやっている改善活動のメモを取り出してから1年たったので振り返ってみたメモ。
書くこと
- 実際にやったこと
- 変わったこと
- 一番大きく変わったこと
- まとめ
実際にやったこと
メモはハッシュタグ #俺俺改善活動 を付けて Twitter へツイートしていました。*1
今月の #俺俺改善活動.構成管理のブランチポリシーを整理してドキュメント化した.普段は見ないものだけど,ブランチ開発経験のない人が入ってきたときは効果すごいある
— えび🦐 (@ebc_2in2crc) 2016年7月28日
今月の #俺俺改善活動.高コストな上に誤りが混入しやすい機能をエンドツーエンドでテストできるようにした.テストは自動化されているから CI に組み込めるし,安心して修正できるようになった(*'▽'*)
— えび🦐 (@ebc_2in2crc) 2016年7月28日
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年9月30日
・テストの25%を占めていたスローテストの実行時間→実質0に
・大量の不良 XML を発見→更生させる
・鬼長い手順書を自動化→手順書レスに
・ふりかえり活動開始の根回し→活動許可ゲット
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年10月31日
・ふりかえり導入 (継続させたい!
・巨大コミットしてた人のコミットがすごく小さくなってきた
・他の現場に移った人が SVN な現場に Mercrial 導入 (DVCS 意味ねーし!と言っていたのに…ホロリ
・新人くんとの間に薄氷の信頼を築く←new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年11月30日
・DSL 作って XML 地獄を焼き払う
・書いてて良かったツールリファレンス
・お隣のプロジェクトにビルドと CI 導入
・新人くんとの信頼関係が少し進展
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2016年12月28日
・イテレーションふりかえり定着
・ヘルププロジェクトに CI 導入
・↑最初から計画してたからCI 自体は5分で載せられた
・新人くんがすごい成長率
・他プロジェクトがヘルププロジェクト DSL を導入検討中
・新人くんとの別れ ← new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年1月27日
・定期的に勉強会を開催することをチームで決めた
・みんながふりかえりの時間を楽しみにしていることが分かった
・ヘルププロジェクト DSL をお隣のチームが導入
・↑に合わせてマニュアル書いた
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年2月28日
・ステージング環境へのデプロイ自動化
・定期的な勉強会開催スタート
・ふりかえりが順調に根付いている
・神クラス四天王に第2撃
ちょっと物足りないな…(´・ω・`)
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年3月30日
・神クラス四天王の一角を崩した (並の中ボスくらいになった
・リリースレトロスペクティブ初開催
・全員が次回開催を要望
・Excel 変更履歴シートの撲滅
・チームメンバーが Vim をインストール←new!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年4月28日
・タスクボード運用開始
・チームメンバー2人が Vimmer に٩(๑❛ᴗ❛๑)۶
・ふりかえりファシリテーター持ち回り開始
・社内プログラミングパズル開催←面白かった!
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年5月26日
・2人目のファシリテーターがデビュー
・品管さんにいろいろと控えてもらえるようになった
・突発作業が多すぎるので見積もりに利用できるように実績記録開始
・「リファクタリング?なにそれ美味しいの?」状態だったメンバーがいまや興味津々.今度勉強会することに
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年6月26日
・ふりかえり発でリファクタリングワークショップ開催
・"リファクタリングすげーいい" とのメンバーの声が!
・神 Excel をキリングしたぜウェーイww → それは余の細胞一つにすぎぬ…ファッ!?
・↑その後,完全撃破(๑•̀ㅂ•́)و✧
今月の #俺俺改善活動
— えび🦐 (@ebc_2in2crc) 2017年7月31日
・知見共有会がほぼ定期的になった
・関係の深いシステムのエキスパートを招いて勉強会←すごく好評だった
・ペアプロハンズオン2回目開催
・残業とかないわーが完全に定着
変わったこと
- ふりかえりが定着した
- 勉強会が定着した
- 必要を感じたら知見共有会を突発的に開催
- 自動化 > 手順書 > なんとなくの口伝、が定着
一番大きく変わったこと
1人で始めた活動ですが、今はもうそんな雰囲気はなく、チームメンバー全員で改善活動をしている、というのが実態です。
改善そのものもですが、やっぱり、チームメンバーも少しずつ変わっていきました。なので、これが契機!というものはなかなかありませんが、その中でもふりかえりはインパクトが強かったようです。
特に、ふりかえりは自分を含めたチームメンバーに大きな影響を与えたと思います。
2週間ごとのふりかえりでは、「計画どおりに行かないのはなにが原因か」「ならば、なにをどのように変えていけばよいか」という雰囲気と意識が生まれました。そして、それを繰り返していくうちに、問題を個人のものとするのではなくチーム全体の問題として共有し、みんなで解決していこうという雰囲気が定着しました。「自分はスキルがないから…」という人も「自分にできることはないか?」と動いてくれるようになり、逆に「スキルがない人はちょっと黙ってて」と言っていた人 *2 が他の人の意見を求めるようになったりと…人によって程度は違いますが、それでも、ちょっと1年前からは考えられないくらい、メンバー全員が変わりました。もちろん、自分自身もです。
まとめ
改善活動に明確なゴールはないと思っています。なぜなら、ある目標を達成したとしても、翌日になってみるとそれが新たなスタートラインになっている、そう感じるからです。
改善活動に対するチームの今のスタンスは、「ときにはダレたりするかもしれないけど、できるだけペースを守ろう」「少しずつ進めていこう」です。というのは、急激な改善を行うと一時的には大きな成果が出るけれども、そう遠くないうちに無理が利かなくなり、息切れしてしまうことをみんなが実感しているので。このスタンスは今後もどんどん変わっていくかもしれませんが、今はこれがチームの共通理解となっています。
1年間を振り返ってみて、これからも改善活動を続けていきたい、そう思っています。
Java で -server オプションを付けたら4割近くも速くなったメモ
Java で -server オプションを付けたら4割近くも速くなったときのメモ。
動機
ログファイル中の XML をパースして XPath で抜き出す調査用のツールを使っていたのですが、本番機 / ステージング機と開発機で実行速度に大きな差がありました。本番機・ステージング機・開発機はハードウェアのスペックからしてまったく違うとはいえ、同じログファイルに対して実行したときの TAT が2倍以上違うとかもザラにあり、少し調べてみました。
開発機では Client VM が使われていた
開発機の OS が 32bit Windows のため、デフォルトで Client VM が使われていたのが原因でした。java コマンドに -server オプションを指定して Server VM で実行するようにしたところ、TAT が4割近くも短くなりました。ちょっとしたツールだしあまり変わらないだろうと思っていたのですが、全く変わるものなんですね。
大雑把な計測結果をメモしておきます。
# Client VM で実行 PS >1..10 | foreach { Measure-Command { java -client Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 32756.72687 Sum : Maximum : Minimum : Property : TotalMilliseconds # Server VM で実行 PS >1..10 | foreach { Measure-Command { java -server Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 24059.97238 Sum : Maximum : Minimum : Property : TotalMilliseconds
ユースケースを元にキャッシュ化
Server VM を使うことで相当に速くなったのですが、使っていたツールの使われ方には以下のような偏りがあったので、
XML のパースと XPath での抜き出しは初回のみ行い、以後はそのキャッシュに対して「ごく一部」を適用するようにしてみました。
# 事前にパースしてキャッシュしておき、それを使うようにする PS >1..10 | foreach { Measure-Command { java -client -Dcache=enable Hoge }} | measure -Average TotalMilliseconds Count : 10 Average : 2667.87865 Sum : Maximum : Minimum : Property : TotalMilliseconds
圧倒的に速いですね。桁が1つ減りました。ちなみに、キャッシュからの検索には PowerShell の Get-Content と Where-Object を使っているのですが、grep コマンドに置き換えたらミリ秒で終わるようになりました。本番機・ステージング機で grep コマンドが使えないのが残念ですが、Get-Content と Where-Object を使う版でも2, 3秒で終わるのでまあいいかな、というところです。
チームメンバーにリファクタリングを紹介する勉強会を開催した
チームメンバーにリファクタリングを紹介する勉強会を開催しました。
動機
- ふりかえりで、最近コードがちょっとよくなってるよね、という話題がでた
- 仕様変更やバグ修正のたびにコードが汚くなって困っている…という声もでた
- コードをよくする方法があるならちょっとやってみたい、という声につながった
- リファクタリングのさわりを紹介 + ハンズオンなんてどう?
ってことで、勉強会を開催することになりました。
スライド中の様子
- 負のスパイラルでは結構深刻な表情
- コードが病むスピードのグラフでは「そうだよね〜 (真顔)」
- マイケル・フェザーズのレガシーコード論が一番食いつきが強かった
- ボーイスカウトルールでは「そうなんだよな〜」「そうだったらな〜」
ハンズオンの様子
まとめ
まだまだ立ち上がったばかりの活動ですが、少しずつ自分たちの手で触れていくのが大事だと思っています。
ふりかえりが出発点なので、まずは毎回のふりかえりで、今回のイテレーションでのリファクタリングを1〜3分くらいでフィードバックするようにしています。すでにイテレーションでのフィードバックがありましたが、ごくシンプルなものでもみんなの食いつきがとてもいいです。
本音
リファクタリングが特別でもなんでもない、チームにとって空気のようになるのが目標です (キリッ
Excel 入出庫台帳の思い出と付き合い方
システムエンジニア Advent Calendar 2016 - Qiita 2日目の記事です。
SI 業界人なら構成管理の現場で一度くらいは遭遇したことがあるかもしれない Excel 入出庫台帳との思い出と付き合い方について書きます。
書くこと
- Excel 入出庫台帳とは
- 付き合いの歴史
- オススメの付き合い方
- まとめ
Excel 入出庫台帳とは
こういうやつです。
この Excel に、これから編集するファイルのパス・バージョン・編集種別 (追加・修正・削除) といった管理情報を記入します。それを申請書として構成管理担当者に提出すると、記入したとおりのパス・バージョンのファイルが送られてきます *1
これは「構成管理物を担当者に払い出す」ので「出庫 (申請書)」と呼ばれます。反対に、担当者が作成・修正したファイルを構成管理に戻す (入れる) ときは「入庫 (申請書)」と呼ばれます。しかし、入庫も出庫も単に「入出庫台帳」と呼ばれることも多いです。
Git しか使ったことがない人にはまったく意味不明だと思いますが、使っていた人もほとんどが「なんでこんなの使うんだ?」という代物です。
そんな Excel 入出庫台帳について、あるプロジェクトで付き合った思い出と付き合い方を書きます。
付き合い前 - 最初期
構成管理のためにバージョン管理システム (以下 VCS) を利用することが多いと思いますが、最初期は VCS を使っていませんでした。
どうやっていたかというと、共有ディレクトリに置かれたファイルを担当者が直接修正 + 日付ディレクトリで運用していました。また、共有ディレクトリのファイルを直接編集するのではなく、ローカルにコピーして編集したあとにディレクトリ全体を戻す、といったことも行われていました。
当然のように、いろいろな問題が頻発しました。
- 修正したファイルが他の担当者に上書きされる
- 削除したファイルが復活する
自分がジョインしたのはちょうどそんな頃でしたが、VCS を使わないのはあまりにも無謀です。そこで、すぐに VCS の導入を提案しました。
付き合い前 - 前夜
チームとしても「このままではまずい!」という危機感を持っていて、すぐに VCS を導入することになりました。自分は Git か Mercurial を推したのですが、最終的には標準ソフトウェアという理由で CVS が導入されました。なお、この時点ではまだ Excel 入出庫台帳による管理は行われていませんでした。
運用の実際
この頃から頻繁にステージング環境にデプロイするようになり、以下のような手順でデプロイしていました。
一直線に進むだけの開発においては CVS + ブランチなし運用でもなんとかやっていけていました。一応。
ふりかえって気が付いたこと
当時は Git や Mercurial ではなく CVS を採用する理由が分かりませんでした。しかし、
- 自分以外のメンバーは Git, Mercurial の経験がなかった
- 一方、CVS の経験はあった
- デスマーチ一歩手前で学習コストが払いづらい
- 不慣れな Git, Mercurial を使った場合の事故が怖い
- 自分はジョインしたばかりだった = 実績がない = 信頼がない
これだけネガティブな環境的要因が揃っているなかで、実績も知名度もないメンバーの意見を積極的に採用するほうが難しいでしょう。
「信頼を得るのに弁舌でなく実績をもってすべき」とか言われても不思議ではないと思います。
付き合い初期 - すべて人力
プロジェクト全体で構成管理プロセスの品質向上が図られることになり、Excel 入出庫台帳 (以下、台帳) が導入されました。また、この頃からプロジェクトが完全にデスマーチ化しました。
運用の実際
台帳を導入したもののファイル自体は CVS で管理されているので、台帳が入出庫フローに直接組み込まれることはありませんでした。その代わり、ファイルを追加したり修正した場合はその実態に合うように台帳に記入し、デプロイの際には台帳の記録履歴からファイルを集めてビルド・デプロイすることになりました。
困ったこと
台帳を導入してすぐに問題が発生しました。問題は大小様々でしたが、一番大きな問題はコンパイルができない *2 ことでした。原因は様々ですが、大雑把にリストすると、
- 台帳に記入されたパスが間違っていて update できない
- 台帳に記入されたパスが間違っていて別のファイルが update された
- 台帳に記入されたリビジョンが存在しない
- 台帳の記入順に update するとリビジョンが巻き戻る。これが正しいのか?
- 台帳はコミットごとに別ファイルとして作られる *3
- そもそも台帳への記入漏れがあった
こういった原因のためにコンパイルできなかったり、コンパイルできても論理的な矛盾 (バグ) があるなどに悩まされました。「昔はブランチをマージする前に禊 (みそぎ) をしたものだ」なんて聞いたことがありますが、この頃はマージどころか単にビルドするだけで何時間もかかるのが当たり前で、通常業務への影響は到底無視できるものではありませんでした。
ビルドは持ち回りでやっていたのですが、1度でもやった人は2度とやりたがらず、自分も1度やってみてすぐに改善を決めました。
付き合い中期 - リファクタリング
台帳による管理を続ける理由はまったくありませんが、台帳は品質向上プロセスの一環として導入されたため、取りやめるためには政治的な壁が高く立ちはだかっていました。そこで、入出庫フローそのものは変更せず、作業の実体だけを変えることにしました。つまり、プロセスのリファクタリングです。
ビルド持ち回り2巡目からはほぼ自分1人がビルドしていたので、チームリーダーの合意だけもらってリファクタリングを進めました。
リファクタリングで変わったこと
- ビルドにかかる時間が20分になった
- 誰でもビルドをしてくれるようになった
- 台帳に記入する時間を開発に充てられるようになった
- 「台帳いらないよね」気運が高まった
やったこと
台帳への記入と台帳からファイルを集めるのを自動化しました。具体的には、
- CVS クライアントを導入
- commit のログから自動で台帳に記入するラップコマンドを作成 *4
- 一連の台帳の記入内容からファイルを集めるスクリプトを自動生成
- 記入内容をチェックして誤りや矛盾がある場合にはレポート生成 *5
- 定間隔で記入内容をチェック
行った変更はすべて台帳に記入・台帳の記入内容からファイルを集めてビルド…という入出庫フローはそのままですが、作業の実体としてはまったく別物になりました。定間隔でのチェックは Windows のタスクスケジューラを使ったのですが、誤りを早期発見できるようになったおかげで無駄な調査時間を一掃することができました *6 *7
どうやったか
できるだけ段階的な自動化を心掛けました。というのは、
こういったありがちなことを避けるためです。
また、自動化後の運用フローも1人ずつ段階的に導入してもらいました。というのは、
- 一気にチーム全体にお願いすると "上意下達" と受け取る人もいる
- 反発したり、言われたから仕方なくやる、になってしまいがち
- 事実上、いきなり全員をフォローするのは無理ゲー
- 相談という形で1人ずつお願いすると自分事と捉えてくれる
- 先行して導入した人が後続する人のメンターになってくれる
目的は構成管理にかかる時間の最小化と余計な作業を減らすことで、自動化された手順を使ってもらうのは手段にすぎないので。
とはいっても、このあたりはプロジェクトや組織の文化次第でいくらでも変わるので、いけるなら一気に導入したと思います。
付き合い末期 - 別れ
自動化を導入してから数ヶ月後、家庭内別居状態だった台帳と別れるときがやってきました。
きっかけ
プロダクトが無事にリリースし、それと同時に複数バージョンのメンテナンスが必要になりました。台帳と家庭内別居したあたりから構成管理周りのことは最初に相談してもらえるようになっていたのですが、この時は「好きにやっていいよ」と言ってもらえたので好きにやることにしました。
やったこと
- VCS を CVS から Mercurial + TortoiseHg に移行 *8
- Mercurial 社内勉強会開催
- ブランチ戦略を策定
- その他、構成管理にかかわるもろもろ
- マネージャーに台帳不要論を納得してもらう
- そして、台帳と完全に縁を切った
いろいろやりましたが、キモは台帳が不要であることをマネージャーに納得してもらうことでした。
マネージャーは台帳そのものが必須だと考えているわけではありません。マネージャーにとって台帳はあくまで手段でしかなく、目的は構成管理プロセスから生み出されるプロダクトの品質が担保されることです。しかし、「台帳という手段があるからこそ目的が達成される」「台帳という手段がなくなったら目的が達成できなくなる」とも考えています。
そこで、台帳が無くても新しい構成管理のやり方 (= 手段) で目的を達成できることを、チームリーダーと2人でマネージャーに説明しました。自分一人では納得してもらえないか、あるいは相当に時間がかかりそうでしたが、チームリーダーが粘り強く説得してくれたおかげでかなり早期に GO サインがでました。この一件にとどまりませんが、チームリーダーに対するマネージャーの信頼の高さに救われました。信頼は大事です。つくづく思います。
オススメの付き合い方
誰がなんといおうと付き合わない、間違いなくこれが最善策です。
それでも付き合わなければならなくなったとしたら、家庭内別居状態→離婚のコンボを狙う、これが次善策でしょうか。
実効性がないプロセスは政治的・文化的な理由から存在するのがほとんどなので、最初から拒否するのは難しいことも珍しくありません。そこで絶対に拒否!と頑張るのもいいのですが、非常に疲れますし最終的に受け入れざるを得なくなることも多いです。ある程度まで頑張っても駄目なら、悪化した状況、つまりリスクが発現するのを前提に考えてみるのも1つのやり方だと思います。
まとめ
ながくなってしまいましたが、Excel 入出庫台帳の思い出と付き合い方でした。
最後に、Excel 入出庫台帳に限らないのですが、プロジェクトのルールや文化を変えていくにあたって心がけていることを書きます。
- 知名度がなければ実績で信頼を得る
- 変化は少しずつ
- 変化は自分から
- 自分自身を変えるのも簡単ではない
- 自分が他人を変えるのはほぼ不可能
- しかし、他人が自身を変えることはできる
- 仲間をつくる・増やす
- メリットを体験してもらう
- トップダウン・ボトムアップに絶対はない
- 技術的正論が通らない (= リスク) ことは当たり前にある、を前提に考える
- 建前を変えられないときは実体から変えていく
- そのときがきたら建前も変える
- 変化は手段であって目的ではない
- しかし、変化がない≒リスクである
いろいろ書きましたが、変化を楽しみながら仕事ができる、そんなシステムエンジニアでいたいと思います。
IntelliJ IDEA + Lombok + Gradle の環境構築メモ
IntelliJ IDEA で Lombok を使う環境を作り直した時のメモ。
やったこと
- SDKMAN! のインストール
- Gradle のインストール
- build.gradle に依存関係を記述
- Lombok Plugin のインストール
- Annotation Processors の設定
SDKMAN! のインストール
homebrew で Gradle を管理していたのを SDKMAN! (旧 GVM) で管理するように変更。
公式サイト に書いてあるコマンドを打つだけで完了。
$ curl -s https://get.sdkman.io | bash # 省略 $ source "$HOME/.sdkman/bin/sdkman-init.sh"
SDKMAN! をインストールすると .zshrc (or .bashrc) に SDKMAN! 用の設定が追加される。
#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!! export SDKMAN_DIR="/Users/shrimp/.sdkman" [[ -s "/Users/shrimp/.sdkman/bin/sdkman-init.sh" ]] && source "/Users/shrimp/.sdkman/bin/sdkman-init.sh"
Gradle のインストール
こちらも公式サイトに書いてあるコマンドを打つだけで完了。
途中で Gradle 3.2 をデフォルトにしてもいいか聞いてくるので、デフォルトにするなら y を入力する。
$ sdk install gradle 3.2 Downloading: gradle 3.2 In progress... ######################################################################## 100.0% Installing: gradle 3.2 Done installing! Do you want gradle 3.2 to be set as default? (Y/n): y Setting gradle 3.2 as default.
build.gradle に依存関係を記述
build.gradle に以下を記述。
apply plugin: 'java' repositories { mavenCentral() } dependencies { compileOnly "org.projectlombok:lombok:1.16.10" }
Lombok Plugin のインストール
Preferences - Plugins から「Lombok Plugin」をインストールする。
インストールを反映するために IntelliJ を再起動するか聞いてくるので「Restart」を選択して再起動する。
Annotation Processors の設定
Preferences - Build, Execution, Deployment - Compiler - Annotation Processors から「Enable annotation processing」にチェックする。
以上。