Baby Steps TK

ゆっくりで良いから、深く仕事をしよう

良いリーダーとは?

友人4人での話し合い

4人で過去、1番良いリーダーがどんな人だったかを共有し合ったら予想外に面白かった。

  • ①事前に決めたポリシーに従って、ロジカルに戦略を立ててくれる人。腹落ち度が高い。 賢い、正しい、ついていこう。と思ったとのこと。

  • ②戦略・実行を任せてくれる人。失敗時は一緒に謝ってくれる。打開策を考えてくれる。 この意見は私。仕事が楽しかった。頑張ろう、創意工夫しようと思えた。

  • ③戦略・実行を任せてくれる人。対等な人間で役目が違うという態度。足を動かして直接会いに来る。 感動した。やる気が出た。人間味があった。とのこと。

  • ④個人個人を見ていて、「お前ならうまくいくよ。」「こういうやり方もあるんだぜ。」「辛かったな。」 俺のことそんな気にかけてるの!?元気になる言葉とアドバイスをくれる。とのこと。

良いリーダー像って、人によってそれぞれだなぁ。おもしろい。 では、世の中的にはどうなのだろうか。

良いリーダー

Wikipedia

リーダーシップは研究の歴史も古く、非常にさまざまな議論がなされ、定義も多岐に渡るが、一例として次の定義が挙げられる:「自己の理念や価値観に基づいて、魅力ある目標を設定し、またその実現体制を構築し、人々の意欲を高め成長させながら、課題や障害を解決する行動」。

古くから議論されているのね。

優れた統率者は「専制型」「民主型」「放任型」の三種類に分類され、その後優秀なリーダーシップは二種の類型を場合によって使い分けるものであるということが考えられるようにもなっていった。

ほぅほぅ、やっぱりいろんなタイプがあるのね。

マネジャーにしてはならない人五ヶ条

ドラッカーは、最も重要なマネジャーの資質=『真摯さ』と言っています。

いかに知識があり聡明であって上手に仕事をこなしても、真摯さに欠けていては組織を破壊する。 組織にとってもっとも重要な資源である人間を破壊する。 組織の精神を損ない、業績を低下させる。

とな。人間が集まらないと組織なくなっちゃうもんね。

①強みよりも弱みに目を向けるものをマネジャーにしてはならない

できないことに気づいても、  できることに目のいかない者は、 やがて組織の精神を低下させる。

人の活動エネルギーが落ちたり、人や組織の個性がつぶれそう。 個性を踏まえた上でできることを選択していきたいですな。

②何が正しいかよりも、誰が正しいかに関心を持つ者をマネジャーに任命してはならない

仕事よりも人を重視することは、一種の堕落であり、 やがて組織全体を堕落させる。

これは、「社長が言うことだから仕方ない」ってヤツか。 ポリシー違反は注意を部下からもしていきたいですな。 あとは、意図がわからない作戦とか質問をした方が良さそう。

③真摯さよりも、頭の良さを重視する者をマネジャーに任命してはならない

そのような者は人として未熟であって、 しかもその未熟さは通常治らない。

「重要な資源である人間を破壊する。」ことにつながるのかな。 数値を重視して邪悪な組織になっていきそう。 それに悲しいけど、頭の良さは年齢で低下するのよね。

④部下に脅威を感じる者を昇進させてはならない

そのような者は人間として弱い。

これも「重要な資源である人間を破壊する。」ことにつながるのかな。 アイデアや現場の知見も吸い出せなくなる。

⑤自らの仕事に高い基準を設定しない者もマネジャーに任命してはならない

そのような者をマネジャーにすることは、 やがてマネジメントと仕事に対するあなどりを生む。

高い基準かぁ。部下に対して達成困難な高い基準を設定するシーンはよくみますけどね。 自分で自分には設定しているんでしょうか。

ドラッカーって結構、チームを大切にしているのね! 見直したわ。 良いリーダー像をマネすればよいと思っていた時期もあったけれど、今の考えとしては、 『自分の個性を出し切ったうえで、周囲の人々の意欲を高める存在。』っていう考え。

