runaround’s diary

なんとなく、つれづれ

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

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

devlove-kansai.doorkeeper.jp

 

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

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

この連続です。

 

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

 

<おまけ>

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

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

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

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

 

前職(イギリス)で習ったらしいです。

 

今年のまとめ

かなりブログ書くのサボってたのにいきなり今年の総括です。はい。

 

そういや今年ってちゃんと目標立ててなかったので、途中で「本当にこれでいいのか?」と迷ったりもしたのです。

来年の目標はちゃんと立てよう。

 

  • ブログお引越し(5月)
    自分のHP -> ブログ -> はてブ の期間を合わせると・・・18年近く。
    最近はめっきり書くのをサボっていますが。
    と言うか気軽に色々と書けなくなってたりますね(爆)。
  • MBP(中古)購入(5月)
    ずーーーっとWinユーザーだったんですが、なんとなく中古を手に入れてみました。
    転職を考えていてMacも触れるといいだろうなぁと思っていたので。
    最初は懸念もありましたがびっくりするぐらいふつーに使えた。
    なんだー、もっと早く手に入れておけばよかったなぁ。
    スペックはそんなによくないですけど、現在も愛用中。
    仕事は相変わらずWinマシンですけどね。
  • 勉強会参加(年中)
    今年は去年に比べてさらに参加率は高かったかなぁ。
    そしてLTで発表までさせていただきました。
    外で発表した内容を英語に直して、現場でもLTすることになったり。
    すごく緊張したけれどいい経験でした。
  • 読書感想文(2冊)
    本はもっと読んでるんですが、ちゃんとブログに書いたのは以下の2冊。
    「現場で役立つシステム設計の原則」
    Java本格入門」
    今年はちゃんと本を読もう、と会社の近所に30分早く到着してまったり読書してます。
    これで積み本は無くなるやろーって考えは甘かったorz
    本を読めば読むほど、他の本が気になるから手に入れたくなる。
    ポケットを叩けばビスケットが・・・のようです。困った。
  • 所属会社退職(9月)
    5年ちょい所属していた会社を退職しました。
    今回は円満に退社できたのでよかったっす。
    今は次の夢に向けて準備中。
  • TOEIC(年中)
    台風で行けなかった回を除いては毎回受験してました。
    ようやく500点台は卒業した感じですが、今度は700点の壁が・・・
    NOVAのTOEICカリキュラムにすごく助けられています。

といった感じ。

 

プライベートでは11月にボイトレスクールの20周年イベントでライブハウスのステージに立ちました。

ギター生演奏でカーペンターズの「Top of the world」を歌いました。

歌詞を盛大に間違えた(同じ小節を繰り返した)けど、ごまかして止まりはしなかった(爆)。

次の課題曲はマライア・キャリーがカバーした「Without you」にしたので、フェイクの練習をしましょう!と講師が張り切ってくれてますw

 

来年の目標は・・・何にしようかなぁ・・・。

TRYは

  • TOEIC 700超え
  • LTよりは長い発表
  • 広い部屋に引越し
  • 英会話力をアップ(せめてNOVAのレベル設定で最高クラスには入りたい)

KEEPは

  • 読書
  • 勉強会参加

ですかねー。

幸せになりた〜い

いきなりなタイトルですが。

はい、今日付けで所属してた会社は退職ですー。

今回は割とすんなりと退職へ着地した感じ。前の会社の時はかなりひどかったので。

(夜中3時ぐらいまで拘束されて問い詰められたかなー)

 

と言っても、実は現場は変わりません。

派遣先のご好意により引き続き働けることになりました。ありがとうございます。

だから派遣元が変わるってことになるんですね。

しばらくは派遣登録して働く予定。

 

理由は詳しく書いても誰も知りたくないだろうしw、

私の下手な文章で気分を害される方面もあったら困るし。

でも、今書いておかないと当時の自分がどうだったか後で忘れそうだから書いときますw

退職する会社には6年近く在籍していまして。

転職を決めた当時と今の私とでは見方や考え方が変わった、というかもっと幸せになりたい!と思ったというか。

新しいことにどんどん挑戦して、みんなで協力して 工夫して開発をスピードアップしているんですけど。

でも所属会社での評価は結局稼働時間になってしまって。

毎日ものすごいスピードで頑張ってヘトヘトになって定時退社しているのに、稼働時間が規定に到達していないと給料が減らされるんですよね。

