radioc@?

レディオキャットハテナ

【勉強会メモ】関西Javaエンジニアの会(関ジャバ) '18 4月度

kanjava.connpass.com

  • 日時:2018/04/13(金) 19:00 〜 21:00
  • 場所:株式会社ロックオン大阪本社

今回のテーマは「キャリア」ということで、それぞれの発表者の考えるエンジニアとしての生きざまが感じられるエモい内容でした。現場では経歴のもっと細かい話やブラックな経験談とか転職で年収がどれくらい変わったとか生々しい話がたくさん聞けて非常に面白かったのですが、あまり細かい話を書いてご本人に迷惑がかかっても良くないので詳細は割愛(じゅくちょーさんの話は全体の流れが重要な気がしたのであまり削れてませんが…)。

エンジニアリングとマネジメント

役職としてのマネジメントに携わるかどうかは別としてエンジニアもマネジメントスキルは重要だと改めて感じました。どの発表でも経歴の過程でビジネスとのバランスを取りながらエンジニアリングを考えて行動されています。コードを書いて生きて「いきたい」ではなくコードを書いていきて「いく」なのはセルフマネジメントしていくということでもあると感じました。

エンジニアリングのマネジメントを適切に行うには、エンジニアとしての勘が働かないと難しい

これは完全に同意です。個人的にはこれだけ変化が激しい業界でエンジニアリングとマネジメントの溝が広がると、発表の中にもあった雇用形態の問題などでエンジニアが疲弊していた十数年前のと同じような問題が別の形で表出するのではないかと危機感を持っています。エンジニアリングとマネジメントの溝を埋めるためにもマネジメント領域でエンジニア的ハックが広がっていけばいいなと思いました。

セルフブランディング

3人ともコミュニティ活動だけでなく個人として執筆活動や大きなセミナーなどの登壇もされているので、キャリア形成と言いつつセルフブランディングに近い話でもあると感じました。言葉にすると大げさかもしれませんが、世の中的に「個」の時代が来るとも言われているので、ひとりひとりが「個」を確立するという視点で今回の内容を考えてみるのも良いかもしれません。そのうえで、行き詰まったときには無意識にはめてしまった枠を取り外すことでキャリアとしても前進していけるのかもしれません。


コードを書いて生きてきた/コードを書いて生きていく

@backpaper0 さん

20代前半

  • プログラマが一番えらい
  • 業務SEとかマネージャ必要なの?
  • 常に新しいことにチャレンジしたい
  • 自分はずっとプログラマー

20代後半

  • 業務SEとかマネージャもすごい人がいる
  • 顧客要望やチームのスキルに合わせて技術選定
  • GitHubの草生やし活動(400日ぐらい)
  • プログラマでいたい

30代前半(今)

  • コードを書くだけではだめ
  • 周りに影響を与えていかないとだめ
  • それでも自分はずっとコードを書いていたい

現在の考え

  • 自分の目的:楽しくコードを書く
  • 仕事の目的:お客様への価値を届ける
  • 仕事において楽しくコードを書くという手段を取るためにどうすれば良いかを考え続ける
  • 今いる環境を変えるor異なる環境へ移る
  • 場をコントロールするのが大事

お金の話

  • 給料を上げるぞ
  • ここ2年ぐらいは給料を上げようと強く思っていた
  • コミュニティでキラキラしてるマンで夢を与えるために給料を上げるぞ

給与ふりかえり

平均年収.jpでチェック

heikinnenshu.jp

ずっとコードを書いて生きていきたいプログラマでもそれなりの収入を得てやっていける

マネジメントスキルとは技術である - エンジニア出身マネージャは管理職業務をハックする -

@daiksy さん

これまでのキャリア

  • 現場から剥がされそうになったら転職

現在

  • 完全にマネージャ
  • プロダクションコードをほとんど書いていない
    • 考え方の変化、環境の変化

管理職とは

  • 管理する人

プレイングマネージャーは管理職?

  • 厳密に言うと違うと思っている(個人的見解)
  • 自分でなんとかできるから管理できなくても良い

管理職とは

  • 自分で手を動かさないが事業やプロダクトに対して責任を持つ人
  • 責任対象に対して自分で手を動かさないからこそマネージメントする必要がある

管理職は素質に左右される?

  • コミュニケーション能力に優れている?
  • 優れたリーダーシップを持っている?

マネジメントは素質に左右されるものではない

  • コミュニケーションにもスキルがある
  • マネジメントには必要な技術がある

マネジメントスキルは 後天的に習得可能な技術 である

心境の変化

  • 以前
    • エンジニアであり続けたい
    • 管理職はエンジニアではない
  • 現在
    • マネジメントスキルは技術
    • エンジニアとして管理職であることもできるのではないか

エンジニアリング環境の急激な変化

  • エンジニアリングのマネジメントを適切に行うには、エンジニアとしての勘が働かないと難しい
  • 多岐にわたるソフトウェア開発に対してそれぞれ異なるマネジメントのアプローチが必要
    • Web開発と同じ考え方で機械学習の開発はマネジメントできない

進捗管理

  • 不確実性をどう制御していくか?
  • ベロシティの偏差を算出して、完了までのスケジュールをうまくいった場合と最悪のケースの両方を想定して予測

マネジメントの学習領域

まとめ

  • マネジメントは後天的に習得可能
  • 技術なのでエンジニア的視点でハックできる
  • ハックするためには知識を身につける必要がある
  • 技術習得のための学習はどんなものでもあれ楽しい

思い込みから逃れた先には、可能性がある - キャリア、コミュニティ、おまけにお金

@jyukutyo さん

客先常駐時代

  • 派遣契約面などで難しい環境
    • 力が欲しかった
    • このままでは毎回プロジェクトは失敗し自分は酷使される
    • しかし所詮1,2年目
    • 学ぶための下地もできていない
  • まずは資格をとりまくった
    • 5週間連続で別々の資格に合格
  • 技術記事を書いた
  • COBOLJavaへ転職
    • 執筆者がいる会社を選んだ
  • 上司から記事の募集⇒とりあえず手をあげる
    • 書くと決まってから調べまくった
  • これはプロジェクトで自分の身を守ることにもなる
    • ⇒待遇がよくなる
  • 技術書を読みまくる
    • 年8万の出費

人生を変えた1冊

実践J2EEシステムデザイン

実践J2EEシステムデザイン

実践J2EEシステムデザイン

DIとSpringにのめり込む

プロジェクトではフレームワークアーキテクチャ選定へ

  • よいポジションよい待遇で入ればプロジェクトの悲しみを減らせる
  • 理不尽を防げる

マネジメントの書籍も読み始める

身近なところは変えられてもそれ以上は…

  • どのプロジェクトにもまともなエンジニア/マネージャは少なかった
  • このまま自分のエンジニア人生を捧げるの…?

このころWeb系企業が浸透

  • すでにやっている会社に入ろう
  • 書籍で読んだことを活かす

XPベースのアジャイル開発をしている事業会社へ転職

  • アジャイルチームのリーダーになった
  • すべてはサービスのために
    • 企画者と話しビジネス要件と技術要件をあわせてバックログを整備
    • 週間のイテレーションを回し
    • ビルドプロセスを改善
    • 障害対応とパフォチュー

主体的に仕事をやれる幸せ

  • 自分の能力を広げる
  • 自分の能力を会社に寄せる

両方大事

何も迷うことはないはずだったが考えもしない方向に進んだ

  • 関ジャバ6年目
  • Java Day Tokyo 2015登壇
  • 関ジャバつまりコミュニティから自分の世界が勝手に広がった
  • いろんな人から話を聞いてJavaOneへ行く
    • Java One San Fransisco 2015
    • 衝撃を受ける

めちゃくちゃエンジニアを楽しんでいる世界中の人たち

  • 当たり前のように英語でスピーカーをしている日本人たち
    • 関ジャバ発起人の1人もやっている
  • めっちゃ楽しげ
    • プロジェクトやメンバーを守る⇒自分を押し殺していた
  • 僕もそうなりたい
    • Devoxx US 2017
    • 15分の英語セッション

