2016-01-03

windows10のマシンにvagrantを入れて、ubuntuを動かす

やりたかったことはタイトルの通り。

http://www.vagrantbox.es/ から、ubuntu 14.04のURLをコピーし、以下のコマンドを実行

$ vagrant box add ubuntubox https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-$ vagrant-disk1.box
$ vagrant init ubuntubox

vagrant upで「Waiting for machine to boot.」で止まって失敗

そのままvagrant upしたのですが、以下のところで止まりました。

==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key

数分待っても変わらないので、原因を調べてみることに。

まずは以下の記事を参考にしました。

virtualboxのguiを有効にするのがどうやら原因の解明にいいらしいということで、以下のようにVagrantfileのコメントアウトを外しました。

  config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
    vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  end

再度vagrant upをやってみると以下の記事に出てくる、「ホストマシンの仮想化支援機能(VT-x/AMD-V)が使用できません。ゲストOSは64ビットCPUを検出できず、起動できません。」というダイアログがでました。

http://qiita.com/super-hot-engineer/items/21e4456b8318db877f5b

ググったらこんなことが「ホストマシンのBIOS設定でVT-x/AMD-V を有効化してください」とりあえずググったページの通りにやってみよう。たぶん自分のPCの仮想化支援機構が無効になっているようだ。

motherboardのCPU設定でvirtulizationを有効にする必要があるっぽい。
わからない人はマザーボードのBIOSメニューでとにかくCPU関連をあさりまくるしかないです。
ボードによってはもしかするとなかったりすることもあるのかも。

BIOSを変更して再起動し、やっとubuntuの14が動きました。
~~ありがとう、ぼくのサンドロック~~
参照先の元記事を書いてくれた皆様に感謝いたします。

2016-01-03

アジャイルコーチというロールについて

エンジニアの学ぶべきことの深度は日々増加していて専門性も高くなり、そのために協調して働くスキルが必要になってきていると思います。

付け加えて言うなら、深くなってるんだから潜るのには勇気がいります。
誰もが教科書やコードを読んで、教えてもらうことなく技術を使いこなせるとは限りません。
たとえ技術力や意思力でヘタレだったとしても、そういった未知の領域に潜っていく勇気を与えてくれるのがスクラムやらXPであると思います。
スクラムやXPが生産性にすぐに直接影響を与えることが大きいとは自分は思っていません。継続的にやってこそ効果が出ると思います。

スクラムやXPの具体的な内容についてはここでは言及しませんのであしからず。

ただわかっているのは、やみくもにそういったプロセス改善のフレームワークを用い、プロジェクトがうまくいかないこともあると思います。
根本的な原因は、そのフレームワークそのものにあるのではなく、プロダクトの品質をキーにしたマネジメントをしていないということだったりします。
あるいは人同士の相互作用でプロダクトができるのを無視して、信頼関係の醸成やコミュニケーション(特に意思決定のルール)を軽視していたりすることだったりもします。
原因はともかく、うまくいっていないという現実の課題に踏み込まないまま、プロセス改善のフレームワーク(の上辺だけ)を適用しようとすることだけに注力しようとするのは自分は非常に危険だと思っています。

(そんな状態が続くとエンジニアのフレームワークに対する嫌悪感がたまり、悪のオーラ力がたまってハイパー化します。あるいは、エンジニアのソウルジェムが濁っていき、魔女化します。)

上手くいかないときはアジャイルコーチに頼ってみよう

そこで出てくるのがアジャイルのコーチです。
僕の知っているアジャイルコーチの最初に言った一言は「スクラムの教科書的な答えが知りたいですか？開発をうまく回したいんですか？」という内容です。
スクラムを単純に教えてくれる先生ではありません。

現場の課題に踏み込み、信頼して任せるということ

よく言われることだと思いますが、(良くないOJTのように)放任するというのと、信頼して任せるのは違います。

最初の段階では、アジャイルコーチはチームに問題があるかどうかを観察し、その課題に対してチームがちゃんと踏み込めるようにお膳立て(ファシリテーション)します。
具体的には、振り返り(retrospective)の効率的なやり方としてタイムボックスを提案してみたり、ときには簡単なワークショップもその場でやったりもします。
僕たちのチームの最初の課題として、KPTのproblemが浅く、tryの理由づけとして機能が弱かったというのがありました。
それを解決するのになぜなぜ形式でチームに問題の掘り下げをさせ、ボトルネックになっていることは何かということを追求させました。
やってるのはあくまでもお膳立てですが、ちゃんと現場の課題に踏み込みます。

コーチはそうした観察とデウスエクスマキナのような(だとちょっと言い過ぎかもしれませんが)交通整理を繰り返して、ある程度になった時点でチームを信頼して任せてくれたと思います。
決して教科書読ませてワークショップやって良かったねして、あとは自分でやれという感じではないです。

(新入社員の初年度研修などはそういうふうにせざるを得ない事情もあると思いますが・・・)

アジャイルコーチ、何となく良さそう！

アジャイルコーチとして、ファシリテーションの技術だけでなく、アジャイルに限定しない問題解決のプラクティスの引き出しが重要になると思います。

あくまで個人として感じたことですが、いいコーチはチームの困ってることを助け、自信を着けさせてくれると思います。
皆さんがアジャイルコーチというロールについて知らなかったのでしたら、「何となく良さそう」と思ってもらえるとうれしいです。

hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか