デスマやトラブルは人を成長させるか
トラブルを乗り越えれば、精神的にタフになるのは間違いない。
あの時のあれほどでないな、と思うようになり、精神的に余裕ができる。
これがタフになったということの正体だと思う。
間違えてしまってはいけないのは、これを成長と感じることだ。
実際トラブルプロジェクトというのは遮二無二手を動かして、膨大な作業量を、納期というプレッシャーに追われながら、体力と精神力を限界まで使い切る世界だ。
成長というものは「仕事」の中にあって「作業」にはないと思っている。仕事とは「事に仕える」であり、他者に貢献する行為だと思う。仕事を通じて技術を学び、仕事の中で工夫して作業し次の仕事の糧にする、このような学びと改善を成長とよびたい。
改善には色々なものがある。自分自身の作業の効率化であったり、みなのため、将来ための標準化や、自動化もある。作業のトラブルシュートをまとめたり、作業の開始と終了の段取りを減らすための工夫もある。
膨大な作業量を、それこそ心を亡くして忙しく作業をしている時、人はただの機械に成り下がっている。未来を慮る余地などないし、誰もが自分の作業で手一杯で、そこに人と組織（チーム）に成長の余地はない。
よく、トラブルが人を成長させるという誤解は次のような場面が複合して起こる。
- （自分にとって）未知の問題の調査と解決にあたっている場合
- 効率度外視で未経験者が仕事を担当している場合
よくよく考えると、どちらも、トラブルなしで経験できるし、むしろトラブルのないところの方がより健全な成長を期待できる。
痛い目に遭わないと覚えない、とは違う。こちらは失敗の痛みを記憶に植えつけることで、事前に痛みを予防・回避する痛みに対する本能の消極性を利用したものだと思うが、自らトラブルを起こして火中に飛び込めということではない。
人間には火事場の◎◎力というものがあり、追い詰められることで力を発揮することが知られている。この力は、生命の生存本能として精神や肉体のリミッターを解放する、いわば最終手段であって、誰もがもっている隠し能力といえる。
リミッターの解放は、精神と肉体へのダメージを被る副作用があることを忘れてはいけない。本当に一生に何度も味わえないようなトラブルに対してとっておくべきものだ。*1悲しいことに、独りで敵に立ち向かい、応援もないままに、リミッターを解放して戦い続け、副作用から深刻な事態になる人間は後を立たない。
どういうわけか、複数のデスマトラブルを経験するほどにデスマを繰り返すことがある。繰り返すどころか、デスマのリスク予防を一切しない、デスマを前提とした計画まで立てるようになる向きもある。私の周りだけだろうか。むしろ好んでデスマに向かっているとしか見えず不思議でならない。戦場という非日常の高揚感とアドレナリンに酔ってしまったのだろうか、ひょっとしたら既に副作用で…。
デスマやトラブルプロジェクトが人を成長させるなどと気安く言ってはならない。麻薬が見せる幻影にどうか惑わされないでほしい。
一つ、トラブルから成長に繋げる方法がある。
- 客観的にふりかえる
当たり前のことだった。だれでも知っている。
しかし、当事者にとってはとてもとても難しい。
先に述べたようにデスマやトラブルは繰り返されて振り返る暇がないことがある。深刻な副作用を与え、精神と肉体にダメージを受け、トラウマとなって直視できないこともある。つかの間の休息期に、わざわざ嫌な思い出など思い出したくもない、というのが人情というのは、よくわかる。ただ、デスマやトラブルにある人は、あれは土方作業だった、ということにならないよう、ふりかえって作業を仕事に昇華し、次の仕事に向かってほしいと思う。
プロジェクトリーダ、マネージャー職にある人は、メンバーの成長のために、どうか振り返りの機会を与えるよう働きかけてほしい。
ありきたりの結論
トラブルが人を成長させるのではない、人が自ら省みることで成長するのだ。
- 作者: 広江礼威
- 出版社/メーカー: 小学館
- 発売日: 2002/12/12
- メディア: コミック
- 購入: 9人 クリック: 169回
- この商品を含むブログ (306件) を見る
*1:アスリートや武道家は訓練して副作用を抑えているからできているのだと思う
Mercurialを使ってみて確信した
DVCSは仕事で使える。(・∀・）イイッ！
Mercurialはいけてる。(・∀・）イイッ！
きっとGitもいけてる。(・∀・）イイッ！
Mercurialがお勧めです。
SubversionもGitもまだ使っていないならなおさら。
- 学習コストが低い*1
- すぐ使えるWindowsクライアントがある
- 小規模～パーソナルプロジェクトで取り扱いやすい
- 開発の質があがる
学習コストの実際
Windowsクライアントがあるということはとても良いことです。インストールから基本的な開発操作の流れまで、３０分程度で済ますことができます。
開発者の日々の作業、update、commit、１日で覚えられます。pull、commit、diff、revert、log、mergeを覚え慣れるまで１周間もあれば充分でした。開発者たちは必要に応じて互いにpullしmergeするようになりました。
リポジトリとブランチの管理はメンバーの1人が覚えれば充分です。初めてということで私自身が担当していましたが、開発をとりまとめる人か、開発のボトルネックが分かる開発者に任せればよいという感じでした。
ブランチ戦術は少し悩みましたが、こちらのサイトが参考になりました。
見えないチカラ: A successful Git branching model を翻訳しました
あるプロジェクトのMercurial導入の軌跡 - 放牧日記
プロジェクトのルールとして前もって決めておくことで、混乱もなく使えるようになります。逆に、前もって決められないプロジェクトはどうあがいても炎上する運命にあるということに気づきましたが、これは別の話で。
Windowsクライアント
tortoiseHgとHgワークベンチです。最初はワークベンチをどう使えばよいかわかりませんでした。ペインの多さにとまどい、最初に怯んでしまったことを告白しておきます。しかし、使い始めてすぐに理解しました、使いやすいようによく考えられている*2、と。
習うより慣れろです。書籍も出ているので記事の最後に載せておきます。
小規模プロジェクトで取り回す
大規模プロジェクトには不向きと感じました。ツールとしては当然大規模プロジェクトでも使えるのですが、組織ルールとしてSubversion（もしくは組織が長年使用しているもの）以外を選択できないケースが往々にしてあります。無理に使おうとすると、Subversion+Git/Mercurialといったハイブリッド構成の管理になります。ハイブリッド構成は構成管理の専任者をしっかり擁立しないと混乱の元になるため、組織の体制やプロジェクトの体力によっては困難です。
私は、実態としてハイブリッド構成*3で管理していましたが、混乱になるため開発者には存在を公開しないようにしていました。
逆に、小規模プロジェクトやプライベートプロジェクトには、「始めやすく」「覚えやすく」「使いやすい*4」の３拍子そろっているMercurialが、気持ち良いほどに馴染みます。
開発の質があがる
質は感覚です。品質が客観的にあがったという結果はありません*5。ただ、感覚として感じたということをここで正直に伝えたいです。
今まで、機能の単位、単体テストの単位、コミットの粒度が曖昧でした。自分の担当の開発の他に、重複する機能の開発、マージ後の不具合の調査と修正、を同時並行に扱っておりソースにはなんらか複数の意図がまぎれているのが常でした。これによって、コードレベルの流用、コードを参照しての再設計が難しい…つまり、一言でいうとスパゲティを量産していました。Subversionの履歴はきまぐれなタイムカードのようなものでした。
Mercurialを使いはじめ、日々のコミットを眺めていて気づいたのは、いま自分がスパゲティを作ったのかそうでないのか、履歴を汚したのかどうかが、目の前に見えているということでした。
(ﾟεﾟ)ｷﾆｼﾅｲ!!
(ﾟεﾟ)…
(；´д｀)気になる
本来、保守性のよいコード、綺麗な履歴というものはツールによってなされるものではなく、開発者の熟練度と心遣いによるものです。このように気づきを与え、また、改善に取り組みやすいという点を、ツールが開発者の成長を助けている＝質があがるとしました。
Git vs Mercurial で Mercurial を採用する理由
この半年Mercurialを使った感想です。
・Mercurialを覚えてからSubversionを覚えてもよい
内部の仕組みを覚えて、ブランチを綺麗に保ちながら使いこなせたらどれだけ素敵なことかと思います。今の時代、開発者はSubversionやGitを『使いこなせて当たり前』と言いたいところですが、現実はそうではありません。開発者が集まってみたら、初めて使う人、なんとなく使ってた人、ざらにいます。プログラムは数ヶ月、数年ぶりなんていう人もよくいます。私です。30歳と60ヶ月をゆうに過ぎた3流開発者もいます。私です。
このような人々（主に私）が、ある程度のコードの質を確保しつつ、忘れてしまうことも含めて、安定した開発をするには、学習コストの低さが重要な要素となってきます。
構成管理の初心者には迷わずMercurialを、ある程度の経験があるのならGitでよいでしょう。
と、私が独断と偏見でMercurial(またはGit)を導入していく意義があると勝手に確信したことでした。
- 作者: 藤原克則
- 出版社/メーカー: 秀和システム
- 発売日: 2013/02
- メディア: 単行本
- 購入: 3人 クリック: 13回
- この商品を含むブログ (6件) を見る
ミイラ取りがミイラになる
汚いコードを見て育った人は、きれいに作ろうと思わないだろう。汚いということと綺麗ということが区別つかないから。
新人をテスト、簡単な機能の開発、修正、と担当させてみるも、入り組んだソースのプログラムを見ながらこなすのに精一杯で、とてもよりよいコードを書く技術は身につかない。
今まで触れてきたコードをお手本にプログラムすることになるだけだ。
よく言われているように、よいコードをかく、よい設計ができるためには、やはり自らが手を動かして書くこと、よいコード、設計をたくさん読むことだと思う。
年々生産するコードの質が落ちていくのはこういうところにあるのだと感じている。
クラスビューとファイルビューを見てて感じた
VisualStudioを使っているプロジェクト。私の周りではファイルビューを使う人が多い。クラスビューのがわかりやすいと私は思ってるが、どういうわけで彼らがそうなったのかつらつら考えてみた。
彼らの作業の特徴は、比較的短時間(?)で次々機能を開発をしなければいけないこと。特定の関数や処理にしか用事がない、少し改造する程度で、影響範囲が狭い(かもしれない)作業が多いことだ。
そこで自分の作業に関わる処理へのアクセスのために脳内ファイルインデックスを作成する。
ファイルアクセス→ファイル内のキーワード検索
これは常套手段の一つだ。これは既知の関数を捜すのにかなり有効に機能している。
私はといえば関数をいちいち全部正確に覚えていないからクラスビューを展開してそれっぽっいクラスのそれっぽい関数名から正確な関数名を思い出して見つけている。
おそらくは長年担当してきた作業の内容が偏った狭い領域だからこそ、彼らなりに作業効率を最適にするために進化したのだろう。
彼らの失敗などの予期せぬ工数増加を恐れて小さく咀嚼したものばかり担当させてきた弊害かもしれないなと思いいたった。
いま、彼らは広範囲に影響する機能を青息吐息で目を回す思いでやっている。未知のファイルや関数を次々に相手している。
改造の相談をされた時には、なるべく「ここを」こうすれば直せる実現できると言わないようにしている。全体やオブジェクトを意識できるように、「このクラスを参考に」「これとこれの関係を調べてみて」と、やや中途半端にアドバイスをおくるように抑えている。
いきなり答えを知るような学習の仕方では学問が身につかないように、考えて理解できるようにならないといけない。
オブジェクト指向で作られているものは素直にオブジェクトで覚えたほうがよい。そのうえでファイルインデックスも作ればよいと思う。
高学歴と低学歴の溝とかうんちゃら
学歴という物差しはいくぶんとまえからあったように思うが、お店の冷蔵庫に入った関連の記事を見てるとやたら学歴というキーワードがででくるのはなぜなんだ。はてなだから？
違和感がある
・学歴は偏差値で測る。
・溝とよべるほど不連続ではない、はず。
・冷蔵庫に入ってもツイートしないような、ネットリテラシーが高い人は学歴が高いことになるのか
と、突っ込みたくなるが、他にうまいカテゴリ方法がみつからない。
一定の教育、躾、マナーの身についていない人々の言動が「可視化される世界になった」というのはなるほどそうだなと思った。
ナポリタンはうまくつくれないけど
スパゲティコードの作り方は自然に見についていた。
どうしていつも同じようにスパゲティばかり作ってしまうのか。
美味しいナポリタンを作れるようになりたい。
そして作り方を教えられるようになりたいと思う。
ただのサラリーマン、プログラムをちょっと触ったぐらいの三流のプログラマ、
が、満足につくれて、教えられるレベルに今からなる。アラフォーなのに。
