育児と筋トレに学ぶ

４０歳過ぎて、急に体力の衰えを感じ初め筋トレをはじめました。 ついにメタボ認定もされちゃったしね。(´・ω・｀)

どうせやるなら、ちょっとマッチョになりたいですよね。 人生でマッチョになった時期なんて無いですんけど。

マッチョになった暁には、ワシのシックスパッドを披露したいと思います。(´・ω・｀)（いらん）

さて、自分のやっている筋トレがマッチョに効果的かどうか、どのように確認すればよいでしょう。 私の中で一つの指標として、「翌日、鍛えた箇所が筋肉痛になっているかどうか」かなと思っております。

筋力を超える負荷をかけることで筋繊維がダメージを受けて筋肉痛となり、再生の際に前回より太くなる。 さらに、筋肉痛が回復したあたりで高負荷をかけると、再生活動中の効果もあり、さらに効率よく再生していける、、、。

と聞いた気がする・・・。（弱

なので、「筋肉痛にならなかった＝負荷が足りなかった」と反省するわけです。

でも、なかなか筋肉痛になるほどの負荷ってムズいですよね。 とはいえジムに通う程の月謝は捻出出来ないしなぁ・・・。

育児の楽しみ

話は変わりますが、うちには５歳の子供がおります。

育児というのは、なかなか大変なもので本当に時間を取られます。

どのくらい時間を取られるかというと、「自分も親の時間を相当に奪っていたのだろうなぁ。ふぅむ。たまには実家に電話でもするかな」などと深夜一人で思い巡らしたりしてしまうほど、時間を取られるのであります。

そんな息子との生活で、予想以上に興味深いのが「子供の成長が見られる」ということです。

言葉で書くとありきたりですが、すごいんです。

子供が、どのように運動能力を身に着けていくのか。 どのように言語をマスターしていくのか。 どのように思考が発展していくのか。

走れるようになった！ ボールを蹴り返せるようになった！ ルールのある遊びが出来るようになった！ 悔しい・恥ずかしいとか言うようになった！ 時間や距離の概念をマスターしている！ 論理的に考えるようになっている！ 嘘をつくようになった！ 相手が喜ぶか考えて言い訳を言うようになった！

などなど、教えたものからそうでないものまで、本当にいろんなことを習得します。

そして、振り返ると「なんか繰り返しやってたのは、これを練習していたのか？！」と気がつくわけです。

子供って、めっちゃ練習してる。 本を読む、字を書く、時計を見る、数字を数える・・・。

とにかく練習してる。 繰り返しやってる。 公文行って、ひたすら短文を書いたり読んだり頑張ってる。

新しいことを覚えるんだから、脳に相当負荷かかってるんでしょうな〜。 日々、脳の筋トレバリに筋肉痛になってんのかな。

人生の先輩として、多少マッチョになれるよういい感じのトレーナーになってやらんとな〜

学び方を学ぶ

さて、夜な夜な家族に見つからないように筋トレしながら、そんな子供の姿を思い返したりしていると、「新しいことの身につけ方」をふと教えられた気になるわけです。

• 適切な負荷をかける（筋肉痛ポイントを見極める）
• 身につくまで繰り返しやる
• 継続させる

もう今更なことばかりですが、インターネッツが進歩して、膨大な情報にアクセス出来るようになっても、人が何かを学ぶのは「面倒臭がらずに、基本に忠実」が大事ってことかもしれませんな〜。

だってもう子供は、日本語で冗談言えるようになってるもんねぇ。

わし、英語で片言もしゃべれないわ(；´Д｀)　なんか負けた感が・・・

こ、今年こそ英語が話せるマッチョを目指すぞ！ あと関数型言語と、機械学習と、統計と、ろじかるしんんｋｇｔ，、、、

Soomloom アブホイール エクササイズウィル スリムトレーナー 超静音ペアリングデザイン 腹筋ローラー エクササイズローラー 膝を保護するマット付き

４０過ぎてもエンジニアを続けるには

４０を過ぎてもなお、エンジニアを続けるには何が必要だろうか。

派遣でレガシーシステムの機能拡張や保守の仕事ではなく（※）、自分でシステム構成を考えたり、新しい技術の検証に時間をもらえたり出来る、そんな自由度を持ったエンジニアで居るには。 ※これも大事です。仕事の内容の話ではなく選択の自由との対比という意味です。

