アジャイルとは環境やったんやー!! Agile Samurai Base Campに参加してきた。

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。

仕様やドキュメントなしで開発することは、アジャイルじゃないんやー。
(そもそもそんなのは"なんちゃって"とか言われる類のものだろうけれど…。)
と、それは置いておいて。

いろいろ試してきたけれど、やっと今日しっくりいった。

自走していると思っていたチームに物足りなさを感じていたんだ。
それは、こういうことだったのだ。

アジャイルの手法を取り入れていって上手くいっていたと思うんだ。
けれど、ある時期にカイゼンが進まなくなったような感じがするようになったんだ。
仕様があってそれにスケジュール通りに応える。
だけれど、もっと出来るんじゃないかと思ったんだが"もっと"という方向にはいかなかった。

きっと、手法を取り入れて(なんとなく)上手くいっていて、それに満足していたんだろう。
本当に必要なのは、ミッション(for user)に対するモチベーションだったんだろうな。

ミッション達成の為に手法が必要で、手法を取り入れることでカイゼン出来ると思っていた。
そして、カイゼンされたことが現実になったら、そこで満足してしまったんだろうな。
(ある意味、そのチームの完成だったのかもしれない。)
けれど、ミッションの本当の目的を忘れてしまっていたんだろう…。

たぶんここでインセプションデッキを確認出来ていれば、また違っていたんだろうな。

インセプションデッキはいつやってもいいんだ!!

悩んだりしたら、やってもいい。
忘れないように定期的にやってもいいだろう。

今まで何故か、途中でインセプションデッキをやるのに躊躇っている気持ちがあったんだ。
途中で方向性が変わってしまうんじゃないかって。

でも、アジャイルってその変化を許容しながら調整して進むことじゃないか!!

だから、インセプションデッキはいつやってもいいんだ!

tips メモ

• 打ち合わせをするときにはアジェンダだけでなく、たたき台を用意していくとよい。
• 指折りして同意ポイント(同意しているときには5,全く同意していない時には1)で、共有度を確認する。
• 打ち合わせなどの後には、まとめたことをスライドにする。そして掲げておく。それを見ればそれぞれが物事を決断出来るようにする。

振り返りはやれ、更に面白くする、多少のことでくじけない。

• PO研修はいい!POがチームに気持ちを伝えられなければ問題なのだ!
• 平鍋さん｢なんでも貼っておけ。｣
• 新卒がわからないとダメ、インセプションデッキがあれば理解しやすい。

まとめ

アジャイルサムライ再入門という感じで、見落としがちだったところを再確認できた。

"手法"に拘らないように考えていたけれども、言葉に出さないようにしていたというだけで、結局"どうやろうか"というところを考え過ぎていたのかなと。
その為に、チームメンバーの"モチベーション"について意識が疎かになっていたと思う。

だので、調整していこうっと。

MojoliciousのRoutesの中身をtree上に吐き出す。

#!/usr/bin/perl
#myapp.pl
use Mojolicious::Commands;

Mojolicious::Commands->start_app("MyApp");

みたいなスクリプトを書いて。

$ perl ./myapp.pl routes

とかするとSTDOUTに、tree上に表示される。

こっちでもよかった。

#!/usr/bin/perl
use Mojolicious::Commands;

Mojolicious::Commands->start_app("MyApp","routes");

『東京家族』良かったです!

小並感ですけれどね。

大変よかったです。

ずーっと幸せな感じがでていてとてもよかったです。

幸せすぎて、自転車のシーンとか橋爪さんと吉行さんとが別々に行動するシーンとかになると、
なんか事故にあって嫌な感じになるのかと緊張したりしましたが、
終始、家族愛に包まれていてとても良かったんですよぉ。

みんないい人ばかりでなんだか、穿ってみてしまう感じもあるんですけれど、とはいっても幸せな感じがとても羨ましくてイヤじゃないんですな。

そして、いい俳優さんばかりなのですが、なかでも蒼井優さんが素晴らしいんですね!!
素晴らしいというか好きなだけなんですけれどね!
最後にそっと手で顔を覆うところなんかもうね!!
いやあー久しぶりに堪能した!

子供のころは、土曜半休+日曜休みで週休二日なんて夢だった。

という訳で?土曜日出勤しています。

休日出勤は別に問題じゃないです。

なんかこんな風に思ったので投下。

｢悪いのは世のなかだと不平を言うのは間違っている。能力のある人が無視された例を私は知らない。失敗するのはたいてい自分の責任だ。｣ 『自助論』

