何かを書く場所

迷走中・・・

あるいはこんな考え方

なかなか日本では普及していないと噂のアジャイル(スクラム)について、いつもと違った視点で考えてみた。
というか思いつき。

ウォーターフォール(WF)の場合

「マネージャー」が管理を一手に引き受け、各「メンバ」は開発作業に集中することが出来る。
このように、役割を明確化することで各自の作業効率をあげている。

「マネージャー」が各「メンバ」とコミュニケーションをとり、確認・集約していくことで課題に対処していく。
「マネージャー」がいかに課題を吸い上げ、解決できるかがポイントになりうる。

「メンバ」は各自の作業に集中するため、組み換えが難しい。
また、各「メンバ」の作業にまたがる課題をなくすため、各「メンバ」に作業を分割していく過程(設計等)に力を割く。

情報も一手に集約されるので管理はしやすいが、それがボトルネックにもなりうる。

アジャイルな場合

マネジメントは「チーム」が行う。
各「メンバ」が幅広く視野を持つことで、より柔軟に動くことが出来る。

それを可能にするため、「メンバ」間のコミュニケーションの活性化や見える化を大事にする。
見えるようにすることで、各「メンバ」気づけるチャンスを広げ、早期に問題を潰しにかかれる。

「メンバ」間の共有が(意識の上でも)されやすいので、組み換えは容易。
また、各「メンバ」の作業にまたがる課題も、途中で発見しやすい。

ボトルネックがない分情報が分散する可能性があるため、いかに共有していくかがポイント。

まとめ

うまくいけば、開発スピードはWFのほうがあるんじゃないか、という気もする。うまくいけばね。
ただ、↑でいう『分割していく過程』がどうしても重いので、細かい案件でも力を割かなければならず、ただただ面倒。

その点アジャイルは、随時課題を見つけながら進んでいく形になるので、細かい案件ならばそのままスルッと進められる。
まー結果漏れてましたーってのはあると思うけど、それは結局WFの場合でもありそうだし。

あと思ったのは、WFの場合はどうしても「任せっきり」になるため、「マネージャー」から与えれられた範囲以上の成長が難しい。 アジャイルだと範囲が広野で成長のチャンスは多いが、割りと各自の意識に左右される気がする。ってところか。

…あまりまとめになってないな。

おまけ

メンバが優秀なら、WFでもマネージャーが雑用係になりつつも成功するし、
メンバがダメだと、アジャイルでも誰も課題を挙げにいかないくて崩壊する。もしくは結局「マネージャー」的な人格が暗黙的に作られる。

逆に メンバがダメだと、WFではマネージャーが疲弊し、それでも超優秀ならなんとかなるかもしれない。 メンバが優秀なら、アジャイルは超楽しい。

やっぱり楽しい方がいいよね。

electronというかFluxやってみた

electron、簡単にデスクトップアプリ作れるなんてすごいですよね。
「このツールいいんだけど、ちょっとこの辺がなー」って時も、自分で作っちゃえばいいんですもの。

ということで、簡単なところでTODOリストっぽいものを作ってみました。 https://github.com/hot7water/electron-todo

ついでに流行りのReactというかfluxまでやってみようと(今更ですが)挑戦してみました。

ちなみに私、nodeはちょっと触ったくらいですし、職場ではまだJQueryっていうレベルです。

electronはとにかく簡単

単純にインストール→動かすだけなら、とっても簡単。
ツールバーに何出すとか色々設定も出来るけど、気にしないのなら問題なし。jsで頑張れば良い。

ファイルの読み書きなんかも、普通にjs上でnodeのfunctionが使えるので、とっても簡単。

Ractが思ったよりとっつきやすい

難しそうだなーと思っていたけど、意外とすんなりいった。
結局のところ、HTMLを分割してそれぞれクラスにしているだけな感じ。

そしてその単位でコンポーネントクラスがあるってのが分かりやすい。

