ゆとりの大切さの明文化

Slackを読み終えました。

 

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

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

 

 

この本に書いてあったことは、僕に、いろんな気づきを与えてくれました。
きっとシステム開発に関わっている人がこの本を読めば、僕と同じように、何かしらの気づきを得ることができると思います。
 
システム開発に関わっていない人であったとしても、仕事で何か計画を立てて、実行しようとした経験がある場合、何かしらの気づきを得ることができると思います。
 
仕事で計画を立てたことがない場合、あまり気づきを得ることができないかもしれません。
 
この本では、プロジェクト管理とゆとりの関係について、記載しています。
仕事とプライベートで、何が変わるかというと、外部からの圧力です。
 
仕事の場合、外部からの圧力がかかりやすく、プライベートの場合、外部からの圧力がかかりにくいです。
 
この本で取り上げられている「ゆとり」というのは、外部からの圧力によって、変化しやすいもので、仕事で計画を立てた経験があればあるほど、「ゆとり」の大切さを実感したことがあると思います。
 
この本では、その「ゆとり」の大切さを明文化しています。ここでいう「ゆとり」には、時間のゆとり、お金のゆとり、構造のゆとり、精神的のゆとり、など様々なゆとりが話されています。
 
今まで、ゆとりは大切だと思っているもののに、なぜ大切なのか、ゆとりがなくなると、何がなくなるのか、そして、どういう影響が出てくるのか、といったことをなかなか説明できない人もいたと思います。
 
僕もそのうちの1人です。
 
でも、この本を読むことで、自分がぼんやりと思っていたことが、文章として整理されました。
 
文書として、言語化して、整理されるということは、大切なことだと思います。なぜかというと、他の人に説明するとき、必ず、言語化して伝えないといけません。
 
同じ経験を持つ人ばかりで集まることができれば早いのかもしれませんが、いつもいつもそういう時ばかりではありません。
 
それに歳をとるにつれて、少しずつ状況は悪くなっていきます。なぜかと言いますと、自分の経験はどんどん伸びていき、プロジェクトの中の自分の相対的なポジションはどんどん上がっていきます。
 
現時点でも、同年代の中ではプロジェクトに関する経験値が多い方だと思っているのですが、それが今以上に、経験値や知識が多い立場になっていきます。そうなると、一つ一つ言語化して、なぜこれがこうなっているのか、というのを説明しないと周りの人に伝わらないことがあるんだろうなあと思ったりします。
 
説明ができないと他の人に伝わらないですし、伝わらないということはその人の納得にならないと思います。結局のところ、相手が納得できないと、いい方向には進んでいかないことが多いので、説明ができないがために、自分が過去に巻き込まれためんどくさいことや先人がわざわざ本にして伝えてくれているアンチパターンを再び自分が踏むことになってしまいかねないです。
 
プロジェクトにゆとりが足りないなあ、と思っている人がいたとしたら、この本を読んでみることをお勧めします。

プロジェクトのゆとり。

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

 その本はこれです。

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

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

 

 

これまで仕事や私生活の中でプロジェクトの管理について考えることが多かったんですよね。

それは、私がプロジェクト管理をしているかどうかにかかわらず、「これってプロジェクトだよな?」と思うことが多いことが関係しているのだと思います。

 

私は、基本的に、プロジェクトに関わる人数が何人であれ、目標を達成するまでにある程度の期間とある程度の作業工程が必要になるものは全てプロジェクトとして考えています。

 

私は、そのプロジェクトが、どういうふうに進んでいけば、どうなるのかを知りたかったんですよね。プロジェクトに関わる限り、できるならば成功させたいと思うので。

 

何でもそうだと思いますが、基本的に、本を読むよりも1回経験するのが理解は早いと思っています。百聞は一見にしかず。というように、100回聞くより1回経験できるのであれば、それが良いと思います。

 

