先日おかげさまでリーダー塾というコミュニティーの4期の卒業式を迎えることが
できました。
ここまで成長・持続するにあたり、多くの人たちのサポートをいただきました。
オブジェクト倶楽部と、そこでの出会いもその一つ。
本当にありがとうございました。

そして、懲りずに5期をスタートさせるのですが、今週の木曜日がゆるい説明会
となっております。

≪リーダー塾　5期のゆるい説明会≫
http://kokucheese.com/event/index/38399/

5月24日(木）19：00～　渋谷にて

●　リーダー塾の運営をやっていてわかってきたこと

リーダー塾というのは、それぞれ違う会社の人たちが参加しているので、
共通した問題や課題に力を合わせて取り組むことがほとんどできません。
そんななか、見えてきたのは、「問いを共有する」ということのつながりです。

リーダー塾は1年間という時間をかけて自分の課題に取り組みながら、
同じように取り組む他者とのコミュニケーションが創られています。
それは役に立つ内容や取り組みである場合もあるかもしれませんが、そうではない
場合もあるでしょう。だけれども、単純に「刺激になった～！」を少し超えているように
見えるつながりはどこから創られているのかに少し興味がありました。

●　問いを共有する

1年間で卒業してしまうので、その後のつながりは本人たち次第です。
それでも、全員は難しくてもなんだかんだと卒業生も含めてお集まりいただいている
のには、参加している人の動機にヒントがあるのだと思ったのです。

・　職場の課題や問題に意識を持っている人
・　自分の成長に意識がある人
・　チームのメンバーや仲間に意識がある人
・　業界や未来に興味がある人

それぞれの視点は違うのだろうと思うのですが、その切り口で考えると、
『自分にすべきことは何なんだろう？』、『今以上に自分にはどんなことが可能なのか？』
など、大きな意味で問いが同じようにあるのではないかと考えるようになりました。

これはあくまでも主催者である私の仮定ですが、知らない人が違う職場にいながらも
同じように一つのテーマで会話ができる・この場に集まってくるにはそんな共通点
があるように思えるのです。

●　人は問いによって動く

人間の行動心理は諸説ありますが、とてもシンプルなところで「問いによって動く」という
考え方があります。
少し先の未来さえも見えず、なかなか確信できるものがないなかで、少し勇気を出したり、
いつもと違ったやり方でアクションを起こしてゆくためには、哲学同様【問い】の力を
使うこともできるのです。

その反面、恐怖や義務によって動くこともできるのですが、そのような外部的な刺激は
一時的でしかなく、承認のように他者に関わられることによって生み出されるものもありますが、
ひとりでは難しい。
自分が自ら自分を動かす動機の一つとして、自分の中にある『問い』という存在に気付く
ということもぜひ頭の片隅にとどめておいてください。

そして、誰かと交流するとき、「この人にはどのような問いがあるのだろうか？」と少しアンテナ
をたててみると、会話している言葉以上にその人の行動が理解することもできるのです。

さて、「問いを共有する」ですが、最近の皆さんの中にはどのような問いがあるでしょうか？
ぜひコメントにてお寄せください。
楽しみにしています。 

上田雅美

■■　上田雅美 [株式会社アネゴ企画・エクゼクティブコーチング・組織開発支援]
■■　URL : http://www.anego.biz/
■■　Twitter：@Anegokikaku
■■　facebook: http://www.facebook.com/masami.ueda 

●日本から世界へ！未来を創る経営者塾　塾長 
http://miraisoukei.org/

●リーダーを育てるコミュニティー「リーダー塾」主宰
https://sites.google.com/site/anegojuku/ 

こんにちは、kunitooです。 

前回はインストールと起動、操作方法、環境の保存、HelloWorldをやりました。

今回はクラス・メソッドの作成を行っていきます。

Helloクラスを作成する

さっそくクラスを作成していきます。

今回作成するのはHelloクラスとsayメソッドです。

赤ボタンを押下してWorldを開き、一番上にある「Brower」をクリックします。

するとSystem Browerが開きます。ここからSqueak内の全てのObjectが参照できます。

独自のクラスを作成するために、はじめにカテゴリを追加します。

一番左のペインで青ボタンを押下し、「add item...」をクリックします。

今回はObloveと入力します。これでObloveカテゴリの完成です。

クラスを作ろう。

次はクラスを作成します。

Obloveカテゴリを選択します。System Browerの下に

Object subclass: #NameOfSubclass

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''

category: 'Oblove'

と出てきました。これがクラスのテンプレートです。#NameOfSubclass を #Hello と変更し保存します。

Helloクラスの完成です。

メソッドを作ろう

次にsayメソッドを作成します。Hello、-- all --を選択します。

クラス同様メソッドのテンプレートを変更します。

messageSelectorAndArgumentNames

"comment stating purpose of message"

| temporary variable names |

statements

上を変更し、

say

 ^ 'hello!!'

として保存して下さい。

Squeakでは「^」がリターンとなっています。なので上のsayメソッドは文字列 hello!!を返すということになります。

メソッドを使おう

作成したsayメソッドを使ってみましょう。

Workspaceを開いて、下記を入力してください。

myHello := Hello new.

myHello say.

上記を選択して、「print it」をクリックしてください。'hello!!'と表示されました。

「:=」が代入で、newでインスタンスを生成します。myHello変数にsayメッセージを送信し、'hello!!'が返ってきたということです。

こんにちは、平田です。

要件定義を主とするエンジニアにとって、お客様の立場になって物事を考えていくことは重要です。

プロジェクトの最初の期間は、要求の収集など、「情報を集めていく」場であることはもちろんですが、私はお客様の立場になって考えることができるようになるために、「お客様の考え方を自分にすりこんでいく」場であるとも考えています。

お客様の立場になって考えることができていると、コミュニケーションミスによる仕様の抜け漏れを減らしたり、将来的な展開を予測した上での設計ができたり、円滑なプロジェクト運営に近づくことができるようになります。

お客様の考え方を身に着けていくために必要なこととは何でしょう？

それはお客様にとってのお客様を意識することにほかなりません。

もしかすると、それは2段階だけではなく、3段階以上になることもあるでしょう

- 自分が事業会社の開発部門であれば、事業部門というお客様がいて、その事業部門が売上をあげるために意識しているお客様を意識する

- 受託開発の多重請負の先にいるならば、元請け会社がお客様、その発注をしている会社がその先にいて、さらにそのシステムを使う人が先にいるということ

- お客様がシステムを使って生み出したもので売上をあげているのであれば、その生み出したものを使う人たちを意識する

自分に仕事を依頼してくれるお客様と同じ視座に立ち、一緒に考えるということを続けることが何より大切なことです。「お客様のお客様を意識し続ける」ことで、お客様との一体感、チームとしての仕事も進めやすくなるのではないでしょうか？

こんにちは、家永です。

本連載は、Acceptance Testingをテーマにし、最近は、Capybaraを学習しています。今日は、JavaScript を含んだ画面をCapybara で テストをする方法を学習します。

サンプル

実装は、下記を参考にしてください。

https://github.com/haru01/capybara-sample/blob/master/app/views/posts/index.h...

この画面を Capybaraで動作確認することで JavaScriptを含んだ自動テストの動作確認をします。

フィーチャーファイルの記述

下記にフィーチャー記述を示します。

https://github.com/haru01/capybara-sample/blob/master/features/posts_search.f...

フィーチャ: 名前が一致した記事一覧が見たい
  @javascript
  シナリオ: 記事を２件投稿した状態で一覧表示する
    前提 記事を投稿する
     | name | title | content        | 
     | 名前A  | 1/1 の晩飯 | 晩飯は野菜カレー。辛かった。 | 
     | 名前A  | 1/2 の晩飯 | 晩飯は野菜カレー。辛かった。 | 
     | 名前B  | 1/2 の晩飯 | わすれた |
    かつ 記事一覧を表示する
    もし 「名前A」で Nameの絞り検索した
    ならば 画面名「記事一覧」が表示されること
    かつ 該当する記事一覧が表示されること
      | name | title |
      | 名前A  | 1/1 の晩飯 |
      | 名前A  | 1/2 の晩飯 |
    かつ 該当しない記事一覧が表示されないこと
     | name  |
     | 名前B  |

ステップファイルについては、下記をご覧下さい。

https://github.com/haru01/capybara-sample/blob/master/features/step_definitio...

JavaScriptを含めてテストしたいシナリオに対して @javascript と記述することで、テストできるようになります（シンプルですね！）。デフォルトの設定では, Selenium で動作確認することになります。ブラウザを使わずに動作確認したい場合には、webkitを使います。下記の設定の記述が必要です。

Capybaraドライバーの設定

Capybara.current_driver = :webkit

サンプル例では、https://github.com/haru01/capybara-sample/tree/master/features/support/env.rb に記述しました。

Gemfileに追加

webkitが使えるように、capybara-webkit を gem 追加しました。追加した内容は

https://github.com/haru01/capybara-sample/blob/master/Gemfile

をご覧下さい。

コマンド実行

bundle install
bundle exec rake cucumber

次回

この連載も残り僅かにの予定です。次は、Cucumber の代替手段のライブラリーを調べていく予定です。

• request spec
• Turnip

参考

https://github.com/jnicklas/capybara

こんにちは。オブラブの内角低め担当のはたけやまです。

今日はiOS5.0の新機能のひとつ「ストーリーボード」を紹介します。

レシピ02: ストーリーボードを使いたい

iOS5.0よりストーリーボードを使って画面のデザインや画面間の遷移をより直感的に定義できるようになりました。

ストーリーボード以前は、画面のデザインを定義するnibファイルを各画面毎に用意する必要がありましたが、ストーリーボードではすべての画面デザインをひとつのストーリーボード上で行うことができます。また、ストーリーボード上で画面間の遷移をマウスを使って直感的に定義できるようになったため、アプリケーション全体の流れを把握することが容易になりました。

今回は以下のような画面1から画面2へと遷移するシンプルなストーリーボードを作成してみます。

新規プロジェクトを作成

まずはストーリーボードを有効化したプロジェクトを作成します。以下の手順でプロジェクトを作成してください。

• Xcodeのメニューより「File – New – Project…」を選択する
• 「Single View Application」を選択して「Next」を押す
• 好きなプロダクト名を入力、ストーリーボードを有効化するために「Use Storyboards」を選択して「Next」を押す
• プロジェクトを作成するフォルダを選択して「Create」を押す

ストーリーボードを作成

プロジェクトを作成したら、さっそくストーリーボードを編集してみましょう。まずは画面1と画面2を用意します。

• 画面左部のプロジェクトナビゲータからMainStoryboards.storyboardを選択してストーリーボードを開く
• ストーリーボード上にViewControllerがひとつ配置されているので、こちらを画面1として利用する
• 画面1へ「2へ移動」ボタンを配置する
• 画面右下のオブジェクトライブラリから「View Controller」をドラッグしてストーリーボード上に配置、こちらを画面2として利用する
• 画面2へ「1へ戻る」ボタンを配置する

ストーリーボードはこんな感じになります。

画面はできたので、次は画面遷移を定義します。

• 画面1の「2へ移動」ボタンをcontrolキーを押しながらクリックしてポップアップウインドウを表示する
• 表示されたポップアップウインドウから「Storyboard Segues – Modal」を選択して画面2へとドラッグします

Storyboard Seguesには「Custom」「Modal」「Push」の3つがありますが、今回は画面1の上に画面2をモーダルに表示させたいので「Modal」を選択します。今回のサンプルには出てきませんが、ナビゲーションコントローラでの画面遷移の場合は「Push」を、オリジナルの画面遷移を行いたい場合は「Custom」を選択します。

これで画面1から画面2への画面遷移が定義されました。画面1と画面2の間に画面遷移をあらわす矢印が表示されます。

画面1から画面2へ戻る

これでストーリーボード上での画面遷移の設定は終了です。画面1から画面2へ遷移できるようになりました。しかし、これだけでは画面2から画面1へ戻ることができません。次は画面2から画面1へ戻るためのコードを作成します。

FirstViewController.h

#import 
@interface FirstViewController : UIViewController
@end

FirstViewController.m

#import "FirstViewController.h"
#import "SecondViewController.h"

@interface FirstViewController () 
@end

@implementation FirstViewController

// ストーリーボードで定義した画面遷移が行われる前にこのメソッドが呼ばれる
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    // 2から1へ戻るために、2のデリゲートへ1をセットしておく
    SecondViewController *controller = segue.destinationViewController;
    controller.delegate = self;
}