リーダーシップ研修受けたから大丈夫です!みたいな人にはやっぱり心を動かされないもんね。

そんじゃーね!

否定ばかりするマン

今日は、否定ばかりする人についてググってみた。

なぜ相手を否定するかというと、
嫉妬やコンプレックス「否定して相手の評価を下げることで、自分の評価を上げたい」
からといった解説が検索上位に表示される。
軽く調べると、ユング心理学がソースになっている模様。

調査

●必ず否定から入る人は自信がなくて不安症 PRESIDENT Online
https://president.jp/articles/-/26777

「壊れやすい自己愛」。強気な姿勢で、自分に自信があるように見せかけている。
内藤誼人

●否定してくる人の心理を理解すると人間関係が大きく好転する
https://millioninvest.biz/archives/1622

『自分を否定ばかりしてくる人は、あなたにとって間違いなく大切な人ではない!』
『いてもいなくても同じ存在』

●人をバカにする人がもつ心理的コンプレックスと特徴
https://tabi-labo.com/201912/fool-heart-characteristic

人をバカにする人の多くは、心理的にコンプレックスを抱えている人です。自分が優位に立ちたいという欲求が強いという特徴があるので、面と向かって反応せずに、適度にあしらうか、毅然とした態度で接しましょう。

●頭ごなしに否定する人は疲れるだけだからなるべく相手にしないほうがいいよ。 かたぴ.net
https://katapi.net/human-relations/no-denial

言いなりになったらその人が考える人生を生きることになりますよ。

そんな中で、ちょっと面白いと思ったのはこちら

●否定する人される人は紙一重 アドラー心理学サロン
https://www.adlersalon.com/entry/2018/09/12/%E5%90%A6%E5%AE%9A%E3%81%99%E3%82%8B%E4%BA%BA%E3%81%95%E3%82%8C%E3%82%8B%E4%BA%BA%E3%81%AF%E7%B4%99%E4%B8%80%E9%87%8D

否定する人と、否定される人は共存関係。
他者を意識するのでなくて自分の目的を実現することに集中することで、
否定することも否定されることも必要が無くなります。

否定する人が存在するには、否定される人が必要とな。なるほど。
否定される側が「アンタの考えはそうなんだろうな。」 「俺はそれでもいいからやるわ。」っていう態度なら否定し続ける人は存在しにくいだろうな。

考察

今日の調査では、具体的な対処法はみつからなかったが、自分で考えてみる。

まず、否定するマンには種類がある。
①自分のやり方を押し付けてくる人
②人の行動を批評してくる人
③とりあえずネガティブな返答をする人

①自分のやり方を押し付けてくる人 については、
「それも良いと思いますが、今回大事にしたい価値観はこうで、こういうやり方でやりたい。」
という回答。
それでも引き下がらないならば、
「わたしにあなたのやり方はマネできないので、今回この仕事はあなたにお願いできますか?」

②人の行動を批評してくる人 も、①と一緒の回答かな。

③とりあえずネガティブな返答をする人 は・・・・困った
思いつかない。
「試してみたいから試すぜ!!」みたいな返しか?

自分が相手に行動を変えて欲しいというようなレスポンスを返す側であれば、
童話『北風と太陽』の太陽のようなポリシーで返答したいところだ。

【CSM研修】3日間で学んだこと

CSM研修を受けた動機

スクラムという面白いチームの形・働き方があり、流行している。
ルール自体はオンラインで公開されており、マネすることができるが、
日本の常識感からはかけ離れているところが多く、
実際に導入したところ「なんで?」「ここはウチでは無理だね。」というのが多かった。

書籍、アジャイルサムライやエッセンシャルスクラム、SCRUM BOOT CAMP THE BOOKを読んだがスッキリしない。