そうはいっても、100回プロジェクトを経験できるかといえば、それは難しいと思います。それに100のアンチパターンを自分で全て潰して行くのは少しばかり心が辛いです。当然のことかもしれないですが、失敗するためにプロジェクトをやることは少ないですし、最初から失敗するためにやるのはモチベーションも上がらないです。とはいえ、絶対に成功するプロジェクトってなんなんだろうと思うようなところもあります。

 

そして、私はプロジェクトをどうやって成功に導くのかを考えるのがプロジェクト管理であると考えています。

 

だからプロジェクト管理について勉強してみようと思っています。

 

まだ、3章しか読んでいないが、すでに経験のあることが書かれています。

 

効率化を進めようとすると、複数のことを並列で作業しようとする。とのこと。

なぜ複数のことを並列で作業しようとするかといいいますと、仮に一つのことだけを作業してして、それな1日の50%くらいの時間で終わるとき、同じくらいの仕事を2つ同時にできるよね?という話です。

 

ただ、それは実際のところ難しくて、複数のことを並列でやろうとすると作業の切り替えが必要になるので、無駄な時間が発生しますよ。とのことに言及されていました。

 

それはわかります。確かに、複数のことを並列でこなそうとすると、それぞれのタスクや情報を管理するコストがかかります。私も同じ状況になったことがあります。情報の管理のためにコストが爆発して、全然前に進まなくて困ります。そして、すごいフラストレーションが溜まります。

 

 

 

とはいえ、これについて少し対策としてこうならないか、と思っていることがありました。

 

今の所、複数の作業をやるときに、作業の切り替えで時間がかかるなら、切り替えなければいいのではないか?と思っていたりします。

 

切り替えないとはどういうことかというと、作業は一つ一つ完了させてクローズして行くということです。

 

複数の作業をやるなかで一番キツいのは、途中まで物事を進めた後に、別のことに着手することです。そして、その後に途中まで進めた物事に戻ってくる時に時間がかかります。

 

戻ってきた後は、自分が何をするのかをサイド考え直すことになります。それが結構な時間かかるし、タイムロスになります。

 

じゃあどうするか、別のことに行った後に戻ってこなきゃいいと思ってます。片道切符しか持たないのではないかと。

 

そうは言っても、自分のやっている作業が完了していなければ、戻ってこざるを得ないように思います。じゃあどうするか、というのを考えて、今の所は、「タスクひとつひとつをできるだけ小さい単位に分割する。」という方法で試行錯誤をしています。

 

何かを思い出すときは、自分の行動の軌跡を確認すると楽になります。だから、タスクの一つ一つの履歴を確認すれば、何をしているのかを追跡できるようになります。

 

ふむ。

 

そうすると次は、「タスクひとつひとつを小さい単位に分割するか」「小さい単位とは何か。」という疑問が湧き出ます。

 

これについては、現在、試行錯誤中です。何がいいのかわわからないのですが、とりあえずは、小さい行動と、小さい成果物単位の集合体として、最終的な成果物を定義すると、うまく行くように思っています。

 

ただし、最終的な成果物が小さい行動と小さい成果物の集合になっている場合、最終的な成果物を構成する行動や成果物を自分で洗い出すことになります。

 

そこでミスが起きると、時間的な見積もりに狂いが出ます。狂うことが悪いと言っているのはないのではですが、少なくとも狂っているのが現在です。

 

じゃあどうするか、というと、とりあえず余分に見積もっています。1日にできることを全体の70%くらいしかつめない。後の30%は、不要なほどクオリティを上げたり、遊んでみたり、別のことを考えたり、と十分条件に対応するような情報をここでやる。僕にとっての「ゆとり」は、そういう部分と思ってます。

 

 

僕が今考えていることは、今読んでいる本で考えている「ゆとり」という考え方とは、少し違うのかもしれません。でも、この本がこれから、どういう風に発展して話が進んで行くのか楽しみになっています。

 

 

 

思考のリハビリ活動

この二週間のひとり旅で少し思考は整理されたのですが、まだまだ、私の頭の中は、気になることや考えたいことで、いっぱいです。頭の中が、たくさんの気になることで埋まっているなと思います。

 

