大学中退から始める娯楽入門

学んだら書くためのブログ。すべての人を幸せにしたい。

議事録から働き方改革

議事録めんどい

会議の役割で一番しんどい&めんどいのが議事録係だとと思います。
会議中に集中力を切らさずに参加者の文言をもれなくまとめていくという高等スキルです。
しかも書いたとしても会議後に
「議事録連携します。認識齟齬等あればご指摘お願いします」
といったダイイングメッセージのみで、
殆どの場合は認識齟齬が合っても修正されず、一生懸命取った議事録は読まれず
多くのメンバーが疑似の内容についてメッセージしくてるという惨劇が日々起こっているのではないでしょうか?

解決策

いくつか議事録に対する具体案を2つ上げてみます。

議事録駆動会議 MDM

会議自体を議事録をなぞりながら進めるスタイルです。
アジェンダの切りのいいタイミングで議事録を会議参加者で作っていきます。
これで議事録担当者の負担が減り、会議での認識齟齬が減ることでしょう。

みんなで議事録

議事録を全員で書きます。
自分の意見は自分で議事録に残して置きましょう。
共有で編集できるツールがあるとなおよしです。
これで議事録はしっかり残るし会議への参加具合が明らかになると思います。

※参考資料 Grow With Googleの「はじめたの働き方改革」でいろいろ教わりました。
こちらの@Udemyコースはいかかでしょうか: はじめての働き方改革 https://www.udemy.com/share/1014mEB0oTdFdRQHQ=/

コミュニケーションが雑すぎて会社員に向いてない

「あー仕事したくねー」

日曜日の夜になると毎回思ってしまう。
私は仕事をいわゆる報連相ができない仕事を溜め込んでしまうタイプだ。
頼まれた仕事は基本的にすべて受けてしまう。
頼まれたからにはなんとかしてあげたいと思うのだが
結局できないので、結果信頼を失ってしまう負のループが生じている。
実際は仕事は嫌いじゃない、むしろ好きなタイプと自覚をしているが
仕事のミスをしたときに逃げる癖がある。
それは社会人を6年ほどやっても、ほとんど成長していない部分でもある。
怒られるのが嫌だから限界まで逃げたい。

逃げることが生きること

何度も逃げ癖については治そうと思って
スクラムという開発手法から心理的安全性について学んだり
Yahoo! アカデミアの講座に参加したりしてきたが治りそうにもない。
もはや治す必要はなく、これは自分の強みなのではないかと思うことにした。
でも逃げ癖を生んだ根本について考えなくては
この悪癖に悩まされる夜が今後も訪れてしまうだろう。

失望させたくない

私が逃げる理由は人をがっかりさせたくないからだ。
こんなこともできないのか、こんなミスをするのかと失望させたくない。 必要とされるため期待を背負って結果逃げる。
本当に悪いループにはいっている。
信頼を得たくて期待をされて失敗する。
最悪だ。

期待をさせるな

相手に期待をさせるから、失望がある。
自分の現実を見つめて、できる範囲で生きればいい。
仕事なんて人生の一部分に過ぎない。
その時間を少しでもストレスのないものにするために 誰からも期待をさせない。
測れる実力と時間でできる範囲の仕事をしよう。
無駄な期待による失望を産むのはやめよう。

誰も期待するな

私は最低限の時間でそれなりの給料がほしい。 勉強会に行きたいし、ドラムもスノボも上達したい。
だから失望させないために断りたい。
仕事は最低限でいい。
それは失望させないためだ。
仕事で人生を押し出されたくない。
だから期待しないでほしい。
私は残業をしてまで仕事を完遂しない。

コミュニケーションが雑すぎて

みんなに優しくしたいから 「きっと終わります」「がんばってやります」 「ぼくやっときます」 という言葉が出てきてしまう。
優しくするというのは雑になっているだけだ。
疲れているのだ。
責任を持つことにも持たせることにも。
責務の監視に疲れている。
このような状態になったらすでにおしまいだ。
そもそも疲れる前に責任の管理をしなくてはいけない。
でもコミュニケーションが雑すぎてもいいではないか。
それは受け止める側がなんとかしてほしい。
コミュニケーションは発信と受信の両者に責任が持たれる。
でも雑コミュニケーションで責任を追うのは発信者だ。
その責任を受け取る側も持ってほしい。
雑だと思ったらすぐに指摘してほしい。
期待してほしくない。