そこで、今回、できるだけ本家に近く、前評判の高いOdd-e Japan(Scrum Alliance公認)の江端さんの
Certified ScrumMaster?(CSM)研修を受けることにした。

自腹で324,000円もの研修費を払うのは初!!

何を学んだのか

書ききれない。
30時間の研修は伊達じゃない。

スクラムの仕組み・・というよりは、どういう行動を取ればよいのか。というところにフォーカスした研修だったと思う。

研修の頭からお尻まで何があったのか書き出そうとしたが、全然終わらない。
とりあえずインパクトの強かったことを3つだけ書き出すぞ。
できるだけ、IT業界以外の人も読める書き方をするよう心掛ける。

人生に影響を残すレベル

根拠なき正義感

例えば、仕事の割り振りをするシーンにおいて、
「やることのない人が発生してしまう。」というような言葉を言う人がいる。

これはもはやただの文化。仕事の完了やマーケットに関係がない。

・休めるときに休んでおけば良いのではないですか。
・別の仕事に手をかけたら、元の仕事に戻るのにロスが発生しませんか。
・その人だけ新しい仕事を始めたら仕掛中の仕事が残ったりしませんか。
・不測の事態に役立つのは、待機している人員ではありませんか。

チーム全員で1つの仕事に注力し、別の仕事をするべきではない。
今回はマルチタスキングゲームというものでこれを立証した。
さらに言うと「皆さん、戦争ミッションに行くチームを想像してください。暇そうだからといって仕事を振りますか?」
というとみんなNOと言う。なのに仕事だと「やることのない人が発生してしまう。」というようなことをさも正論のように言い出す生き物である。

スクラムマスターはこれを解決する。
科学的なノウハウというのは、「え?」と思われるものであって、みんながすぐに同意してくれるものではない。
これをやっていくのは”難しくて効果の大きい仕事”だと思う。

Undoneを作るな

ソフトウェアなら、パスワードを適切に暗号化しているか、サーバーダウンから復旧できるか。
想定するアクセス数に耐えられるのか。
他の業界でも、最低限製品・サービスとして絶対に必要なことはあるはず。

つまり、タスクの種類は2種類存在する。

・Definition of done(完了の定義)・技術品質
・Acceptance Criteria(受け入れ条件)・製品品質

ユーザーや即物的ステークホルダーは、直ぐに成果の見えるAcceptance Criteriaの仕事をやるように言ってきます。
しかしながら、Definition of doneの仕事は真っ先にそして常にやるべきです。
さもなければ不慮の事故やハッカーからの攻撃によって、あなたのチームは解散することになるでしょう。

この話は、私個人の人生にも適用されると感じています。
周囲の人たちは私に、年収やブランドや権利、どれだけ人の役に立っているか。などを気にするように言ってきます。
しかしながら、本当に大切にすることは、健康で安らかな暮らしや愛、知性、ロマンといったことではないでしょうか。

Definition of doneの中で
達成したものをDone、未達成なものをUndoneとし、優秀でクリーンなチームはUndoneを常に0であるように目指します。

製品が拡張される時にはDefinition of doneが増える可能性があるので、しっかりと管理しましょう。
デジタル製品の場合は、自動テストツールを作成するのが良いでしょう。

・・・なぜ、今までなかったのか不思議なくらい必要だと思うリスト。
これがない製品やサービスは、どうやって安全性や個性を守って改善していけるのだろうか。

ちなみに、
”完了の定義”という言葉はQiitaなどの記事で正しく使われていないことが多い。
下記のような信頼のおける発信元の情報を参照すること。
https://www.agilealliance.org/glossary/definition-of-done/
https://www.scruminc.com/definition-of-done/
https://www.infoq.com/jp/news/2014/03/process-definition-done/

本当は、英語が読めればよいんだろうな。

仕事に影響を残すレベル

仕掛りタスク制限(WIP制限)

WIPとは「work in progress」の略で、つまり"進行中の仕事"のこと。
有名な話なので、詳しいことはググれば出る。

