リスク管理の勉強をしています

以前のブログにも書いたのですが、「熊とワルツを」って本を読んでいます。

熊とワルツを - リスクを愉しむプロジェクト管理

 ちなみに、まだ読んでいる途中です。

結構ヘビーなんですよね。

 

一つ一つの話の内容が濃いのと、単純に少し古いので、今の時代で考えたらどうなんだろう？

みたいなのを考えながら読んでいると、なかなか読み終わりません。

 

それでも書いてある話は面白いんですよね。

 

 

 

面白いなあと思う話をいくつか紹介してみようと思います。

 

リスク管理をするメリット

 

まず、この本の中で、「リスク管理をするメリットが何か」について、記載されていました。

この本によると、リスク管理をするメリットというのは、意図的にリスクをとることができること。らしいです。

 

なるほど〜。

 

確かに、よく分からない不確定要素がたくさんある、という状況だと、これ以上不確定要素を増やしても大丈夫なのか分からないと思います。全体像が把握できていない状態で、新しいリスクが出てきたら、色々疲れると思いますし、リスクが管理されていない状態では、なかなか意図的にリスクを取ろうとは考えにくいと思います。

 

しかし、不確定要素がいくつあって、そのリスクが発生した時に、どんな影響が起きて、それに備えがあると分かっていれば、新しいリスクが増えたとしても、それがどうなるかを把握することができるので、前向きにリスクについて考えることができると思います。

 

なるほどね。私もリスク管理したいですね。前向きに冒険できそうです。

 

この本に書いてあったかどうかは覚えていませんが、関連して私が思うこととして、リスク管理って全体で一緒にやった方がいいと思うんですよね。

 

プロジェクトを統括している人（マネージャ）がリスクを管理するかどうか、という話を考えてみると、少なくともマネージャの心情的には、リスク管理したい状況になると思うので、マネージャとしてリスク管理をすればいいと思うんです。

 

でも、現場の近くにいて、マネージャではない人で、おそらくプロジェクト全体について考えている人はいると思うんですよね。そういう人からすると、プロジェクトのリスクについて、色々思い当たることがあると思うんですよね。

 

そういう状況で、マネージャが現場の人にオープンではないプロセスでリスク管理をしていると、現場から見ると、リスクを管理しているのか管理していないのか分からないんですよね。リスクが管理されているかどうかわからないと、非常にストレスが溜まる状況になります。だから、全体を巻き込んで、一緒にやる方が、プロジェクト全体のパフォーマンスが上がると思うんですよね。

 

この本の中では、リスク管理基盤の存在について、触れていました。

 

リスク管理基盤の存在

 

この本の中に次のことが書いてありました。

 

「リスク管理の基盤がない状態で、リスクを発表すると、発表した人が困った立場になる。」

 

これについては、あー、わかるなあという感じです。

 

リスク管理の基盤というのが、具体的にどのようなものを指しているのか、は本を読んで欲しいのですが、少なくともリスクを発表し、それがきちんと扱われて、どういうふうに検討されて、どういう風に対処されていくのか、のプロセスがきちんと流れる状態になっていないと、リスクを発表した人が困った立場になるんでよね。

 

この本で書いてあったのですが、だいたい、そういうリスクを管理する基盤がない状況で、リスクを発表すると、「負け犬」「やる気がない」「敗北主義者」などと言われるそうです。

 

私は、基本的に自分が正社員の時でもアルバイトの時でも、ボランティアの時でも変わらず、「こうなったらダメなのでは？」「こうしてみたらどうか？」「ここがうまくいっていないと思う」などの話をするのですが、私の見立て場、世の中の８割９割の組織やグループでは、そういった話をすると、「やる気がない。」「根性がない」「めんどくさい」「楽しようとしている。」「お前がやればいい」などと言われます。そういう話になると、改善策を出すのが、結構疲れるんですよね。

 