今の私は、自分の話したいことや、自分が考えたいことが絶え間なく湧いてくる状態です。今の私の状態は、1人で一つのことについて考えている時に、別のことも浮かんでくる状態です。

 

別のことが浮かんでくると、そっちが気になって仕方がなくなります。そして、浮かんできた別のことを考えていると、また新しいことが気になり始めます。そうして、私の思考の対象は、どんどん入れ替わっていきます。

 

思考の対象がどんどん入れ替わって行くと、累積的な思考時間としては、どんどん蓄積されて行くけど、一つ一つのなかなか話の進展具合としては、芳しくないという状況になります。

 

あんまりよくないと思います。

 

以前はもっと頭がすっきりとしていました。もっと頭がすっきりしていた際は、自分の言いたいことを自分の頭の中で整理することができました。

 

私はそういう状態になりたいです。頭がすっきりしていて、それをどうしたらいいのかを、頭の中で、考えがまとまる状態です。

 

こうやってブログなどのために、文章を打っていると気付くことがあります。それは、自分が書いている文章には、結構な頻度で接続詞や助詞が抜けて書いていたり、間違えて書いているということです。主語が抜けているときもあります。

 

何にしても、私は、正確に日本語を喋れないようになっていると思います。例えば、主語がないまま言葉にして行くのが癖になっていることもあります。

 

前は、最初はそういうの好きじゃなかったのに、気がついたらこういうふうに、主語がないまま喋り出す癖がついていました。

 

おそらく、3年前は、自分で考えて、大量の文章を書いていました。

しかし、この三年間は、自分で考えて文章を書くことがかなり少なくなっていました。

そのことによって、自分は正確な日本語を喋れないようになくなったと思います。

 

とはいえ、それでいいとは思っていません。

ですので、少しずつリハビリを進めていきたいと思っています。リハビリの中で、一つ一つの文章の精度を上げて、きちんと主語を意識して、文章を書くことができると思う。

 

だから、私は、今、こうやって考えていることを文字にして行くことで、再度リハビリに励んでいます。

 

ひとり旅に行ってきました。

こんにちは。

会社からゆっくりと休暇をいただきましたので、ひとり旅に行ってきました。

 

先々週は、4泊5日で、北海道に行ってきました。 

先週は、4泊6日で、バリ島に行ってきました。

 

久しぶりにひとり旅に行ってきたんですが、だいぶ落ち着くことができました。

 

私は、普段は東京で生活をしているのですが、今回、北海道やバリ島に行って、改めて、東京って恵まれてる環境だなあと改めて確認しました。

 

なぜかといいますと、東京って基本的に情報やイベントへのアクセスがすごく容易ですし、治安も良くて安全な街だと思います。

 

北海道は、安全とは思いますが、「あれ?ここ大丈夫なの?冬とか大変じゃない?」というような場所はちょくちょくありました。

バリ島でも、時折、生死に関わりそうな、話を聞いたり、バイクをヘルメットなしで乗っている人がたくさんいるのをみて、安全じゃないなあと思うことがありました。

 

まあ、旅行について、今回は、詳しく書くつもりはありません。

 

今回は、何かしらブログを更新したいなと思いまして、こうしてブログを更新しています。

 

今、仕事を一旦休憩にして、色々考え事をしている時期になります。

 

普段の私は、気になることはひたすらメモにとっています。その気になることについて、一つ一つ、時間のある時にひたすら詳しく考えてみるということをしています。

 

ただ、それがこの3年くらいは、溜まりに溜まってしまって、全然消化できていませんでした。ただ、この二週間ほどで、結構消化することができました。よかった。

 

とはいえ、気になることを考えると、新しく気になることが出てくるというものです。ですので、数としては、そんなに減ってはいないのですが、それでも、頭の中が整理されたようで、少し気持ちいい気分ですね。

 

それとは同時に、読みたくて溜まっている本も少しずつ読み進めています。

 

