「苦しかったときの話をしようか」

苦しかったときの話をしようか

まとめ

人生とはなにか、会社とはどんなもので、働くとはどういう意味か、社会とはどういうものかなどを父が子に伝えたいことを手紙としてまとめるスタイル。

子を持つ親として、こういうことができるのは一つの本望であると思う。

本書が素晴らしいと思うのは、著者が自分の経験や考え(パースペクティブ)を、親として子に押し付けないように細心の注意が払われているというところかと思う。子が、その他人のパースペクティブを土台として、自分のパースペクティブを形成し、最良の決断が自分自身でできるようにというのが目的になっている。

個人的に、この本の中でビジネスパーソンとして最も読む価値があるのは、本のタイトルとなっている第5章だった。アメリカ駐留時代の壮絶な戦いの記録を含めた、森岡さんが苦しかった時の3つの話。

森岡さんですら、

  • 原因論的にいうと)過去がトラウマになって今でも電話に出られない
  • 自分が信じられないものを他人に信じさせようとしなければならなかったが言えなかった
  • 自分が無価値だと感じてしまう

ということがあったのだなと。しかしそれを乗り越えるのはやはり自分の強みへの集中と、覚悟であった。 こういうのを見ると、自分には、覚悟や戦略的思考、行動を起こす勇気がまだまだ足りてないのだなと思わされる。

他にも読んでみたい。

「ワンダー 君は太陽」

ワンダー 君は太陽

「僕は普通の10歳の子じゃない」--オギーは遺伝子の疾患で、人とは異なる顔で生まれてきた。27回の顔の手術のせいで自宅学習を続けてきたオギーだが、両親は息子を外の世界へ送り出そうと決意する。だが、5年生で入学した学校で、オギーはいじめや裏切りなど初めての困難と出会う。幾度もくじけそうになりながら、家族の愛を勇気に変えて立ち向かうオギーの姿に、周囲の人々が変わり始める。そして忘れられない1年を締めくくる修了式の日に、最大の出来事が待ち受けていた──。

遺伝子の疾患のせいで引きこもるオギーとその家族が勇気を持って入学という一方を踏み出す話なのだが、子を持つ親として自分ならどうすることができるだろうかとあらゆる場面で考えることになった。

この映画の良いところは、物語の視点がオギーだけに固定されてないことだと思う。それによって、例えば障害を持つ人本人だけでなく、周囲の人の自然な関わり方とは何か、物語を見る側の我々の心に訴えかけてくるものが大きくなる。

親や周囲から少しだけ保護が必要なオギーにすべての関心が集まりがちだが、姉ヴィアにはヴィアの複雑な感情があり、親友ジャックにはジャックの立場があり、ミランダにはミランダのと、みなが自分や周囲の幸せのために懸命に生きようともがいている。

一つの目立つ事象を固定的な視点でとらえずに、あらゆる人の心を通して見ることができ、つまり相手の考えを想像し、そしてどうあるべきかを考えることができる。それが可能なのが映画や小説なのである。この点において、フィクションであるか実話であるかは当然重要ではない。

オギーがジャックを助けたあとに、エイモスが「さっきかっこよかった」と言った時の関わり方がとてもさり気なくて、この映画が必要以上の演出によって感動を求めるようなものになっていないことを象徴するような場面だった。

ネート演じるオーウェン・ウィルソンはどこかでみたことがあるような記憶があったが、「ミッドナイト・イン・パリ」に出てた人なんですね。ググってスッキリしました。

「アジャイルサムライ」

アジャイルサムライ

読むの2度目。前回よりも実戦経験を得た上で読む。

メモは、改めて意識したいと思った部分や気づいた部分、だけ。

3つの真実

  1. プロジェクト開始時にすべての要求を決めることはできない
  2. 決めたところで、どれも必ずと行っていいほど変わる
  3. やるべきことはいつも、与えられた時間と資金よりも多い