セッションが採択されてから猛烈に英語習得

  • 通勤時、発音CDを口付さみ
  • NHK語学のストリーミングを聴きまくる
  • 有給を取って1週間フィリピンの語学学校へ
  • 海外エンジニアと交流してさらに自分を高めたい
  • 自分を取り巻く状況が勝手に良い方向に変わっていく
  • JOnsen
    • 英語で議論でボコボコにされる
    • 復活する時に前より強くなれる

2015年からすでに5回海外カンファレンスへ

  • 打算的にやっているわけではない
  • 単にそのほうが面白そう

エンジニア人生というより人生そのものを豊かに

  • 2017年会社では課長に
  • マネジメント研修なるものが控え
  • 課メンバーの育成も仕事の中心に

そういうのが仕事でもそこまで嫌じゃない

  • でも関ジャバ代表としてこんな普通じゃない経験をさせてもらっていわゆる日本企業の管理職になってしまっていいのか?

経歴を公開してオファーを待ってみよう

  • 企業から直接メッセージをもらったときやりとりを始める
  • エンジニアとしての自分の力量には自信がない
  • こんな経験してる人も日本にはまだ少ない
  • 日本の普通じゃないキャリアを歩んでみよう

⇒現職へ転職

まとめ

  • 今の自分の少しだけ外にあることを(かなり後悔しながら)なんとかこなす
  • 背伸びしてギリギリできるかな?をやってみる
    • 背伸び=今の自分の外、だけどすぐ横にあること
  • 失敗しても実は失うものなんてない
  • そうやって少し外を繰り返していくといつの間にか選択肢が増える

「いろんな選択肢のうちのこれしかない」と「やることがこれしかない」は全然意味が違う

無意識にはめた自分への枠を取ろう!

Java News - Java 10リリース!

@jyukutyo さん

Java SE10リリース

  • 3/20
  • non LTSリリース

varガイドライン:Style Guidelines for Local Variable Type Inference in Java

orablogs-jp.blogspot.jp

Graal

おそらくこの内容

www.youtube.com

JVMCI

リリースサイクルの話、ライセンスの話、バージョンアップの変更点などは2月の関ジャバの記事を参照。

radiocat.hatenablog.com

【勉強会メモ】総関西サイバーセキュリティLT大会(第8回)

sec-kansai.connpass.com

  • 日時:2018/04/11(水) 19:00 〜 21:00
  • 場所:CTC大阪オフィス

何度か参加させて頂いている総サイLT。セキュリティの知識と意識を高める意味でとても良い機会になっています。

セキュリティ力を高めるためにサンドボックス環境を作るのはマルウェアなどの再現だけでなく、セキュリティの問題が起きる仕組みを学習したり、対策をトライアンドエラーするのにも活用できそうだと思った。

ヤフーさんが自社で実施しているHardeningについては流石に簡単に真似できることではないものの、演習の重要性は改めて感じたので小規模でも演習形式での訓練をしてみるのは良いかもしれない。アプリ屋の視点ではセキュリティだけでなくバグ対応の演習(あらかじめバグを仕込んでおいてチームで復旧や修正や顧客対応をする)のような形でも訓練が出来そうだと思った。

激化するサイバー攻撃に対する防御術 / 伊藤忠テクノソリューションズ 大谷 誠司さま

サイバー攻撃の現状

⇒セキュリティ情報をちゃんと分析するスキルが必要

  • 人が欲しいけどなかなか体制が組めない
  • 本業が忙しくて質も量も増やせない

⇒一人ひとりのセキュリティ「力」を高めていくことが重要

高めるためには?⇒事前の訓練・演習によるスキルアップ

  • 自然災害⇒全社BCP訓練
  • 通信聴きなど⇒IT-BCP訓練
  • サイバー攻撃の訓練は空白地帯になりがち

NISCなど主導で多くの訓練・演習は進められているが大きな訓練は効果も高いが大変

⇒やはり一人一人のセキュリティ「力」を高めていくことが重要

セキュリティ力を高めるTips

