runaround’s diary

なんとなく、つれづれ

カンバンによるムダのカイゼンの事例　を聞いてきたよ

お勉強

今日はGW前のスプリント振り返りもあってぐったりしながら、この勉強会に参加してきました。

devlove-kansai.doorkeeper.jp

デブサミ行きたかったなーと思ってたんですが、登壇者の高橋さんが関西で再演してくださるということでありがたやありがたや・・・。

今回は資料に加筆されていたようですが、諸事情でUPはまだとのことですのでデブサミの時のスライドをここに貼らせていただきます。

speakerdeck.com

 

カンバンに関してはうすーい知識のみですがざっくりとは知っていまして。

仕事ではJIRAを使ってタスクのチケット管理をしています。

 

あまり詳しくは書けないのですが仕事で最近問題だなぁと思うことが多くて、今日のお話を聞いてヒットすることが多く色々と思うことがありました。

 

以下、高橋さんと中村さんのお話を聞いてざっくりと殴り書きです。

 

見える化をするから、ボトルネックが見つかってカイゼンしやすいってことなのかなぁ。

 

振り返りについては、アジェンダを決めて行なっているとのこと。

フリーにしちゃうとぼやけちゃうんですかね。そういやTryがそんなに出なくてふんわり終わっちゃうことあるなー。

アジェンダ決めちゃうと他に言いたいことがあった場合、言いづらいってことはありますかね・・・。

 

新規参入者へのカンバンやカイゼンについての説明はチームメンバーが自発的に行っているんだそうで、いいチームだなーと。皆、納得してやっているから説明できるんでしょうね。

カイゼンでやり方がコロコロ変わるとメンバーは戸惑わないのか？との問いには、基本的に振り返りでTryが出て、皆で決めたことを試してゆくので不満は出ないんだとか。

まぁ、つまりですよ。チームを管理する人が一人で頑張って決めたことをメンバーにやれ、っていうのは大体上手く行かないとのこと。

激しく同意します。

 

面白いところではDoneになったふせんはどうするの？って疑問。

ふせんは時間が経つと剥がれやすくなるので、捨てちゃうことが多いみたいですね。

残しておいて束になったのを見るのもモチベーション上がっていいかも、というお話も出てましたw

 

デジタル vs アナログ について。

導入時はアナログの方が手軽にはじめられていい、というお話が。

デジタルだとツールの仕様を理由に（というか言い訳？）管理できないものが出てきたり・・・

ただ、ツールは同じものを使い続けるとフォーマットが揃っているので過去のデータによる分析ができるメリットもあるのでは、というお話も出てました。

 

あとカンバンの奴隷にはなっちゃダメだ、とw

カンバンの管理に必死になるのは良くないですね。目的が違う。

 

高橋さんのお話でコードレビューによる手戻りの話がありまして、カイゼン策として「最初に設計して認識を合わせて合意をしておく」という下りが。

丁度気になっているところだったので質問して具体例について教えていただきました。

  • publicメソッドはメソッド名を決めておく
  • privateメソッドは多少うんコードでもOK
  • テストケースを先に書く
  • クラスにこだわってレビューが炎上するチームならクラス図を書いておく
  • of とか with とかでモメるチームの場合、英語表記はこだわらないルールにする

なるほどーと思いました。合意しておくと手戻りの時間も短くなりそうだし、特定の人の良くわからないこだわり等で振り回されてレビュー終わらない問題も解消されるかなと。

 

今日の結論。

 

チーム皆で手分け・協力して決定、調査、開発。

これがまるっと幸せ。

第8回　関西DB勉強会　に参加してきたよ

お勉強

本日はこちらに参加してきました。

kansaidbstudy.connpass.com

 

参加が初めて、グラフロのナレッジキャピタルタワーに行くのも初めてでして。

案外サクッと場所がわかったし、とても和やかな雰囲気の会場で安心しましたー。

女性率はかなり低かったですが。

 

DB自体そんなに詳しく無いのですが、色んなDB達の話を聞けて理解できる部分も断片的だけどあったし良かったです。

 