- (void)secondViewControllerDidFinish:(SecondViewController *)controller
{
    // 2で戻るボタンを押された場合、2の画面を閉じる
    [self dismissModalViewControllerAnimated:YES];
}

@end

SecondViewController.h

#import 

@protocol SecondViewcontrollerDelegate;

@interface SecondViewController : UIViewController
@property (nonatomic, assign) id  delegate;
@end

@protocol SecondViewcontrollerDelegate 
- (void)secondViewControllerDidFinish:(SecondViewController *)controller;
@end

SecondViewController.m

#import "SecondViewController.h"

@interface SecondViewController ()
@end

@implementation SecondViewController

@synthesize delegate = _delegate;

- (IBAction)done:(id)sender {
    // 1へ戻るボタンを押された場合、1へ処理を委譲する
    [self.delegate secondViewControllerDidFinish:self];
}

@end

ここで作成したFirstViewControllerを画面1のビューコントローラクラスに、SecondViewControllerを画面2のビューコントローラにセットします。

これでストーリボードによる画面遷移は完成です。command – Rでプログラムを実行して画面1と画面2が行き来できることを確認してみてください。

まとめ

今回はストーリーボードを駆け足で紹介しました。次回はストーリーボードのもうちょっと詳細を紹介する予定です。

先日、とあるところでちょっと話題になったことです。
とある場面で、実は本を出してみたいなって思ったので、勇気を出して相手の人に
相談をしてみたんです。 