【メリット】
・一人当たりの成果向上。
・チーム当たりの成果向上。
・俗人化せずチーム全員にノウハウが蓄積し次の仕事が早くなっていく。
・ブロッカーとボトルネックが見えるようになり、組織改善のとっかかりにできる。
・早く人に見せられるようになり、フィードバックをもらい改修が可能になる。
・ミスを修正するチャンスも多くなる。

【デメリット】
暇な時間ができることにイライラするかもしれません。
でも、数ヵ月の成果に注目してください。

私の経験談から言っても、
個人でもチームでもWIPが増えると、ミスが多くなったり、混乱したり、疲れたりする。
WIPでググると、
「仕事ができる人は、ひとつひとつの仕事を確実に終わらせる。」
「始めるのをやめて、終わらせるのを始める。」
という言葉が出てきたけれどもまさにそうだと思う。

参考にしてほしい記事

過去の参加者の書いた記事を読むのは面白い。
そこそこ習ったことも違うんだな。

2016年
スクラムマスダーの日記 アジャイルスクラムに関連した内容が多めです
https://scrummasudar.hatenablog.com/entry/2016/12/19/080000

【CSM研修】今まで勘違いしていたスクラムの知識

驚いたこと

ウォーターフォールにも繰り返しがある

ウォーターフォールの原典には、『・・・を2回以上のイテレーションをするように』とある。

完了の定義

受け入れ条件とは別物。包含関係にもない。 PBL(Product Backlog List)より先に、 DoD(Definition of Done)のリストを作り、
開発チームも常にそのリストを先に達成するべき。
そうしない場合Undoneと呼ぶ。(※決して、直訳で読んではいけない。)

【参考】ScrumInc
https://www.scruminc.com/definition-of-done/
独自の定義済みの定義、またはすべてのユーザーストーリーにわたる一貫した承認基準。

Scrumはアジャイル開発の派生だと思っていた。

Scrumのほうがアジャイルより歴史が古い
Scrum 1993年
アジャイル 2001年

講師いわくアジャイルは壊れたスクラムとのこと。

Scrumとは何か

×経験主義に重きを置いたフレームワーク

『現状を把握するフレームワーク』である。
『組織論』と『集団心理学(ジョージ・ミラー)』の学問に基づいており、日々研究・更新している。
19個の”薄く硬い”ルールからなる。

このフレームワークは、問題の発見は助けるが、問題の解決方法については助けない。

システム開発以外の方が取り入れられている。FBIや居酒屋の運営。

ウォーターフォールとは何か

×仕様が決まっている開発向けのフレームワーク
×納期が決まっている開発向けのフレームワーク

『統制を取るフレームワーク』である。
大量生産時代が背景。

スクラムマスター(SM)が勉強するべきこと

・『組織論』と『集団心理学』の学問
ティーチング
・ファシリテーティング
・メンタリング
コーチン
・シチュエーショナリング   ・指標の作成(2つ以上の数値を使った数式。)

レトロスペクティブ(ふりかえり)ですること

指標に基づいた作戦変更。
メンバー本人の発言や感覚は真実ではないので気を付けること。

プロダクトオーナー(PO)が勉強するべきこと

×プロダクトの責任者

スクラムチームの投資収益率 (ROI) を最大化する。』
スクラムチームと別の会社の人間がPOになることはあり得ない。
ROIの計算はPB1件ごとではない。

マーケットディスカバリーに集中。
PB1件1件をPOが作成するのは、ROIが低いといわれており、チームに任せたほうが良い。
POの研修では、ひたすらROIの計算をする。

Q&A

Q.タスクAをやるには2人で十分だと思われるのですが
全体最適化について、論文を読むこと。
タスクAに後続するタスクを考慮すると、全員がタスクAに関わるべき。

Q.暇な人が発生してしまうのですが
『作業をしている量の最大化』には価値がない。
『1機能が検証可能な状態となること。』を目指すべき。