1 ) ドメイン情報にも注目しよう

  • ドメイン取得時に同一ユーザー名やメールアドレスを使っているケースもある
  • DomainBigData で調べる
  • 同じ名前で登録している他のドメインを調べる
    • 登録日付や登録者情報に関連したドメインに注目

2 ) 難しくないお手製サンドボックスを活用

必要なもの

3 ) マルウェアを捕獲してみよう

4 ) 資産管理はセキュリティの要

資産・構成を把握

5 ) セキュリティの世界に目覚めた方々へ

  • 利用者目線
    • STOP, THINK, CONNECT
  • 目覚めた人目線
    • 気づく、止める、共有する

ヤフーでHardeningを実施する意味 / ヤフー 太田 俊明さま

セキュリティ演習を自社で実施

Hardeningとは

目的:サービスとセキュリティの両面を考える

WASForum主催

wasforum.jp

ヤフーのHardeningとは?

  • 本家の思想をベースに全従業員向けの演習としてカスタマイズ
  • 前回で2回目
  • 2日構成
    • Hardening Day(競技日)
    • Softening Day(振り返り日)
  • 主催:ヤフーJapan
    • 協賛:IDCFrontier,LAC
    • グループ会社も参加
  • 規模
    • 競技者:1チーム9人、9チームで81名
    • 攻撃担当:25名
    • サポートスタッフ:25名
    • 来賓:30名

演習設定

経営者が社員旅行満喫中

  • White Team…スタッフ、進行役
  • Read Team…攻撃者
    • Inside…ハッカー
    • Outside…ユーザー、マスコミ、経営者
  • Blue Team…競技者

システム

  • 総コア:343コア
  • NW:32セグメント

Ecサイト

  • ファッションサイト
    • 比較的新しい、安価な商品
  • 盆栽
    • レガシーなシステム、高価な商品
  • コーポレートサイト、SNSなど

演習シナリオ

  • 7時間の競技の中で26回の攻撃を敢行
    • 標的型メール攻撃、ECサイト改ざん、などなど
  • クライアントPCがブルースクリーン
  • 個人情報がSNSに貼り付け
  • お客様直接来社の恐怖

評価軸

  • 売上
  • 技術
  • 広報
  • 顧客対応
  • サービス
    • 社長への報告、サービス運営状況、競技への取り組み方・姿勢

最優秀賞:データ守り隊

  • 社長への報告・相談をきちんとしていた

セキュリティ演習を実施する意味

  • 1 ) インシデント対応経験のある人を増やす
    • 実際にインシデントがおきた時の対応を経験していることの強み
  • 2 ) 「セキュリティは重要」の根底理解
    • 推進する側も重要度が理解されているほうが進めやすい
  • 3 ) 社員全員が組織力を活かす
    • 会社の規模が大きくなるとお互いのことがわからず連携の生産性が落ちる

LT

サイバーセキュリティ対応の契約のあり方について

伊藤さま(弁護士)

サイバーセキュリティの重要性

  • 個人情報抜かれると損害賠償のリスク
  • 例)ベネッセ
    • 1人500円で5万人⇒2,500万円

契約面でのリスク回避の難しさ

  • そもそも契約にセキュリティを盛り込む意識がない
    • セキュリティ対策ができていて当たり前?
  • セキュリティ要件を契約で決める難しさ

⇒なかなか契約にセキュリティ要素は入っていない

判例での黙示の合意の恐ろしさ

水準は継続的に更新される?

  • 何が基準?
    • IPAの警告?
    • OWASP Top10?
  • 基準が決まったところで対応できる?

まとめ

  • 100%対策がありえない
  • 損害額が多大
  • 攻撃者の悪意⇒避けられない
    • 保険対応
  • 社員教育はちゃんとしましょう

迷惑メールを眺めていたらSecHack365でWebアプリをつくることになった話

@HighHigh_hill さん

SecHack365…U25のセキュリティハッカソン

sechack365.nict.go.jp

迷惑メール

  • URLのみ書かれたメール
  • 楽してお金が稼げる
  • アダルト系
  • 銀行など

1件1件見るのは…

  • 膨大な量のメール

URLだけのメール

  • 何が目的かわからない
  • URLを押して見たい