だから、アジャイル開発を選ぶのだ。 計画→フィードバック→改善のサイクルをちゃんと回すことで変化に対応しやすく、よりよいプロダクトへと軌道修正しやすいから。

開発チーム

開発チームにはクロスファンクショナルなメンバーで構成されていて、テクニカルライター、ビジネスアナリスト、プロジェクトマネージャ、プログラマ、データベース管理者、UXデザイナー、テスターなどが含まれる。

アジャイル開発を始めると、プログラマとプロジェクトマネージャくらいしか開発チームにいない、ということはよくあるけど、テスターを追加するというのはやったことがないかも。結構別働隊的に動いているかな。。

インセプションデッキについて

プロジェクトがどんなものであるかを短い10個程度の質問によって明らかにし、すべてのステークホルダーに見えるようにする、というもの。 プロジェクトを立ち上げると、いろんなマネージャーや企画方面からの夢が大きくなりがちですが、対立点やバランスを考慮した上で、こういったものを予め決めておく事は重要ですね。途中で、絶対に、根本を揺るがすことを言ってくる人がでてくるので、そういうブレそうになったときに皆でみるものとして使えます。

特に重要なのは、

  • 期間を見極める(いつリリースするか)
  • やらないことリスト
  • 何を諦めるか

あたりかなと思いました。 ちなみにインセプションデッキ上の期間および費用の見積もりは超適当で、精度なんてあてにならないもの。

開発期間を見極める

小さく始めるためには、プロジェクトを6ヶ月にするのがリスクとのバランスの上では最長という考え方があるらしい。 あくまでも、アジャイル開発という点からすれば、ということであるけれど。

これは与えられた制約条件の中にすでにリリース時期がある程度固定されてしまう場合があると思うけど、たしかに「サイクル」ということを意識すると、短いほうが良さそう。

ユーザーストーリーの単位はINVEST

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

POを企画とか開発しない人がやったりするとこのあたりは絶対と言ってよいほど守られないので、スクラムマスターや開発チームからしっかり監視する必要がありますね。Jiraのテンプレートに反映させるべきかもしれない。

見積もりは不確実である

いわゆる不確実性コーンであり、遠いものほど不確実性が高まるので、スコープのコミットする時期を遅くするほうが良さそう。

NEGATIVE BALL

さいたま近代美術館にいって、MOMAS展を見に行った。

久しぶりに現代アートを見ると何を感じるのだろうか。何か得るものがあるだろうか。 (という期待をして毎回チャレンジするけど、いつも撃沈している)

今回も、いろんな作品を想像力を働かせて見てみる。何となくこんなものを書いたのかなーとか、この人はなぜコレを描きたかったのだろうかなどと適当に想像してみる。ほとんどのものはよくわからなかったか、あるいは自分にとって価値のあるようなものを感じることはなかった。

ただ唯一、志水晴児氏の "NEGATIVE BALL" という屋外に飾られた展示物にだけ、吸い付かれるように心を奪われた。

立法体の一部を球でくり抜いたような作品。まるでPower Pointで2つの図形を合成して切り抜いたようなもので、球型の穴の下部にはここ数日降った雨水が濁って溜まり、枯れ葉などのごみ、そしてボウフラのような微生物が漂っていた。

f:id:fkrsrn1122:20210910171314j:plain
negative ball

予備知識なく、現地で見ているときは、正面から見るとなんとなくハートっぽく見えるけど、なぜ"Negative"なのかなと思った。くり抜いて反転させている = "Negative" ?なのかなーと考えた直後に、全く別のところから、別の考えが突如浮かび、ハッとした。それはアドラー心理学の「意味づけ」だった。

一つの事象は、見る人独自のメガネによって意味づけされ、解釈される

といったような意味だ。

rj77.hatenablog.com