技術力だけでは不十分だ。 もし技術力だけで、その評価を勝ち得るには、専門分野で５本の指に入るくらいのレベルが必要だろう。 オープンソースプロダクトの中心的コミッタだったり、まつもとゆきひろさんのように言語を作ってしまうような。 業界の人なら、聞けば知ってるくらいのネームバリューが欲しい。

もちろん、価値は評価する側によっても大きく変わる。 「上記ほどの技術力は我が社にはオーバースペックだ」と感じる会社からは、期待する評価・自由は得られないだろう。

そうではなく技術力を評価しようと思っている会社においても、やはり４０を過ぎてくると生半可な技術力程度では管理者（マネージャ）への道を進められる。 右肩上がりになる給与（人件費）に対して、中途半端な技術力では稼ぎにならないからだ。 残念ながら、技術者の単価よりも管理者の単価のほうが高い。 そして仕事において、中途半端な技術力の差は単価に反映されづらいのだ。 その微妙な差が、お客さんの求めるものの成否を分けるなら話は別だけれども。

では４０を過ぎてもなお、エンジニアを続けるための方法はなんだろうか。

個人的には、月並みだけれども「技術のアウトプット力」だろうと感じる。

ブログ、勉強会のLT、執筆、さまざまな方法があるが、こうした不特定多数向けにコンスタントに自分の技術をアウトプット出来る力こそが、エンジニアを続けられる唯一の方法ではないだろうか。

社内において、定期的な技術発信で社内の技術力アップに貢献する。 周囲のエンジニアの勉強意欲に良い刺激を与えられている。 社外への発信において、見込み顧客からの問い合わせが入る。 採用募集を出さなくても、優秀なエンジニアが応募してくる。 会社の知名度アップに貢献する。

様々な波及効果により、非エンジニアの人たちにも技術的な凄さを理解してもらうことができる。

「あの人の持っている専門知識は、同業の人達があのように評価するのだから凄いのだな。」と。

そして 「こんな価値あるエンジニアを管理者にしてしまうなんて、もったいない。」 そう周囲に思わせることが出来るのだ。

※管理者という仕事を低く見ているわけではありません。あれは、エンジニアの先のステップではなく全く別スキルが求められる別ジョブだということです。

「あの人には技術のことをして、アウトプットしてもらうのが良いよ」と思ってもらえるのだ。

---

そんなことを脳内がグルグル回りながら、なぜもっと若い頃からブログを書き、勉強会でLTの一つもしてこなかったのだろうと後悔しているのでありました。 ４０代からでも、まぁ頑張りますけども。 もはや管理職と二足のわらじ状態からのスタートなんだよなぁ。(´・ω・｀)まぢかよ 育児もあるし、時間ないわー

ほんと。若い皆さん。 積極的にブログを書いて、社内勉強会も企画して、覚えたことをアウトプットする練習しといたほうが良いですよ。 そして、そんな活動を評価してくれる会社に出会っておいたほうが良いですよ。

あと英語な。

情熱プログラマー ソフトウェア開発者の幸せな生き方

やる気クエスト

Kindle Unlimited で面白いマンガを見つけてしまいました。

その名も「やる気クエスト」

やる気クエスト（１） (純コミックス)

※unlimited のリンクじゃないです。すみません。

タイトルでも分かるように、いかにも昨今ありがちな「マンガで分かる系」のビジネススキルを紹介する本です。

しかし！ この本は、ただの「マンガで分かる系」ではありません。 本当に説明がマンガだけなのです！

「マンガで分かる系」の本は、確かにストーリー仕立てで学ぶ内容を解説してくれるのですが、大抵マンガの後に必ず文章の解説が出てきます。 入り口をマンガにして敷居を下げているものの、結局活字で理解かい！というハイブリッドさに、どことなく微妙な感じがしてしまうのです。 だって「マンガで分かる」って書いてるのに・・・。

まぁ、ハイブリッドでもマンガ部分で登場人物たちに感情移入して、ストーリーに入り込めれば頭に残るのでありがたいんですけど。 落差がね〜(´・ω・｀)