うえだ　：　わたし、今度本を出したいと思っているんですよ。
今日は、本の内容について相談したいのですが・・・

あいて　：　そうですか！それはいいですね。
では、難しいテーマですが、話しましょう。
どうぞ。

うえだ　：　えっ！難しいんですか！？

こんなやりとりがありました。

私はちょっと話してみたかっただけなんですが、何も話す前から「難しい」という
言葉をきいてしまったので、

・　迷惑だったかしら？
・　自分が知らないあまりに簡単に考えすぎていたのかも？
・　こういうのはもっと練ってから相談するものなの！？
・　やっぱり、私が書くなんてだめでしょうか？
・　今どき出版は大変なのか・・・

今日、皆さんと考えてみたいのは口癖です。

この会話の相手だった人も、話を聴く前だったので無意識だったと思うんです。
しかし、ちょっとの言葉がどれほど会話に影響するのかをとっても考えさせられました。
きっとこの相手のなかのイメージとして、「こういう話は大変だ」という前提がある
のかもしれませんね。

このPostを楽しみにしている読者の皆さんのなかには、コンサルタント業務など
いろんな方の相談に乗るお仕事の方も多いのではないでしょうか？
そんな方がいらしたら、ちょっと自分の口癖を気をつけてみることも大切です。
例えば、周囲の人に「気になるくちぐせってある？」って聞いてみる。
可能であれば、録音をして聞いてみることもお奨めです。
自分で気をつけていると、話しながら「あっ！」っと気がつくこともできるようになります。