Q.壊れたスクラムとは何ですか
目的に基づいて、学問を利用していないチーム。
やり方をテキトーにこねくり回しているだけ。

Q.仕事が少なくなりチームを解散しなければなりません
人、チームを先に作り、そこに仕事を振るべきです。
なので、解散はしません。

感想

日本の会社の常識、そしてソフトウェア開発の常識、
さらには、日本で流行しているスクラム開発の実践との差はかなり大きいと感じた。

今後は、情報の発信元に気を配り、信用のおける情報を入手することを心掛けたい。
ScrumIncやScrumAllianceなどの国際展開をしている団体や、
そもそもの提唱者。論文や研究家を意識すればよいだろうか。

また、スクラムをうまく実践するには、スクラムフレームワークを理解することだけでなく、
多くのビジネススキルが必要となることが分かった。

アドラー心理学を調べてみた

アドラー心理学ってなに?

『嫌われる勇気』という本で話題になった『アドラー心理学(個人心理学)』。
むかし、心理学とか脳科学とかの本にハマっていた時期もあったのですが、
アドラー心理学ってなんぞ?とモヤモヤしておりました。


そこで一冊、アドラー心理学系の本を初めて読んだ。
他の心理学本でありがちな「貧乏人の子は貧乏になりやすい。」みたいな統計や傾向で終わらずに、
「影響はあるかもしれないが、決定因ではない。」みたいな前向きな言い回しが常にされているのが良いと思った。

起源を調べてみると、眼科医のアルフレッド・アドラー(Alfred Adler)が、
目の見えない患者と接する内に編み出されたコミュニケーション方法や考え方らしい。

全体像を図に書いてみました。

アドラー心理学全体像

アドラー心理学全体像

(ご自由にお使い頂いて結構です。編集可。URLくらいは紹介してくれよな。)

 

気に入ったところ

特に気に入ったのは、
・【対人関係論】人間が行動するときは、常に相手役がいる

・【勇気づけ】困難を克服する活力を与えること
の2点。


一つ目の対人関係論。
誰かのために行動する方がパワーがでる。と思っていたり、
ゆくゆくは必要になる大きなモノよりも、自分が所属しているコミュニティで評価されている小さなモノを優先してしまう心理があると思っていて、それらを表現する言葉としておっいいなと思った。

関連して、”優位性を追う”=>”劣等感を感じる”という話も書かれていて、
このあたりが激化する競争社会に響いて流行したのかな。


二つ目の勇気づけ。
これは昔から開発チームやら人間の集団には”温度”というのがある・・という持論を持っている。。
最近はre:Workやスクラム開発界隈における”心理的安全性”という言葉が合致するかなと思っていたのだけれど、
アドラーにおける”勇気づけ”の方が、より能動的に高めることができるという点で合致すると思った。

気に入らなかったところは全然ない。
私の人生観・世界観にかなり合致すると思う。


以下は、自分向けのメモ。
ときどき読み返したい。

そんじゃーね。

 

メモ

⚫勇気とは
不確定性の高いチャレンジが可能で、目的に向かって他の人と力を合わせたり、貢献することが可能な精神状態。

⚫勇気づけるとは
"ほめる"と違いひとことの結果に継続性があり、チャレンジに失敗した相手にも可能な態度。

⚫注意や指摘はI(私)メッセージで発信する
、かつできるだけ状況を広くしないように表現する
✕あなたが悪い。
〇今回、わたしは~で迷惑した。
〇わたしはそれをやめてくれるとありがたい。
〇わたしはもっと~してくれた方が助かる。

⚫勇気をくじく発言はしないようにする
・恐怖による動機づけ
・あれが原因で失敗したという過去原因志向(普通、要因は1つではない)
・重箱の隅をつつくあら探し(意図や意志と無関係)

GCP入門セミナーに行ってきた

Google Cloud Platformのハンズオンセミナーに行って参りました。


今まで、AWSAmazon)を使ってきた私ですが、そろそろ他のクラウドサービスも触っておこうかなと思い、GCPGoogle)について勉強してきました。

 