つまり、完全な球体をあえて反転して、Negativeな視点で見ると、こうやって重くてゴツゴツしたものになり、中に不純物が溜まってしまい、いろいろと厄介に見えてしまうけど、見方を変えればもっとシンプルなんだよ、ということである。

何も解説がないし、答え合わせのしようがないのだけど、まあこれは多分、偶然による完全に個人的な解釈であろう。最近アドラー心理学に傾倒していることで、自然とそういう見方になっただけかもしれない。でもなんだか自分の中でとてもしっくりきてしまい、すごく惹きつけられたのだった。これのポストカードがあったら買って帰ろうかと思ったが、残念ながら見当たらなかった。

このオブジェについて、あとで検索してみたが、以下の記事にあるような見方が一般的なのだろうか。

www.sarashinado.com

現場で自分が見たときはしっかりと日があたっていなかったこともあって、内側に球体が浮いているようにも見えなかった。 もしかして、水が反射して球体の内側に投影される影が、凹んだ形に投影された球だから、"NEGATIVE BALL" なのだろうか。(でも凹型をNegativeというかな??) どちらにせよ天候という偶然性が大きく関わっているのは確かである。もし自分が製作者だったなら、ある偶然が成立しないと理解できないものを、説明無しで展示するということはしないかなーと思ったり。

どちらでも良いのかな。コンテンポラリーアートってこういうものなのかな、とちょっと思ったのだった。

あと、さいたま近代美術館がある北浦和公園には中銀カプセルタワーの展示があることを後で知りました。。。残念。またいつか行きます。その時に "NEGATIVE BALL" を見たら自分はどんな解釈をするのだろうか。

blog.aco-gale.com

「いつも自分のせいにする罪悪感がすーっと消えてなくなる本」

いつも自分のせいにする罪悪感がすーっと消えてなくなる本

さいしょにまとめ

罪悪感のタイプを分類する前半と、それぞれについてどう付き合うべきかの後半。

前半の内容には納得感があった一方、その一つ一つを後半で網羅できていなかったように思いました。

メモ

罪悪感は誰にでもある

  • 罪悪感とはルールみたいなもので、誰しもが持っている。もしなくなったら手を使って良いサッカーみたいな人生になるかもしれない
  • ドラマを盛り上げる演出役
  • 罪悪感は消すものではなく、付き合っていくもの。
  • まずは自分の中にあることをしっかりと受け止める
  • 罪悪感とは
    1. 自分は幸せ担ってはいけないような気がする
    2. 自分は大切な人を傷つけてしまうと思う
    3. 大切なものは自分から遠ざけてしまいたくなる
    4. 愛する人と距離が近づくと怖くなり逃げたくなる
    5. 自分は穢れていると思う
    6. 自分は迷惑な存在なんじゃないかと思う
    7. 幸せになることが怖いし、信じられない
    8. 誰かに愛されるという発送がない
    9. 誰かの愛がうけとれない
    10. . 助けを求めることが苦手だ
    11. . 自由になることは誰かに迷惑をかけるものだと思っている
    12. . 問題が起きると自分のせいのように感じてしまう
    13. . 自分は毒のような存在だと思っている
    14. . うまくいきそうになるとつぶしてしまいたくなる
    15. . そもそも何かを壊したい欲求が自分の中にある
    16. . 自分は表に立ってはいけないと思っている