自分のくちぐせがみつかったら、ちょっと考えているといいのかもしれません。
・　自分の仕事の中にある前提条件や価値観
・　チャレンジやリーダーシップについて考えていること
・　自分の体験

たいていの場合は、ご自身の体験に影響されていることが多いと思います。
自分が失敗したことや、うまく行かなかったことを目の前の人がやろうとすると、
無意識に自分に当てはめて「それは大変だ」っていうスイッチが押されてしまいます。
するとどこか、脳は「やっぱり大変だ」という方程式を完成させようとしてしまいます。
それが、脳の認識のやり方の一つです。

人の話を聴くときには、この脳の働きに邪魔されないようにしたいんですね。
まずは、相手の話をそのままお聞きする。
ちょっと気になる方は、ぜひご自身のくちぐせを注意してみるといいかもしれませんよ。

試してみた方は、コメントで教えてくださいね！

上田雅美

■■　上田雅美 [株式会社アネゴ企画・エクゼクティブコーチング・組織開発支援]
■■　URL : http://www.anego.biz/
■■　Twitter：@Anegokikaku
■■　facebook: http://www.facebook.com/masami.ueda 

●日本から世界へ！未来を創る経営者塾　塾長 
http://miraisoukei.org/

●リーダーを育てるコミュニティー「リーダー塾」主宰
https://sites.google.com/site/anegojuku/

こんにちは、ursmです。

今回はRuby on RailsとMongoidを使って簡単なブログアプリケーションを作ってみます。

Mongoidとは

RubyからMongoDBを操作するためのライブラリのひとつです。Rubyのオブジェクトをドキュメントにマッピングすることから、ORMならぬODM (Object Document Mapper) と呼ばれます。Railsのモデル層を抽象化したライブラリであるActiveModelに準じたAPIを持っており、Railsとの組み合わせがとても簡単に行えます。