SecHack365で制作物

感想

  • 迷惑メールを見るだけではなくてアプリを作ってさらに興味が深まった
  • 類似度の計算はまだまだ

ハニーポットのログ分析

@morihi_soc さん ⇒ハニーポッター

著作:ハニーポット観察記録

サイバー攻撃の足跡を分析するハニーポット観察記録

サイバー攻撃の足跡を分析するハニーポット観察記録

ハニーポットのログはどれを見たらいいですか?

  • あなたの興味を引く何かがあれば気の済むまで勉強しましょう

ハニーポットを植えた時はきっと知りたいことや目標があったはず

  • モチベーションに沿って分析するログを取捨選択
  • 趣味のハニーポッターなら見ないログは捨ててOK

ヒント

  • HTTPのログで見たこと無いURIがあれば調査
  • SSHサーバのハニーポット⇒人間が操作しているようなログを調査
    • 攻撃者の動きに注目
  • モニタにハニーポットのログを常に流して光ったら見る

ノマドワーカーは見た

新大阪のうどん屋での出来事

  • 商談の資料を確認してほしい
    • ノートPCを外で使ったらISMS違反
  • 会社に電話して資料の内容を読み上げてもらう
  • 電話越しに口頭でPCのパスワードを伝える
  • 資料をスマホで写メして訪問先に送信

告知

アルティメットサイバーセキュリティクイズ2018

connpass.com

【勉強会メモ】"個人のタスクマネジメント"のコツや悩みを話す場

devlove-kansai.doorkeeper.jp

予定の都合で参加を見合わせていましたが当日になってやっぱり参加できそうだったのでキャンセルで空いた1枠に滑り込んで参加してきました。個人のタスクマネジメントはみんな同じような課題感はあるものの、やりかたはその人の仕事のしかたや生活に合わせて人それぞれなので色々議論の捗るテーマな気がしました。会社の勉強会でもテーマとして扱ってみんなでLTしてみたいです。

みんなだいすきTrello

セッション後のダイアログでも周囲の人にどうやってタスクマネジメントしているかを聞きましたが全体的に圧倒的なTrello人気でした。ツールに固定されないタスクマネジメントの話ではありますが、細かなTipsはTrelloに最適化されている印象です。確かにレーンを分けてステータス管理ができて様々な他のツールと連携できる多機能さは他のツールではなかなか実現できておらず一度慣れると手放せない便利さだと思います。

タスクの書き方と粒度はスクラム方式で

タスクの書き方は発表者のかたもそれぞれ話題にしていましたが工夫が必要な部分だと思いました。思いついた時にすぐタスクとして登録したのは良いとして、あとから見た時に結局目的が何だったのかわからなくなったり、粒度が大きすぎてきちんと管理できなかったりというのは私も経験があります。スクラムバックログを管理する時にユーザーストーリーで書くように、「やることよりありたい状態を書く」というのは常に意識しておくと良さそうだと感じました。粒度に関してもスクラムと同じで1日以下のタスクに分割するのが良いと思いました。スクラムのプラクティスは個人のタスク管理にもハマりやすいと思います。

チェックポイントを設定する

毎朝タスクの整理をするのも、どの発表者のかたも実践されていました。とにかく発生したらタスクを登録していくことは重要ですが、前述のタスクの書き方なども含めてタスク管理の課題を改善していくためには自分の必要性に合わせてチェックポイントを設けてふりかえりやタスクの整理をするのが継続させるためのコツのように思いました。

色つき星取表

このプラクティスは知らなかったので参考になりました。個人のタスク管理では自分のさじ加減次第で優先度が決まるタスクも多いため、気づいたら自分の好きなことばかりやってしまい、重要な課題のあるタスクはいつまでも完了しないという状況に陥りがちです。一年のはじめにあの本を読むとかあのプログラミング言語を勉強するとか抱負を決めたものの、結局やらなかったということもよくあります。そういう状況を回避するために色つき星取表を作ってテーマごとの取り組みのバランスをチェックしてみると良さそうです。ただ、個人的には毎日時間をかけて星取表を管理するのは継続に不安を感じるので週単位や月単位でざっくりまとめる程度が良いかもしれません。サイクルを長くするほど適当になりそうな気もするので人それぞれだとは思います。