その点、この本は違います。 マンガのみで解説しています！

しかも、その展開や登場人物の行動に違和感が殆ど無い！ 「あー、わかる。このやる気のなくなり方分かるわ〜。」と思ってしまうのです。 それでいて、解説内容が薄いかというとそんなことはありません。

確かに活字量に制限があるのですが、そのおかげで逆に「ヤル気コントロール」に必要な要素にコンパクトに纏まっており、要点が記憶に留まりやすくなっている気がします。 イラストこそ上手とは言いづらいものの、とはいえ見づらくなく（初期のパプワくんを思い出したりして・・・）、ストーリーにも引き込まれつつ読み進められるので読み終わった後に、かなり頭に残っています。

とても覚えやすい情報量になっているのです。

いや、これすごいな〜。 自分もこのくらいに要点を整理したドキュメントが書けるようになりたい。

本の内容に関しては、ストーリー内で謎解き的に解説される形式のため あまり書くとネタバレで読む時の楽しみが薄れてしまうのですが、、、 以下の内容は非常に印象的でした。

・ヤル気の量は有限 ・常にヤル気を出してたら人間は死んでしまう。だからヤル気を使いすぎないようにセーブしている ・ヤル気をセーブするタイミング、出るタイミングをマスターすることでヤル気を無駄なく必要なときに使えるようになる。

さて、そのヤル気をコントロールする術とは？！

まだ完結してないマンガなのですが、続きが気になるわ〜

※unlimited のリンクじゃないです。すみません。

やる気クエスト（１） (純コミックス)

やる気クエスト（３） (純コミックス)

やる気クエスト（４） (純コミックス)

やる気クエスト（２） (純コミックス)