コミュニケーションが雑すぎて会社員に向いてない

つまりこういうことだ。
コミュニケーションは発信側に責任が生まれる。
受信側は「こういう意味だと思った」といえば無罪放免だ。
責任を負ったら給料は増えない。
評価はされない。
責任をとっても企業に務めている限り何も得はしない。
会社員こそ責任とはできる限り離れて生活するべきなのだ。

結局、お金がほしい?

何がしたいか?

仕事で人間関係でちょっとした悩みがあり
「相手はなんでこんな要求をするのだろうか?」
「なぜ私はこんなにつらいのだろうか?」
と思考してみました。
一通り整理がついたのでpukeします。

問答

ディレクターとのある会話。
私はあるプロジェクトのエンジニア代表的なポジションにいました。
最初のリリースで私はMVPでリリースする想定いましたが
ディレクターは最初の構想通りのリリース想定という思い違いがあったのです。
私はMVPでリリースしてユーザーの反応を見てから次の開発判断をしたからった。 MVPでリリースするという構想が全く伝わっていなかったのが最大の問題でした。
本当ごめんなさい。とだけ心の中で唱えておきます。
でも
「○○さんは、なんでそんな細かくリリースしたいんですか?」
と言われて若干ムッとしてしまった。
この機能をリリースして本当に効果があるのかわからない。
しかも多くの改修を加えたところで、それを直してテストをするのはエンジニアなのだ。
予定が遅れれば残業するリスクを抱えているのは我々なのだ。
余裕を持って工数を伝えることはできる。
でもそれで負い目を感じるのは我々なのだ。(見積もりは本当にきらいだ)

ともろもろ思ったところで何もおこならないので私は週末のスケジュールを確認して納期とスケジュールを飲み込んだ

結局、お金

私はサービスをより多くの人により便利に使ってもらうために
エンジニアをやっていると思っています。
一番うれしいのは初めて会った人が私の作ったサービスを使っていたとわかったときです、、、、、、、、、、

というのはきれいごとでした。 サービスを使ってもらって嬉しいのではなくて
サービスを作ってもらうことによって自分にお金が入るのが嬉しいのです。
社会的な評価があがる気がするのがうれしいのです。 社会的な評価があがることによって、次の転職先で給料があがることが嬉しいのです。
結局はすべて金儲けです。
ディレクターも自分が担当したプロジェクトがある程度の納期で
宣言したとおりの機能が作れていれば評価があがって給料が上がるから
先程の問答になったのでしょう。
結局、お金なのです。
結局、仕事はお金のためです。

それでも私は

より人々を幸せにしたいと思います。
私がお金を得てしたいことはまず家族を幸せにしたい。
更に余裕があれば友達を幸せにしたい。隣に住んでる人を幸せにしたい。
そして世界中の人を幸せにしたいと思います。
そのための手段はお金だけではもちろんなく 時間、すなわち命をかけて人を幸せにしたいです。

ソースコードレビューの際に気をつけること(備忘録)

コードレビューどうやるんだっけ?

プログラミングのレベルは大して上がっていないんですが
業務上ではプログラミングをするよりコードレビューをする場面が多くなってしまいました。
それにあたって、自分なりに判断基準をもってソースコードレビューを行うために本記事にまとめる。

ポイント

  • プロダクトのバグを減らすのと保守性向上のために行う
  • 開発者、レビュアーともにプロダクトの仕様理解につながる
  • チェックリストを用いて漏れなく迷いなくレビューを行う

ソースコードレビューはなぜやるか?

レビューに関わるのは開発者とレビュアーになります。
レビュー後にプロダクトはどうなるかと登場人物の行動を考えてみる。

開発者

  • レビュー指摘を持ってソースコードを修正する
  • 仕様の知識が増える
  • コードの知識が増える
  • 効率の良い処理の記述方法を知る

レビュアー

  • プロダクトの仕様がわかる

プロダクトはどうなる?

  • ロジックのミスが少なくなりバグが減る
  • ソースコードの可読性が高まり追加開発の際に効率がよくなる

レビューで辛いこと

現時点でレビューでの辛みを考えてみた。
今回の記事はレビュアーとして視点だけれども
両者からの観点でつらみを考えてみる。

開発者観点

  • PRの説明を書くのがめんどくさい
  • レビューをもらうのが怖い

レビュアー観点

  • 開発者の意図がわからない
  • そもそも仕様理解も必要
  • 辛いレビューをするのが大変
  • そもそも自分がそんなに知識がない → わたし