仕事ではMySQLを使っているので8.0リリースのお話が聞けて何より・・・というか、jsonからテーブル作っちゃうのは一番ビビりました。

データの型としてjson型があるのは以前から知ってはいたのですが、まさかこんなことが出来るようになるとは・・・。

今後使う機会がくるかどうかはわからないですが・・・w

 

「クラウドを活用した位置情報分析の活用事例」はDB寄りというよりはサービス寄りの話を沢山していただきました。

 

RDBに呪われてきた私としては目からウロコの話ばかり。

過去の知識に囚われていると新しい技術やデータ設計の話についていけなくなりそうですね。今後もしDB選定のチャンスに恵まれても困らないように、勉強しておかないとー。

 

ユーザーさん側のセッションもすごく面白かったし、DBベンダーさんの貴重なお話を聞けて本当に良かったです。

Women Techmakers in Kansai - IWD18　に参加してきたよ

お勉強

今日はこちらに参加してきました。

wtmkyoto.connpass.com

時々参加させていただいている関西Java女子部のきの子さんにお声がけいただいて、申し込み。学生さんも来られるとのことですごく楽しみでした。

LT発表できるようなネタがなかったので、お話を聞く側に徹しておりました。

（色々とチャチャ入れてましたが・・・）

 

会場はエムオーテックス社のカフェテリア。すごい素敵。

ラインティングも雰囲気いいし、カウンターもピアノもあって・・・。

 

ゆったりと会が始まり、LTがどんどん行われていきました。

きの子さんがScalaとKotlinのお話中、憎っくきnullの話題が出てきまして。

参会者の学生さんたちはプログラミングの初級者ということもあって、色々と丁寧に説明されていました。

あとクラスやインスタンスの説明も。

 わかりやすく説明する、というのはいかに難しいことなのかを再認識しました。

 

今回一番取り上げられていたのはFlutterのこと。

jp.techcrunch.com

アルファからベータになってかなり導入しやすくなったのと、チュートリアルも充実したこと、などとても詳しく説明していただきました。

あとDart言語もちょっと面白そうですね。

私はずっとJavaに呪われた人なので大体Javaと比べることになるのですが。

やっぱ手数が減って読みやすそうだなぁーという感じ。

 

学生さんの発表は、プログラマーのお母さん（！）がかっこよくて自分もやってみたい！とSwiftでアプリを作ってみたお話。

環境でエラーが出まくったり何度も作り直したりして大変な思いをしたとのこと。

でも、作るの面白い！という感想。・・・すごい！

エラー出まくってよくわからなくなったら凹むと思うんですが、それでも面白いと思うなんて、ほんとすごい！

そしてお友達は国際学や観光学専攻の方で、ゲームが好きなのでUnityでゲーム作ってみたんですって。

お友達のプログラマーのお母さんに色々教えてもらったり、自分でキャラクター描いてみたり。

彼女はそれまでPC持ってなかったんだって・・・。ゲーム作るためにPC買ったそうです。

彼女はプログラミングもよくわからない、英語のドキュメントもよくわからない状態から頑張ってみたとのこと。

自分が考えた通りに動いたのを体験して、すごく楽しかったそうです。

それにLTも堂々、しっかりお話されていてほんと素晴らしかったです。

これからもぜひ色々作って楽しんで欲しいなぁ。

 

仕事としてプログラミングをするとまた別の事情は出てくるんだろうけど、まずはものづくりの楽しさ、面白さ、（そして時々辛さ）を楽しんでもらえるといいのかなと。

 

それにしても若さってすごいなぁと再認識（こら

情熱ですよ。パッション。そして明るい。

 

LTが終わりにごり酒と羽二重餅やお菓子をもぐもぐ。

大変楽しくおしゃべりさせていただきました。

コミュニティ運営の大変さなどについても貴重なお話していただいたり。

イベントに参加できて本当によかったです。ありがとうございました。

 

それにしても皆さん精力的に活動されていてホント頭が下がります。

イベント終了後、高速バスで遠方まで帰られる方もおられてびっくりしました。

 

私も頑張らないとー。

 

関西Javaエンジニアの会(関ジャバ) '18 4月度　でキャリアのお話聞いてきたよ