｢自分は頑張っているのにとかしっかり仕事しているのに評価されない。｣とか言う人いるけれど、そんなのはただのいい訳だ。

評価されないのは評価されないことしかしていないから評価されないんだ。
それを評価しない周りに責任転嫁なんかしているから、
いつまでたっても評価されるべきことがわからないでグズグズ言い訳をするんだ。
評価されることを考えもせず調べもせずに何を言う。

人の評価を求める前に、自分が人に見せられることをしているのかよく考えるべきだ。

まぁこんな時にそんな風に考えてしまう自分はしっかり社畜なんだろうなぁ。
とはいえ、自分なりには会社に尽くしているつもりはサラサラ無いし。
自分の成すべきこと、それが将来の糧になることだと考えて行動している。
と思っているからどうでもいいんだけれどね。

納得感を引き出すということはやった方がいい。

チームで活動しようと思うなら、メンバーが納得したうえで進むべきだろう。

• 活動の価値がどこにあるのかわからない＝ゴールがわからない。
• ゴールがわからないので自発的に動くことができなくなる。
• 価値の観点がわからなくなると、反省点もぶれるので改善が適切でなくなる。

とかメモって見た。

書き起こそうとするといろいろ気になって進まないな。

DBから引っ張ってきた値が文字化ける!!

開発で使っていたソースを、いざ本番サーバーにアップ!!
という作業をしていたら何故か文字化けする!

ソースは変えていない…開発と本番差異はなんだろうと。

• フレームワークバージョン揃えた
• テンプレートエンジンバージョン揃えた
• ORマッパバージョン揃えた
• DBIバージョン揃えた
• DBD::mysqlバージョン揃えた

もうDBかな?と

で、文字だから文字コードの確認

mysql> show variables like 'char%'; 

	開発	本番
character_set_database	latin1	utf-8
character_set_server	latin1	utf-8

｢コーコダー!ナオセー!!｣

ということで、これが原因です。

これを変更するには、my.cnfを編集します。

だので、my.cnfの場所を探しましょう。

> mysql --help | grep my.cnf 
> /etc/my.cnf /etc/mysql/my.cnf 

という感じで、my.cnfを読み込む順番が表示されます。
この読み込み順で読み込まれますので、前にあるのは後ろにあるmy.cnfで上書きされていきます。
ご注意ください。

で、それをどうするか。

1. その順でファイルを探して開いてください。
2. 今回は本番を開発に合わせるので latin1にします。

(普通ならutf8に合わせたほうがいいと思います。)

[mysqld]
character_set_server = latin1

3. character_set_serverを変更すると、character_set_databaseも変更されています。

これで、my.cnfを閉じて、mysqlをリスタートしてください。

mysql> show variables like 'char%'; 

をして期待通りになっていることを確認。
文字化けが直りました。

以上。

なんか、何度もコレに突っかかってる気がする…。

DevLOVE現場甲子園2013に行ってきた その1

先週から風邪を引いたり、仕事が忙しかったりでやっとこさ。
沢山メモがあるので、ひとまずその1ということで。

混沌とするサービス開発の現場でニーズに集中しつづけるためにゴリゴリ工夫したこと

発表者:森雄哉 氏

まとめ(発表を受けて、今度やりたいこと!)

今までは、それぞれの言葉で目的を共有するだけだったけれど、
狩野モデルなどを使って観点を定めて、価値基準の共有やズレを認識してみたい。

やなせたかしさんは、やはり偉大だなと思いました。
アンパンマンの歌が、この年になっても感動するとは素晴らしい。
そのことに、気づかせてくれた森氏にも感謝m(_ _)m

メモ

サービスを成功させたい!!というのが動機。

サービスを開発するにあたって関係者の要求はバラバラである。
そして、その結果。価値の軸が曖昧になり誰も求めていないサービスが出来上がる。
成功させるには、軸の創造、要求の収束が必要となる。

お客さんは、自分の欲求を満たせるからお金を払ってくれる。

狩野モデルを使って、必要要件をすりあわせてみる。

ズレについて可視化が行える。

要求に仕様は書かれていない。
要求と仕様には隙間がある。
要求をそのまま仕様に落とさない方がいい。

すりあわせる為に検証をする。

その要求が達成できる最良の手段を仕様に落とす。
要求>手段>なぜならば
手段>なぜならば>要求
意味が通るであれば、それでよし。
そうでなければ、手段を疑え。

"とりあえず"は、目的が甘い。から出てくるキーワード。

アンパンマンの歌

何が君の幸せ。何をして喜ぶ。わからないまま終わる。そんなのは嫌だ!!