ちなみにパプワくんはこちらです。(ヽ´ω`)

南国少年パプワくん 全7巻完結 (新装版) [マーケットプレイス コミックセット]

大規模プロジェクトの失敗と変化の許容

大規模案件の炎上話は胸が痛みますね・・・ 自分も若いころ「連日終電、月に休みが１〜２日」を数ヶ月という経験をしましたが・・・ここに書いてあることが本当だとすると、想像を絶します。

blog.livedoor.jp

いやー・・・これは・・・

下請けの方々におかれましては、まだ未来もあることと思いますので脱出も視野にいれて良く考えて頂ければと思う次第です。 後ろ指さされたっていいじゃないですか。 心を病んでまでするべき仕事ではありませんからね。 経営者の方は大変でしょうけど・・・。

弊社では、さすがにこんな酷い状況はめったにありません。 普通に休めてますし、帰宅して夕飯食べて子供がネタ後に妻と海外ドラマを観る余裕だってあります。 今夜は、「２４　リブ・アナザー・デイ」の最終話みちゃいました。 いやー・・・しかし、あれは・・・

観終わってグッタリしたわー。 だってジャックが、ろ、、おっと。

そんなわけで、責任感とガッツあふれるのに不幸な事故に巻き込まれてしまったIT戦士の皆様。 大企業の失敗を押し付けられて溢れる才能や家族との時間を無駄にしているなんて、もったいないですよ！ 弊社では絶賛エンジニアの方を募集しております！普通のライフワークバランスを取り戻しましょう！ （謎の宣伝）

それにしても、なぜいい大人が大勢集まるプロジェクトが大失敗してしまうのでしょうか。

企業間の利権のせいでしょうか。 いまだにウォーターフォールだからでしょうか。 多重構造のせいで、１次請けはボンクラなのでしょうか。

いずれも要因としてあるかもしれませんが、最も致命的なのは「ソフトウェア開発は問題の細分化が難しいから」ではないかと思います。

大きな問題に直面した場合、解決のセオリーは「細分化」です。

一般的に、問題が大きくどこから着手していいかわからない場合、行動プランを立てられる程に問題を分割し、優先順位を決めて着手します。 これはソフトウェア開発に限りません。

２００人でなわとび１００回飛んでください！と言われて、大縄跳びで２００人同時に１００回飛べるでしょうか？ 誰かが縄に掛かっただけで失敗。 回す力が不十分で縄が弛んだら失敗。

こんな仕事、とても不可能でしょう。

でも５人ずつ個別に１００回飛ぶのを４０組やればOKならどうでしょう。 これなら達成できそうな気がしますね。

しかし、ソフトウェア開発ではこの分割をされることは、ほぼ無いです。

設計・開発は、機能単位に分割して実施しますが、最後に一つにまとめてゴールしようとするのですから一塊に扱っているのと同じです。

「上場企業の基幹システムのリプレース案件」と聞いて何を思うでしょうか。 この業界が長いほど、デスマーチの未来が脳裏をよぎると思います。

でも、こんなスケジュールだとしたらどうでしょう。 最初は「顧客管理」だけ作ってリリース。 その後、「受注」を作って結合してリリース。 一段落したら「在庫管理」を作って結合してリリース。 その後も、「発注」「請求」「経理」と、段階的にリリース。

一気に刷新となると大炎上を覚悟するところですが、上記のように機能単位で開発・リリース出来るなら、なんだか行けそうな気がするぅ〜。（古い）

しかし実際に、上記のように対応することはありません。

なぜなら、後半の開発で設計が変更になった場合、前半につくったアプリまで修正する必要が出てしまうからです。 特に「データ設計」は、後からの変更が非常に面倒くさい。

後で変更が発生したら、ドキュメントも大幅修正。プログラムも大幅修正。 データベースに至っては、テーブル構造から変わるかもしれない。 既存データへパッチを当てないとダメかもしれない。

などなど。 想像すればするほど、うんざりしてしまいます。

「だったら最初から全部考慮しとこうよ。」ということで、全部まとめて整合をとろうとしちゃう。 そして失敗してしまう。

悲惨な歴史の繰り返しなのであります。

しかし。

逆に考えると「単機能開発、後から結合」が実現出来るのであれば、もはや大規模プロジェクトなど恐れる必要はなくなります。 簡単に言えば、個別に作った後くっつけるときにくっつけ方を考えれば良いのですから。

「あー、受注と請求をくっつけるには、請求側に受注データのキー持たせないとですね〜。」 「なるほど、じゃぁ受注データのキー渡せるようにしますね。」 「OK。くっつけられるように次のリリースでカラム追加しておきまーす。」

なんて、気軽に会話出来ればいいわけです！

昨今流行りのアジャイルやスクラムも、人にフォーカスしつつ、その根底を支えているのはCIツールや、テスト自動化があってのことと思います。 つまり製品の品質担保を自動化し、大きな変更が発生することを許容することで、ソフトウェアにおける問題の細分化と向きあおうとしているのです。

ここです。ここ。

「変化を許容すること。」

特にデータ構造の変化の許容と品質の担保。 その手法の体系化とツールによる自動化。

これらが可能になれば、ウォーターフォールでも全く問題ありません。 日本のIT再生の鍵はここにありや！（大げさ）

変化を許容せよ！

ん？どこかで聞いたような・・・ ２００１年頃流行った、エクストリーム・プログラミングかな？

ケント・ベックは、もうずっと先に行ってたんやな・・・。

いずれにしても、今年後半は「変化を受け入れる」活動に注力していきたいと思います！ まずはテスト自動化の確立からっ！

なお、弊社は絶賛エンジニアの方をぼｓｙ（しつこい

アジャイルサムライ−達人開発者への道−

ショートケーキにイチゴをのせるエンジニアになりたい。

今年のテーマは雑談力にしようと決めました。 もう半分終わっちゃったけどｗ

２０台、３０台は技術書ばかりで、教養を培う本には一切触れてきませんでした。 友達に紹介されて村上春樹さんの本を２冊ほど読んだけど。 こうした自己投資分野の偏りが、現在の「プログラマとは会話が広がるけど、その他のジョブの人とはサッパリ(ヽ´ω`)」の要因の一つかもしれません。

てなわけで、あわてて「池井戸潤」の文庫かったり、「孫子の兵法本」を立ち読みしたりしてる今日このごろです。

で、今読んでいるのが「仕事。」という本です。

仕事。

どこかのブログで紹介されていて、それがずっと気になっていて数週間。 ついに意を決して購入。 Amazonで古本で・・・安くなってたんだから意を決するも何も、まず買えよという感じですがｗ

おかげで、元のブログが何だったのか失念してしまいました・・・。すみません。