※参考

放置プロジェクトをなくすために「色つき星取表」を使ってみよう|結城浩

私のタスクマネジメント

ちなみに私はGoogle Keepを使ってタスク管理しています。Trelloと違ってDoingやDoneのようなレーンわけしたステータス管理はできませんが、誰かとステータスを共有するわけではないので不要と割り切っています。ただ、個人のタスクでも期限があるものや、必ずやらないといけない重要なタスクはあるので常に上から優先度順に並べておくようにしています。Google謹製なのでKeepでリマインダーを設定すれば連携機能などは使わなくてもGoogleカレンダーに表示されます。

仕事ではチームでTrelloなどを使っていてステータス管理も重要なので、仕事と個人のタスクの切り分けは必要になってきます。タスク管理しているというより、あまり細かく管理しなくて済むようにGoogle Keepを使っていると言えるかもしれません。


俺とTrelloと終わらんタスク

松尾さん( @matsuoshi

speakerdeck.com

Trelloの気に入っているところ

  • 直感的
  • 自由、柔軟
  • 無料から使える
  • Chrome拡張でさらに便利
  • スマホアプリがある
  • エンジニアとの親和性が高い
    • API外部連携
    • ショートカットキー
    • Markdown対応

ツールはなんでも良いと思う

  • 以前はアナログな紙で管理していた

毎日のタスク管理

  • 自分専用のTrelloを用意
    • 仕事のタスクもプライベートのタスクもまとめる
  • レーンわけ
    • Todo
    • Today
    • Waiting
    • Done

朝イチでタスク整理

  • 1ポモドーロ(25分)以内で1日のタスクを整理
  • メール・チャットなどチェックしてTrelloへ
  • すぐ終わるものを終わらせる
  • 昨日のDoneの振り返り

個人のタスク管理で気をつけていること

自分のタスクはすべて1箇所に集める

  • 私的なタスクも集約
  • 家族や趣味、個人プロダクトなど
  • 業務のタスクと同じように管理

1箇所に集めるために

  • chrome拡張の Add to Trello が便利
    • 開いているタブのURLをTrelloに追加
  • スマホからすぐタスク追加できるようにボタン追加
  • 風呂場でも追加したい

とにかくタスクとして書く

  • 発生したらすぐ書く

期限を切る

手離れを意識する

  • 情報不足⇒質問を投げて待ちのレーンに異動
  • 着手できない手持ちタスクを減らすと精神が安定

気をつけているけどなかなか難しいこと

他のタスクに逃げない

  • ついつい楽なタスクに着手しがち
  • 結果的に面倒なタスク先送り
  • イマジン…やらなかったらどう面倒なことになるか想像する

タスクの分割

  • 大きなタスク
    • 例)DeveLove関西スライド作成
  • 今日はここまでできていれば上等というラインを決める
  • Trelloのチェックリスト
  • ハードル低くスタート
  • 終わりのないタスクは?
    • ひらめき(降りてくるタイプ)は悩ましい

本当に自分のタスクか

  • そもそもタスクが多すぎる
  • 依頼⇒しなきゃいけない?を考える
  • やらないという判断
  • あとから「一人で抱え込む必要なかった」となる事もある

Trelloの小ネタ

常駐させる

  • ブラウザの固定タブ
  • 常駐用ブラウザ:Vivaldi

Chrome拡張

Trello拡張

  • Card Ading ⇒しばらく使っていないカードの見た目が古くなっていく
  • タスクの棚卸しなどに

メモもTrelloに

  • よく更新するテキストメモもTrelloで管理

繰り返しタスクの登録はIFTTT

  • 毎月1日に経費精算のカード自動追加

Widget for Trello

面倒くさがりが継続できるタスク管理

和田さん( @fillz_noh

どういうタスクを管理?

  • イベント企画
  • メンバーとの面談
  • 買い物
  • やりたいことリスト
    • 例)DevLOVE関西で話し手

