The oshiire has been full of love since 1999
お前は「[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG」で味をしめたからといって、また「IPA 独立行政法人 情報処理推進機構」ネタなのかと言われそうですけれども、そうじゃない、だってそうじゃない。
基本的に、その日にあった、または最近あった出来事を元に blogのネタを日々書いているので、実は、毎日 blog書くのは結構大変です。そんなに、毎日、なにかあるわけじゃなく、ナニゴトも無く穏やかに過ごす日だってあるわけで、なかなか大変なのです、これでも。ただ、落書きしてるわけじゃなくて、これでもすこしは頭を使ってるんです…( ﾟдﾟ )ｸﾜｯ!!
いい加減「WEBサーバを新しいのにしたら、blog書くようにしよう(´∀｀)」なんて言っている状態ではなく、なにも書いていないので、日本語を書くことがものすごく苦手になっている気がしてやみません。
致し方ないので、やっぱり、日々アウトプットもしていく飛鳥があるなとキーボード叩いてみます。やってみます。おう、やってやんよ!!( ﾟдﾟ )ｸﾜｯ!!
最近の活動内容はこんな感じです。
そろそろ、これらについて、ちょっとずつアウトプットしていかないとなーって気はしてます。ホントに。仕事の気分転換的ですけど。
先日、”qpstudy 2014.04 一般枠 〜俺の屍を超えて行け、でも踏まないで〜 on Zusaar” 久しぶりの、本年初めての qpstudyでしたね。もう、Markdown の書き方すら怪しいくらいにアウトプットしていなくて、ホントに自分がやばい気がします。死にそう。
さて、そんな qpでは「インフラエンジニアとは、なんだ」と称して、インフラの領域と、構築フェーズについて一般的なことに少し拡張してお話ししてきました。
このまとめも、そのうちやらなきゃなーと思ったら、あれから 2週間くらい経過してますね。ゴメンなさい。本番編のスライドも作らないといけない気はします。でも、本番スライドできたら、数年それで食べていける気がするので、それネタになんか書いても良さそうです。
ぶっちゃけ、数年前から「要件定義書いてー(´∀｀)」「設計書書いてー」なんて言いつつもずっとすすんでおらず、テンポラリで移行した仮想鯖で満足した日々を送っていますが、イロイロとやたらめったら課題山積なので、本気でサーバの更改案件を進めています。
んで、qpstudy 2014.04 でもやった手前、その考え方に従って、要件定義からテストまで実施してみようと、実際に要件定義書を書き始めました。適当でいいやと思っていたら、なかなかの傑作(分量的に)になってきてしまい、このまま進んでいっていいのかどうか、非常に悩んでいるところです。
なにをというと、誰も長すぎて読まないんじゃないかという一抹の不安。
文書は置いといて、構築自体は進めています。で、フツーにやったら面白くもなんともないので、インフラ構築にアジャイルの要素を組み込んでみたり、TDD してみたりと幅は広いです。新しいことを取り込んで進めているために、遅々として作業自体も進んでいかないのですが、全部できあがった暁にはそれなりの経験を積めて楽しいことになるんじゃないかと、一人キャッキャうふふしてます。仕事の役には立たないのに。たぶん。
今、作ってみようと考えているサーバはこんな感じになってます。年内には、全てのサーバが移行できたら良いなぁ、なんてそんな時間感覚での気構えです。所詮、家のサーバです。
ということで、開発環境やテスト環境がなかったので、vagrant 活用してます。そして、上記のサーバ更改にあたり、chef や serverspec のお世話にもなってます。
“sho7650 – Qiita“でも、vagrant や chef に触れられていることで、その熱き想いは理解いただけると考えています。そんで、どれくらい熱いかというと、会社の社内勉強会(研究会とでも言うほうがいいのか)でも、この 3つのプロダクトをターゲットにして、利活用について検討を始めてます。おいらがリーダーやってるので、好きし放題です。やりたい放題です。しかし、なんで女子が少ないのか。
さて、そんなこんなで、今、この 3つのプロダクトは私から外して語ることはできません。面白いネタができたら、小出しにしていこうと思います。
ついでに chefは “sho7650 (sho kisaragi)” github にも更改済。おい、パスワードモロみえじゃないかという突っ込みはスルーします。基本、パスワードは変更されるための初期パスワード扱いです。data-bag にいれて暗号化するとかゴメンなさいめんどくさいのです(おい
先ほどの github や Qiitaを見ていただくと分かるとおり、.emacsrc とかもいじって遊んでいます。楽しいです。もう、ほとんど飽きました実生活の一部となっていますけどね。
それと、GNU screen です。気がついたら 4.2あたりで縦分割できるようになってオシャレです。でかい画面のオレには必須機能でした。楽しいです。
しかし、hardstatus と caption はホントに意味が分かりません。どっかに、hardstatus シミュレータとかないんでしょうか。
ということで、気分転換に *rc ファイルをいじり始めると、夜更けになっているので、こういう楽しい環境設定は、ヒマでヒマで仕方ないときに廻しておくことにした方が良い気がします。でも、気分転換にやっちゃうんですよね。平気で 2時間くらい。そりゃ、資料もできませんわ。
こんな感じで生きてるのでご安心ください。
最近、寝室が変わって、毎晩フライングボディプレスト、ローリングソバットに耐えしのぐ夜をすごして睡眠不足ですが、なんとかしてみたいと思います。
かしこ
[tmkm-amazon]4863541333[/tmkm-amazon]
[tmkm-amazon]4774146005[/tmkm-amazon]
ここまで、プロジェクト運営における課題を改善できないか、ゲーミフィケーションを用いて仮設を立てて考えてみました。現実的な課題とあわせて一緒に考えることで、よりゲーミフィケーションの考え方が理解できたのではないでしょうか。
ゲーミフィケーションの考え方は古くからあるものですが、最近になって体系化されつつある、発展途上の方法論でもあります。根底にあるのは、利用者に楽しんでもらおう、という「おもてなしの心」です。使用するツールもアプリケーションも、実際の利用者は人間です。人と人との関わりをもって関係をしていくためには、相手を思いやる気持ちが必要不可欠です。
そして、そのおもてなしの心は、人と人との交流をへて、相手の心理的な報酬へと繋がります。
報酬とは金銭的なものばかりではなく、もてなしたことで得ることのできる精神的な報酬のモチベーションが重要です。人を動かすためには、お金も重要ですが、行動すると良い結果に繋がる、精神的な報酬がそこに生まれることが必要です。そのためには、相手を思いやる気持ちをもって、課題の解決につなげていくことです。
課題を解決するための「報酬」と「交流」、根底にある考え方は「おもてなしの心」であることがゲーミフィケーションの重要な考え方となります。
“[Gamification] ゲーミフィケーションでプロジェクトを改善するには? (5/5) [デスマーチ]” の続きを読む
冒頭の話を思い返してください。
私は、プロジェクトの運営課題に対して、ゲーミフィケーションを適用すれば解決できるのではないだろうか、と考えました。
これからお話しする内容は、残念ながらまだ実績のない、机上の空論です。ですが、私は一つの確信を持って、この解決方法を推進していきたいと考えています。
それは、「みんなでするゲームは面白い」と言うことです。
思い出してください。子供の頃でもいいです。家族旅行でも、修学旅行でも、友人らとの旅行でも何でも良いです。そこで、なにかしらのゲームをやりませんでしたか?
定番のトランプ、双六、人生ゲーム(R)、uno(R)、それから、TVゲームの対戦でも、多くのゲームをする機会があったのではないでしょうか。そして、負けてしまって悔しい思いもしたでしょうが、ゲーム自体は楽しく、面白くありませんでしたか?
もしかすると、「TVゲームなんてくだらない、楽しいとも感じない」とおっしゃる方もいらっしゃるかも知れませんが、TVゲームはやらなくても、ボードゲームやじゃんけん、すくなくとも運動会でかけっこや騎馬戦などのゲームはしているはずです。みんなで集まってするゲームは面白い、楽しい、そう言った記憶がよみがえってきませんか? [I]よみがえらなかった人はゴメンね
“[Gamification] ゲーミフィケーションでプロジェクトを改善するには? (4/5) [デスマーチ]” の続きを読む
References
| ↑I | よみがえらなかった人はゴメンね |
|---|
それでは、これらの原因を解決するたまには何をすれば良いのでしょうか。
文章で示すことは簡単です。次の 2つです。
これだけです。さぁ、実践してみましょう。
“[Gamification] ゲーミフィケーションでプロジェクトを改善するには? (3/5) [デスマーチ]” の続きを読む
さて、そもそもプロジェクトの抱える課題とはなんでしょうか。
“[Gamification] ゲーミフィケーションでプロジェクトを改善するには? (2/5) [デスマーチ]” の続きを読む
もう、昨年の話なんですけれども。必至に書いた割には、日の目を見なかった執筆原稿があります。レビューもいただいたものの、内容を見返せば見返すほどオチがないので、表に出すには時期尚早だな、と思い、そのままお蔵入りさせていました。
ただ、お蔵入りしていたら、完全にもったいなさすぎるので、提言までの内容として公開します。もう 1年以上も前ではありますが、今時点でも、このアプローチはまだ新鮮だとは思うんですが、いかがでしょう。
今更、ゲーミフィケーションかよと言うことよりも、日本人の根底として存在するもてなしの心から、改善活動ができないかと考えています。
“[Gamification] ゲーミフィケーションでプロジェクトを改善するには? (1/5) [デスマーチ]” の続きを読む
多分、これで一通りは終わりになると思われます。”[応用編] アクアリウムエンジニアリング(2/3) テスト計画と開発局面 [再利用] | oshiire*BLOGoshiire*BLOG“の続きです。
今回は実際にくみ上げたものを確認するための「テスト」です。テストが終われば、はれてサービスインとなります。
なぜか、こんな先まで続いてしまった第三弾。”[応用編] アクアリウムエンジニアリング(1/2) 要件定義から設計局面 [再利用] | oshiire*BLOGoshiire*BLOG” の続きです。しかも、まだ次回に続きます。おい。
今日は実際の手を動かす局面になりますね。開発(構築) とテストの計画です。
想定した作業どおりに進めれば良いだけなので、説明自体は楽なのですが、テスト計画について先に述べておきます。