なんだかねー。社員への還元率の良さをアピールしてた割にはね。

結局効率悪く仕事してだらだら残業してると給料増えるんでしょってことで。

あとはまぁよくある営業サイドがイケてないってことかな。

今の働き方はもともと私にあっている、と思っていたのですが最近は合わなくなってきたのかもしれませんね。まぁ、成長したってことにしとこうw 

 

しばらくは勉強会行って情報集めたり面白い人を見つけたり、

英語を勉強していろんな人と交流したり、

LTの技を磨いて立派なLT芸人を目指したり、

 

・・・がしたいですw

いろんな人のビブリオバトルなんかも見てみたいなぁ。

 

面白い人のすすめる面白そうな本に出会えるw

デブサミ関西2017に参加してきたよ

去年は直前になって知って行けなかったので、今年は受付開始すぐに申し込んで行ってきました!٩( ᐛ )و

平日っていうこともあったので、前もって職場にもアピっておいた・・・w

event.shoeisha.jp

さすがに大きなイベント。神戸行くのも久々だったしちょっとまごついたりして。

顔見知りの方もチラチラお見かけしたのでご挨拶などして、まずは基調講演へ。

 

基調講演

イノベーティブなテクノロジーとエンジニアの未来
榊原 彰 [日本マイクロソフト]さま

以下、私のきたない文字のメモでございます↓

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

デブサミ関西2017 基調講演メモ

あと、てらだよしおさんのセッションでも観せていただいている動画。

いつ観ても素敵。2つ目のパーキンソン病の女性の話は初めて観てちょっと泣いた。


Seeing AI 2016 Prototype - A Microsoft research project


This invention helped me write again - BBC Stories

この仕事を選んだ動機は人それぞれあってそれで全然良いとは思うんです。

お金の為、家族の為。趣味の発展系とか。

その動機の一つに「少しでも社会を良くしたい、貢献したい」がプラスされるのも良いなぁと実感したお話でした。

イノベーション

武闘派CIOが情シス不要論を斬る!
友岡 賢二 [フジテック]さま

 

https://www.instagram.com/p/BYxGGltj-SB/

デブサミ関西 2017 武闘派CIOのお話まとめ

インスタでは2画像あります。

満席状態ですんごい勢いの良いお話っぷりw

情シスの方にはすごすぎる刺激ある内容だったのでは・・・。

でもね、これ別に情報システム部やチームのだけの話じゃ無いと思います。

待ち受け専門じゃダメっすよね、仕事は。

データテクノロジー

データの見える化で進めるデータドリブンカンパニー

尾崎 弘宗 [ヤフー]さま

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

デブサミ関西 2017 データの見える化についてのお話まとめ

確か立ち見も出てたような・・・。

私のいる現場自体もサービスを多数持っていることもあって、他部署データの利用というのは理解しやすい内容でした。

まぁ、でもちょっと地味な感じだったかなw

いや、地味が悪いってことでは無いですよ。

開発プロセス

リレーセッション:チームを良くするスクラムの実践
大友 聡之 [Cafigla LLC.]さま /天野 祐介 [サイボウズ]さま

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

デブサミ関西 2017 スクラム実践のまとめ

こちらもインスタだと2画像です。

スクラムはうちもやってます!従来型開発の呪縛から逃れてスクラムに慣れていくの、大変でした!(爆)

サイボウズさまの外部コーチを召喚して、すごい勢いでスクラムに慣れていく様にちょっと感動。リモート部署とのやり取りもかなり工夫されてますね。すごいなぁ。

アーキテクチャ

3000社の業務データ絞り込みを支える技術 〜kintoneのアーキテクチャと高速化〜
三苫 亮 [サイボウズ]さま

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

デブサミ関西 2017 kintoneのアーキテクチャのお話まとめ

こちらもインスタだと2画像でーす。

可変のテーブル定義。大変そう・・・(~_~;)

現在開発中のお話までしてくださってました。パフォーマンスの課題が解決されそうとのこと。

スペシャ

『スモール・リーダーシップ』 〜チームの議論をスムーズに行うための方法を考える読書会ワークショップ〜
和智 右桂 [ハピネット]さま

最後にワークショップw なかなかの疲れっぷりでしたが・・・

事前にこの本を買って(2割引でした!)ほぼ満員状態で開始。

https://www.instagram.com/p/BYxgh1BD-xx/

デブサミ関西 2017 スモール・リーダシップのお話まとめ