なぜタスク管理?

  • やることをすぐ忘れる
  • メモしてもタスク登録するのがめんどくさい
  • チャンスを逃さない
  • 締め切りを守る

GTD

postd.cc

  • デビッド・アレンが提唱
  • 2006年ごろからのライフハック
  • 頭の中のやることをすぐに書き出す
  • 定期的なリストレビュー
    • 各リストのタスクを見直し
    • なかなか着手できないタスクを分解
    • 定期的にイベント化

※参考

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

GTDツール

デイリープラン・デイリーレビュー

  • 朝と夜の設定した時間に通知

デイリープラン

  • その日に割り当てたタスクの見積もり、計画

デイリーレビュー

  • ふりかえり

問題点

例)「田中さんの今後の件」

  • あとで見直すと何のタスクかわからない

思いついたことを頭の中に残しておくのが気持ち悪い

  • 家で思いついた時にネック
  • シャワーの時

工夫していること

ユルくやる

  • 定期的なリカバリーポイント
  • 優先順位より能率を考えて手を付ける
    • 午前中のほうが進めやすいなど

やりたいこともたくさん登録

  • ToDoばかりだと見るのも嫌になる
  • 時々眺めてポジティブな気持ちになる
  • 夢のリストを作って宝物にしていく

リズムを作ってやる自分なりのタスクマネジメントの話

中村さん( @yohhatu

speakerdeck.com

今日お伝えしたいこと

やらなくていいのでは?

自分でやらなくていいのでは?

もっと楽にできるのでは?

逆にやる人も多い

道具

Trello

Coogle Calendar

  • 予定を登録

toggl

  • 時間を記録
  • ふりかえりの時に時間の使い方のバランスを見る

DocBase

  • その日の記録(日報)

色付き星取表

  • 傾向を記録
  • 力を入れているタスクや放置しているタスクを可視化

サイクル(リズム)

  • 毎月⇒ありたい状態を決める
  • 毎週⇒土曜日に計画づくり
    • 色付き星取表とTogglを見てTrelloを更新する
  • 毎日⇒Trelloを更新
    • ふりかえりをして日報を書く

気をつけていること

リズム大事

  • 一定のリズムでチェックポイントを設ける

やっていたことに戻れるように

手離れよくする

  • 自分がボールを持ったままにせずすぐ返す
  • 完璧より早さ
  • メールの未読を0にする

やることよりありたい状態を書く

  • 例)募集ページを作る⇒募集に申し込めるようにする
  • ゴールの状態を書く

【勉強会メモ】スクラム道関西 第102回定例会(オープン・ジャム)

scrumdo-kansai.connpass.com

  • 日時:2018/04/04(水) 19:00 〜 21:00
  • 場所:TAM COWORKING OSAKA

個人的に得た気づきや学びのメモです。その場で話したことというよりは、話した内容を持ち帰って自分なりの解釈で整理し直しています。

リーンコーヒーでテーマを決めて議論をしました。

※参考

www.slideshare.net

ふりかえりはムダか?

ムダと考える理由はチームの状態によって異なる

  • 忙しくてふりかえれない
  • ふりかえっても課題が解決しない
  • ふりかえることがない、何があったかを思い出せない

⇒まずはふりかえりがムダと思われている理由や背景を考えてみる

参加者の巻き込みのコントロール

  • 来てほしい人が来ない
    • なぜ来ないのか?ふりかえりの意義を理解してもらえているか?
  • 時々参加する偉い人
    • 呼ばないのもアリ
  • POに参加してもらうか?
    • 開発の課題が中心かどうか⇒受託か自社製品かなどのプロジェクトの内容にもよるかも

ファシリテートが超重要

  • 状況に応じたテーマを拾い上げる
    • 長期視点で考えるか短期視点で考えるか
      • 忙しくて目の前の問題が山積みなのに長期的課題の話をしても意味がない
      • 逆にプロジェクトが落ち着いている状態なら長期的にチームをどうしたいかという話をする良い機会にもなる
  • 一部のメンバーだけが話すぎないようにする
    • 発言が多い人にお願いして聞き手に回ってもらう
    • トークボールを使ってみる
  • アクションが出ない
    • KPTはアクションが出にくいので注意