GWあたりに読みたいと行っていた本で、「パーフェクトソフトウェア」という本がありました。この本は読み終えました。

 

システムとかソフトウェア開発がうまく行っているのかうまく行っていないのか、という判断は難しい、ということについて学ばせてくれる本でした。

 

読んでよかったですね。ソフトウェア開発に詳しいベテランにたくさんの経験談を聞いたような気分になりました。実際にこれから、この知識が活かせるのかわからないですが、そのような話があると認識していきたいですね。

 

はい。

 

旅行の中で、他にも本を読んでいました。

 

例えばこの本です。

愛するということ

愛するということ

 

 

エーリッヒ・フロムが書いた哲学の本ですね。愛って何だろう。という話を書いてます。

 

そう、めんどくさい話なのです。私は結構めんどくさい話をモゴモゴと考えたりします。

 

この本でもそうなのですが、基本的に本に書いてあることって、本を読まなくても自分で経験して、自分で考えて、自分の考えを整理すると、同じことに到達することがあると思います。

 

この本も、まだ読んでいる途中ですが、私が1人でモゴモゴと考えていたことに近いことが書いてあったりと、なるほどなるほど。と思うところがありました。

 

それは本を読んでいて面白いことだと思っています。

 

さて、とりあえず、今回のブログはここまで。

 

何が言いたいかよくわからない感じになっていますが、まあ文章を書くリハビリと思って、少しずつ書いていきます。

読みたい本がたくさんありすぎて困る状況

こんにちは。みなさん、楽しいGWをお過ごしでしょうか

 

僕は、まああいかわらずの生活を送っています。

 

少々、実家に帰省したりもしましたが、今は自宅に帰ってきて、いつも通り本を読んだり、黙々と勉強したりなんかやってます。

 

Youtubeで適当に音楽を流していて、最近はこういう音楽が流行ってるんだね。みたいな感じでやってます。

 

いきなりですが、最近、読みたい本がたくさんありすぎて、やばいことになっています。

 

買うスピードと本を読むスピードが一致していなくてすごい勢いで本が溜まっていっています。

 

困った。

 

まあ勉強したいという意欲があるだけ、今は幸せと思って、マイペースに勉強しようかなと思っています。

 

とはいえ、全然消化できないと心のモチベーションも下がっていくのでどうにかしたいなと思っています。

 

なんとかできないものかと思って、とりあえず、読む本をリスト化してみました。

 

リスト化してみたものの、一つ一つが大きくて、全て読書中の状態から進まず、それもなかなかモチベーションに影響があるなあと思っています。

 

というわけで、全ての本に対して、目次の章単位で、AIに追加しました。

AIというのはアクションアイテムね。人工知能とかそういうやつじゃないですよ。

 

こうやって、一つの章を読むたびに、一つの章をOK!ってチェック入れていくと、多少なりモチベーションを保って、読書できるかなあとか思ってます。

 

なんか、やってもやっても終わってないというか、何もやっていない気分になると、自分は何をやってるんだろうな、って思っちゃいますしね。

 

こんな感じで、読書をたくさんしたいなあとか思っていたりします。

 

ソフトウェア開発のテストに含まれていること

何かしら文章を書きたい気分なので、文章を書こうと思う。とはいえ、今のところブログに書きたい話も特にないので、今日読んでいた本の話をしようと思う。
 
今日もパーフェクトソフトウェアっていう本を読んでいた。パーフェクトソフトウェアという本は、ジェラルド・ワインバーグ(1933~)の著書の一つ。ソフトウェア開発の世界では、有名な人だと思うので、知らない人は調べてみてもいいと思う。簡単にいうと、ソフトウェア開発仙人みたいな人。
 
そして、パーフェクトソフトウェアは、ソフトウェア開発が大好きなジェラルド・ワインバーグがソフトウェア開発のテストについて書いた本。まだ、少ししか読んでいないけど、話の密度が濃い。
 
