「道は開ける」読んだ

「不安と闘う術を知らないビジネスマンは若くして死ぬことになる。」アレクシス・カレル

 

不安といかに立ち向かうか。簡単に書くと以下の内容である。

- 最悪の事態を想定する
  - ほとんどの場合それよりマシだろう
- 紙に書きだしてみる
  - 後で読み返したら大した悩みでは無くなっている
- 宗教の力を信じる
  - (現代日本で暮らしているとちょっと……)
- 不安をプラスに転じることは出来ないか考える
  - 短所を長所に変える
- ひたすら働く
  - 忙しくしてたら不安なんて忘れる
  - (これはどうかと思う)
- 無駄なことに悩まない
  - 悩んでもどうしようもないことは多い

文章にするとなんてことないが、膨大な実体験とともに述べられると圧倒的な説得力をもつ。

SEのやりがいの話

先日会社で仕事のやりがいについて話す機会があった。

「大変だったプロジェクトをやり遂げた後の達成感」
「休日の素晴らしさを感じられる」

多くの先輩からこんな意見が出たが、冗談でなければストックホルム症候群の一種じゃなかろうか。

もちろんそのときの快感はあるだろうが、そのために苦労するのは間違っているように思える。

私としては、計画したとおりにプロジェクトが進み(リスクが顕在化しても事前に検討した対策を発動できて)、スムーズに完了できた時の方がはるかに気持ちいいと感じる。

そんなうまいこといかねぇよ、という声もきこえてきそうだが、少なくともそこを目指す必要があるはずだ。

苦労したり失敗した方が成長につながる、という意見もあったが、それはほとんど関係ない問題だろう。
苦労しなくても学ぶことはできるし、逆に日々対応に追われるような状況の場合は、とにかく目の前のことを処理することに終始してしまって成長どころじゃない。

以上、全て主観だが、モヤモヤしたので書き残しておく。

「ソフトウェア見積り - 人月の暗黙知を解き明かす」

社内勉強会で発表しました。

Reveal.js で作った資料を GitHub Pages で公開。

http://takerutakahashi.github.io/SoftwareEstimation/

実践ポモドーロテクニック

最近ポモドーロテクニックを実践しています。

ポモドーロテクニックとは

  1. タスクを決める
  2. 25分間、タスクに集中する
  3. 5分間休憩する
  4. 1.~3を4回繰り返したら15分~30分休憩する

効用

  1. モチベーション維持できるよ!
  2. 集中力向上するよ!
  3. 時間間隔身につくよ!

興味を持つに至った私の状況

  1. 集中力切れると惰性で作業しちゃう
  2. メール受信したら見ちゃう→もとの作業なにやってたっけ……が発生
  3. コーディング中にトライ・アンド・エラーを繰り返しちゃう

「トライ・アンド・エラーはクソ、一発でコンパイル通せ」by Code Complete 第2版 下巻 (誇張しています)

実践した感想

  1. モチベーション維持できる
    「面倒だけどとりあえず25分やろう」
  2. 集中力向上?
    まだ実感なし。
  3.  タスクの見直し大事
    「集中して作業してたけど、実は重要なタスクじゃなかった」を避けられる。
    この状態って、ヘタに達成感を得ちゃうから余計にタチが悪い。
  4. 25分がちょうどいい
    ただし1時間くらい没頭するときもある。適した長さは人によって違うんでしょう。
  5. どうやって休憩するか迷う
    スマホいじったりWebニュース見たりしても別に休まらない。
  6. タスクカンバンとの相性いい
    タスクを選ぶリードタイム短縮。
  7. 俺仕事遅いわ
    自分がどんなペースで仕事してるのか定量的に測れる。感覚より25分の繰り返しが多いとへこむ。

これから

  1. 続けます
  2. タスク優先度決めるところも何か一工夫したい

結論

  1. オススメです。

「エンジニアのための【業務知識】がわかる本」読んだ

結構なボリュームだが、呼んでみると拍子抜けするほど浅い(悪い意味ではない)。各分野のプロフェッショナルになるには相当の知識が要るのだろうと思い知らされる。

あと会計は本気で勉強しなきゃいかんなと思った。

 

業務アプリケーションとは何か(何をシステム化するのか)が感覚として身につく。研修が終わった新人あたりが読むのが一番ちょうどいいと思う。

帯の「顧客の視点で提案できるエンジニアになる!」は明らかにおおげさだ。

来週から基幹システムの開発に携わるから読もう、とかの目的で読むには遅すぎる。

オブジェクト指向とコミュニケーション

ソフトウェア開発の原則、高凝集、低結合。

機能を疎結合、責務を分割、データ・振る舞いの隠蔽……

多くのエンジニアは、業務だけでなく日常的にこれらのオブジェクト指向的な考えを磨いているだろう。

 

しかし、チーム開発はこの逆があるべき姿なんじゃないだろうか?

知識を冗長化、責任を分散、作業内容を公開。

まあ完全に逆とはならなくても、違う考え方をするべきだという意識が必要だろう。

人間を(無意識に)オブジェクトとしてとらえてしまうと多分チーム開発はうまくいかない。

チーム開発のコミュニケーションは難しいとよく言われる。その難しさはこんなところにもある気がする。

 

 

読んでます(まだ序章)。

「なぜ人と組織は変われないのか」を読んだ

タイトルはどう見てもありがちな自己啓発本だが、充実した内容だった。

本書に寄れば、その答えは「自らを守る免疫が作用しているから」となろう。

人と組織は、自らの何かを変えようと願うがうまくいかない。このとき、以下のようなメカニズムが生じてている。本書では「免疫マップ」と呼んでいる。

1. 改善目標を立てる。
2. 1.を阻害する行動をとる。
3. (多くの場合無意識化に)2.を引き起こす目標をもっている。
4. 3.を正義とする強固な固定観念がある。

例を挙げる。登場するのは会社のマネージャー。改善目標は、「業務の忙しさを緩和するため、部下に作業を移譲する」だ。

1. 部下に作業を移譲したい。
2. 生じた作業を自分で実行してしまう。
3. 卓越した、唯一無二の存在だと思われたい。指示だけ出して手を動かさない人間になりたくない。
4. 多くの作業は、部下よりも自分でやった方が速い。自分で手を動かさない人間は価値がない。

なるほど、筋が通っている。
では、どうすればいいのか?

本書では、免疫マップを発見するまでに鍵があると述べている。

人と組織が変わるには、心理と行動が同時に(互いに作用しあって)変わる必要がある。多くのダイエットが上手くいかないのは、ダイエット法のみ取り入れられ、心理が本当に変わっていないからだ。あるいは「ダイエットしたい」という想いを抱えたまま何も行動しないということもあるだろう。

免疫マップを分析した上で(このプロセスは事例を挙げて詳細に述べられている)、「強固な固定観念」の正しさを検証し、トライ・アンド・エラーを繰り返すことによって初めて人と組織は変わっていくことができる(そしてそれは年月を要する、ということも強調されている)。

 

私の最近の免疫マップは以下のようなものだ(中島義道の「怒る技術」などにも影響を受けている)。

1. 他人とのコミュニケーションで不快感が生じたら、早い段階でその原因を相手に伝えたい。
2. 他人の言動にあまり関与しない。
3. 不快感を持ちたくない。相手に反発することで厄介事を起こしたくない。
4. 他人とのコミュニケーションは、自らを抑えてでも穏便に済ませるべきだ。

これは徐々に改善?されてきている。とはいえ、この免疫マップも向き合い続けることで形を変えていくだろう。