今までだとHTMLと処理はどうしても分かれていたので、
「あれ、この処理どこでやってんだっけ？」とか「こっちでもonClickの処理やってんのかよー」的なことがあった。
HTMLと処理がコンポーネントに閉じてるため、そういうことは無くなりそう。

…まぁ他のFWもそんな思想はあった気がするけど、Reactの方が強制力が高い感じ？

パフォーマンスとかは、大したもの作ってないからわかりません。

fluxを使いこなすのは難しいかも

とりま一通りは実装できたと思っている。
それぞれ役割がはっきりしているので、それぞれパーツ作りも明確で良い感じ。

けど、まだところどころ間違ってると思うし、登場人物と「データの流れが1方向だよ」だけでは済まない実践的なところが多い。
この辺はまだ別途気になったところは書いてこうかな。

っていうのもあって、チームで導入するならちゃんとルールとか整備しておかないと、
アンチパターンを踏みまくって、「なんだ、使いづらいじゃん」になりそうな気がする。

Elixirをインストールしてみる

最近気になっている言語、Elixir。
とりあえず触ってみよう！ということでインストールしてみました。

yumとかでもいけるっぽいけど、ソースから。基本的には公式に書いてある通りに。

Erlangのインストール

まずErlangのインストールから。elixirはこれさえあれば動くらしい。
elixir公式にも書いてあったけど、Riakのサイトを参考にした。バージョンは最新版に。
https://docs.basho.com/riak/1.3.0/tutorials/installation/Installing-Erlang/#Installing-on-GNU-Linux

sudo yum install gcc glibc-devel make ncurses-devel openssl-devel autoconf
wget http://www.erlang.org/download/otp_src_18.0.tar.gz
tar zxvf otp_src_18.0.tar.gz
cd otp_src_18.0
./configure && make && sudo make install

最後にリンクとか貼りまくってしれっと終了。scuccessとかcompleteとか出ないからちょっと不安。

Elixirのインストール

いよいよ本丸。

git clone https://github.com/elixir-lang/elixir.git
cd elixir
make clean test

最後にテストが動いてるっぽい。無事全部パスして、終了！

あとはパスの設定だけ入れれば完了。

echo 'export PATH="$PATH:/usr/src/elixir/bin"' >> ~/.bash_profile

そして