7つのタイプ

  1. 誰かを傷つけてしまった、壊してしまった(加害者の心理)

    1. 仕事で大きなミスをしてしまい、取引先はもちろん、自社にも大きな迷惑をかけた
    2. 子どもが自分の意見を言わないのは私があれこれ指示を出しすぎたせいか

    加害者と被害者は悪循環の関係

    「無害者」になる

  2. 助けられなかった、役に立てなかった(無力感)

    1. 他人のサポートをしたがむしろ足手まといになってしまった
    2. 自分に期待してくれた会社や上司に精一杯成果をあげようとしたが、うまく行かなかった
    3. チームのためにと一生懸命頑張ったが、うまく行かずみんなを休出させてしまった
  3. なにもしてない、見捨ててしまった
    1. 仕事上のある問題に気づいていたが何とかなるだろうと思って見過ごしていたら、大きなトラブルに発展してしまった
  4. 恵まれていることへの罪悪感
    1. 高学歴・高収入が嫌味になるのではと思って身構えてしまう
  5. 自分は毒である、自分は穢れている
  6. 親やパートナーから受け継いだ罪悪感
    1. 「私なんかの子どもでごめんね」と言われるとその環状をコピーしてしまう
  7. そのほか
    1. キリスト教の原罪
    2. ...

自分の許し方

  • 正しさを主張する人ほど罪悪感が強い
    • 罪悪感が強ければ強いほど、認めた時に保証や謝罪をしないといけないと思い、正当化・責任転嫁をする
  • 自分のせいにするのではなく、すべての問題は50:50と捉える。
    • 対等

罪そのものを客観的に眺める

  • 「自分のせいだ」と自分を責めるよりも、「自分がやったコトに原因がある」と捉えることで、客観的に自分を見つめる
    • それでも叱られたら、一応「謝罪」はしておく
  • 自分で許すことができなければ、問題は何も解決しない
  • 「自己肯定感」が必要
    • これが自分だもの
    • ミスをした後輩に接するように自分に接する
  • 自分の感情の波を乗りこなす
  • 客観視し、実況中継するように観察し、ラベリングする
  • 自分自身に「無罪」を宣言する
    • 肯定的暗示
    • 「私は私を許します。私は無罪です。・・・。・・・etc」と繰り返す
  • 罪悪感は他人に感謝することによって癒やすことができる
  • 自分らしく生きている(架空の)自分をアドバイザーに指名し、助言を求める

「賢者の書」

賢者の書

一人の少年サイードが、9人の賢者との対話を通じて、幸福になるために何が必要かを学び、書に記していく物語。 前半は比較的あっさり進んで、後半数十ページは手厚く、この本の一番大切なモノが書かれているように思う。

それは、

人はいつ、どんな状況でも、何度でも変わることができる。そして、それを信じなければならない。

ということじゃないかと思う。

この本の著者・喜多川泰氏のシリーズは物語を通じて人生の教えを伝えてくれるものが多いらしい。 概要やコメントをみると、就職活動中の若者向けであったり、人生に迷いをもつ中年向け、などいろいろターゲットがあり、自分の人生を振り返ってみたり、生きる勇気を失いそうになってしまった時などに利く物が多いようだ。

今回が2冊めで、一冊目はこちらでした。

もう一つくらい読んでみようかなと。

「Scrum Boot Camp」

Scrum Boot Camp

スクラム開発を仕事で導入しているものの、うまく進められておらず、改めて勉強しようかなと。 改めて、なので、網羅的になってないのはすみません。

さいしょにまとめ

Scrum開発とは何か、マンガによるストーリーを交えながら解説してくれるもので、初めての人にもわかりやすくまとめられている。 といっても、実践はまた別なんですよね。

アジャイル開発とは、スクラム開発とは

まずは基本的なところから復習して正しく抑えなくてはならない

アジャイル開発とは

事前にすべてを予測し、計画することはできないという前提のもとに、以下のような進め方をする開発の事を言う。

  • 関係者は目的達成のために協力しながらすすめる
  • 関係者からのフィードバックを継続的に得ながら、計画を調整する
  • 少しずつ作り、できたものが求められているものとあっているか確認する

ちなみに、Agileという英単語は、機敏な、敏捷なという意味らしいです。とてもイメージに合っていてわかりやすいです。

eow.alc.co.jp