ただ、１割ほどの組織では、そういった話をすると、きちんと拾われて、きちんと解決策の検討が始まっていきます。

 

それは、発表する機会があるのか、という話もそうですし、それについて議論する機会があるのか、という話でもあります。

 

世の中では飲みニケーションみたいな、飲み会でのコミュニケーションがバカにされていますが、個人的には、飲み会というのは、リスクマネジメントのために有効なパターンでもあるんじゃないかなあと思っていたりします。

 

とはいえ、僕の場合は、飲み会で愚痴を言うのは好きじゃないですし、他の人をいじる飲み会も好きではないので、リスクマネジメントのための飲み会は行きたくないなあと思うのですが。

継続的インテグレーションに入門した話

昨日、継続的インテグレーションの本を読んでいました。継続的インテグレーションって、面白いなあ。と思いました。

「いきなり何の話やねん。」という話なのですが、私はお恥ずかしながら、CIとか継続的インテグレーションとかよくわかっていなくてですね。

そもそも、継続的インテグレーションって何だろう。という状況です。噂には聞いていて、カッコ良さそう。みたいなイメージがあります。

とは言いましても、私と同じくらいの理解度の人はいるだろうと思い、少し説明を入れます。

まず、私が読んでいたのはこの本です。

継続的インテグレーション入門

まあ2009年に発売された本なので、少々古いのですが。

とりあえず、簡単に、継続的インテグレーションってなに？っていう話をしますと、

継続的インテグレーションっていうのは、「継続的にインテグレーションすること」です。

なんのこっちゃ。というところがあると思いますので、少々噛み砕いて記載します。

昔からソフトウェアは、一人の人ではなくて、複数の人で作っていました。

でもそれは一人で作っただけでは動きません。

複数の人が作ったものをつなぎ合わせて一つの製品として、作り上げていました。

まあ家を作るのに似ていますよね。

電気屋がいて、大工がいて、施工屋がいて、と分業制になっていますし、大工にも複数の大工がいて、別々に気を切り出してきて、それを切り出した後に持ってきて、組み立てていきます。

そのいろんなものを繋げて組み上げていく作業を、「インテグレーション（統合）」と言っています。

で継続的にインテグレーションする、というのがどういうことかと言いますと、すぐにインテグレーションしていくのを連続的に繰り返すイメージです。

家の例で言いますと、今までのやり方だと、おそらく、大工が鉄骨か木か、で柱を立てますよね。そのあとで、施工やあたりが、壁を作っていって、電気屋が電気用品くっつけて言って、という流れだと思います。（なんとなくのイメージです。）

これは、継続的インテグレーションではないです。

だって、大工が柱を立て終えていないのに、施工や電気工事は始まらないですよね。段階的にくっつけていってるんです。

それが、継続的インテグレーションなら、少し違います。大工が柱をてていると同時に、施工が始まって、電気工事も始まって組み上げていきます。そして、それが悪いかを常に設計士が見ている感じです。

作業量的には、先に設計士が、全てを設計した上で、段階的にやった方が、少ないと思います。ただ、ソフトウェア開発の特性上、継続的にやった方が、効率がいい状況に、現時点ではなっています。

最近のソフトウェア開発だと、新しいことが多すぎて設計段階で全てを把握することができなくなっているんですよね。しかも、設計段階でいろんな調査をした上で作るものを設計しても、作り終える頃には、状況が変わっていて、使い物にならないとか、そういうことがあります。

例えば、家を建てるのに、１０年かかるって言われて、最初の３年が設計って言われたら、設計終わってから出来上がるのに７年かかりますよね。

そんなに時間があったら、子供産まれるとか家族が増えるとか、ルームシェアしたいとか、転勤したいとか。色々状況が変わってくるわけです。それで、出来上がったのはいいものの、全然使えない。とかなると悲しいですしね。

それだったら、細かく設計せずに、とりあえず作り始めて、作りながら、この設計だと危ないなあ。と思う部分を修正していく方がいいんじゃないかという話です。