良いPBIにするには?

悪いPBIとは?

粒度の大きいバックログは分割する

  • 分割できないということはない
  • うまく分割するのもスクラムのテクニック
  • まずは画面などの機能単位、次にCRUDで分割を検討する

PBIの候補が複数ある場合は両方作ってみる

  • 例えばA案とB案のどちらが良いか判断できない時
  • 両方作ってみてスプリントレビューで判断する
  • どちらか良い方だけをリリースする
  • 予算やリソースの許す範囲でやる

職場の問題かるた

職場の問題かるた ~“言える化

職場の問題かるた ~“言える化"してモヤモヤ解決! ([かるた])

思っていてもなかなか言い出せないような職場の問題が「あ」〜「ん」の言葉でかるたに書かれている。職場でよくある問題が書かれたかるたが読み上げられるのを取っていくゲーム感覚を交えながらディスカッションする。問題を「言える化」するかるた。

※参考

www.pocke.co.jp

【読書メモ】伝え方が9割

伝え方が9割

伝え方が9割

新年度が始まるということで新社会人向けの本としても紹介されているこの本ですが、著者自身がダイヤモンド・オンラインで連載している記事ではどちらかというと指導する側の伝え方にスポットが当たっているように思います。

お願い上手の秘訣は伝え方が9割-ゆうちょの新社会人応援!-ゆうちょ銀行

diamond.jp

下記のインタビュー記事でも部下に伝わらないとぼやいても状況は変わらないので相手が何を考えているかを想像することが大切だと言われています。

mirai.doda.jp

いずれにしても、何か伝えたいことがあるときにそれをストレートに言うのではなく、相手のことを考えたうえで決まったテクニックを使うように工夫をすれば格段に伝わりやすくなるというのがこの本で書かれていることです。

個人的にも営業や企画担当の人と仕事をすると資料の作り方がうまいなと感じることは良くありますが、それは常に相手を意識して伝え方を工夫しているからだと思います。仕事で書く文章は論理性も大事なのでテクニックに走り過ぎるのは良くない思いますが、エンジニアは特に論理性ばかりに意識が行き過ぎて何を伝えたいのかわからない文章を書きがちなところもあります。こうしたテクニックを覚えておいて要所要所で使うと良さそうです。また、エンジニア的には勉強会などで発表する時の資料のワード選びには特に役立ちそうだと思いました。


「ノー」を「イエス」に変える技術

人は1日に平均22回の頼み事をしている。お願いのしかた次第でその頼み事の返事の「イエス」の確率を上げることができる。

3つのステップ

  • 自分の頭の中をそのままコトバにしない
    • なんでもかんでもストレートに言うのはバクチと一緒
  • 相手の頭の中を想像する
  • 相手のメリットと一致するお願いをつくる

7つの切り口

相手の頭の中を想像するときには7つの切り口で考える。

  1. 相手の好きなこと
    • 相手のメリットからつくる
  2. 嫌いなこと回避
  3. 選択の自由
    • 2つ以上の相手の好きなことから並べる
  4. 認められたい欲
    • DNAに組み込まれている欲を刺激
  5. あなた限定
  6. チームワーク化
    • いっしょにやろう
  7. 感謝

「強いコトバ」を作る技術

強いコトバとは以下のとおり。

心を動かすエネルギーのあるコトバ

世の中の情報量は、10年で約530倍になった。個性のないコトバは無視される。

「強いコトバ」をつくる5つの技術

  1. サプライズ法
    • 「!」や「凄い」や「そうだ、」などのサプライズワードを付ける
  2. ギャップ法
    • 伝えたいコトバの反対のワードを前半に入れる
  3. 赤裸裸法
  4. リピート法
  5. クライマックス法
    • 「ここだけの話」「一言だけ」などのクライマックスワードを付ける

「強い長文」を作る技術

  1. 先を読みたくなる「出だし」をつくる
  2. 読後感をよくする「フィニッシュ」をつくる
  3. 飛ばされない「タイトル」をつくる

それぞれの決めどころに強いコトバの技術を使う。