お勉強

今日はこちらの勉強会に参加してきました。

kanjava.connpass.com

 

前日まで補欠で繰り上がって参加できるようになりました。

人気の勉強会で申込数もキャンセル数もハンパないですね・・・。

できれば「キャンセルしない枠」「キャンセルするかも枠」で分けて申し込みできると良いのですけどね・・・。

 

珍しく？コードとか一切出てこない会。

でもエンジニアとして社会人として、キャリアを考えるのは大事だし、人がどんなことを考えてどうキャリアを積んで来たのか興味津々です。

登壇者みなさんが文系出身、過去に一緒に仕事をされたりして繋がりがあったとのこと。ほほぅ。

うらがみさん⛄️が哲学科出身だったり、だいくしーさんが昔毎日ボーリングしてたり、じゅくちょーさんが知らないことでも積極的に立候補してから猛勉強してたことがわかりました（え？

年収などの話題もあり。

だってやっぱ楽しく仕事してお金も沢山欲しいでしょ、誰だってーw

あとツイート禁止の話、めっちゃ面白かったwww

もちろんここでも書けませんけども。

 

コーディングを続けたい、という夢も素敵だし、

マネージメントだって技術、という話は激しく同意できるし、

海外のエンジニアと交流して視野が広がる、というのは私も体験していて本当にそう思います。

 

私といえばコーディングは嫌いではないけれども没頭はしてないのかも。

どちらかというと業務を深く知って効率化するためにどんなシステムがいいのか考えて、作り上げて使ってもらって喜ばれてさらに儲かるとすっごく嬉しがるタイプ。

あとチームメンバーや上司、同僚にすごく尊敬できる人がいるとその場に留まりたいタイプだと思います。

だから、仕事が単純作業か尊敬できる人がいない職場からはスタコラサッサと抜けて来たw

あと居心地が良い場所は定期的に離れたくなるタイプです。（飽き性？

冒険してみたくなるのかなー

出世欲はほとんどないと思います。

あったら今の業界だけでポンポンっと４社も渡り歩いてないかなー。

 

今まで本能（野生の勘？）で渡り歩いて来て、嫌な目にもあったけれどそれが転機でいい方向転換できたりもしているので悪くないと思っている今日この頃です。

"個人のタスクマネジメント"のコツや悩みを話す場　に参加してみたよ

お勉強

今日はこちらに参加してきました。

devlove-kansai.doorkeeper.jp

 

もともと個人タスクは紙ベースで管理してたのですがTrelloを最近使い始めたヨチヨチユーザとしましては、皆さんはどんなタスク管理をされているのかが知りたくて知りたくて。

登壇されたお三方のお話もすごく面白くて（お風呂でタスクを思いついて記録するまで念仏を唱えるあたりがお話が被ってるw）。

その後ダイアログでも参加者の方々から貴重なお話を聞けたので、今後色々参考にさせていただこうと思います。

 

自分の個人タスクについては今後こんなことを試してみたいなーと。

（仕事タスクは現場でJIRAを使っていて、個人タスクとは全く切り離して別管理です。）

  • タスクを作っても時間を決めていなかったので、ポモドーロテクニックで時間を測ってやってみる。

    www.lifehacker.jp

  • タスクを完了するのにどれぐらいかかったか計測する。
  • ボードは１週間単位で作っていたが、切り替えが面倒なので１枚ボードで運用してみたい。
  • ただしリストは細分化してみる。
    「やりたいこと（夢含む）」
    「やるべきこと」
    「今週やること」
    「やったこと」
  • 面倒くさいことは拡張機能など探して試してみる。
  • 「やりたいこと」「やるべきこと」に定着するチケットは本当にやることなのか、定期的に棚卸しする。
  • 「やったこと」は墓場化する可能性が高いので、定期的に振り返る。
  • チケットに写真を積極的に載せてみる。（単に見栄えが面白そうだったので・・・w）
  • 思いついたら積極的に記録！（入力面倒なので音声入力使いたいけど、周りの目が気になる場面もあるのがね・・・）

とりあえずこれからTrelloにガンガン入力してにらめっこします。