でも、家づくりの場合、それはできません。なぜか。

家づくりの場合は、様々な安全基準があったり、全体として、バランスを取るべき指標があります。例えば、防音性とか、どこいどれくらいの負荷がかかっているのかとか。あとは、釘の打ち方や利用する材料にしてもポリシーがあるかもしれません。

それらは、基本的に設計士が事前に考えて、設計図を書き、それを元に作っていくわけです。でも、きちんと設計せずに作り始めると、いろんなバランスが崩れてきた場合に大変なわけです。だから、設計士が常に組み立てるのを見てるんでしょ？っていうと、確かに、見ているんですが、そんな素早く全ての検討項目を考えつくすのは、さすがに設計士にも厳しいわけです。それができるなら、最初の設計がめちゃくちゃ早くなると思うので、細かく設計してから作った方がいいと思います。

じゃあどうするんだ。っていうと、ソフトウェア開発の継続的インテグレーションでは、自動的に設計士が見て判断するような部分を全チェックしていきます。

そういう環境を作って、みんなで一つの場所に組み上げながらソフトウェアを作っていくのが継続的インテグレーションです。

なるほどね〜。面白いなあ。

もう少し継続的インテグレーションについては、詳しく調べていきたいと思います。

継続的インテグレーションについて調べているうちに以下のようなブログも出てきたので、紹介しますね。

www.kaitoy.xyz

ジョギング始めました。

本ブログにお越しの皆様

お世話になっております。

一日１５分間のジョギングを始めたmtbです。こんにちは。

いきなりの話にはなりますが、最近、ジョギングを始めました。

皆さんはジョギングしてますか？というか、運動していますか？

私は、全然運動していません。

普段はデスクワークですし、休日も特に用がない限りは家でゴロゴロしながら本を読んでいるかパソコンを触っているような人です。

フットサルやってますよ！とか、ゴルフが趣味なんですよ！とか、なんか多少なり運動する機会があればいいのかもしれませんが、私の場合は、特にないんですよね。

残念です。

ですので、運動のために、ジョギングを始めました。

最近読んだ本によりますと、運動をすると脳の神経にいい影響があるようですね。

ちなみに、最近読んだ本というのはこの本です。 

脳を鍛えるには運動しかない! 最新科学でわかった脳細胞の増やし方

 あ、アフィリエイトじゃないですよ。

この本は、まだざっと全体を眺めた程度で細かく読めていないのですが、一部、気になる話が書いてありました。

その話というのは、運動をすることで脳の神経細胞にいい影響があって、その影響というのは、精神病患者に支給される高額な薬よりもいいことがあるとの話です。

なんと。

すごいですね。運動にそんな効果があったとは。

そういえば、中学生、高校生くらいの頃、運動をたくさんしていたのですが、あの頃は、なんとなくメンタルマッチョだった気がするんですよね。今よりも。（今もある程度メンタルマッチョかもしれませんが）

今は、全然運動をしていないのですが、個人的な感覚としては、以前より、メンタル的に凹みやすくなったような気がしています。

あと、この本にも書いてあったことですが、定期的に運動するかどうかで、アルツハイマーになる確率が結構変わるみたいですね。

なるほどね〜。

やっぱり運動は大切ってことですね。

というわけで、私は運動を始めました。

と言っても、２〜３日に一度１５分ほどランニングするだけです。

「なんで毎日やらないの？２〜３日ってなんなの？適当なの？」

「１５分じゃダイエット効果ないよ。有酸素運動は、３０分以上やって初めて、脂肪燃焼効果があるんだよ」

「しんどいなら、ランニングじゃなくて、ウォーキングでもいいと思うよ」

こんな声が、どこからともなく聞こえてきました。

せっかくなので、一つずつ回答したいと思います。

「なんで毎日やらないの？２〜３日ってなんなの？適当なの？」

２〜３日というのは適当です。