アプリケーションを生成する

それでは早速始めましょう。Mongoidのバージョンは今時点の最新安定版である2.4.5を、Railsも同様に3.2.1を使います。

$ rails new blog --skip-active-record
      create  
      create  README.rdoc
      (snip)
      create  vendor/plugins/.gitkeep
         run  bundle install
Fetching gem metadata from https://rubygems.org/.........
Using rake (0.9.2.2) 
(snip)
Using uglifier (1.2.3) 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
$ cd blog

blogというヒネりのない名前のアプリケーションを作りました。今回はモデル層にMongoidを使いますので、ActiveRecordを使わないようオプションを指定しています。

次に依存ライブラリを設定します。railsコマンドによって生成されたGemfileからコメントを取り除き、Mongoidを追加したものが以下になります。

source 'https://rubygems.org'

gem 'rails', '3.2.1'
gem 'jquery-rails'
gem 'mongoid'
gem 'bson_ext'

group :assets do
  gem 'sass-rails',   '~> 3.2.3'
  gem 'coffee-rails', '~> 3.2.1'
  gem 'uglifier', '>= 1.0.3'
end

bundleコマンドでライブラリをインストールします。

$ bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
(snip)
Installing bson (1.6.0) 
Installing bson_ext (1.6.0) with native extensions
(snip)
Installing mongo (1.6.0) 
Installing mongoid (2.4.5) 
(snip)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

最後にMongoidの設定ファイルを生成します。

$ rails g mongoid:config

Mongoid config not found. Create a config file at: config/mongoid.yml
to generate one run: rails generate mongoid:config

      create  config/mongoid.yml

生成されたmongoid.ymlは以下のようになっていました。ローカルで開発する分にはこのままで十分です。

development:
  host: localhost
  database: blog_development

test:
  host: localhost
  database: blog_test

# set these environment variables on your prod server
production:
  host: <%= ENV['MONGOID_HOST'] %>
  port: <%= ENV['MONGOID_PORT'] %>
  username: <%= ENV['MONGOID_USERNAME'] %>
  password: <%= ENV['MONGOID_PASSWORD'] %>
  database: <%= ENV['MONGOID_DATABASE'] %>
  # slaves:
  #   - host: slave1.local
  #     port: 27018
  #   - host: slave2.local
  #     port: 27019

モデルを作る

ブログの記事を表現するモデルを作ります。格納するプロパティはタイトルと本文、投稿日ぐらいにしておきましょう。

$ rails g model post title:string body:string
      invoke  mongoid
      create    app/models/post.rb
      invoke    test_unit
      create      test/unit/post_test.rb
      create      test/fixtures/posts.yml

モデルの実体、app/models/post.rbは以下のようになっています。

class Post
  include Mongoid::Document
  field :title, :type => String
  field :body, :type => String
end

投稿日を格納するため1行追加します。

class Post
  include Mongoid::Document
  include Mongoid::Timestamps::Created # 追加
  field :title, :type => String
  field :body, :type => String
end

Mongoid::Timestamps::Createdは初回の保存時に現在の時刻を記録してくれるモジュールです。

さて、これだけで大体できてしまいました。試しにコンソールから触ってみましょう。

$ rails c
Loading development environment (Rails 3.2.1)
>> p = Post.new
=> #<Post _id: 4f4bfc080767974737000001, _type: nil, created_at: nil, title: nil, body: nil>
>> p.title = 'hello'
=> "hello"
>> p.body = 'world'
=> "world"
>> p.save
=> true
>> p.created_at
=> 2012-02-28 06:56:39 +0900
>> p
=> #<Post _id: 4f4bfc080767974737000001, _type: nil, created_at: 2012-02-27 21:56:39 UTC, title: "hello", body: "world">

とても簡単ですね。

記事の一覧を作る

railsコマンドで空のコントローラとルーティングを生成します。途中先ほど作ったモデルを上書きするか聞かれますが、noと答えます。

$ rails g resource posts title body
      invoke  mongoid
    conflict    app/models/post.rb
  Overwrite /home/ursm/src/blog/app/models/post.rb? (enter "h" for help) [Ynaqdh] n
        skip    app/models/post.rb
      invoke    test_unit
   identical      test/unit/post_test.rb
   identical      test/fixtures/posts.yml
      invoke  controller
      create    app/controllers/posts_controller.rb
(snip)
       route  resources :posts