AWSは便利ですが、個々のサービスはGoogleの方が強力なんですよね。特にAI活用など。これを活用するにはGCPバケットにデータを入れておく必要があったりするので、AWSを中心としたアーキテクチャでも少しはGCPを混ぜて使う機会があるのではないでしょうか。

 

学習したノートをQiitaに載せました。

 

qiita.com

qiita.com

新しい開発チームを作る①

4月!!別れと出会いの季節ですね。

4月から新しい開発チームを作っていくのですが、
まずは何から手を付けるべきでしょうか。


●自分が人にものを頼まれるとき、何が欲しいか。

【必須】
・達成したい要件
【重要】
・欲しいものの具体的なイメージ
・予算、スピード感、品質(テストの粒度)


●自分がいざシステム開発を始めるとき、何が欲しいか。

・2~4カ月分くらいの予定表
・開発環境
・チームメンバーの来歴と現在持っている仕事の状態

 

うん、こんなもんだな。

「人がどうしたら働きやすいのか」というのに教科書はないはずだ。
人それぞれだもんな。
(試しにググってみると、みつからなかった)

 

-----

細かく見ていこう。

●達成したい要件について
これはないと話が始まらないだろう。
ただ、必須要件だと思っていたことが必須でなかった。
ものすごい達成に時間をかけたのに使われない機能だった。
みたいなことが発生しないように、都度、継続的に認識合わせをしていきたい。

 

●欲しいものの具体的なイメージ
これは、開発者としては、あったほうが素早く開発できる。

ただ、未知の技術の存在やシステムに詳しくない顧客といった要素を考えると、
ガッチリとは決めずに、都度、製品のプロトタイプとチームの状態、優先度を鑑みて
修正できるとよいと思う。


●予算、スピード感、品質(テストの粒度)について

スクラム開発(アジャイル開発の1種)では「何を諦めるのか?」
をはっきりさせておくというプラクティスがある。

下記のトレード・オフ・スライダーが参考だ。

 

 

f:id:rtk8170:20190321130531p:plain

トレードオフスライダー

これがハッキリ決まっていると、 「優先順位は何か」「どこまでやったらリリースするか」という意思決定がスムーズになり、調整や議論が大きく減るので非常に働きやすい。

とはいえ、利害関係者が複数いたり、偉い人や顧客にブレがあるとこの通りにはいかない。チームが混乱しないようにリーダーが外部と調整・クッションする部分ではあると思う。

 

●2~4カ月分くらいの予定表について

全体の開発スケジュールのうち、自分が何を担当する予定があるのか。
これが分かっていると、事前に外部の講座を受けたり記事を見たりしておける。

社外との調整予定や、チーム内での製品レビューも予定表に書いておく。


●開発環境

完全新規のプロジェクトだと、
”決め”の意思決定をしていく必要があり、誰がそれをするのかが曖昧なままで、グチャグチャになったりすることも。
担当者を決めちゃったほうが良いと思う。


●チームメンバーの来歴と現在持っている仕事の状態

メンバーが助け合うため、もとい初対面の人に話しかけるにはあったほうが良い。
何に詳しいのか、どのくらい仕事を持っているのかが分かると質問や簡単な雑談がしやすくなる。

はてなブログ始めました!

はてなブログ始めました!
Twitterだと文字数制限があったり、後で見返すのが困難だったり。
そこそこ大きいことをまとめるのにブログ(ノート1ページ)くらいのサイズって良いと思う。


今考えているブログの構成はこちら。

●目的
 システム開発で困る人を減らす。

●カテゴリ
 A1_ニュース
 A2_近況報告
 F1_チーム
 F2_人の働き方
 F3_格言
 K1_設計
 K2_開発
 K3_プログラミング

 

趣味記事は少なく、IT系の仕事について役立つ記事を書いていければと思っています。
ハウツーだけでなく、自分の感性や経験をアウトプットしていけるといいな。