もっぺんプログラミング(´・ω・`)

もっぺん頑張って副業プログラマを目指してます。

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

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

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

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

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

仕事。

仕事。

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

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

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

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

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

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

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

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

うまいなぁ。

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

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

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

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

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

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

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

なるほど・・・。

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

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

雑談力への道

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

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

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

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

あかん。

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

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

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

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

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

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

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

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

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

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

simplearchitect.hatenablog.com

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

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

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

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

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

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

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

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

ふ、不安すぎるっ

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

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

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

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

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

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

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

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

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

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

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

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

せめて自分だけでも(セコい)

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

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

おっさんプログラマ、ニワトリを目指す

昨今、A.I.ブーム、機械学習ブームですね。

新たな付加価値として注目されているIT業界の会社さんも多いのではないでしょうか。 アイデア次第で自社サービス、自社製品、自社ソリューションに取り込む余地がありそうです。

しかし手軽になってきたとはいえ、やはり使いこなすにはベースに統計分析の知識は必要になります。 GUI等で簡単にロジックを組めるといっても、何をやっているのかわかっていなければ、サンプルを応用出来ないですし、モデルのチューニングもままなりません。

これまで探索木だけの世界だったおっさんプログラマひしめく会社が、いきなり統計分析で付加価値を出せるようになるのは至難の業であります。

解決策としては「社内で人材を育てる」か、「外部から会社や人材を買ってくるのか」なわけですが どちらの場合も、会社がまず目指すところは「A.I.分野で儲かる仕組みを作る」です。

外部から買うお金がない場合、時間をかけて自社で育てていくことになります。 自社開発に期待いただけるのは、社員も新しい分野にチャレンジできてありがたいんですが いかんせん、本業と二足のわらじになりがちで大変です。 R&D費とか積んでもらえたら、楽なんですけどね〜(´ε` )

そんなこんなで、かなり気合を入れないと結果を出せないままズルズル・・・という展開もありそうです。

いずれにせよ会社組織としては、まずは小さくていいので、「儲かる仕組み」を作る。 規模が小さくても、営業が出来て、仕事が取れて、納品して、お金をもらえる。 その仕組みを作ること。

その仕組ができたら、次はその規模を大きくしていく。 仕組みを作って実行していた人たちが、それを手順化して、次の世代を招きいれ実行できるように訓練する。 次の世代が実行できるようになったら、その次の世代を招き入れ訓練する側に回ってもらう。

ビジネスの世界では、まずニワトリを作る。 儲かるニワトリが出来たら、タマゴを産んでニワトリを増やしていく。 ニワトリが増えてきたら、優秀なニワトリを養鶏農場のおっさんに進化(!!)させて、新たな養鶏場を設立してニワトリで儲けさせる。 ・・・と、ループ。

おっさんプログラマとしては、このループの中で生き残っていけるかどうか正念場であります。

おっさんが頑張るよりは、新卒採用で詳しそうな学生に来てもらう方が早そうではありますが、立ち上がってない事業との二足のわらじに付き合ってくれるような奇特な人材はなかなかいません。 普通、その分野に既にコミットしている会社に行くよね。

その辺も含めて、失敗したらゴメンね前提で「部署立ち上げから一緒にやろう!」で人を集めるのもありそうですが。 誘う側に、相当なコミット力がいるな〜

関わり方は色々ありそうですが、おっさんプログラマとしては「新たなニワトリ作成」を意識して動いてイカンとアカンなぁ。と思う次第であります。