まず記事の一覧画面から作りましょう。/postsで一覧が出てほしいので、PostsControllerのindexアクションを次のように実装します:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.desc(:created_at)
  end
end

descは指定したプロパティをキーにして逆順にソートしてくれるメソッドです。すべての記事を新しい順に取得してインスタンス変数に代入しています。

続いてビューを作ります:

# app/views/posts/index.html.erb
<% @posts.each do |post| %>
  <article>
    <h1><%= post.title %></h1>
    <%= simple_format post.body %>
    <time pubdate<%= post.created_at.to_date %></time
  </article
<% end %>

記事1件ごとにタイトルと本文、投稿日を出力しています。

それでは、この状態でサーバを起動して…

$ rails s
=> Booting WEBrick
=> Rails 3.2.1 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2012-02-28 07:26:38] INFO  WEBrick 1.3.1
[2012-02-28 07:26:38] INFO  ruby 1.9.3 (2012-02-16) [x86_64-linux]
[2012-02-28 07:26:38] INFO  WEBrick::HTTPServer#start: pid=20555 port=3000

http://localhost:3000/posts にアクセスすると、先ほどコンソールで作った記事が表示されます。

投稿機能を作る

投稿フォームを表示するアクションと、フォームから渡されたパラメータを元にモデルを作成するアクションをそれぞれ実装します:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.desc(:created_at)
  end

  def new
    @post = Post.new
  end

  def create
    Post.create!(params[:post])
    redirect_to :posts
  end
end

投稿フォームはRailsの仕組みを利用してとても簡単に書けます。

# app/views/posts/new.html.erb
<%= form_for @post do |f| %>
  <%= f.label :title %><br>
  <%= f.text_field :title %><br>
  <%= f.label :body %><br>
  <%= f.text_area :body %><br>
  <%= f.submit %>
<% end %>

http://localhost:3000/posts/new から適当な文章を打ち込んで送信すると、一覧画面に投稿が表示されます。とても荒削りですが、一応ブログらしきものができてしまいました。

MongoidとRailsの組み合わせは裏側がMongoDBであることをまったく意識させないばかりか、スキーマ定義が必要ないぶんRDBよりもサクサクと開発できる感触すらあります。

おわりに

長らくご愛読いただきました本連載も今回が最終回となります。少しでも楽しんでいただけたなら幸いです。また機会がありましたらお会いしましょう。

こんにちは、天野勝です。

見える化ガイド、連載の第5回目は、「見える化ツールいろいろ」です。
本連載の第1回で、見える化を定義した通り、異常が分かって、行動を誘発するような仕組みは、多種多様に存在ます。今回は、タスクボード、バーンダウンチャート以外の見える化ツールをいくつかご紹介します。

■アナログな見える化ツール
◇ニコニコカレンダー(ニコカレ)[*1]
その日の帰り際に、その時の気分に応じたフェースマークをカレンダーに貼るというものです。
チームのムードが見えるようになります。
チームによっては、朝と帰りの2回シールを貼っていたり、フェースマークに加えてその日の残業時間も記録しているところがあります。
ニコカレを運用するには、チームがそれなりに成熟している必要があります。成熟していないと、自身の気持ちは下向きだけど、他のメンバーが上向きな気分だと、なかなか貼りにくかったりして、ついまわりにあわせてしまうなんてことが起きかねません。正しい情報が共有できなければ、見える化としては成立しないのです。

◇バグレゴ[*2]
バグを発見したら、バグに応じてレゴブロックで造形を作って、レゴシートに積むというものです。
製品のバグ状況が見えるようになります。
レゴシートという物理的なサイズに制約があることで、多くのバグを積むことができず、バグ対応のきっかけとなります。
このような遊び心のあるツールを導入することで、バグに対するマインドセットが変わるという効果も期待できます。詳しくは、リンクの資料をご覧ください。

■デジタルな見える化ツール
◇表計算ソフト
表計算ソフトを大きいディスプレイに表示するというものです。
どのような情報を見えるようにするかは、チームによって様々です。
リアルタイムにグラフを更新したり、情報を蓄積するのに力を発揮します。
大きいディスプレイというのは貴重なので、ただ情報を発信するだけに使うのはもったいなく、通常の作業にも使われることが多く、絶えず情報を表示していない現場が多いようです。

