最近の仕事をした気になれるツール
5年くらい前はメールをいかに見ないようにして自分の仕事を進めるかを考えていた。仕事場に着いて、PCを開いてメールでも見はじめたらあっという間に30分や1時間は立ってしまう。メールの内容はプロジェクトの進捗上の障害であれば見過ごすこともできないから、あれこれと指示をするなり、手配をしたりする事になる。
それが今ではslackに置き換わった。メールのinboxからチャンネルになり、情報が分断されるようになった。だからか、チャンネルはopenであることが望まれ、KPIのようにopenと鍵の付いたチャンネルとDMの比率を比べる。
メールはinboxの中で探しにくいがslackも流れが早くどこにレスをつけて、どれに返さないといけないのかすぐに分からなくなる。
結局、メールのinboxのサブフォルダはチャンネルになったに過ぎない。
仕事上のコミュニケーションは、ブレストのようなものであればオンラインでも構わないが集まってテーマに付いてあれこれとやるが、実作業はそれの方向性を決めれば個々に振られるからコミュニケーションで取り交わしたい情報量は少なくてよくなる。だから、slackでのコミュニケーションは短い。
メールは元メールを引用した上でやり取りを冒頭なりインライン（このやり方はとても合わない）で往復させるので、気が向けば大元に戻って記憶を整理し直せる。しかし、小さな情報量となっているslackは自分の記憶なりスレッドなりで追いかけなければならない。その上、レスが付いても見つけにくいから結果的に放置をしてしまう。
メールもそうだが、slackも投げっぱした方が主導権を取るコミュニケーションである。メンションをつけてどうかを確認するポーズを取る。噛み合っていればまだマシだが、そうとは限らないから堪らない。
気づくと自分の仕事をする時間より、slackで溶けていく時間の方が多いのはメールと同じだ。メールも絶滅していないから、そっちも時間を溶かす一因である。
生産性をあげるのがコミュニケーションツールだった気がするのだが、返って生産性を悪くしているような気がしてならない。
23日のローストチキン
23日は天皇誕生日ではなくなったから、休みではなくなった。去年までなら、23日にクリスマスケーキと食事を用意して、家族の団欒をしていた。美味しいもの買い込み、テーブルクロスを広げ、CAVAなり、ノンアルのスパークリングなりを開けて、最後に小さめのブティックのクリスマスケーキを食べてお開きだ。
23日が休みで無くなるというのは昭和に戻るような感覚を持つ。24日や25日クリスマスケーキを買うのだ。平成に代わり23日が祝日となったため、ホリデーシーズンは長くなった。クリスマスケーキも23日から注文することができた。今年のカタログを眺めると、23日にクリスマスケーキを用意するブティックは減った。
子どもさん達も大きくなり、それぞれのスケジュールで生活をしている。恋人がいれば恋人と過ごすようになる。クリスマスケーキは24日か25日だから仕事帰りにと考えると早仕舞いしなければ、支度も大変だから食事にありつけるのは遅い時間になってしまう。
ワイフとどうしようかと話して、クリスマスケーキは止めることにした。食事も日にちをずらして機会を設ければいい。そういう話になった。
これが10月下旬だったか、11月上旬の頃の話だ。
今月に入り、ワイフが短期の入院をすることが急に決まり、それが23日だった。本来の手続きなら3ヶ月後とかになるらしい。話の展開が早く、あっという間に決まった。
子どもさん達が小さい頃は、peckのチキンを注文していた。過去形なのは、取り扱いがなくなってしまったからだ。フィリングにレバーが使われていてお気に入りだった。その扱いがなくなったので、別のお店に変えてみたが、どうも違う。有名ホテルのチキンで半ば妥協して数年が経っていた。
23日は日曜日で、デパートではクリスマスムードを押し出していたが去年ほどクリスマス感の客はいなかった。そんなとき、生の丸鷄が手頃な値段で並んでいた。確か、去年までは売り切れていたような記憶があった。
クリスマスの食事をするつもりはなかったけれど、中に詰め物をしてローストチキンを作ってみようと思い、手頃なサイズを買い物カゴにいれる。
ピラフを作り、鶏を処理してフィリングを詰める。230度で40分、200度で20分、そのまま余熱で10分。塩胡椒の鶏、3種のハーブをアクセントにしたピラフは鶏の油を吸って甘みを増す。
ワイフに声をかけて、ローストチキンをテーブルに出す。どうやら口にあったらしい。もう23日にローストチキンをどれにしようかと悩む必要がなくなった。
![ダッチオーブン極楽クッキング[雑誌] エイ出版社のアウトドアムック](https://images-fe.ssl-images-amazon.com/images/I/51D-HOM%2BhvL._SL160_.jpg "ダッチオーブン極楽クッキング[雑誌] エイ出版社のアウトドアムック")
プロジェクトで失敗しないチームの要素
システム開発のプロジェクトで割と結果を出せていたのはある意味不思議と言えば不思議なのかもしれない。
世の中では、プロジェクト自体かなりの割合で失敗しているとか（古いPMIのNetwork誌だったか）とかウォーターフォールの失敗の割合とかアジャイルのプロジェクトの失敗とかをときどき見かける。
ご想像のとおり金額で言えば大規模なプロジェクトではないし、小さい方かもしれない。ただ、プロジェクトの規模が小さければ、案件数は大規模に比べて数桁も多い。規模の小さいプロジェクトは元々のQCDのリソースのサイズは小さいので1つ間違えると致命的になるのは想像に難くないだろう。
どのプロジェクトでも、その中で特に立て直しのプロジェクトに巻き込まれたり、召喚された場合、何をやっていたかと言う言えば、色々と思いつくことやらなければならないことをあれこれとやっていたのであるが、思いつくことを書き出してみるとこんなことをやっていた（はず）。
- プロジェクト目的の刷り込み
- プロジェクトのカルチャー作り
- 自律したマインド作り
- 個々のエンジニアのスキルの理解
- エンジニア同士で言い合える関係
１は、プロジェクトの仕事のゴールである。これを曖昧にしておく理由はない。終わるまで続ける。
２はプロマネの考え方、例えば項番3以降を実現できるチームをプロマネが作りたいと思っているから、それを具現化できるチームの文化を作ることである。
3は、プロマネが指示するは、プロジェクトの目的の設定、向かう方向、進むスピードであって、エンジニアへの箸の上げ下げではない。であるから、それに少なくとも理解してもらえるためのマインドをチームとして持たなければならない。
4はプロジェクトであるからプロジェクト目的の達成に必要なチームとしてのスキルセットがあるはずで（これについては何度もこのブログで取り上げている）、個々に違うスキルとスキルレベルを持ったエンジニアを招集している。それが前提になければおかしい。その前提を理解し、エンジニアひとり一人違うバリューを持っていることを受け止められるチーム作りを必要とする。これがないとただ経験の長いエンジニアがろくに成果を出せないのに若手エンジニアにマウントしたり、若手エンジニアが忖度してしまいかねない。そんなのは求めていない。ここに違いがあることを受け止め、相互に尊敬がなければならない。
5はプロジェクトチームは4を前提として1を目指すのだから、それぞれのスキルやレベルを根底に、ロールの役割を果たさなければならない。そのミッションを履行するためには、つまらないと思ったことでも言える関係でなければならないし、他のメンバの視点は自分にないものだとして、ニュートラルに傾聴する心根を持ち合わせていなければならない。決めつけや思い込みをなくすための1つの方法でもある。
この他に当たり前のようにプロセスデザインやプロジェクトマネジメントなど色々とするのであるが、それもやるし、そうした成果に直接結びつくことと並行してチーム作りをしていると案外とプロジェクトは失敗しない。
退職エントリまとめ（2019年10月〜12月）
2019年版の退職エントリのまとめ。大晦日までは10日ほどあるが、毎週末に四半期ごとにまとめてきたので、10月から12月分を。
例えば10月の退職エントリを同じウインドに開いていくと、タブはみるみると小さいくなり、しまいにはファビコンだけになってしまう。感覚的に以前そのようなとき、ファビコンははてなばかりだったような気がしないでもないが、今では半分くらいnoteの水色のファビコンが占拠している。
ブログなどはすっかりレッドオーシャンな気がするが、ビジネスというものは面白い。何が流行るかわからない。
プロダクトは放っておけば継続的イノベーションの戦略を取るため複雑怪奇になっていくが、新しいプロダクトはポジションを確保するために対局のシンプル路線を目指すのはどこも同じだ。
第4四半期はドワンゴ退職エントリと現職エントリと営業目線のエントリとそれを取り巻くエントリで賑わっていたようだが、全く記憶に残っていない。
さて、2020年は作業平準化の観点からも、月刊にでもした方が良いかもしれない。
これからの10日間よりは年末年始のタイミングで退職エントリが増えそうだが、それはそのときにどうするかを考えることにしよう。
10月
さくらインターネットをやめて博士課程に。
9月に退職。戦力外通知…。
特許商標事務所の方。
SREエンジニア。
メンタルは辛いねぇ。
VRか。
青いRの。
赤いRの楽天から。
ドワンゴ、これが発端なのか。
タイトル詐欺では。
学童の会社、でいいのかな。
DeNAを退職。モバイルエンジニアさん。
9末で退職。
近畿大学を退職。
高円寺の会社だった人。あそこか。
退職は5月。
11月
ドワンゴ在職エントリ（転職エントリの対として）。
ドワンゴ営業サイドの。
ドワンゴ退職エントリ…。
前々職がドワンゴで引っ張り出してきたエントリ。意味あるの。
退職エントリをリファクタリングして遊んでる。
商工会は地雷臭しかしない。
メルカリを退職して創業。アイヌ語なのか。
LINEだった人。
絵師さんか。執筆時点では無職。
12月
退職したのは５か月前。
1月に転職したのか。
1年前に。
つらみ。
エージェント系を使って転職。
fumisan.hatenadiary.comfumisan.hatenadiary.com
あなたの業務改善は業務のほころびのITパッチワークでしかないのではないか
業務の機械化、今ではITに置き換えるには2つのアプローチーがある。ちなみに、置き換える手段はなんでも良い。ガッツリとスクラッチでコードを書いてもいいし、サクッとSaaSでやれるならそれでもいいし、RPAでハンコをペタペタと押させてもいい。
そのアプローチの1つは、業務担当の困っていることを単純にITに置き換える方法だ。計算ミスが多くて月末月初になると残業が多いとなれば、集計を人手からITでルールをコードで書いたプログラムに置き換えるかもしれない。
転記が多くてミスが頻発しているなら、転記をしなくて済むようにデータを繋ぐかもれない。
よくある業務改善の風景である。こうした解決は単にToDoをこなしているだけで、業務のほころびをITでパッチしているようなものだ。
業務にパッチばかり当てる仕事ばかりしていると、エンジニアの仕事は要件は業務サイドから明確に出てきて、ToDoをITで業務のパッチを作る下請け作業が仕事だと身に染み込んでしまう。
こうした考えが身についたエンジニアは、得てして『業務改善が好きだ』『現場の課題を解決することは役に立てるので続けたい』という傾向がある。
そうした志向は良いものかもしれない。
しかし、これでは一向に業務の不具合をITで繕っているだけでしかない。本当の業務の機械化でしかない。
こうした業務の機械化、業務の不具合のパッチばかりでは、ITの利用者である業務の担当者にITに接する時間を増やしている反面、ITで業務を良い方向に変化させるという観点は一切ない。
業務を機械化することの価値を作っているのは業務の担当者であり、パッチ作りをしているエンジニアは仕様に基づいて業務パッチを作る下請けでしかないのではないか。
エンジニアなら、ITを使うことで業務を良い方向に変化をさせたい。
![[柴田明美のパッチワークキット]干支の額シリーズ2020「ねずみのファミリー」](https://images-fe.ssl-images-amazon.com/images/I/41gpFEIcO1L._SL160_.jpg "[柴田明美のパッチワークキット]干支の額シリーズ2020「ねずみのファミリー」")
来年にやらないことを決めておくこと
もう年末進行のような状態が続いているのは、業務量は変わらない一方で年度末の評価や新年度の準備を始めようとするからである。では年末でない時期に調整してやればいいのであるが、業務量は波があるとしても一定のボリュームがあるので、なんら解決にならない。
以前述べたかもしれないが、プロジェクトや業務の活動テーマにおいて『やること』より『やらない』ことを決める方の効能は大きい。やることは、放っておくといくらで山積みを始めて溢れ出す。やらないことは、実はとても決めにくい。ルール的なもの、たとえばこんな振る舞いはしないのようなものであれば、やらないことを決めるのは案外易しい。
しかし、課題や取り組みなどは、ついつい『やった方がいい』と言う思考にはしりがちだ。実際に、チームで来年の活動テーマを話してみるといい。
- 来年度やりたいことをリストアップ
- やりたいことをグルーピング
- やること、やらないことの仕分け
- やりたいことを四半期で完了時期を設定
- 必須とできればと線引き
- チームの新年度の活動テーマの出来上がり
2のグルーピングは、メンバから出てきたやりたいことが多々被るのでKJ法的にまとめているだけである。
3のやることを選ぶ際に、やりたいメンバが自分でやりたいと言わなければならない。誰がオーナーシップをとるかをその場で宣言するようなことをするのは、やった方がいいを排除するためのリトマス試験紙でもある。
上手くいって90分で4まで進めばまずまずである。2でグルーピングするときに何をするかヒヤリングは入るし、似て非なるテーマがあればそれの確認で相当時間を使う。
実際、いくらやりたいことをリストしても確保するリソースの中でしかそれをできない。必須としてもいくらでも差し込みで緊急度の高い案件は割り込んでくる。
ただ、そうであっても何をやるのかの共通理解を作っておくのは良いことには違いない。そうしたプロセスを経たことの意味は大きい。
意見を言うとそれに同意するのに話を蒸し返すのはやめて欲しい
進捗が芳しくないプロジェクトのミーティングに呼ばれて、気になることをいくつか質問することはよくあるシチュエーションかもしれない。
ミーティングの主催者自身で考えたプランにロジックがあるなら、少し修正をするなり、追加のアクションをするなりでリカバリできるだろう。
しかし、ロジックがない場合は、そうは行かない。
そうした状況であるかどうかは、会話の中である程度判別できる。例えばこちらから気になる点を質問を投げ掛けたときの表情を見るといい。だいたいわかっていない表情をする。頭の上に？マークが3つくらいチカチカしているのに、口では『そのとおりですね』『（コメントの）考え方の方がいいと思います』などと言う。
でも、顔つきはおかしい。
全く理解していない。
こういった反応をするエンジニアは、100％自分の考えが良いと思っており、他者の考えの良いかもしれないところを受け入れようとしない。
そのまま進めるか、進められずスタックして、またミーティングをする。そして話を蒸し返す。
前回のミーティングはなんだったのかと小1時間詰めたくなっても仕方がないだろう。
ぶっちゃけ、ゴール設定ができ、それを自分で引いたスケジュールで進捗するのであればどんなやり方であってもいいのである。
でも、進捗しないからどうして良いかわからなくて、ミーティングをセットする。しかし、思うように進まない理由を解消する銀の弾は得ることができなくて、消化不良のままその場は終わってしまう。
本心は自分のやり方は問題がなくて、周囲の関係者に問題があり、それを指摘し、それのアドバイスが欲しいのかもしれない。でも、原因は、進捗できな本人のロジックにある。
それを気づかせないのは、上手くいくとお花畑のようなプランを疑わないからである。
それなりに経験を重ねていると、上手く行かない前提でプランを構築する。そうしておかないとバッファはないし、考慮不足時に自分の首を絞めてしまうからだ。
力量不足であることを常々意識し続けたい。