さて、「楽しいR」でも読んでみるか・・・(遠

LightTableのClojureのバージョンを変更する

Clojureの勉強再開しました。(人生5度目) 今年こそClojure使いになりたい・・・(´・ω・`)

社内メンバーへも普及したいので、まずはエディタや開発環境の調査から。 ということで、LightTableを使い始めました。

LightTableは、エディタ上でそのままコードの評価ができるプログラマ向け素敵エディタだそうです。 エディタの使い方も日本語訳があると嬉しいですね。 少しずつ本家サイトの英語を読みながら精進します。

さて、そんなLightTableが使用するClojureのデフォルトバージョンを上げる方法です。

まず、今使っているバージョンは以下の手順で確認出来ます。

  • Light Tableを起動する
  • (Cmd/Ctrl+n) で新規ファイルを作成する
  • (Cmd/Ctrl+スペース)でコマンドペインを表示する
  • コマンドペインに、”Syntax”と入力して、”Editor: Set current editor syntax”を選択する
  • 言語選択画面に移行するので、”Clojure”と入力して、”Clojure”を選択する (これで、新規作成した未保存の空ファイルでもClojureが動作可能に)
  • clojure-version と入力して、Cmd/Cntrl+Enter を押してREPLを実行 すると実行結果にClojureのバージョンが表示されます。

私の環境では、使用しているClojureのバージョンは 1.5.1 でした。

この変更方法は、LightTableのFAQに書いてありました。

FAQ · LightTable/LightTable Wiki · GitHub

plugins/clojure/runner/resources/project.clj ファイルの :dependencies org.clojure/clojure "x.x.x" の"x.x.x"の箇所に、デフォルトで使用したいバージョンを書けばOKとのことです。

Windows版は、LightTableのzipを解凍したフォルダに上記ディレクトリがあります。 Mac版は、LightTableのzip解凍後、アプリの中にあります。 具体的には以下のパスです。

lighttable-0.8.1-mac/LightTable.app/Contents/Resources/app/plugins/Clojure/runner/resources/project.clj

Macのアプリって、フォルダのように中に入っていけるんですね。 Mac初心者で知りませんでした・・・。なるほど。

はじめてのClojure (I・O BOOKS)

はじめてのClojure (I・O BOOKS)

今年こそアウトプットの年にしたい

40歳になってエンジニアとしての方向性を問われるようになってきたわけですが・・・ 伸び悩んでるわー(´・ω・`)

年末年始にかけて、自分に足りないと感じた場面・分野などを思い出し 対策として何が必要か、いろいろ考えてみました。

情報の整理・共有方法から、予定の段取り方法 プロジェクト管理方法から、敬語の使い方 雑談力のあげ方、英語力まで 様々なレベル、分野で課題だらけでしたが 最終的に出た結論としては、「頭を良くしないとダメ」という結論でした。 (結論がアホっぽい)

まぁ、アホっぽい目標ではあるのですが 個々の課題の対策を突き詰めていくと、割りと共通的なテーマにあたるんですよね。 「いかに素早く頭のなかを整理してアウトプットするか」

論理的に顧客に何かを説明するのもそう。 チームメンバーに指示を出すのもそう。 次の10年やりたいことを整理して会社に伝えるのもそう。 会社・部署の方向性を話すミーティングで何かをネタ出しするのもそう。 勉強した結果を脳に定着させるのもそう。

インプットして、整理して、アウトプットする。

この速度と精度を上げるトレーニングをするしかない。 瞬発的に何かを返せない場面が増えると、どうもアホっぽくていけない。

このあたりの脳の基礎体力(筋力?)が、どうも足りてないんだな。多分。

40歳以降もエンジニアとして生き残っていくには、発信力が左右する気がします。 GitHubソースコードを発信し、Qiitaでナレッジを発信し 会社でもビジネスの動向、掘り下げるべき技術の方向性を発信し 来季の目標を発信し

発信し続け、「あいつに技術者でいてもらうことが重要だ」と周囲にアピールし続けないと。

アウトプット力が低すぎて、いきなりは何もできないですが アウトプットの練習しまくって、アウトプット力を上げる年にするぞっ

ようやくAnsibleの入り口にたどりつけた…

VagrantCentOSの仮想環境を作って、Ansibleでアプリデプロイが今風らしいので(出遅れ)勉強してみたんですが、Ansibleで小さなサンプル動かせるくらいの入り口に辿り着くまで、結構かかってしまった…(´・ω・`)

帰宅して子供が寝てから1,2時間ペースなのでボチボチ前進すな。

一方、今月はじめから客先常駐になってしまってAzure資格の方はさっそく頓挫しております。
だいたい、やりますって宣言すると頓挫するよね。(ダメ)
常駐案件で使うべくAnsibleの勉強を先にやっとこうかなと。

PowerShellSSH対応されたらAnsibleからAzure操作できるようになるんじゃろか。

さて、ではAnsible入り口までの足跡を備忘として書いてみます。
Mac OS X 10.10.3 Yosemite 使っていますけど、Macも初心者です。(´・ω・`)

やったこと。

1. Vagrantをインストール…の前にHome brew インストール

Macでソフトウェア管理ってよく知らなかったので、Homebrew を入れることにしました。
以下、参考にさせていただきました。Homebrew-cask でVirtualBoxとかも扱えるんですね。
Homebrewでパッケージ管理を行う方法 ‹ 技術の犬小屋

2. VirtualBoxVagrantをインストール

brew cask からインストールしました。
VirtualBoxVagrant を作っても仮想OSインストールするの面倒だなと思ってたら、ネットからイメージを取ってくるサービスがあるんですね。すごい。
Vagrantbox http://www.vagrantbox.es/

でも、こういうのってセキュリティの心配とか大丈夫なんでしょうか。
勉強で使う分には、まぁいいけど業務で使う場合には自前でOSインストールからやったほうがいいんですかね。(´・ω・`)

3. Vagramtをさわってみる

Boxから仮想イメージを取得してOSの起動と停止をやりました。
vagrant box add ...
vagrant up
vagrant ssh
vagrant halt
vagrant destroy あたりを試しました。
とりあえず、コマンドラインから起動・ログイン・停止あたりができればOKかな?

4.Ansible チュートリアルに取り組む

Ansibleを使って複数台ホストを操作するいい感じのチュートリアルを発見したので、ここからは以下のサイトをなぞることに。(そして、少しハマることに)
Ansible チュートリアル | Ansible Tutorial in Japanese

Ansible はbrew からインストールしました。

4.1 Vagrantfile を編集して2台起動できるように

上記サイトにある通りにVagrantfile を編集して node1, node2を起動可能にしました。
自分の目標はnode1にWebサーバー環境を作って、fluentdでnode2にログを送って node2側 fluentdで集計する…までやってみたいところですが。果たして。

4.2 Ansibleのssh接続にVagrant秘密鍵をコピー

node1からnode2へも ansibleでpingが打てるように秘密鍵をコピーとのことですが、ここで少しハマりました。秘密鍵がない!!(あるけど鍵が違ってて接続できない。だったかな?)
どうも vagrant 1.7 より秘密鍵ファイルの場所が変わったぽいです。

Vagrant 1.7.1導入したら若干不具合が発生したのでメモ - re:inventing the wheel

前:~/.vagrant.d/insecure_private_key
後:./.vagrant/machines/default/virtualbox/private_key

なおVagrantfile に以下を記述すれば、個別フォルダにキーが作成されない模様
config.ssh.insert_key = false

4.3 Ansibleでsshユーザーを指定する

以下を参考にさせて頂きました。
インベントリファイルに ansible_ssh_private_key_file と ansible_ssh_user を書いています。 Ansibleでsshユーザを指定する - Qiita

4.4 pingは通るがcopyでハマる

上記までで、ansibleコマンドから node1 にping が打てるようになりました。

momoizo$ ansible all -i hosts -m ping
192.168.33.11 | success >> {
    "changed": false,
    "ping": "pong"
}

が、Macからnode1にファイルコピーを試してみたらエラー(´・ω・`)

momoizo$ ansible all -i hosts -m copy -a "src=/xxx/momoizo.txt dest=~/momoizo.txt"
192.168.33.11 | FAILED >> {
    "checksum": "4c31f8b889d4b1c477941a45ec2d2ccd48775b94",
    "failed": true,
    "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"
}

どうも CentOS(node1)でSELinuxが有効になっているせいらしいです。
解決策としては、libselinux-python をインストールせよ・・・と

4.5 Ansibleでlibselinux-python をインストールする

playbookで SELinuxがインストールされている場合で、かつ無効でない場合に libselinux-python をインストールするように組んだ方を発見。すごい。

Ansible GalaxyにGitBucketのroleを登録した
http://sankakuvalidator.hatenablog.com/

というわけで参考にさせていただき、初playbook に挑戦

playbook のひな形は以下のサイトの下の方に出てくる ping モジュールを使った Yaml ファイルをベースにしました。task:部分に上記サイトのタスクをコピーっと。
Ansibleのドキュメントを読んでみたメモ - Qiita

4.6 getenforce で ”[Errno 2] No such file or directory” でハマる

上記で作った playbook を実行してみると、どうも No such file or directoryエラーが出て動かない。YAMLの書き方の問題なのか切り分けができなかったので、ansibleコマンドで単体実行してみる。

momoizo$ ansible all -i hosts -m command -a "getenforce"
192.168.33.11 | FAILED | rc=2 >>
[Errno 2] No such file or directory

やっぱりダメ。 vagrant sshでログインして getenforceしたら動くので、ansibleに何か足りないんじゃろか?と思ってたら違いました。
ansibleでsshした際のパスが足りてなくて"コマンドが見つかりません”的な状態が上記エラーで出てました。
なーんだ。

momoizo$ ansible all -i hosts -m command -a "which getenforce"
192.168.33.11 | FAILED | rc=1 >>
which: no getenforce in (/opt/python-2.7/bin:/usr/local/bin:/bin:/usr/bin)

momoizo$ ansible all -i hosts -m command -a "/usr/sbin/getenforce"
192.168.33.11 | success | rc=0 >>
Enforcing

getenforceをフルパス指定したら動いた。

というわけで、playbook の方は一旦 sudo: true を記述して動くようにしました。 無事 node1 に libselinux-python がインストールされてファイルコピーも動くようになったぽい。

でもsudoで解決もイマイチのような… sshログイン時とsshコマンド実行時のパスの違いをでなくする方法を調べなくては。

で。今ここです。

進みは遅いですが、vagrant, ansible のssh関連の設定場所が分かったし、コマンドの使い方や playbook の使い方も少しわかりました。
ようやく入り口にたどりつけた感じ…

次は node1にwebサーバー環境作って、fluentd入れてログ収集して… というのを目指したいと思います。

あと、Webで調べると誰かのまとめ記事がすぐ見つかって入門者としてはすごくありがたい反面、ソフトウェアのバージョンが古くて動作が違ってハマるということもしばしばでした。 英語力をアップして、まずは公式のGetting Start的なものから読み始めるくらいになりたいなぁと改めて思いました。 がんばらんと(´・ω・`)

↓これは買いました。自分はAmazonじゃなくてGumroad からです。

入門Ansible

入門Ansible

入門 AnsibleのPDF、EPUB版を発売開始しました — そこはかとなく書くよん。