モブプログラミングを実践してみよう!! 〜アジャイルモンスターのモブプロ入門〜　に参加してみたよ

先日はこちらの勉強会に参加してきました。

 

devlove-kansai.doorkeeper.jp

 

ワイワイと和やかな雰囲気でスタート。

各デスクにディスプレイを運んでチームに別れて・・・

あ、私今回は見学者ですw

ちょっと引いた目線で色々と観察したかったので。

（の割には横から色々とチャチャ入れしてましたw）

 

もう既に現場で実践されている方もかなりおられてちょっとびっくり。

 

開発はお手軽なこれで。

 

https://repl.it/

 

 

私が見学しているテーブルでは言語がphpになりました。

phpに長けた方もおられたので安心。

あと、書いたことがある、という方も。

（ちなみに私はほぼ書いたこと無いっす。）

 

最初は環境が動くのかを検証する為、Hello Worldを出して「やった〜🤗」。 

 

さて、今回のお題は自動販売機。

 

 コメントでやることを書いたりもしていたけれど、ちょっと混みいってきた・・・

中村さんがささっと付箋＆ペンを出してくださって、機能洗い出しなど。

 ガシガシ書き進めて行くと、したくなるリファクタリング。

機能追加するにはやらないといけないあるあるですね。

あと、ちょっとめんどくさそうな実装から逃げる為にも・・・w

 でもね、ちゃんとこの後に在庫管理実装されてました。えらい！w

 

まずは第一ターンの振り返り。

 

めっちゃ面白い・・・でもすっごい疲れたw

（見てるだけでも疲れましたわ）

及部さんもおっしゃってたんですが、モブプロで得られる知見は本当に文章化しづらいことが多いなぁと気づきました。

 

休憩時間に会場出てすぐにある自動販売機をみんなで視察。

思いっきり変な集団と化していましたが（爆）、普段使っている自販機をまじまじと見てみるとさっきまで気づかなかった機能を色々と発見。

 

第二ターンは少しメンバーが入れ替わり。

まずは新しいメンバーに今までの経緯を説明し、再びスタート！

さっき自動販売機を視察した成果（？）くじ機能が実装されましたw

（あとで他のチームのを見たら、テストしやすいように当たりの確率実装方法を考えておられてちょっと悔しかったw）

 

あと、どんどん実装されていくと飲み物を格納するレーンという考え方が大切だと気づき・・・（もう遅い）。

自動販売機に飲み物を補充する時、縦方向にレーンみたいなのがあってそこに積んでいるんですよね。

この考え方があるとコーヒーのホット・アイスも分けられるし（もう遅い）。

 

とりあえず在庫追加も実装されました。

そいや、自動販売機の周りに出現する登場人物って補充するおっちゃん、買う人だよな。

 もうだめだーwって苦笑いしながらもホット・アイスの管理実装中に第二ターンが終わったのでした。

 

他のチームのみなさんの話も聞いたりしていて、「おお！その考え方があったか！」とうなづくことばかり。

 

第二ターンの振り返り。

この半日で「あー！この構造じゃだめだー！」ってとこまで到達したのはすごいなぁwって。

第二ターンはじめからちょっとその匂いはあったので、ぶっ壊して最初から作るっていうのもありだったかな？なんてお話も出ていました。

確かにその手もありますね。

私の参加しているテーブルのところが一番うるさかったらしいです（爆）。

私の意見も取り入れていただいて、飲み物種類におしるこが入ったの嬉しかったですw

 

モブプロで嬉しい点は作業を分担しないので、他のメンバーに向けてのシェアは既に終わっていることですね。認識合わせやレビューはわざわざ時間をとってやる必要が無い。

あと、みんなで交代しながら実装するので上手い人の技を盗む良いチャンス。

既に実践されている人のお話を聞いたところ、参加人数は4人〜5人が良さげでした。

 

その後は近所の居酒屋へ移動し、さらに皆さんと交流させていただきましたー。

かなり興味深いお話が聞けてよかったです。

 

まずは業務時間外でちょこちょことやってみたいなー、モブプロ。