同じパートを読んだ人同士は相談会っぽく、別パート同士で集まった時は要約を話して共有する、という感じでした。

著者の方が「こんなにワークショップが活発になるとは。」とかなり驚いておられました。確かに開始したら隣の人の声も聞きづらくなるぐらい盛り上がってたw

やっぱ関西だからですかねぇ・・・。

著者さんにサインいただきましたっ

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

昨日のデブサミ関西2017でワークショップにも参加したスモールリーダシップ。著者の方にサイン頂きました。

この間のロッシェル・カップさんのセッションに参加したサーバント・リーダーシップと共に、ちゃんと理解し行動に繋げたい内容です。(まずは読まねば)

懇親会

関西Java女子部のきの子さんにお誘いいただいて、コミュニティの宣伝LTをしてきました。

javajok.connpass.com

めっちゃ噛んだw

あとポケモンGOスイクンって言っても反応薄かったw

他にいろんな言語のいろんな活動をされているコミュニティや、会社さんや個人さんやたろうさんも飛び入り参加されたりして大変楽しい会でした。

ありがとうございました!

 

読むべき本が増えました・・・ガンバロウ( ✌︎'ω')✌︎

 

 

「Java本格入門」を読んでみたよ

やっと読み終えたので、一旦感想などをアウトプットしておこうと。

books.rakuten.co.jp

 

もう既に沢山の方が読んで感想など出尽くしているとは思うのですが、今の自分としてはどうだったか、は残しておきたいのです。

この内容は先日参加した関西Java女子部の部活でも感想を話したので、そちらがベースになります。

全体の感想

  • 普段思い込みで何となーく使っていることが多い!と気づいてしまっていい意味でショックを受けた。(いや、本当はわかってたことなんだけどw)
  • 単なる書き方だけではない、お作法(こう書くと良いよ)についても丁寧な説明が書かれている。人に説明することがある時に、パクって使いたい!(こら)
  • Java7やそれ以前、Java8それぞれのサンプルコードが載っている。私はこの業界に入った当時は1.4を使っていて、残業の嵐の中であまりしっかり勉強せずにここまで来てしまっているのでとてもありがたい内容。
  • 実は・・・例外処理が苦手・・・という意識がずっとあって。でもすごくわかりやすく解説されていて、これまたありがたい。
  • ビギナーにはツラい本かも。ある程度Javaをガリガリ書いた人、もしくは他言語を書ける人でちょっとJavaを知っている程度の人には良いのかなぁ。
  • チャプター12(デザインパターン)から以降は、人によって色々意見が分かれそう(っていうか宗教戦争的な何か・・・)
  • Jenkinsのインストール手順が丁寧に載ってて、ちょっとびっくりした。
  • テストのチャプターはもっと内容が多いと嬉しいのだけど・・・

特に推したいこと

今、一生懸命Stream APIやラムダ、あとOptionalとかに慣れようとしていることもあって、この本は仕事場の引き出しに入れていつでも読めるようにしておきたいと思います。

(そういや今日、Scalaビギナーズのハンズオンに参加してて、Optionの話の時にJavaのOptionalを思い出してたなぁ・・・。)

オマケ

本の表紙に書いてある「”動けば良い”で済ませるのではなく、効率的で品質の高いコードを書くために。」がとっても胸にしみますよ。

負債が山積みのプロジェクトでまだまだ負債を積み上げようとする人にこの本を投げたい(爆)。

「現場で役立つシステム設計の原則」を読んでみたよ

平日は仕事前の30分、仕事後は時々晩御飯待ちの間に読書するようにしています。

 

今日まで読んでいたのはこちら。

books.rakuten.co.jp

厚さは結構あるのにとっても軽く、最近の製紙や製本技術の向上には驚かされます。

そして本を開いてみるとびっくり。案外字が大きいw

なのに読んでみたら内容が濃い!

 

読み終わって晩御飯までちょっと時間があったのでインスタで呟いたりしてました。

 

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

現場で役立つシステム設計の原則、ようやく読み終わった。大事だと思う所に付箋。

インスタは大体ツイッター連携してるので、ツイッターにも流れまして・・・。

 

そしたら・・・

 

なんと!著者さまが反応してくださって、心臓飛び出るかとw

食べてたチキンのフライ吹きそうになった・・・

どこに付箋を貼ったのか興味を持ってくださってたみたいです。

 

今度こちらの読書会に行く予定でして。