アジャイル開発では、おおよその全体像を明らかにした上で、大まかにコストを決めて、その範囲内で大事なものから順番に開発していくので、ベストエフォート型とも言えるかと思います。 ベストエフォート型なので、例えば1年後のリリースに向けてどこまで開発できるか、という事をコミットするのが非常に難しくなる。特に大きなプロジェクトの一部だと、自分たちの都合だけでスケジュールやコストを決められないのにも関わらず、内容をコミットしなければならないというジレンマが悩み。そうするとどうしてもディフェンシブな見積もりをすることになるのかな。あるいは、どこまでできるかは優先度に従って流動的である、という事自体を前提に、ボトムラインをコミットすることになるのかなと。

Scrumとは

アジャイル開発手法の一つで、作業と会議と成果物を以下のように定める

  • 要求を実現したい順に並べ、成果を最大化する
  • タイムボックス:固定の時間に区切って作業する
  • 透明性:現在の状況や問題点を常に明らかにする
  • 検査:開発しているものが正しいのか、進め方に問題がないのかを定期的にチェック
  • 適応:もっとうまくできる方法があれば、やり方そのものを変える

コレを基本に、自分たちの環境でどのように適用できるかをアジャストするように考え、調整していくスタイル。 実際に動かしながら考えたり変えたりするのって難しくて、特にプレーイングリーダーとかだとどうしても、この辺が疎かになってしまうのが悩み。

プロダクトオーナー

  • プロダクトの結果責任を取る
  • バックログの管理者で、並び順の決定権を持つ
  • プロジェクトに一人
  • プロダクトの価値を最大化するのが目的
  • 開発チームに干渉できない

行うこと

  1. プロダクトのビジョンを明らかにし、共有する
  2. プロダクトバックログを常に最新に保つ
  3. プロダクトバックログの項目の内容をメンバーが理解できるようにする
  4. リソース計画を定める
  5. 予算を管理する
  6. 作る順番と時期をステークホルダーと相談する
  7. 作られたものが要求にあっているかどうかを検査する

非常に役割が多い。 1-3, 7は企画的な役割だし、4-5はマネージャ的だし、6は開発のリーダー的役割。 POがしっかり決まって主体的に仕事をするようなチームだとすごくうまく回りそうな気がするんだけど、僕は運が悪いのかそんなものを見たことがない。

開発チーム

  • プロダクトを作る
  • 全員揃えれば作れる

つまり、本来はUXチームとかも含めるべきなんですね。大きな組織だとこの辺がむずい。UXはいろんなプロジェクトに少しずつ顔を出して組織としての統一性をもたせるような仕事の仕方になるので。専任になるといいんだけどね。

スクラムマスター

  • プロセスがうまくまわるようにする
  • 妨害の排除
  • 支援と奉仕
  • 教育、ファシリテート、コーチ

行うこと

  • バックログの管理方法を考える
  • 関係者にアジャイル開発について説明
  • スプリントイベントの進行
  • POと開発チームの会話を促す
  • 妨害リストの管理
  • ...など

これも役割が多いので、これは(開発をしない)専任の人をひとり作るのが良い。もし開発と兼任するのであれば、その人が開発にコミットできる時間を最初から減らしておくか、分業するのが良いかもしれない。実験してみたいところ。

デイリースクラムで何を話すか

一般的には

  • 前回からやったこと
  • 次回までにやること
  • 困っていること となっているが、結局ただの報告会になってしまう。

デイリースクラムの目的は、進捗報告会ではなく、スプリントのゴールを守るための検査である」 というのはちょっと忘れがちだなと。スクラムマスターの役割はプロセスを効率化することなので、このあたりで目を光らせないといけない。

あと、妨害リストの管理というものは、ルールを決めてしっかりやっていなかったけど、すごく重要だなと。 技術的なものと、プロセス的なものと、あるいはそれ以外にもいくつかありそうだけど、上司に見せて報告しやすくしておくのも良さそう。

ということで、基本部分と改めて気になったところだけだけど。

シリーズものもあるし、他にも読んでみたい。