話の密度が濃すぎるので、とりあえず、SEやプログラマになりたての人にはオススメできないし、ソフトウェア開発が好きじゃない人にもオススメできないと思ってる。でも、ソフトウェア開発をより良くしたいと思っている人なら、一読する価値はあると思う。
 
今回は、パーフェクトソフトウェアの4章「テストとデバッグはどう違う?」を読んだ。そこでは、一般的にテスト、と言われているものが、どういうもので何を含んでいるかを話していた。個人的にすごく興味のあるはなし。
 
なぜかというと、最近、ソフトウェア開発の一つ一つのタスクが大きすぎることについて悩んでいて、それを整理したいと思っていたからだ。これについては、詳しく書くことがあったので、また今度書くことにする。
 
そんなことを考えながら、ソフトウェア開発の中にやることって何が含まれているんだろうとか考えていた。それで本を読んでいたら、パーフェクトソフトウェア、という本に出会って、その中で、テストがどういうもので、何をやるべきなのかについて書いていた。
 
この本によると、テストには、次のような工程が入り乱れている。

発見のためのテスト・・・新しい情報が見つけようとする。

絞り込み・・・バグが発生する条件を特定しようとする。

特定・・・バグを修正できるようにコードの中のバグの位置を探す。

重要度の決定・・・修正したことによるリスクと、バグを修正しないことの影響を天秤にかける

修正・・・コードを修正する

トラブルシューティング・・・ソフトウェアの動作の障害を取り除いたり回避したりする。

学習のためのテスト・・・ソフトを使うために試行錯誤する。または遊ぶ。

 

1人でやっているときは、これらを好きな時間にスイッチすればいいが、複数人でやっていたり、組織的にやっているときは、これの役割分担がしっかりしていないと揉め事が起きるよ、という話をワインバーグはしている。

 

 

 

これまで、ソフトウェアを開発しているときに、自分がやっていたことをこういう風に可視化されると、もう少し管理しやすくなるような気がした。

とはいえ、これをどうやって管理しよう?という部分までは今のところ考えが及んでいないんだけど・・・。

 

今年のGWでやりたいこと

挨拶

みなさんこんにちは。mtbです。GWに入りましたね。

みなさんは、GWに何をする予定でしょうか?まだ、予定が決まっていない人もいれば、予定がたくさん決まっていることもいるのかなと思います。

 

私は、連休が始まりましたので、ひとまず田舎の方に帰ってきました。

私は連休があると田舎の方に帰ってくることが多いんですが、特に田舎の方で何かをやるという話でもありません。まあ都会にいてもできることをやってるケースが多いです。(例えば、プログラム作ってるとか、音楽作ってるとか、本読んでるとか・・・)

 

とはいえ、連休中にこんなことやりたいなーと思っていることがあります。

 

連休中にやりたいこと

こんなことが連休中にやりたいと思っています。 

  • GitとGithubを勉強したい
  • Pythonでプログラミングしたい
  • Pythonの開発環境を整備したい
  • 「パーフェクトソフトウェア」を読みたい
  • Pythonプロフェッショナルプログラミング」を読みたい
  • 「データ解析のための統計モデリング入門」を読みたい
  • 「ソフトウェア開発者の人生マニュアル」を読みたい
  • 「ストレスフリーの整理術 実践編」を読みたい

まあ、他にもあるし、これが全部できるのか、、、というとなかなか怪しい部分ですが・・・。 

一つ一つ軽く触れようと思います。


GitとGithubを勉強したい

お恥ずかしながら、私、ほとんどgitとgithubを使ったことがないんですよね。

「git?あー、バージョン管理システムの分散型のやつね」とかなんか知ってる風のことを言いますが、実際はよくわかっていません。

ただ単に、gitとかgithubのことを本とかで軽く読んだだけです。

実際に使うってところになった時に、どういう風に使うのとか、どんなことができるのとか、どんな風にやるといい感じなのか、とか、全然よくわかっていません。

 

まあそういうのは、「個人的に追々やっていけばいいかな?」と思っているところがあったり、「最初はわからないのはしょうがない。」的な考えはあるのですが、しょうがないと言いながら、個人的には早くわかるようになりたいという気持ちもあるので、ちょっとこの機会に詳しく勉強したいなあと思っています。

 