毎日やるぞ！！！って決めて、毎日できなかったら、

なんか気分的にがっかりするんです。自分のモチベーションが下がるような状況はできるだけ避けていきたいという意図があります。

そりゃ、毎日やると自分で決断して、毎日できればいいんですけど、気合を入れて始めれば始めるほど、できなかった時のダメージが大きいんですよね。

そもそも、毎日やるって、結構難しいんですよね。

友人と飲んでる時とか、仕事で遅くなった時もやるの？って思いますし、そんなしんどい時にも頑張って走ってる人がいたとすれば、その人はすごいと思います。

でも、私の場合は、しんどい時は休むし、この運動だけをストイックに毎日やることはできません。他にストイックにやりたいことはたくさんあるので、精神力が持たないというのが本音です。高校生の時に、毎日１時間くらい走ってたのが懐かしいなあ。

「１５分じゃダイエット効果ないよ。有酸素運動は、３０分以上やって初めて、脂肪燃焼効果があるんだよ」

ダイエット効果がない、というより、ダイエット効果が薄い、ではないかなと思います。走ってるんだから、家で寝てるよりは、カロリーを消費していると思います。

有酸素運動を３０分以上やったら、効果があるという話は知っているのですが、全く運動をしていない状態から、いきなりランニングを３０分間するのって大変なんですよね。しんどい。

しんどいと、やめたくなります。それじゃあ続かないと思います。１５分くらいのランニングでも２〜３日に一回やり続けていると、体力が少しずつついてきます。

そうしてから時間を増やしてもいいんじゃないかなあと思っています。ですので、基本的にしんどいと思う前に、家に着くようにしてます。家着いてから、「あ〜今日のランニングも余裕だったわ〜」って思えるようにしたいなと思ってます。

そういえば、今日のランニングは、気づいたら２０分走れました。

「しんどいなら、ランニングじゃなくて、ウォーキングでもいいと思うよ」

ウォーキングってなんか好きじゃないんですよね。

ウォーキングっていうとなんか、意識高い歩き的なイメージがあります。うーん。

あ、一人で行く場合の話をしています。

一人で行くなら、ぼーっとしながら散歩するくらいの方がいいかなあ。

とは言え今回は、運動したいという気持ちがあって、私の性格上、単位時間あたりの運動密度を上げたいという気持ちがあり、、ランニングという話になっています。

自分で話してて思いましたが、単位時間あたりの運動密度を上げるなら、もう少し走るペースを早くしてもいい感じなのかな。

さて、話が平坦というか、起承転結が弱い文章で申し訳ないですが、本日のブログはこのあたりで終えたいと思います。

んー、このブログは、面白くない。

みなさまお疲れ様です。

会社員の方は、今日も仕事を終えられたでしょうか。

学生の方は、もうお家ですか？それともアルバイトでしょうか。飲み会でしょうか。

何れにしても、みなさま本日もお疲れ様でした。

私も、仕事を終えて帰宅しました。

帰宅している最中、他の人のブログを拝見していました。

何人かのブログを拝見していると、他の人のブログ記事と自分のブログ記事の違いといいますか、差といいますか、自分のブログが客観的に見て、どのように見えるのだろう、と言った部分が気になってきました。

なるほど。こう言うブログは見やすくて、こう言うブログ記事は、見にくいのね。と言うことを他の人のブログを見て考えてしまいました。

あと、他の人のブログを見ていて、こう言うブログは、面白いけど、こう言うブログは個人的にあんまり面白くないなあ。と思うこともありました。

面白い/面白くない、と言うのは、決してその筆者自体が面白くないと言いたいわけではなく、文章として、何か勿体無い感じがしたと言う話です。

さて、偉そうなことを言っていますが、私のブログは、どうでしょうか。見返して見ましょう。

「面白くありません」

残念です。非常に残念です。

他の人のブログを見ていて、あーこう言うブログはいいなあ。と個人的に思うことがありました。