◇チケット管理システム
Trac、Redmine、JIRAのようなチケット管理システムも多く用いられています。
これらのメジャーなツールには、プラグインでタスクボード風のビューや、バーンダウンチャートを表示できるように拡張できます。

■アナログツールか、デジタルツールか
アナログも、デジタルもそれぞれ良い点がありますので、それらの特徴を活かして補完して使ってみてください。
まずは、アナログツールで運用して試行錯誤し、ルールが整ったところでデジタルツールに移行するというのがおすすめです。

◇アナログツールの良いところ
・初期コストが安く、すぐに立ち上げられる
・運用ルールに合わせてレイアウトなどを容易に変更できる
・一度に多くの情報を見せることができる
・手で更新するので、異常時のフィードバック感が強い

◇デジタルツールの良いところ
・大量のデータを管理しやすい
・集計が容易
・ネットワークで遠地ともリアルタイムに同期できる
・同じ情報を、用途に応じたビューで表示できる

■おわりに
これで、この連載は終わりです。
この連載が、みなさんの職場が見える化されてカイゼンが進む何かしらの助けになれば幸いです。

ニコニコカレンダー
http://www.geocities.jp/nikonikocalendar/index_ja.html

レゴブロックを使った欠陥の「見える化」--バグレゴによる試行--
http://www.jasst.jp/archives/jasst07e/pdf/A4-1.pdf

オブログ読者のみなさん、岡島です。こんにちは。

今日はデブサミ。私は参加していないのですが、時折TLを眺めると、『心地よい空間から出ていく』という言葉をたくさんみることができました。前後の文脈はわかりませんが、デベロッパーとして高みを目指す以上安住の地はない。安住してしまえばそこで成長は止まってしまう。ということだろうと（勝手に）理解し、何か胸に迫るものを感じております。

さて、デベロッパーとしての精進というと、私は、私のブログの中でも紹介したTさん、を思い出さずにいられません。

今回なんでこんなオチのない昔話をしたかといえば、長年弊社で一線のアークテクト・技術者として働き、私たち開発者から慕われたTさん（もちろん、 E-INTRAの生みの親）が先日定年退職されたからなのです。Tさん、お疲れ様でした。そして、育ててくださり、ありがとうございます。

実はTさんは数年前のオブラブイベントに登壇しており、その時もにコンピュータの基礎から教えるんだと、とても熱い思いを持って話されていたことも思い出し、ますます胸に熱いモノが。

そんな気分の今日なので、Tさんから学んだ「精進し続けるデベロッパーの姿勢」をいくつか挙げさせてください。

技術は食わず嫌いしない

「トランジスタ以降の技術は全て誤差の範囲だ」と言ってのける人ですが、その誤差である新しい技術（言語など）に対する感度は敏感でした。Javaには真っ先に取り組みましたしRubyにももちろん手を出しています。UNIXが好きでしたがWindowsも必要に応じて使っていましたし、先入観だけで技術を食わず嫌いする意固地さはなく、柔軟でした。（もちろん、食ったうえでの「嫌い」はありましたが）

車輪の再発明を気にしない

すでに存在するソフトウェアやコンポーネントでも、一度は自分で作ります。効率化が叫ばれる昨今、このような行為は「車輪の再発明」と呼ばれ嫌われますが、Tさんはお構いなしでした。今思えば、技術の本質を理解し、システムにブラックボックスを作らないためにも必要な姿勢だった気がします。もちろん、自分で作ったうえでさらに良いものがあれば、そちらを利用する柔軟性は必要です。（とはいえ、メーラーはいつでも自作してた気がします。ネットワークライブラリに慣れるのにちょうどよい題材なんだ、って）

スピードだけがすべてじゃない

Tさんは超ベテランのプログラマなのですが、いまだにキーボードは2本指（左右それぞれの人差し指）でタイプします。もちろん、ブラインドタッチできる一般のプログラマよりタイピングスピードは圧倒的に遅いのですが、本人いわく「お前らはたくさんキーボードをたたくけど、その分間違いも多いだろう。頻繁にDeleteしてる。一方俺は、しっかり考えてからキーボード叩くからDeleteすることがほとんどないんだ。だから、効率はそんなに変わらないんだよ」とのことです。

人に教えることで自分も成長する

新人の教育だけでなく、社内のあらゆる人の技術的な質問に丁寧に答えていました。もちろん、私も大いに教わったのですが、いつでも、表面的なことで なく、本質的な部分を教えようとしてくれていました。一般によく言われることですが、「人を教えることで自分も学び成長する」ことを体現していました。