Pythonでプログラミングしたい

まあこれはあれです、Pythonでプログラミングしたい。って話です。

ちょうど、今、Pythonのプログラム課題があるので、それやろうと思っています。

Pythonプログラミング、というかプログラミング自体に少々ブランクがあるので、早く慣れて、もっとスピードアップしたりクオリティ高いプログラムかけるようになりたいなあと思ってます。

 

とりあえず、Pythonでプログラム書くのは気分がいいし、かけるようになっていくと、なんか気持ちがいいです

Pythonの開発環境を整備したい

Pythonのプログラムを開発する開発環境をもっと整備したいなあと思っています。

今のところ、

iTerm2 + vim + pyenvになっています。

もうちょいソースチェックツール入れたり、テストフレームワーク入れたり、色々やりたいことがあります。まあ何をやれるのかよくわからんので、調べるところですかね。


「パーフェクトソフトウェア」を読みたい

これです。 

パーフェクトソフトウエア

パーフェクトソフトウエア

 

ソフトウェアのテストとはなんぞや?って話について書いてます。

個人的に気になるので読み進めているところです。GWに読み終えなくてもいいですが、ちょっとは読みたいなあと思っています。


Pythonプロフェッショナルプログラミング」を読みたい

これです。 

Pythonプロフェッショナルプログラミング

Pythonプロフェッショナルプログラミング

 

私のPythonプログラミングは独学なので、Pythonでのプログラミングってどんな風にやるのがいいんだろう?というのを知りたくて買っていました。

前に3〜4年くらい前にざっと読んだんですが、当時は「へー、こんなことがあるんだ」くらいしか理解することができませんでした。というか、当時は、仕事でソフトウェアの開発に関わってもなかったので、何を言ってるのか、いまいちしっくりこなかったという感じです。これも、また改めて読み返したいなあと思っています。

 

「データ解析のための統計モデリング入門」を読みたい

 これです。

いわゆる統計の有名な入門書です。緑本とか言われていますね。

これも2年くらい前に読んだんですけど、再度読み返そうと思っています。

なんでかというと、またそのうち、データ解析の話に関わりそうなんですよね。

ここ1年2年は、データ解析の話をほとんどしていないと言っても過言ではないので、ちょっといろんな知識を復活させていかないと、色々問題がありそうだなあ。と思ってます。まあこれもぼちぼち読み進めたいですね。

久しぶりにざっくり見ると、楽しそう。


「ソフトウェア開発者の人生マニュアル」を読みたい

 これです。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

 

いわゆる自己啓発本です。今のところ、はじめの方だけ見ました。

読んでて「あーそうそう、僕も1人で同じこと考えた」みたいなことを思います。

多分、基本的に複数の選択肢があった時にどちらかを選ぶということはどういう意味を持つのだろう?という話について、考えたことを書いている流れの本だと思っています。

私も、多くの人と同じように複数の選択肢があった時、両方とも考えて見て、どうするか考えるので、読んでおくとそのうち楽になることがあるかも。と思って読みたいと思っています。


「ストレスフリーの整理術 実践編」を読みたい

 これです。 

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

 

私は自分のタスク管理をGTDでやろうと思って、色々モゴモゴしているのですが、なんかいまいちしっくりきていない部分がちょいちょいあるので、もっといい感じにGTDを回していきたいなあと思っています。

そのために、色々考えたり試行錯誤してますが、試行錯誤した後に、この本を読むとなるほどなるほど、と思うことがたくさんあるんですよね。

そんなこんなで、ちょいちょいこの本は読み進めていきたいと思っています。

終わり

まあ、とりあえず、私は相変わらずです。GWでも普段の生活とそんなに差がなくて、ただ単に場所が変わっただけみたいな感じですかね。

5月2日くらいまでは、実家周辺にいるので、時間がある人は声かけてください。飲みにいきましょう。