そのブログは、そのブログを書いている人の個性が出ていると言いますか、そのブログを書いている人の人間性が現れているようなブログです。

その人個人の感想があったり、その人個人の考えが記載されていると、あーこの記事は面白いなあ。と思ったりしました。

でも、一方で、自分の考えを記載していなかったり、どこか他人行儀といいますか、自分の言葉が少ないブログというのは、読んでいて少し残念な気持ちになりました。

なるほど。

そのように考えながら、自分のブログを見ていると、なんか薄いといいますか、本を読んだから書いているような内容が多くて、あんまり面白くないなあと思いました。

あと、記事に書いてある内容に力が入っていて、読んでいて少し疲れちゃうなあ。とも思いました。

もっと、肩の力を抜いて、ゆるい記事を書いてもいいのかな、と思ったりしました。

はい。

もうちょっと読んでいて、人として興味が湧くような記事が書けたらいいですね。

もう少し、そういう記事を書いていきたいと思います。

バランスを取った方がいい？

自分の中に、なんとなく「バランスを取った方がいい」と考えているところがあります。

 

このブログを読んでいる人も、バランスを取った方がいいと思いますか？

それとも、ある程度、バランスは無視した方がいいと思いますか？

 

人によって程度はあると思いますし、人によってバランスを取る理由は様々だと思います。

 

今回は、ふと、自分は、なぜ「バランスを取った方がいい」と考えているのだろう。と思いました。

 

「バランスを取る」ということの目的は、「バランスを良い状態にする」ということだと思います。

 

バランスが良い/悪い、という言い方が、なんともいえないのですが、私のイメージでは、バランスを取るというのは、プラス要素とマイナス要素を相殺しようとする動きだと考えています。

 

何か、新しいことを始めた時に、良くも悪くも周りに影響が及びます。

その中で、できるだけプラスの要素の影響だけを及ぼして、マイナス要素の影響を少なくすれば、バランスが良い。と言われるように思います。

 

私が考えるに、何か新しいことを始め、それが及ぼす影響の中には、意図したものもあれば、意図しないものもあると思います。

 

意図しない影響が波及したとしても、別に気にしない。という人もいるでしょうが、私の場合は、自分が始めたことによって、意図しない影響が波及するのは、可能な限り避けたいという想いがあります。

 

おそらく私は、周囲に影響を波及させるのであれば、意図的に波及させたい。という想いがあるんだと思います。

 

なんていうのでしょうか。

 

自分が選択してやったことで生じた影響を、「そんなもん知らん！」っていうのは簡単かもしれませんが、私自身としては、そんなことを言いたくないなあと思うのです。

 

自分が選択したことなんだから、それで起きた影響も、なんとかしたい。という想いがあります。

 

とはいえ、人生そんなに簡単じゃないと言いますか、バタフライエフェクトのように小さなことが大きなことに繋がることを考えると、自分の選択で生じた影響を全てコントロールするのは無理だと思います。

 

ただ、無理だと思うというのと、それを全くやらないというのはまた別の話だと思います。無駄だとしても、理想を目指してみるのも悪くないと思います。

 

バランスを取るのって難しいですよね。

こどものリスク管理

新しく本を読み始めました。

次に読み始めた本はこちらです。

熊とワルツを - リスクを愉しむプロジェクト管理

 先日読んだ本、「ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解」を書いたトム・デマルコの続編になる本です。

前作では、ゆとりがないことが原因で、様々な問題が引き起こされていることについて記載されていました。

そして、最後は、リスクを管理しよう、という話で終わっていました。

まだ、この本も２章を読んでいる途中なので、どのように進んで行くのかは、わかっていないのですが、少なくとも、リスク管理に関する話がたくさん記載されているようです。

リスク管理か〜、聞いたことあるぞ〜、と思いながら読んでいたのですが、１章に書かれていたリスク管理のありがちな間違いに自分はギクリとしたところがありました。