川村元気さんという映画プロデューサーの方が、言葉、音楽、映像等のジャンルで一流の１２名に対し「人生を楽しくするための仕事。」についてインタビューした本です。

結果を出してきた人の仕事観・人生観に少しでも触れられるというのが、こんなに刺激になるなんて。 IT業界の人じゃないのに。

読書って大事だなと、改めて思いました。

この本の中で、自分は特に「糸井重里さん」の内容がすごく心に残りました。

その昔「ほぼ日」で「僕の仕事はショートケーキにイチゴをのせること」と書かれていたそうです。 そのことに関して対談で以下のようにのべられていました。

イチゴをのせなくてもおいしいショートケーキをつくるのは大前提ですよね。でも、「イチゴがなくてもおいしい」と、特にプロ同士は結構そこで喜んじゃう。のせるイチゴがみつからないと”うれしさ”がないのに。 ... （中略） 要するに「作品です」って満足するんじゃなくて、「商品」にして満足する。

うまいなぁ。

ソフトウェア開発をしていて、「技術者の独りよがりでは駄目だ。」「ユーザー目線でないと。」とはよく言われるし分かっていたつもりですが、「ショートケーキのイチゴが無い」の表現にドキッとしました。

買いたくなるような”何か”をきちんと考えられてたかなと。

また、糸井さんは３０代でコピーを作っていた時の脳内について、次のようにも言われていました。

頭のなかに広場があって、そこの壁に言葉を書いておいて、頭の中の登場人物にチェックしてもらっている時間が長いんです。見ず知らずの人、自分と考えの違う人、よく似た人、、、

これは単に想像力が豊かであれば出来る問題ではないですよね。 やっぱり、それまでにいろんな人と会って、意見を聞いて、そこに耳を傾けて、ってやってきた積み重ねがあるからこそ、頭のなかの広場に沢山の人が居るのかなと。

と考えた時に、自分の頭のなかに居るのは、、、、９割プログラマｗｗｗ 偏ってるわ〜・・・(；´Д｀)

自分のアウトプットに対する評価を脳内で先にシュミレーション出来るって凄いですよね。 そのシュミレーション力を鍛えるには、おそらくまず、いろんな人と仕事をして実際にアウトプットを見てもらって、、、というのを繰り返さないとダメなんでしょうね。

なるほど・・・。

４０歳を過ぎ今更感もありますが改めて、いろんな立場の人達（エンジニア職以外の）との交流を頑張ってみよう。 頭のなかの広場にいろんな職種の人を集めて、僕の乗せたイチゴが美味しそうに見えるかじっくり意見を聞けるようになりたいなぁ。

そんなことを息子のブランコを押しながら考えていた夏の日でした。

雑談力への道

最近仕事で、改めて雑談力って大事だなと思います。 あぁ。雑談力。難しいわ・・・

ちなみに、この雑談力を説明すると ”話している相手が「なるほど」と言ってくれるネタをサラサラとスムーズに出す力” といったイメージです。

これまでプログラマでやってきましたので、プログラマ仲間との会話では雑談力は比較的発揮しやすい。 「ｘｘｘという技術が最近流行ってきていて、これを使うとｘｘｘが便利になりそう！」だの 「開発手法のｘｘｘは、ｘｘｘと比べてうんたらかんたら」だの 同じ興味を持つもの同士、日頃見聞きしている情報を展開するだけで雑談力が発揮できちゃう。

ところが、ひとたび管理者、経営者、営業職の方と話すとなると、もう話すことが出てこない。 雑談力０であります。

あかん。

いかんせん職種が違うと興味のポイントも違ってくる。 プログラマ同士でキャッキャ、ウフフと盛り上がった話題は全く響きません。 相手からネタを振られても、まったく広げられない。

しかしながら、ソフトウェア開発は営業チームが売ってきてくれたり、経営者が開発費用を出してくれたり、お客様が使い勝手に意見をくれたり、いろんな立場の人達が関係して、はじめてお金を頂けているようなところがあります。

プログラマではない人にも作ったものの良さを分かってもらうために、刺さるトークを！ 次に作るもののアイデアを頂くためにも、刺さるトークを！ 開発費に、もう一声足してもらうためにも、刺さるトークを！