devlove-kansai.doorkeeper.jp

その際は他の参加者さんの見解などを見聞きするのが大変楽しみなんですが、とりあえず現時点でちょっと感想をまとめておこうかと。

第1章

光の速さで付箋をつけたのはこちら。

1つの変数を使いまわして代入を繰り返す書き方を破壊的代入と呼びます。

 破壊的。ほんとですね・・・。私、金融系のシステム開発が一番長いこともあって計算ロジックのとこでこれやっちゃうとヒドイ目に合うの、すごくわかります。

あと、やっぱり値クラス。

「数量」は単なるintではありません。「電話番号」は単なるStringではないのです。

 正直言って後頭部殴られた感覚・・・。今までDB設計したあと、実装はホント慣習でテキトーにIntegerやStringで扱ってた・・・( ;∀;)

Telephone型の例はとてもわかりやすくて、現場のシステムだったらどんな感じで当てはめたらいいかなぁ〜ってぐるぐる考えてました。

最近ほぼ全部のソースを読む機会に恵まれてまして、何気に気づいた・・・

えっ?Telephoneクラスあるやん・・・_:(´ཀ`」 ∠):

3年近く開発してるのにこんなクラスあるの気づかなかった・・・(爆)

あ、でもクラスは存在しているんだけれど、ホント一部の機能でしか使われてなくて存在感がとっても薄かった・・・。

これはちゃんと整頓して実現させたいですね。もちろんチームの同意を得るためにサンプルコードとか書いて提案してみないとですが。

第2章

Enumを使用した状態遷移の表現、つい最近もステータスの表し方でチームメンバーが頭を悩ませていたこともあってすごく身近に感じましたw

そうかー、こういうやり方があったか!と。

第3章

業務データと業務ロジックを一緒にしたドメインオブジェクトを設計するときに、どのパッケージに置くべきか、そしてどのパッケージの内容を知っていてもよいか/知っていてはいけないかを整頓し、改善を続けることで、業務ロジックの全体的な関係が明確になってきます。

 今のチームのソースはかなり綺麗な方だと自負しているのですがw、それでもこのロジックやサービスクラスってこのパッケージでいいのかなぁ・・・わかりにくくないかなぁ・・・と悩んだりすることもあります。

改修のチャンスがあれば、ちゃんと検討して改善するのはいいことなんだなぁとちょっと自身が湧いてきました。

第4章

ドメインモデルの考え方についてとても詳しく説明されていて、今後もいろんな本を読んで勉強する予定です。

一番激しく同意したのはこちら。

分析・・・人間のやりたいことを正しく理解する

設計・・・人間のやりたいことを動くソフトウェアとして実現する方法を考える

頭では理解できていても、人に説明するときにわかりやすく良い表現ってなかなか出来ないものですよね。それがとても簡潔に表現されていて感激しました。

あと、業務への理解というのはシステム開発者としては永遠の勉強のテーマだと、私は思っているのですが、こちらも激しく同意しました。

文書で体系化した情報、現場で実際に使われている場面や帳票や資料、そして業務の経験者との会話。これらを常に組み合わせながら対象業務の知識を広げて行きます。

第5章

サービスクラスについては、今のチームのソースはほとんど実現が出来ていてかなりほっとしましたw

きっと最初にルールを決めて書いて、展開してくださった方のおかげです。

あと、ちょっとデカいなぁと思った既存のサービスクラスはぶっ潰して解体、小さくリファクタリングしたりしてますwww

第6章

値クラス使ってない!の次にやっちまったーーー😅  と思ったのがこの章w

テーブル設計なんですけど・・・NULL値が入ったテーブルある・・・

そのせいでプログラムも超ダサいことに・・・API・・・

ちゃんとテーブル分けたらよかったんですね・・・そっか・・・

 

そして一番笑った部分はここ。

もっとひどい設計が「自由項目」や「予備項目」と呼ばれるカラムです。

 出たーーーーーーー!!!予備項目!!!

その昔とあるシステムでカラムが150個ぐらいある汎用的なテーブルがあって、あるお店のデータならカラム13には住所が入ってるけど、他のお店のデータならカラム13には顧客の性別が入ってる、みたいなのに遭遇しましたね。

ソース側は何が何だかですよ。読んでもさっぱりテンション上がらない。

予備項目職人だったら「ああ、カラム13か。あの店だったら住所だよね。」とか即答しそうですけどね(こら

第7章

うちのチームのシステムでは画面側(テンプレートエンジン)はThymeleafを使ってまして、画面側で色々出来てしまう(そして読みやすい)ということもあり、実装者によって法則がまちまちになりがちです。

ソースレビューで読んでてちょっと辛いなと思ったら「出来ればJava側で編集しておいてから画面側は表示だけにしない?」と提案することにしています。

そういう意味ではこちらはとってもぴったりで納得できるな、と。

画面まわりのロジックから業務のロジックを分離する

第8章

WEB APIの仕組みについてわかっているつもりでしたが・・・ちゃんと整頓立ててもう一度勉強させていただいた、という気分です。

いかに私はノリで開発してるかってことですね😜

最近チームでAPIを根本的に見直そうと話し合ったこともあって、この章はかなり参考になること間違いなしです。

第9章

うちのチームでは設計と開発、テストまでを原則同じ人間でペアプロすることにしています。「原則」と書いたのは途中で1人を残してペアの組み替えをすることがあるので。

それと、ドキュメントに関しては開発する前のイメトレや課題調査のアウトプットとしています。処理の大まかな流れだけ書いて、詳細はソースを読めば良いし。

しかし、最近特に考えていることがあります。古参メンバーがいなくなってしまい、既存処理がなぜそうなっているかの理由(歴史?)がわからなくなってどハマりするという苦い経験をしました。であれば、理由や歴史はドキュメントに書いておいた方がよいのではないかと。

・・・と、この章読んだら答えが書いてあったw

やっぱ分析時の資料は残しておいた方が良いのですね。

ホワイトボードなどでラフスケッチなど書いて写真を撮ってアップしておいたり・・・

第10章

オブジェクト指向の学び方・・・結局、なんとなくずっとJavaを書いてきたけれど実際自信を持ってオブジェクト指向!身についてますよ!と断言できるのかどうか・・・。 

ただ、私が恵まれているなぁと思うのは・・・

  • 新規開発の現場も行ったけれど、保守開発の経験が長かった
  • 今のチームで設計改善も含む開発の機会を得ている

ということでしょうか。

面白そうな本もたくさん紹介していただいているので、読んでみようっと。

これとか。

books.rakuten.co.jp

「心理的安全性」のことに思いを馳せてみる の勉強会に行ってきたよ

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

 

devlove-kansai.doorkeeper.jp

 

スピーカーのお二人にとても興味を持ったのと、チームビルディングなどにも興味があったので光の速さで参加申し込みしました。

 

およべさんのスライド

speakerdeck.com

どちらのお話を聞いていても、チームで色々工夫して色々考えて、苦労もありながら、でもうちのチーム最高ーーー!ってことがとてもよくわかりました(雑)。

 

んでもって・・・

私がいるチームもほんとサイコーでーーーーーーーーーっす(ほんとに)。

手前味噌?いやいや、多分本当に毎日きゃっきゃ言いながら開発してますよ。

 

面白そうな本もたくさん出てきたんですが、これはお気に入りに入れておきました。

次のお買い物マラソンで買おうっと。

books.rakuten.co.jp

 

ドラゴンボールを揃えてチームを変えられるとしたら何を願う(願いは1つ)?

うーん・・・変えて欲しいことがないんですよね。冗談抜きで(^_^;)

なぜなら、こうしたいな、と思ったら「ねぇねぇ」ってみんなに相談してやってみて、うまく行ったら継続、うまく行かなければ諦めるかやり方を変える、みたいなことを日常やってるから。

まぁ、願いといえば・・・これ以上うちのチームのリソースを剥ぎ取らないで( ;∀;)って感じですかねw

今が一番バランスがいいかなぁと思っていたり。

困ったなぁと思ってた人たちが他へ移ったってこともあるけど(爆)。

 

何か困ったらすぐにメンバーへ相談できる。

ちょっとパニクってたらとりあえずメンバーに話して考えを整頓できる。

なんならホワイトボードに書きながら頭の中にあることをメンバーと整頓できる。

チームメンバーの作業に興味を持てる。

ペアで前向きに開発できる。

品質を上げることを常に目標に掲げられる。

メンバーからの指摘を素直に受け止められる。

チームメンバーのことを思いやれる。

毎日「やったー!(バンザイ)」が言える。

 

以上が私が心がけてる&今日の勉強会で見聞きして、ぜひ継続したい&やりたいと思ったことです。