その話というのは、対策のわからないリスクは、リスク管理に挙がってこないという話でした。

私は、プライベートでも、こういう風になったら嫌だなあ、とか、こういうのが気になるなあ、っていうことは、全てタスクリストに突っ込んで管理しています。そして、その一つ一つについて、検討して何をするのかの行動を洗い出しています。

いや、厳密には洗い出そうと思って、気になることはメモしていますが、現状は、検討項目が多すぎて、間に合っていません・・・・。まあこれは置いといて。

対策のわからないリスクが、リスク管理にあがってこないということは、リスク管理が、リスク対策用行動管理になっているということです。

本書の中では、それは「こどものリスク管理」と言っています。

うーん、じゃあリスクを管理するにはどうすればいいんでしょう。

とりあえず、定期的に何かを監視するとか、何かコトが起きた後にやることの準備をしておくとか、ですかねえ。

多分、この話は、本の中に書いてあると思います。

この後、どういう風に話が進んで行くのか、楽しみにしています。

ゆとりの大切さの明文化

Slackを読み終えました。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

この本に書いてあったことは、僕に、いろんな気づきを与えてくれました。

きっとシステム開発に関わっている人がこの本を読めば、僕と同じように、何かしらの気づきを得ることができると思います。

 

システム開発に関わっていない人であったとしても、仕事で何か計画を立てて、実行しようとした経験がある場合、何かしらの気づきを得ることができると思います。

 

仕事で計画を立てたことがない場合、あまり気づきを得ることができないかもしれません。

 

この本では、プロジェクト管理とゆとりの関係について、記載しています。

仕事とプライベートで、何が変わるかというと、外部からの圧力です。

 

仕事の場合、外部からの圧力がかかりやすく、プライベートの場合、外部からの圧力がかかりにくいです。

 

この本で取り上げられている「ゆとり」というのは、外部からの圧力によって、変化しやすいもので、仕事で計画を立てた経験があればあるほど、「ゆとり」の大切さを実感したことがあると思います。

 

この本では、その「ゆとり」の大切さを明文化しています。ここでいう「ゆとり」には、時間のゆとり、お金のゆとり、構造のゆとり、精神的のゆとり、など様々なゆとりが話されています。

 

今まで、ゆとりは大切だと思っているもののに、なぜ大切なのか、ゆとりがなくなると、何がなくなるのか、そして、どういう影響が出てくるのか、といったことをなかなか説明できない人もいたと思います。

 

僕もそのうちの1人です。

 

でも、この本を読むことで、自分がぼんやりと思っていたことが、文章として整理されました。

 

文書として、言語化して、整理されるということは、大切なことだと思います。なぜかというと、他の人に説明するとき、必ず、言語化して伝えないといけません。

 

同じ経験を持つ人ばかりで集まることができれば早いのかもしれませんが、いつもいつもそういう時ばかりではありません。

 

それに歳をとるにつれて、少しずつ状況は悪くなっていきます。なぜかと言いますと、自分の経験はどんどん伸びていき、プロジェクトの中の自分の相対的なポジションはどんどん上がっていきます。

 

現時点でも、同年代の中ではプロジェクトに関する経験値が多い方だと思っているのですが、それが今以上に、経験値や知識が多い立場になっていきます。そうなると、一つ一つ言語化して、なぜこれがこうなっているのか、というのを説明しないと周りの人に伝わらないことがあるんだろうなあと思ったりします。

 

説明ができないと他の人に伝わらないですし、伝わらないということはその人の納得にならないと思います。結局のところ、相手が納得できないと、いい方向には進んでいかないことが多いので、説明ができないがために、自分が過去に巻き込まれためんどくさいことや先人がわざわざ本にして伝えてくれているアンチパターンを再び自分が踏むことになってしまいかねないです。

 

プロジェクトにゆとりが足りないなあ、と思っている人がいたとしたら、この本を読んでみることをお勧めします。