問題を解決し続けたいという思い

Tさんに「定年後はゆっくりするんですか？」と聞いたところ「もっと研究したいことがある」と答えられました。今までのように「仕事として問題が発生する」環境じゃなくても、「世の中には解決を待っている問題はたくさんある」ということでしょう。まさに「ハッカーウェイ」。

私はまだまだTさんの領域には到達することはできませんが、年齢重ねても「柔軟さ」と、「本質探究心」、「問題を解決したいという思い」を持ち続けます。そして、このような思いに共感できるデベロッパーと一緒に仕事をしたいという気持ちを改めて強くしております。

市谷です。

昨年12月に、スキニーなシステム開発のススメと題して、クラスメソッドさんと共催でセミナーを開催しました。

スキニーなシステム開発のススメ <永和システムマネジメント ×　クラスメソッド 共催セミナー>

永和システム、クラスメソッドが手を組む開発スキームの狙いは、両社互いの強みを活かすカタチを作ることで、システム提供の幅を広げることです。それは単に営業の幅を広げるためのものではありません。さらには、永和システムとクラスメソッドだけに限るような狭い話でもありません。広く多くの方々と、これからのシステム開発を模索していきたいと考えています。

これまでのSIでよくあったのが、どこか1社がユーザ企業に対してフロントに立ち、それ以外の関係企業がそのバックに周り、プロジェクトを統制するカタチです。その狙いは、ユーザー企業とのコミュニケーションパスとマネジメントを1本化することで、システム開発の成功確度を高めることにあります。ここでいう、成功とは、お客様が求めるQCDの最低限のクリアとしましょう。

現実は、従来どおりのシステム開発のやり方で、お客様が価値を感じられるか問われる時代に入っています。その背景には、これまでのSIとの比較対象が新たに現れたことが1つ挙げられると思います。私がそのことを強く感じたのは、かつてフロント企業に所属し、SaaS/PaaSベンダーとの競合に敗れた時です。品質、コスト、納期の面で、どれか1つで差がついて敗れるのではなく、全体として勝てないということが現実になっていることを身をもって理解しました。

これまでの開発での課題を2つ挙げます(下図、左側)。

1つは、統制を効かせるためのフロントーバック体制の横の関係がもたらす、デリバリまでの時間です。システムを必要とする人たちの手に届き、作ったものを確認してもらい、そのフィードバックを得るまでのサイクルが長くなります。この影響は様々なところに出てくることになります。コストがかかる以上に問題となるのは、フィードバックを反映させることができず、ユーザーが必要なシステムを手に入れられない可能性です。

もう1つの課題は、コミュニケーションパスの1本化が、関係各社の連携を断つ側面を持っているということです。本来、複数の企業が関与するということは、その多様性の強みを活かせる可能性があります。プロジェクトとしての統制は必要ですが、そのためにせっかくの強みの連携を活かせないというジレンマが起きることになります。

これに対して、新たな開発スキームはどう描けるのか(図の右側)。フロントーバック体制がボトルネックになるならば、別の枠組みが必要です。プロジェクトに、関係各社がフラットに参画し、ユーザ企業と関係会社でコミッティを形成するカタチです。プロジェクトに必要な統制は、コミッティでかけます。垂直統合の体制が採られる背景には、事実上商流の維持のためもあります。ただ、プロジェクトマネジメントも開発における1つのロールとして捉えると、営業関係をシステム開発体制で実装する必要はない、と個人的には考えています。

このような開発スキームにも課題はあります。開発対象のシステムやプロジェクトによっては、強い統制が必要となることもあるでしょう。そもそも、営業戦略的に開発的に、フラットな関係を結べる相手でなければなりません。キャラクターが被っていては互いの強みを活かすことはできません。また、開発のやり方自体が合わなければ、現実的に組むことはできません。まだ、この開発スキームには仮説も含まれており、これから検証をしなければいけないものです。課題は少なくありませんが、ITを必要としている人たちの期待に応えるためには、変わらなければならないはずです。

本質的な価値を提供できる手段があるならば、それを取ればいい。確信が得られるまで、仮説・検証・改善を繰り返し、模索していけばいい。大切なのは、真実に向かおうとする意思ではないでしょうか。やり方は1つではありません。冒頭のとおり、広く多くの方とこれからのシステム開発を描きたいと思っています。チカラをあわせましょう。