iex
Interactive Elixir (1.1.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

起動した！

アジャイルとスクラム

スクラムって、頑張って実践しようとするとむしろアジャイルじゃなくなるよね、という矛盾について。

スクラムとは

スクラムとは、アジャイルの開発手法の一つ。
役割や開発の工程、会議体などが決まっている。

といってもそこまで厳密に決まっているわけではなく、ある程度の「枠組み」だけが決められている。
細かい所は各チームで実践を通じて、それぞれに合わせて変化させていくことが求められる。

・・・といった理解。

アジャイルについても少し

アジャイルマニフェストにこんなものがある。

  • プロセスやツールよりも個人と対話を
  • 計画に従うことよりも変化への対応を

アジャイルにおいて大事な考えとして、決まりごとや慣習にこだわりすぎてはいけないというのがあると思う。

もちろん、意味のあることであれば続けることも必要だが、
「決まりだから」「いつもやってるから」という考えは危険である。

ちょっと違う事態に陥った時に対応できなくなるし、何よりチームとしての成長を妨げることになる。

つまり、アジャイルというのは不定形だ。
誰でも上手くいくような明瞭なプロセスは存在しないし、
あったとしてそれに満足して足を止めてしまったら、それはアジャイルではなくなっているのだろう。

スクラムはアジャイルか

スクラムはある程度のことが「決まっている」。
だが単純に「決まっている」ことに従うだけでは、アジャイルではなくなる。

ということは、スクラムを守ろうとするとアジャイルではなくなる。
だが、アジャイルであろうとすれば、スクラムの枠組みからははずれるかもしれない（これはチームによるけど）

スクラムとの付き合い方

ここまでスクラムを、どちらかというと否定的な意見を書いてきた。
だけど、スクラムは素晴らしい考えだと思う。僕自身を大きく成長させてくれた。

そう、成長させてくれた。ここにスクラムの大きな意味があると思う。

いきなりチームをアジャイルにするのは、難しい。
アジャイルは不定形で、非常に概念的だ。具体的にどうしたらよいかも分からない。

そこでスクラムなんだろう。
ある程度は決まっているから、まずは実践してみる、ということが可能だ。

そして実践を通じて、アジャイルになっていく。
最終的にはスクラムの枠組みからははずれるかもしれない。でも、それでもいいんだと思う。

まとめ(感想)

スクラムは、それ自体を実施することが重要なのではなく
スクラムを通じてアジャイルになる(もしくはアジャイルを保つ)ということが大事。 プロセスやツールよりもコミュニケーションを！

rbenvをansibleつかってインストール

ansibleの勉強も兼ねて。

環境

今回はvagrantのprovisoningは使わずに、サーバを2台用意。 共にvagrant上に立てたcentos6.2

  • nodeA : ansibleを実行するサーバ
  • nodeB : rbenvをインストールするサーバ

VagrantFileは、それぞれIPのとssh用のポートを設定。

まずansibleが使える環境づくり

ここはvagrantのprovisioningで。
鍵は事前に作っておきます。
鍵の置き場所は適当に変えてください。

※Ansible チュートリアル | Ansible Tutorial in Japaneseを参考に、vagrantの鍵を流用しようとしたのですが、何故かうまく鍵が使えず…

<nodeAのprovisioningスクリプト>

sudo yum update
sudo yum install -y ansible
sudo yum groupinstall -y "Development Tools"
sudo yum install openssl-devel
chmod 400 /vagrant/keys/id_rsa

nodeB側でも、鍵の登録をしておきます。

cat /vagrant/keys/id_rsa.pub >> ~/.authorized_keys

以上設定終わり。

まず疎通の確認から

これで、nodeAからつながるはず。
まず疎通の確認を、なのですがansibleでは接続先はファイルに書いておかないといけないので ファイルを作成します。

echo "{nodeBのIP} ansible_ssh_private_key_file=/vagrant/keys/id_rsa" >> hosts

これで、疎通確認ができるはず。

ansible -i hosts {nodeBのIP} -m ping

successってでれば、疎通成功！

rbenvのインストール

ようやく本題。

playbookはこんな感じ。 書き方が拙いのはご勘弁。

    - yum:
        name: git
        state: latest
      sudo: yes
    - yum:
        name: "@Development Tools"
        state: present
      sudo: yes
    - yum:
        name: "openssl-devel"
        state: present
      sudo: yes
    - git:
        repo: git://github.com/sstephenson/rbenv.git
        dest: "{{ rbenv_dir }}"
        accept_hostkey: yes
    - git:
        repo: git://github.com/sstephenson/ruby-build.git
        dest: "{{ rbenv_dir }}/plugins/ruby-build"
        accept_hostkey: yes
    - lineinfile:
        dest: ~/.bash_profile
        regexp: 'PATH=.*{{ rbenv_dir }}/bin'
        line: 'export PATH="{{ rbenv_dir }}/bin/:$PATH"'
    - lineinfile:
        dest: ~/.bash_profile
        regexp: 'rbenv init'
        line: 'eval "$(rbenv init -)"'

rubyのインストール

node2でrbenvコマンドが叩けるようになったので、あとはrubyをインストールするだけ

rbenv install --list
rbenv install 2.2.2
rbenv global 2.2.2
rbenv rehash

問題が１つ。

rubyの部分をansibleにするかどうか。
…冪等性とか考えると、playbook書くの面倒だし
…バージョン変更とか考えると、ファイル自体は別にするべきだろうし。

うーん、やめておくか。