人が自ら考え、判断し、行動するように成長をうながすフィードバック ワークショップに参加してきたよ

お勉強

先日こちらに参加してきました。

devlove-kansai.doorkeeper.jp

 

いつもコミュニケーションは悩みのタネ。

壁にぶち当たってもがく→試行錯誤→ちょこっと前に進む

この連続です。

 

この年になると、大してスキルないのに人に意見するシチュエーションになることが多くて。

でもって、トラブルも抱えることあるし。

少しでも何かいい方法学べればいいかなーと思って参加しました。

 

まずは近い席の方々4人1組でチェックイン（自己開示）。

職場のチームでは振り返りの最初にやってますね。

話すのは「名前」「仕事」「今の気持ち」「体調」「参加の目的」。

特に体調って開示したらいいよ、とのこと。

普段はニコニコしている人でも体調崩していると不機嫌に見えたりしますもんね。

何か怒ってるのかなー？とか他の人から思われたりします。

本音を安心して言える環境作りも大切。相手を信頼してないとタテマエだけの自己開示になってしまいそうです。

 

フィードバックについての説明にうつりまして。

資料にある例を読むとなるほど、と理解はできるのですが・・・。

実際やってみるとなかなか難しい。

 

まず、フィードバックする為に観察するポイント。

  • 話の進め方
  • 視線、伴う動作（ジェスチャー）、話す姿勢、聞く姿勢
  • 声のトーンや速さ
  • 相槌、応答
  • 気持ちや感情

説明を聞いてたどり着いた私なりの考えとしては、以下のポイントが重要かなと。

  • フィードバックはこまめに
  • 相手の成長を願って
  • 相手が気づいていない可能性のあるクセなどに気づいてあげる
  • 「あなたは〜しませんでしたね」ではなく「私はあなたに〜して欲しいと思いました」（他人はそう思ってないかも）
  • 相手の受け取りを要求しすぎない

どうしても「評価」になりがちなんですよね・・・

評価になっちゃうと相手は威圧感を感じて「じゃ、直します」とか「次は気をつけます」とかしか言えなくなっちゃう。

（じゃ、どうやって気をつけるの？と質問しちゃってさらに相手を追い詰めることに・・・w）

あくまで「事実」と「その時の自分の思ったこと」を組み合わせて伝えると良いのかな・・と思ったり。

 

ワークショップでは「後輩に対するフィードバック」について話すことに。

2人があるテーマで話して、他の2人が観察。

話した2人はお互いにフィードバック、観察の2人は話した2人へフィードバック。

私は良かれと思って渡したフィードバックを、攻撃と受け取って聞き入れてくれない人はどうすればいいんだろう？的な話をしました。（このテーマ、DevLove関西さんのイベントに参加するきっかけになったものです。参加当時からこのことで悩んでるんですねw）

こういう反応をする人は今までに酷い指摘や攻撃を受けてきて、本能的に自己防衛が働いているんじゃないかと。

一旦張り巡らされた防壁ってなかなか解けないんですよね。困ったことに。

で、しつこく「ねーねー」って話しかけると悪循環らしい（爆

他の方の話題では、すごく引っ込み思案な新人さんが「大丈夫です」とフィードバックを断ってきて困った話など。

 

観察しあってフィードバックを渡し、さらに色んな気づきが。

すごく話し上手に見えるのに「話すの苦手なんです」って自己申告があったり。

まさにジョハリの窓ですね。自分が知ってる自分と人が見ている自分の違い。

私は人のジェスチャーや体の動きを観察できていると思ってたけど、そうでもなかったw

みんなすごく観察していて感心することばかりでした。

 

今回知ったことを踏まえて、ちょっとずつ試して行きたいなぁ。

 

＜おまけ＞

英会話レッスンで先生とこのフィードバックのワークショップの話をしていたら、

「フィードバックサンドイッチ」って言葉を教えてくれました。

https://www.instagram.com/p/BfSkTGODpFe/

NOVAの先生が教えてくれた、フィードバックサンドイッチ。ネガティヴなフィードバックはポジティヴなフィードバックに挟んで伝えると良いらしい。

 

前職（イギリス）で習ったらしいです。