ソースコードレビューでのチェックリスト

これは開発者とレビュアーが両方使えるチェックリストになる。
PRとDIFF(ソースコードの差分)ごとに用意した。
これを漏れなくチェックすればソースコードレビュー漏れはないかもしれない。
少なくともレビュー時にチェックリストを思い出す脳内メモリが節約できる。
チェックリストが埋まらない部分があればすぐ聞くことである。

PR

  1. 説明文で仕様がわかるようになっている
  2. PRのタイトルと説明文が一致している
  3. UI変更がある場合にスクリーンショットもしくは動画が記されている
  4. 設計思想がわかるようになっている

DIFF

  1. 変数名に誤植がない(名詞、動詞のスペルミスはないか)
  2. コメントに誤植はない
  3. インデントに誤りがない
  4. プロダクト全体の設計パターンから大幅にずれていない
  5. 既存のライブラリの再開発を行っていない
  6. 冗長な処理を記述していない
  7. 共通のオブジェクトを用いている場合、オブジェクトの中身が保証されている
  8. 処理の順番が実現したいことに大して等しい

参考資料

コードレビューの際に気をつけること - Qiita

昔いた会社にスクラムの考え方を徐々に浸透させてみる

RGST2019のAdventCalender Day24!

adventar.org

昨日はtakakigさんでした!

日々アウトプットを意識していますがなぜって部分は深く考えたことがなかった。。
私もアウトプットの理由を自分自身に問いかけながら本投稿を進めていきます。

takaking22.com

昔いた会社にスクラムの考え方を徐々に浸透させてみる

伝えたいこと

  • あらゆる業態、業界であってもスクラムの知識は役に立つ
  • RGST2019ではたくさんの人と話したいよー

金融業界での失敗

個人的な体験談です。
今でこそ、ゆるふわなWeb企業でゆったりサービスを作っていました。
1個前は6ヶ月間ほど金融系企業のシステム部門にいました。

そこでは1人に1システムを担当し業務内容はプログラミングや設計書作成は一切なく
発注している会社にシステムの不具合や要望をエスカレーションするだけでした。

仮に障害が起こっても電話をすることしかできず何もできない。
同じ会社の人間も他人の担当のシステムは全く無関心。
当時は上司が部長でしたが、システムのことは知らない天下り部長でした。

結果として体調を崩して退職しますが、当時の自分はすべてを組織のせいにして何も改善をしようとしていませんでした。

問題点を振り返る

あまり思い出したくない過去ですが頑張って振り返って
当時の組織の問題を重要度順で2つ考えました。

  • サービス間で責任分離されており当事者意識がない
  • 組織改善のサイクルが回せていないため成長が遅い

スクラムでの解決策

最初からスクラムを導入というのは難しく、
なまらスクラムフレームワークに当てはめてもよくないことが多いので
スクラムの考え方を部分的に少しずつ浸透させていくとよいと思いました。

サービス間で責任分離されており当事者意識がない

スクラムの必須となる当事者意識の醸成が必要。
ビジョンの共有を行いましょう。
現状のサービスレベル、チームレベルでの問題点を洗い出し
ビジョンとの差異について目線合わせができればよかった。。。

 

www.lifehacker.jp

組織改善のサイクルが回せていないため成長が遅い

定期的なレトロスペクティブを行える状況を作る。  
業務の評価を週次で行い、障害は事前に防ぐ。
障害が起きるたびの振り返りであモチベーション的にも辛いし
実際に障害の対策の話しかできないので効果が少なそう。

振り返りについては様々なプラクティスがあるので
障害などが起こったタイミングで提起すれば良さそう。

個人的にはエモーショナルグラフがおすすめです。

nulab-inc.com

今後の活動

業務ではスクラムに拘らずにサービスとチームをよくするために動く。
社会的にはアジャイル開発の考え方を浸透させてより
楽しく仕事をするためのヒントを提供していきたい。  

[宣伝]LeSS Huge!

1日目に東名阪を跨いだLeSSのお話をさせていただきます。
LeSS Hugeはもちろんリモートワークでのチーム開発に興味のある方や
大人数チームでの開発事案としてレアな話ができると思いますので、ぜひ起こしください!
そして飲み会には進んで参加しますので、みなさま仲良くしてください!!!

confengine.com

 

Cycle inside TownMap; building could produce unreliable results....

経緯