あぁ。そんな刺さるトークを自在に操れたなら！ もうスムース人間関係なソフトウェア開発現場で快適作業ですよ。これ。

そんなこんなでの、雑談力です。 雑談力身につけたいわー。

「聞き手の興味ポイントを推察し響く話題を出す。いつでも話題が出せるように引き出しを増やしておく。」

理屈は簡単ですが、ともすると自分にとって興味のない分野だったりするのでアンテナ立てるのが、なかなか難しいですね。 でも意識すれば、いつかきっと今よりはマシになるはずｗ

そんなこんなで、雑談力向上も意識しつつブログを書いてみようと思った日の日記でした。 （中身なくてすみません）

アジャイルの勝ちパターンが知りたい

「ウォータフォールは何のメリットも無い」というエントリが熱いですね。 今夜は風が弱くて我が家も熱いわ〜

simplearchitect.hatenablog.com

自分も可能なら世界がアジャイルになってくれと思っているので、おっ！と思って読んでみました。

が、やはりモヤモヤしたままでした。 んー。

アジャイル系の記事って、「世界はみんなアジャイルってる」「ウォータフォールは正確な見積もり前提だから無理ゲー」「日本は遅れてる」みたいな内容が多いんだけど、具体的にアジャイルが日本で浸透しない理由と解決策を解説した記事が少ないですよね。 なんでだろう。 （すみません、知らないだけかも。いい記事があったら教えて下さい）

アジャイルを導入したい、という話を社内ですると上層部からは以下のような質問が出る。

• ドキュメント書かなくて本当に大丈夫なの？
• 大規模プロジェクトの場合、見積もりどうするの？
• 短いサイクルでリリースで品質大丈夫なの？

特にSIの場合、お客さんと契約する際の金額・開発期間、納品物等に影響するので、マネージャ陣は特に心配してくる。

それに対して、アジャイル系な回答は概ね以下の感じ （私の周りでの経験なので、一般論ではないかも。すみません）

• 書かないわけじゃないです。必要なものは書きます。
• 長期では見積もらないです。ただ早いサイクルでリリースしていくので、早期に触ってもらえます。
• テスト自動化します。（あるいは簡単な確認でリリースします）

ふ、不安すぎるっ

ドキュメントの「必要なもの」ってなんじゃい。主観なの？ソース読めってことなの？（読むけど）

SIがドキュメント多すぎで、そのくせメンテされなくて無駄なコストのデメリットはすごくわかる。

にしても、何を書いて何を書かないかの指針も無いとか、それでは上層部の説得が出来ないですよ。(´・ω・｀) ただドキュメントを書かないプロジェクトにしか見えなくなるやん。

アジャイル界では、まだ体系化されてないということなのかな？ 「書く、書かない」の判断基準とか、ウォータフォール時のドキュメントを「必ず書く、必要に応じて書く、時々書く、書かない」に分類して示してみるとか、何か必要なんじゃないのかな。

見積もりにしても、「結局開発は早くなりますから」とか言われるんだけど、いつ開発終了するか事前には分からないらしい。 事前に見積もるのは無理ゲーなのはわかるけど、お客様に何て説明して仕事を頂けばよいのか。

まずはやってみてください。とか言われても、失敗する気しか起きない。 上司やお客様に、どうやって進めていって、いつ終わるのか説明できる気がしない。

そもそもSIに当てはめるのがダメということなら、そういう話でも良い。 ただ、実践前に感じるおっさんどもの不安を解消できる説明が欲しいだけなんです。

アジャイルの勝利の方程式が知りたいというか。

ウォータフォールって、なんだかんだで中規模クラスなら成功体験を持ってる人って普通にいるんですよね。 で、それらが体系化されて日本の書店には、新人SE向け書籍としてまだまだ沢山売られている。

そんな人達にアジャイル良いですよって言うんだから、勝ちパターンを想像できる程度の説得力は欲しい・・・。 お願いします。世のアジャイル先輩たち。

アジャイルの成功パターンをどんどん発信してください。 ウォータフォール時代にこうやってた箇所は、いまはこうやって進めてる。お客さんに話してる。とか、対比して教えてほしいです。

あぁ。 我が社も早くアジャイルの波に乗りたいわー。

せめて自分だけでも（セコい）

アジャイルサムライ−達人開発者への道−