本日のコンパイル事件簿。 carthageで使っていたSDKをpodに乗せ換えた。

error: Cycle inside TownMap; building could produce unreliable results. This usually can be resolved by moving the shell script phase 'h' so that it runs before the build phase that depends on its outputs

とりあえず注意も読まずにClean Build Folderしてpod updateして再実行。

...

したら通った。 意味はあとで調べるとしてよかった。

スクラムマスターになれたから今の自分がいる〜抜擢編

5分で読める投稿です。

ポイント

  • マネジメント経験を活かして入社3ヶ月目でスクラムマスターに抜擢
  • スクラムとはプロダクト開発を最高に楽しむ方法の一手段

経歴

私はスクラムマスターの経験から「結構人生楽しいんじゃないか?」と考えられるようになってきました。

下請けシステムインテグレーター 21歳
↓
金融の社内SE 25歳
↓
充電期間
↓
Web企業 27歳

私は大学を3年で中退しています。
単位は問題なく取っていましたが部活や遊びすぎでお金がなくなって就職という道を選びました。
就職のタイミングではプログラマーになろうとは考えていませんでした。
給料が大学卒並に貰えてホワイトカラーならどこでもいいと思っていたので 、出版社や家庭用品の営業なども受けていました。
その流れで最初に受かったのが下請けシステムインテグレーターでした。
当時は業界の情報も全く知らなかったので1回目の面接で内定がでたので 「この企業は私にこんな期待してくれてる」と本気で喜んでしまい入社を決意しました。
1社目の会社ではそこそこの成果を収めて3年目に周りが金融系企業のの社内SEに転職します。大学卒以上しか取らないような企業だったので私はこのとき「やっと周りに追いつけた。まともな会社に入れた」と思いました。 このときの仕事は1文字もプログラムを書くことはなく ひたすら営業や業務部門からの要望を下請けのシステム会社に引き継ぐというもので、いわゆる責任だけを取らされるポジションでした。その結果、激務と慣れない調整業務に全く慣れず6ヶ月後に体調を崩し突如退職します。
そこから3ヶ月ほどの休養期間を経て今の会社に転職しました。

スクラムマスターに抜擢された理由

今の企業は良い意味で風通しがよく社員個々のレベルがものすごく高いです。
ただBtoC企業で締切などに対する意識があまり高くなく、ゆるい組織でした。 入社当社は大きな衝撃を受けて、あらゆる人にそのゆるさを訴えてきました。 そして朝会などでのファシリテートも積極的に取りに行って組織のゆるさの改善に自らの力で取り組んでいきました。
年も若く、突出した技術力のない私がいくら行動しても影響力はないと思っていましたが、そういう背景もあってかLeSS-Hugeを導入するにあたってスクラムマスターに抜擢されました。
旧組織での経験を現職と融合させるのが中途入社者の強みです。私は喜んで前職で身につけた仕事に対する責任感を今の組織に活かしていく方法としてスクラムマスターの役職を受諾しました。

スクラムとはプロダクト開発を最高に楽しむ方法の一手段

スクラムマスターになるにしてもスクラムのことは初心者だったのでめっちゃ勉強しました。
Scrum Boot Camp に始まりファシリテート入門など必要そうな本は読み漁りました。
セレモニーなど形式的な部分は一通り覚えましたが
私はスクラムとはプロダクト開発を最高に楽しむ方法の一手段と考えました。
常に振り返りを行ってプロダクトとチームを成長させていこう
ROIを高めながらみんなで幸せになろう。
そのお手伝いを推進していくのがスクラムマスターの仕事と考えました。 例えば、リファインメントではストーリーに対する不安をチーム全員で吐き出して見積もりを進めます。
このリファインメントを行えば不明確な箇所がなくなり、みんなが腹落ちしている状態になります。
「わからないけど、どうせ自分は作らないからいいや」
という感じにはなりません。
レトロスペクティブではチームの全員がチーム運営の課題解決の答えを探します。
組織改善がリーダーに一任されることなくチーム全員の課題となります。
課題は解決させるよりも、自分で解決するほうが絶対効果的です。

私は楽しいチームを作りながら強いプロダクトを作りたいと思いました。
そこで意識したのは下記の2点

  • スキルマップの平準化し業務の属人化を減少させる
  • エリアの課題をチームに積極的に持ち出して全体の課題解決の意識の醸成

ただ志高く望んだものの最初の半年は正直失敗でした。 (次回につづく)