今回は Java の列挙型 (Enum) についてです。

前回のジェネリックスと同様に、列挙型も Java5 以降に追加されました。
Java5 がリリースされてから、もうずいぶん経ちますが、意外と列挙型をよく知らないという人も多いのではないでしょうか。

• 項目30 int定数の代わりにenumを使用する
• 項目31 序数の代わりにインスタンスフィールドを使用する
• 項目32 ビットフィールドの代わりにEnumSetを使用する
• 項目33 序数インデックスの代わりにEnumMapを使用する
• 項目34 拡張可能なenumをインタフェースで模倣する

恥ずかしながら、この本を読むまで、Java の Enum がここまで強力なものとは知りませんでした。
Enum の使いどころや利点を紹介したいと思います。

Enumとは

C言語では、列挙型というと、「名前付きの整数定数を定義するもの」ということになると思います。

C# などの .NET の言語でも、基本的には enum の実体は int 値ですが、Java の enum はこれらとは異なります。

Java での enum はインスタンス数が制限されていることを実行環境が保証している本格的なクラスです。

Effective Java では、このことを「インスタンス制御されている」と記述しています。
別の言い方として、enum は「シングルトンを汎用化したもの」とも書かれています。
（シングルトンとは、デザインパターンの1つで、インスタンス数が1つであることを保証するクラス設計のパターンです。）

この説明だけでも、勘のよい人は Java の enum が非常に有用なものだと直感していただけると思います。

Effective Java では固定数の定数が必要な場合には、常に enum を使用すべきだと断言されています。

業務プログラムでよくある「～区分」というデータなどは、まさに enum を使用すべき場面なのではないかと思います。

以下では、本の中で挙げられている、具体的な使いどころを紹介します。
もちろん、詳しくは書籍を読んで下さい。

基本の使い方

public enum Sex {
  MALE, FEMALE
}

これで Sex クラスはインスタンスが MALE と FEMALE の2つしか存在しないクラスであることが保証されます。

Sex クラス型の変数に MALE と FEMALE 以外の値を入れることはできませんし、MALE を表す場合は常に同じインスタンスなので == で等価比較を行うことができます。

また、以下のようにすると、内部的に値を持たせることも可能ですし、インスタンスを適切に文字列化することやその逆も可能です。

public enum Sex {
  MALE("M", "MALE"), FEMALE("F", "FEMALE");

  private final String shortName;

  private final String longName;

  Sex(String shortName, String longName) {

    this.shortName = shortName;

    this.longName = longName;

  }

  @Override

  public String toString() {

    return longName;

  }

  private static final Map stringToEnum

    = new HashMap();

  static {

    for (Sex e : values()) {

      stringToEnum.put(e.shortName, e);

    }

  }

  public static Sex fromString(String shortName) {

    return stringToEnum.get(shortName);

  }

}

このように、Enum は完全なクラスなので、インスタンスフィールドを持たせることも、コンストラクタや static メソッド、インスタンスメソッドを定義することも可能です。

ただし、Enum は不変であるべきですので、インスタンスフィールドは final とするべきです。
コンストラクタは、Enum のクラス定義以外では呼び出せません。
(上記の例では Enum の定数定義を括弧付きで記述しているところでコンストラクタが呼び出されています。)

利用先(クライアント)のコードを再コンパイルすることなく、enum に定数を追加することも、定数の順序を変更することも可能です。これは int の定数で表す場合と比べて大きな利点です。

ビットフィールドの代替(EnumSet)

1つの変数で複数のフラグ等の状態を表したいときに、ビットフィールドと呼ばれる方法を利用することがあると思います。

// 古いコードの例
public class FlagSampleOld {
  public static final int FLAG_A = 1;
  public static final int FLAG_B = 2;
  public static final int FLAG_C = 4;
  public static final int FLAG_D = 8;

  private int state = 0;

  public void turnOn(int flag) {

    state |= flag;

  }

  public void turnOff(int flag) {

    state &= ~flag;

  }

  public boolean isOn(int flag) {

    return (state & flag) != 0;

  }

}

FlagSample flag = new FlagSample();

// A と B と C のフラグを ON

flag.turnOn(FLAG_A | FLAG_B | FLAG_C);

// A と C のフラグを OFF

flag.turnOff(FLAG_A | FLAG_C);

// A のフラグが立っているか

flag.isOn(FLAG_A);

上記のようなコードは、turnOn や turnOff に渡される値を保証できないことや、フラグを文字列化する適切な方法が無いことや、使用可能なフラグを列挙することなどができません。渡される値を保証できないことは予期しないバグの元になりますし、文字列化できないことはデバッグの時の解析を難しくします。

Enum と EnumSet というものを使用すると、こういった問題を解決できます。

public enum FlagEnum {
  A, B, C, D
}

Set flag = EnumSet.noneOf(FlagEnum.class);

// A と B と C のフラグを ON

flag.addAll(EnumSet.of(FlagEnum.A, FlagEnum.B, FlagEnum.C));

// フラグの状態を文字列化

flag.toString() // => [A, B, C]

// A と C のフラグを OFF

flag.removeAll(EnumSet.of(FlagEnum.A, FlagEnum.B));

// フラグの状態を文字列化

flag.toString() // => [C]

// A のフラグが立っているか

flag.contains(FlagEnum.A)

標準的な Java の Set のインターフェースのままで記述しているので、少し記述量が増えていますが、これで型安全なビットフィールドを表現することが可能です。

パフォーマンスについても、Enum定数の個数が64個以下の場合、EnumSet は内部の状態を long で表現するため、ビットフィールドのパフォーマンスと比べても遜色ないそうです。

振る舞いを持つ定数

すでに、メソッドの追加を行っているので Enum に振る舞いを持たせることができるのは分かると思いますが、それぞれの Enum 定数でメソッドをオーバーライドすることも可能です。

本の中に書いてある具体例を挙げます。

public enum Operation {
  PLUS("+") {
    double apply(double x, double y) { return x + y; }
  },
  MINUS("-") {
    double apply(double x, double y) { return x - y; }
  },
  TIMES("*") {
    double apply(double x, double y) { return x * y; }
  },
  DIVIDE("/") {
    double apply(double x, double y) { return x / y; }
  };
  private final String symbol;
  Operation(String symbol) {
    this.symbol = symbol;
  }
  @Override
  public String toString() {
    return symbol;
  }
  abstract double apply(double x, double y);
}

この定数ごとに振る舞いを持たせる Enum は、内部で使用するロジック(アルゴリズム)を切り替えることができる、ストラテジパターンというデザインパターンに利用することができます。

シングルトンパターン

これは、最初に挙げた enum の項目ではなく、下記の項目で説明されています。

• 項目3 private のコンストラクタか enum 型でシングルトン特性を強制する

シングルトンとは、そのクラスのインスタンスが1つしかないことを保証するクラス設計のパターンですが、Java 1.4 までは、private なコンストラクタを用意して実装するのが一般的でした。

Java 1.5 以降では、シングルトンは下記のように、Enum を使用して実装するのがベストです。

public enum SingletonSample {
  INSTANCE;

  public void xxx() { ... }

}

終わりに

Java の Enum は、他の言語での同様の概念から想像していた以上に便利だと思います。

この本で、その便利さを知ってから、業務のプログラムでもいくつか Enum を使用するように置き換えました。

初心者～中級者でありがちなのは、新しい概念を勉強すると、使い方をよく分からないうちに何でもそれを使おうとするので、結果的に使わない方がよいものまで使ってしまって困ったことになる、というのがありますが、Enum についてはどんどん使ってみてもよいのではないでしょうか？

（もちろんプロジェクトの他のメンバーも Enum を理解していることが前提になりますが。。。）

これからも、勉強会で出てきた話題の中から役立ちそうなものを紹介していきたいと思います。お楽しみに。

―― 若手やこれから入社してくる人に向けて、NDiSに欲しいと思う人材像を教えてください。

弊社社長向阪(以下略 K)： ほしいと思う人材・・・もちろん今もおるんやけど自分で考えて動ける人間かな。

―― さきほどのお話から一貫してらっしゃいますね。

K：自分から質問するときでも、わかってるひとに聞くくらいやから自分に正解なんてもってないと思うんやけど、「自分はこう思うんやけどどうですか」と言える人間。

―― 提案してくる人間ですね。その点ではよくない意味で思い当たる節があったりもします。代替案を言わずに「この件は難しいですね」、という話をしてしまって、難しいのはわかったんだけどどうすんだよということになったことが・・・。

K：別にアイデアがなかったらこういうこと考えたんですけど全然いいアイデアうかばないんですわ、というのでもええのやけどね。

―― そうですね、何か一言がないと・・・いきなり無理ですといってしまってはだめですよね。

K：おまえどないしたんや、となるわな（笑）

* NDiSの社長になるとわかったときの気持ち

―― NDiSの社長になるとわかったときどう思いましたか？というかNDiSってどこやねんという感じだったのでしょうか？

K：言われたときは正直びっくりした。

―― やっぱりそうですよね（笑）

K：元々積水化学のある工場の工場長で、春から晴れてNDiSにきたんやけど、NDiSにくるってことを言われたんが2/3やってん。1ヶ月前やったから、そりゃびっくりしたよ。え、どこです？って（笑）

―― じゃあやっぱりNDiSのことはご存知なかったんですか？

K：いや知ってたよ。そらシステムも工場に関係するからそれは知ってるよ。NDiSのメンバーも化学ソリューションのメンバーは来て知ってる人間もおったけどこっちきて顔と名前あうのは７～８人やな。けど楽しいよ、楽しい言うたら怒られるかもしれんけど。

―― どのへんですか？

K：いや、まさかこの年になって言葉を一生懸命覚えることになるとは思えへんかった。

―― なるほど

K：スクラッチやSaaSやASPやなんだかんだって。新鮮やね、それとやっぱり生産系の工場にいるメンバーとシステム系におる皆さんのメンバーとやっぱり違うやん、タイプが。

―― 確かにそうかもしれません（笑）

K：まだ名前がなかなか覚えれんからそこはつらいなぁと。

―― 覚えてもらおうとでてくる若手が少ないのかもしれませんね。

K：いやまぁこっちからいかなあかんねんけど、そやからこないだいくつか部内会議にいかせてもらったりとかしたんやけどそれでもまぁ二人ぐらい覚えたらええとこやね。ただやっぱそうしていかへんとすすまへんし。社員の写真もって歩いてるよ。

* 上司に言われて落ち込んだこととそのときの立ち直り方

―― 若手のころ、上司に言われて落ち込んだ時はありますか。そんなときどんな方法で発散したり、立ち直ったりしましたか。

K：こっちが間違っていたら他のところで見返すようなことをやった、仕事上。確かにここは間違ってたけど、あんたの言うてることはここがちゃうよと、性格的に悪いんかな（笑）

―― 他人に愚痴るとかいうのではなくてということでしょうか。

K：いやまあ、酒飲んで愚痴りまくっとったよ。

―― なるほど、それで次の行動を起こすと。気分の立ち直りは早いほうだったんですか？わりと後々までひくということもなく、飲んでも次の日はみたいな感じでしたか？

K：基本的にはそうなんやけど、ものによってはずっとひいてるのもあるけどね。

―― あー、そうなんですか。

K：言われた中身というよりは、やっぱりその人との人間関係やな。ドッカーンと言われても関係によっては後にひかなかったりもするし。
　確かに現場でも言われたことあるよ、一回。信頼しとった人に言われて、確かにそのときは落ち込んだけど、その人にも別のところで「あんたここちゃうで」ということをやったんや。仕返しとかではなくて、やっぱり自分の存在っていうのを見せたいやん。そういうのは後にはひいてはないけど、やっぱりネチネチっとやられてんのはなんとなくメンタル的に、、、やっぱりその人との関係やろうね。まぁいろいろありましたわ（笑）

―― NDiSの人はあんまりガーッって言わないですけどね。

K：まぁどっちか言うたら言い方はみんなやさしいよね。

―― そうですよね、気を遣っていただいてるのかわかんないですけど

K：まぁまぁ、だけど強く言うていいか場面かどうかもあるやろうし。こっちきてからきつい言い方したことは何回もあるよ。会議で何回も！じゃなくて何回か、かな（笑）

* インタビューする立場だったら誰にどんなことを聞いてみたいか

―― 向阪さんがインタビューする立場だったとしたら、誰にどんなことをインタビューしてみたいですか？
今後のインタビューの参考にとかいうことも考えています。誰って言うのが抽象的でもいいんでしょうけど、例えば若手にとか管理職にとか・・・。

K：若手にあなたのキャリアプランはなんですかって聞きたいな！

―― 普通に業務的になってしまいそうです（笑）

K：そやなぁ(笑）難しいなぁ、誰にどんな質問をしたいか・・・。

―― 向阪さん自身が知りたいことではなくても、次はおまえらあーいう感じの人にこういうこと聞いてこいよっていうのもあれば・・・。

K：すぐには思いつかんけど、例えば若手の技術屋さんに、まぁさっきいうたことに近いんやけどね、「あなた他に比べて一番勝ってるのは何や」と。
　強みっていうとなんかこう漠然としてるから、自分が一番自信をもって他には負けていないことはなんなんや、と。強みっていうとなんか広い意味になってしまうんよね。何が自信あるんやいうのは独りよがりでいいんよ、別に他のを全部分析したとかでなくていいんよ。それはもう自分が思っていることでいいと思う。
　ただ会社としての強みっていうのは…なんかNDiS見とったら独りよがりなところがあるんよ。ここが強いですいうけど、ほんならあんたどこの市場で考えてるのん、と。それは競合ってどこにおるの、と。（それに対して）どこが勝ってんのと聞いたらあんまり答えがでてこないんやね。だから独りよがり、思い込みなんよ。もっと広いところで戦おうとしたら強みって強みにみえるんやけど、ものすごく漠然としてるんやね、どんどんどんどん絞っていったら見えてくるやん、相手とか得意点が。
　シフト君なんかでも強いのは、特殊なややこしい看護士のスケジュール管理とかそういうところで強みがでてくるわけで…ただシフト管理だけだと強みって目立たないよね。そこで狙いを絞ったところが上手く成功してる理由だと思うねんけど。
　まあ、個人に対してはそんな難しい話ではなくて、「他の人に何勝てるんや」というレベルの話が聞きたい。「いやいや体力ですわ」とかね。

―― 思い込みですすんじゃう人もいますからね、ずっと。

K：そこはそれでもいいと思うよ。まぁずっとそれで一生いかれたら困るけどな（笑）

―― 確かに(笑）それでどんどん成長していってくれればいいんですけどね。

K：やっぱり自分をどう意識するかやろうね。無難に仕事をしようと思ったら僕ものすごい得意やからね。

―― （笑）

K：No2なんてめちゃめちゃ得意なんよ。上からいわれた仕事、あんまりやりたくない仕事を適当に手抜いてやってるように見せるなんてものすごい得意なんよ。(笑)そんなんわかってるだけに嫌なんよ。別にそれを否定するわけではないけどね、そういうのも大事やから。
　おもしろないのはやれへんけどね、やっぱり自分の意識ってあるやんか。もちろん組織の人間やからそんなめちゃ逆らったことはできないけど、やっぱり自分のやり方とか思いとか自信とかがあるやん。それと自信の反対というか不得意やと思ってるとこってあるやん。やっぱりそういうとこってかなり意識しながら仕事してると思うんよ、そういうことを意識するのは大事やな、と思うね。こんな偉そうなこと言うとったらこの先「おまえはちゃんとやってんのか」って言われそうやな。

―― とんでもないです（笑）以上でインタビューは終わりとなります。長い時間ありがとうございました。

―― 一番やりがいを感じる仕事、作業は何でしょうか？

弊社社長向阪(以下略 K): 若い頃、学生のときは化学工学を勉強していた。勉強したことを活かせるところがいいと思って、積水化学に就職した。
　積水化学といったら、技術を使い、設備を導入して使う側、ユーザね。実際にプラントを作って、それを輸出するとか、作るのはメーカー。私はユーザへ行きたかった。
　自分が設計した設備が目の前で動いて、すぐ実績が出る。いい悪いがすぐでる。そういうのがやりたくて入ったら、たまたまそういう仕事をさしてもらって…自分の設計したやつが、思うとおりに動いたときは、めちゃめちゃうれしい。

―― 立場が上になってくると、抽象度の高い仕事、上流工程とか、直接結果が見えないような仕事が増えてくると思うんですが、そこならではのやりがいというのはあるんでしょうか？

K: １０年ぐらい前から、何がおもしろいかって言ったら、結果じゃなくて、メンバーの人たちが、今でいうとあなたたちが、やりがいを感じてくれたときが、一番うれしいですね。
　今の僕の仕事って自分がなんか手を出して、なんかしらの成果物を作るというものじゃない。工場長のときから、みなさんがやりがいを持って仕事してくれってずっと言い続けてたんやけど、誰かが『やったー！できました！！』って言ってたら、そんときはやっぱうれしいな。それが今の僕のやりがいかもしれへんね。

* 管理職、またはリーダの最大の苦労

―― 管理職、またはリーダの最大の苦労とはどんなものでしょうか？

K: 自分で全部できないこと。

―― もどかしくなるってことですか？

K: というときもあった。工場で働いてたとき、上の立場になっても、作業をやりたくてしかたないんやね。でもあんまりやりすぎると、下も育てへんから、仕方なくやってもらう。やってもらって出来栄え見たら、自分でやった方がええのできるわって思うんやけど、そらぁ、経験が違ったら、出来栄えも違うわな。

―― まさに今、それを感じます…
上の人たちがやったらさっと終わるのに。僕らがやったら遅いし、出来も悪い。

K: でもおんなじ人がおんなじやり方でやってたら、組織が成長せんからなぁ。
同じやり方でやらんとあかん作業ももちろんあるやけど、全部を引き継ぐ必要はないな。

―― 部下の育成方法とか、気をつけていることとか、どうしようかなとか学んだこととか、ありますか？

K: 部長ぐらいの立場から、そういうことで悩んでてたわ。例えば工場で現場まわって、いろんな人と話をする。そのとき、不満を言ってくる人もおれば、仕事の話をする人もいて、色々言われたり言ったりするけど、全てを覚えてない。それから手帳をもつようにした。自分が言ったことを書くようにした。でも絶対無理ってすぐわかった。全部なんて書ききれんし、時間的にも無理やわな。
　で、何をしたかって言ったら、『自分の判断の軸をずらさない』、それしかないなとわかってきた。これが一番大事。そうすると、だいたい前に言ったことに近い、正反対な話はしないってことに気がついた。今できてるかはわからないが、上の立場になったらそういうことが大事やな。

―― まさに私達もそうですが、上の人に報告したときに、前と全然違うことを言われることがあるんです。前打ち合わせしたときは、それはやらんでいいって言ってたのに、後で報告にいったりすると、あれはまだ出来てないんかとか…

K: 違うことは絶対あるんよ。

―― それは仕方ないですよね。

K: この立場になって思うけど、そんなん全部覚えてるなんて無理。

―― ささいなことが違ってもいいけど、本質的なところが違ってなければ…てことですねぇ。他にもありますか？

K: １０年ぐらい前…４５ぐらいのときに、悩んでたことがあった。僕が上の立場になって、僕らと世代が違う人達と仕事をするようになったとき、なんかマニュアル人間みたいな人らばっかりやねんな。課長とかの立場のときで、例えば、部下らがデータとって、なんかのグラフを書いてきたとする。僕が「こうゆう絵書いてきた方がわかりやすいんちゃう」って言ったら、絶対後でその通り書いてきおんねん。今でもそうやけど、「こんな考え方でけへんか？」って言ったら、必ずそういう見方されるから、「例えばやで。例えばこうゆうときにこうゆうアプローチするとかあるやん、例えばやで！」と、考えが固定されへんように意識して言ってる。
　さっきと同じ話で、同じ人間作ってもしゃーない。上が言うことに従いつつ、さらにいいものをどう作ったらええか考える、そういうのは僕ら世代は得意やった。絶対こうしろっていう指示はあるよ。それはもちろん守らんとあかんけど、でもそういうのは割とすくないやん。

―― 若手は気をつけないといけないですよね。気をつけるというより、たぶん何やりゃいいかさっぱりわかんない状態で、そういう風にいわれるともうそれ以外思いつかない状態になるんでしょうけど。

K: 上から言われた実験をやってるときも、僕らの時代はただ作業としてやるんじゃなくて『これは違うなぁ、こっちの方がいいと思うんやけどなぁ。』って考えたりしてたよ。だからさっさと言われた実験は終わらせて、自分の考えたのを試したりしてた。言われたとこはやらんなあかんと思うけど、こうしたらええんちゃうかなぁと思ったら、絶対試してみたいんよ。ほんだらやらなあかんことは、さっさと終わらせたいからものすごいはよできる。生産性めっちゃあがるで。
　それで、「言われたことはやりましたが、実はこんなこともやってみたんです。こんな成果もでます。こっちの方がよくないですか？」って上司に言うんや。やってみた事実、結果がなったら、「こういう方がいいんじゃないですか？」と仮説を言ったって、経験ある上司が言ってきた実験やから、だいたい下の者が間違ってること多い。こういうのあるんですけどって考えたなら、やってみて結果だして、成果をみせんとしゃーない。もちろん人によるけど、そういう人たちが減ってきた気がするなぁ。

* キャリアプラン

―― 新人のころに思い描いていたキャリアプランどおりでしょうか？また、思い描いていた自分になれていますか？

K: さっき言ったように、実際ものが目の前でできるのが好きやったから、工場希望やって、積水時代はずっと工場やってん。積水化学技術屋で６０人ぐらい同期おったけど、ずっと工場でしか勤務していないのは私だけ。

―― それは異動の願いがきても断ったんですか？

K: そんなんできません（笑）たまたま。NDiSにくるまでずっと工場で働いて、その中で立場がかわっていって、一番下から一番上まで経験さしてもうた。
　本題に戻ると、キャリアプランは本格的には思い描いていません（笑）だけどやりかったのは、ものづくり。ちゃんとは思い描いていないけど、やっぱり上の立場になりたいとかはあった。立場が上になったら、自分がやりたい、できる範囲っていうのが広がる。入った頃から上の人たちを見とってそう思ったから、上の立場になりたいとは思っていた。

―― 何十年後とかまで思い描いていましたか？

K: （首を横に振る）

―― そんな先のことをちゃんと描いても、状況もかわるでしょうし。この質問っていかにも就職雑誌に書いてあるような質問で、普通はそういう風には考えないもんですよねぇ。
　でも最近私達は期末の面談の度に聞かれますよ。５年後１０年後のキャリアプランどうするのとか。

K: こんな仕事がしたいとか、こういうことやりたいからあの部署行きたいとかは思ってたよ。

（続く）

タイトルは、【1人対6万人の戦い】です。
それでは、Vol.5の始まり～始まり～。

お客様先で、お客様のニーズに合わせてデモをする。
躊躇こそなくなったものの、
これだけで既にお腹一杯のコマタです。

目の前にはたくさんの人、人、人。
誰かと来ていたら、ほんの一瞬目を離したら見失ってしまいそうです。

今日は、コマタが販売している、快決！シフト君の展示会です。

実は、配属されてからコマタに与えられた試練は、
客先でのデモではなく、ある大きな展示会への参加でした。

東京ビックサイト。

このひろ～い会場に、医療関係のあらゆる器具・システムが
集まっています。
3日間に渡って行われるこの展示会では、全国各地から医療関係
のお客様が何万人と来場します。

その膨大な数のシステムの中の1つに、快決！シフト君のブースがあり、
カタログの配布や、製品のデモをしながら、
たくさんのお客様にシステムの良さをアピールする
それはそれは絶好の機会なのです！！

ただ、お客様先でのデモと違い、今回の相手は、
シフト君のみに興味があって来場する訳ではありません。
「シフト君の話を聞いてみたい！」と要望されておらず、
限られた時間の中、何百とあるシステムの中から、
いかにしてシフト君に興味を持ってもらえるかが勝負です。

シフト君のデモは、少しずつ出来るようになってきています。
アピールポイントをおさえて、短時間で「これすごいね。」
と思ってもらえるよう、プレゼンテーションの練習もしました。
私のデモデビュー。いざ、本番です。

私の経験は、まだとても経験とはといえないほど浅く、
社会人としての経験でさえほぼ皆無の状態です。

しかし、お客様から見れば、そんな私も「会社の一員」です。
私が放つ言葉は、会社の顔としての責任もあります。
自分の勝手な認識で情報を伝えてしまえば、
それが後で大きなトラブルとなることも有り得ます。

とはいえ、ビクビクしながらデモの対応をしても、
頼りなく、あまりいい印象とは言えません。

経験を積むことが一番の近道ですが、
積むためには、まず動き出すことからです。

動き出すための気合は、お弁当の効果もあって十分です。
どうなるコマタの展示会デビュー？！

結果は次回をお楽しみに。

そこで、NDiS Techでは実際にベテランにそのような質問をぶつけてみることにしました。
どうせお話を伺うならトップが良いだろう、と今回は弊社社長へのインタビューです。
まずはウォームアップとして本の思い出話から。

―― ではまず、今いきなりというのは難しいかもしれないんですけども、年代別に感銘を受けた本というのを。

弊社社長向阪(以下略 K):もう覚えてる範囲でいいでしょ？(笑) どんな本読んだか？んーとね、若いころ…２０代？高校のときはほとんど本読んでなかってん。大学になってから一部読みだして、社会人になってからのほうがよく読んだと思うけど、最初のころはね、普通の文学書。まあ、簡単にいうたら北杜夫とかね、五木寛之とか、大江健三郎やとか、あるいは安部公房とか。

―― 砂の女とか？

K: 砂の女とか。結構面白いんねん。そういう本を読んでた。それと、今でもあるNEWTONがあるね。あれがちょうど創刊されたときで、35年くらい前かな、あれも結構古いんや。竹内均さんの。これ読みたいなと思ってあれは定期購読。そういう時代があって、それから推理小説、海外のアガサ・クリスティとかにハマって。そっからはもう適当やね。ここ20年ぐらいは、だいたい新書が多くなってきた。で、あんまりその、それでなにかを得たいとかは思ってない。もうずっと買ってるもんはただ題名見て買ってる。

―― ああ、新書の棚で『さおだけ屋はなぜ潰れない』を見かけて、とか？

K: そうそう、その本はベストセラーになる前に買って読んどった。面白いなと思って。

―― 社長は理系、ということでよろしいですか？

K: そうそう。化学工学といって、化学と機械の中間みたいな、プラントとかコンビナートとか蒸留とか濾過とか、そういうような…。

―― ニュートンとかはその流れですよね。

K: そうそう。あと理系ということで「生物と無生物とのあいだ」というのが面白かったから、結構理科系の本よ。でも文章力あるし面白い。その一個前が…。(さまざまな話題に華が咲きましたが残念ながら割愛)

K: …けど、もうあんまり小説とか読まなくなった。マニュアル本は読みたくないしね。

―― よく経営者の方で歴史ものにハマるケースが多いようですが…。

K: 昔ははまったよ。陳舜臣とか三国志とか…。そういう時期もあった。なんかをずーっと読み続けることはなくて、そのときの気分で。ひとつそういうジャンルを読みだすと面白いからそればっかり結構読みますやん。ところがそのうちに飽きてきて、一時ハードボイルドもの読んだり…だからあんまりそんなに歴史ものには詳しくない。

* 身に付けておくべきスキル

―― 若いうちに身に付けておくべきスキルはどのようなものでしょうか？お前らこんなのつけとけよという…まあ技術的なものはそれぞれやらないといけないと思うんですけど。

K: 技術的なことも技術的以外のことも含めて、自分が「これは勝てる」というものを。

―― 強み、みたいなものですか。

K: うん。それはべつに「長時間仕事ができる」でもかまわん。ずっと集中できる時間が長いとか。あるいは「こういう言語のこういうところは絶対に強い」とか、自分の作ったプログラムはあとで誰が見ても絶対にわかりやすいんやとか。そういうものを持つべきやな、と。で、金太郎飴はだめなんですよ私。要らない。どう切ってもいっしょっていう人間なんて組織におってもしゃあないから。だから個性は必要やろうなと思うし、それはやっぱり若いうちでないと。歳いってくるとだんだんだんだん、収束してくるからね(笑)
　で、全部（のスキルを）真ん中にする必要はない。自分の劣ってるところとか、他人に対してできてないところって誰でもあるやん。たとえばプレゼン能力がものすごく悪い、と。仮にね。でもそれだけを上げることを一生懸命やったとして、その代わりなんかの強いところが下がってもしゃあないし。ただあんまりにもそれが悪かったら、自分の仕事とか人生が、やりにくい。自分が損するから、そこの部分はある程度上げようという、そういう話はみんなにしてるけど。まあ、そんなことは、若いうちはまあいいやと。

―― 底上げはまあ底上げとして…

K: だから、５点満点で言ったら全部３点にする必要はないと。ただ1点のやつは、せめて２点にしないと自分困るやろと。そんなことは若いうちはいいから…まあ2点ぐらいにはやらないといけないだろうけど…まずは4.5のやつを、5にするとか。自分が自信持てるやつを絶対に作る。

―― はい。

K: で、その若い頃を思い出して一番歳取ったなあと感じたのは、僕一応技術屋やったから、プラントのシーケンス制御をやってて。プラントの順番に反応機があってそこに原料仕込んでバルブが開いて…シーケンス制御ってわかるよな？

―― あんまりわからないです…。

K: あの、順番にここのバルブ開きますこここうやります次撹拌器に回ります、と設計していく仕事なんだけど、ある程度中の反応の技術もわからないといけないし、インターロックつけなかあかんわけね。あるプラントの制御を考えようと思ったら、じーっと頭の中で考えないとあかんわけ、まだモノができる前なんだから「次はこうやってこうやって…」と。
　それが、二十代は30分続けて真剣に考える。それだけじゃ絶対完成しないから5分休憩してまた30分考える。ところが三十代後半になったら、10分考えたら5分休憩せなあかんのね。頭の回転が続かない。やる気はまんまんよ。でも続かないんよ。そうすると…生産性って多分…どのくらいになるやろな。多分半分以下よりもっと悪い。それが嫌になってくる。だから若いときには集中したらそれだけのことができる。年を取ってくると確かに物理的な体力も落ちるし記憶力が落ちてくるのもあるんだけど、それより真剣に集中して考える時間がなくなるようになる。

―― 集中できる若いうちに強み、個性を磨いておけ、ということですね。では、向阪さん自身が、若いときに「これだけは負けない」と自慢できるような個性的なスキルにはどのようなものがありましたか？

K: おー、…ちょっと待って（笑）そういわれると難しいね…。僕のやってる技術領域はもともとやる人が少なかったんだ。だから、制御システムもある程度わかります、現場作業もわかります、化学的なことも機械的なこともわかります、それがトータルでわからないとできないような仕事なんだけど、そういうことが大丈夫、うまくできる、という感じだったね。そういう仕事をずっと19年間ひとつの工場でやってた。もうそこではなんでもできるようになってるわけ。そのころには技術課長ぐらいになってたんだけど、で、移った工場になって今度は中身全然知らない。その時に何ができるようになってきたかというと、人の目を見て「こいつに賭けようか」と。(笑) そういうのがわりと当たるようになってきたなあ。

―― つまり歳を取ってくると「誰に任せればいいか」という目が鍛えられてくるんですね。

K: そう、技術を覚えても立場が変わると役に立たないんだな、と19年目に異動したときにハタと感じた。

* 若いころ行っていた自己研鑽（技術的なことでも、精神的なことでも）

―― では次に、若いころ行っていた自己研鑽を教えてください。

K: 入社して最初の1年目2年目は同期のメンバーや4,5年上のひとも含めて勉強会しようや、といって何回も本を買ったりしてやったり、そういうことをやってたなあ。自己研鑽しようとしてやった感じではあまりやってなかったなあ。

―― 今の若い社員に大して「自分たちのころはあんなことやったのに、なんでやらないんだろう」みたいなことはありませんか？

K: ああ、「あんまり議論しているところを見ないなあ」とは思う。「それおかしいやんなんでこうなんのや」みたいな。例えば自分のときは、技術検討会みたいなのあるわけ。そこで議論もするし終わってからあとでタバコ吸いながらしゃべったり、また酒飲みに行ったらまたその話の続きになったり…とか。別に上下関係も部署も関係なくそういうことをよくやったんだけど、なんか今のみんなは粛々と仕事しているみたいで。やってる仕事を互いにあまり知らないんじゃないかな。同じ部内でもそうだし、ましてや東京・大阪の間など…。まあそのために今はワーキンググループみたいに横断的にやっている活動もあって、あれはいいことだと思うけど、ともかくあまり横断的な議論が多くないなあと思う。

(続く)

タイトルは、【鳴らない！コマタの携帯電話】です。
それでは、Vol.4の始まり～始まり～。

まずは、一人で行って、一人で帰ってくること。

7月中旬。ドキドキの一人デモデビューから、
無事独り立ちを果たしたコマタですが、
まだ、営業としての始めの１歩に過ぎません。

わからないことだらけだった社会人生活も、
がむしゃらに走り回っているうちに、少しずつ流れは理解しはじめている。
そんな気がしていました。
一人で帰ってこれたことに安心したのでしょうか。

さぁ。デモよかかって来い！向かうところ敵なし！
･･･数回終わっただけで、この調子です。

そんな有頂天コマタの隣のデスクで、
普段は外を飛び回っている先輩が、珍しく社内で仕事中です。
1日中鳴りっぱなしの携帯で、忙しそうに話をしています。

「はい。Nです。あ～どもども！！お世話になっております～･･･」
親しげな口調から察するに、相手はおそらく販売店様です。

配属時、営業には不可欠との理由から、
コマタにはピカピカ新品の会社携帯が貸与されました。
目立たない色が良かったのですが、在庫が無かったとのことで、
届いたのは赤い携帯でした。。

手にした赤い色の携帯。色んな意味で重みがありました。
これから、自分がやっていくべきこと。それに不可欠な道具。
「責任持って頑張んなさいよ！」と携帯から聞こえてきそうでした。

そんなことを思い出しながら、
改めて、無造作に机に置いている赤い携帯を見た時、
ふと違和感を感じました。
･･･この携帯と先輩の携帯、何かが違う。
色の違いだけではありません。

そんな折、先輩の電話が終わりました。

「コマタ。デモ依頼があったから行って来い。」

デモ依頼！それは、また一人でデモに行くということ。
突然の言葉に、さっきまでの調子はどこへやら、
以前のデモでの緊張感を思い出し、思わず躊躇。

「えっ？あー･･･。はい･･･。行ってきます･･･。」

っておい！コマタよ。
言ってる事とやってる事が違うのではないか？

そして、更に追い討ちをかけられるかのように、
先輩からアッパーを食らいます。

「デモの依頼電話が俺にかかってくるようじゃあかんな。
コマタが販売店様から信頼されてない証拠だぞ。」

ぐはぁっ。

そうです。先ほど自分の携帯を見たときに感じた違和感は、
これだったのです。

鳴らない、電話。

コソコソと携帯をかまうと、
コマタの携帯の着信履歴は、部署のメンバーのみ。
件数も、10件に満たない数でした。

あぁ、そうか。
信頼は、待っていて得られるものではない。
出来たことに安心するのも必要だと思います。
しかし、そこで立ち止まっている暇はないのです。
常に自分から動き出さなければ。
そう思いました。

まずは、
コマタという人間がここにいるぞ！！
という意思表示をすること。
知ってもらうことから始めよう！

大きな目標に躊躇する前に、
目の前に、自分が出来る範囲で、
前向きな目標を作ることって大切ですね。

考え方を切り替えてからというもの、
不思議とデモに躊躇することはなくなりました。

とは言っても、始めの一歩の始め。まだまだ先は見えません。
新人コマタの奮闘記、ドタバタと続いています。

タイトルは、【独り立ち、カツ(且つ)一期一会。】です。
それでは、Vol.3の始まり～始まり～。

「もう無理です。」
「お前、ここで諦めるのか？」

「でも、もう自信がないんです。」
「まだ始まったばかりだぞ。もうちょっとふんばれよ。」

目の前には、頭がすっぽり入るほどのどんぶりに、
頭がすっぽりはみ出すほどのご飯の盛られた器。
その上には、コマタの顔の2倍ほどの大きさのトンカツが
器を優しく包み込むようにのっています。

現在、半分程度たいらげたものの、
たまらず吐いた弱音に、カツをいれているこの方は･･･

･･･シャレを言っている場合ではありません。

カツを入れているのは、上司ではありません。
快決！シフト君の拡販にご協力頂いている、販売店のWさんです。

先日のデモデビューが終了するということは、
私の部署では「営業としての独り立ち」を意味します。
新人として配属されてわずか2ヶ月での独り立ちは、不安で一杯でした。

そんな中で私の支えとなったのが、
担当エリアとなった東北地方での数々一期一会でした。

今回は、その一例です。

シフト君の販促活動は、NDiSの営業メンバーのみが
行っているものではありません。
シフト君をお客様に紹介して下さる販売店の方を中心とした
営業体制をとっています。

冒頭でカツを入れて下さったWさんとの出会いは、
岩手県にシフト君のデモ同行をした時のことでした。
生まれて初めての東北新幹線。
緑色の新幹線に揺られること2時間半。

東北への移動は、時間がかかるため、
一件のデモの為に一日を費やすこともあります。
ですが通常は、販売店様に何件かデモ希望を
集めて頂き、同じ日に2件、3件とデモをさせてもらっています。

今日は午前と午後に1件ずつデモがあったため、
こうして空いた時間にお昼ご飯を食べているという訳です。

お腹はカツで一杯ですが、ご飯を食べながら、
次のお客様をどう攻略するかを話し合うのは面白いです。
こんな観点で話をしてみてはどうか？
もし、お客様がこんなことを言われたら、どう答えるのか？
何だか、「営業してる！」って感じです。

もちろんそれだけではありません。
恋の話、お酒の話。などなど、

ベテランWさんの様々な営業経験から、学ぶことはたくさんあります。
「なるほど！」と思ったことを忘れないために、
コマタは必死でメモを取ります。

これが、いつか「コマタ流」営業活動に役立つように。

今回の同行を含め、コマタが経験したデモ同行はわずか数回。
その数回でも、学ぶことはたくさんありました。

しかし、その「たくさん」は、先輩や上司からとってみれば、
わずか数パーセントにすぎません。
その数パーセントの範囲で、「仕事をこなしているんだ！」と酔いしれていたコマタは、
早くに独り立ちを迎えたことは「認められた証拠」なんだと考えていました。

この後、それが大きな勘違いだったことを
コマタは身をもって経験するのですが、

･･･今日はここまでで時間切れです。

「Effective Java 第2版」は Java を仕事に使うプログラマなら、是非読んでおきたい書籍です。

とは言っても、日々の業務で忙しかったりすると、なかなか新しい本を1冊読むことは難しく、私もこの本の初版は新人時代に読みましたが、第2版は読んでいませんでした。

第2版は初版にはない、Java5 以降に追加されたジェネリックスや列挙型についての情報が充実しています。
ジェネリックスを使うとなぜかコンパイルエラーや警告が発生して困る、という人はこの本を読むと解決策が分かると思います。

• 項目23 新たなコードで原型を使用しない
• 項目24 無検査警告を取り除く
• 項目25 配列よりリストを選ぶ
• 項目26 ジェネリック型を使用する
• 項目27 ジェネリックメソッドを使用する
• 項目28 APIの柔軟性向上のために境界ワイルドカードを使用する
• 項目29 型安全な異種コンテナーを検討する

今回は、この本を読んで気付いたジェネリックスをうまく扱うためのポイントを何点か紹介したいと思います。
詳細については書籍を読んで下さい。

ジェネリックスとは

まずジェネリックスとはどういうものでしょうか。

例えば、java.util.List や java.util.ArrayList といったコンテナ型を使用する場合、Java 1.4 以前であれば

List list = new ArrayList();
list.add("one");
list.add("two");
// ...
String one = (String) list.get(0);

というように、取り出すときに格納されている要素の型に応じて、String型であれば String にキャストしなければいけませんでした。

これをジェネリックスを使用するとこう書けます。

List<String> list = new ArrayList<String>();
list.add("one");
list.add("two");
// ...
String one = list.get(0);

最初の変数 list の宣言と、ArrayList インスタンスの生成時に指定している <String> の部分がジェネリックスの型パラメータです。

これだけ見ると、ジェネリックスは取り出すときにキャストを書かなくていいから便利、くらいにしか思いませんが、裏を返せば取り出すときにキャストを書かなくても、実行時にキャスト例外が発生しないことをコンパイラが保証してくれている、ということです。

ジェネリックスをうまく使うためには、実行時にキャスト例外が発生しないとコンパイラが判断できるための情報をすべてコードに埋め込んであげないといけません。

このことをちゃんと意識することがジェネリックスをうまく利用するためには重要です。

Web開発の現場などでは、Perl や Python、Ruby といったLL(Lightweight Language)などの動的型付言語(変数の型を指定しない言語)が注目されていますが、ジェネリックスは静的型付言語である Java の静的な型チェックをより強力する手法ですので、ある意味 LL とは真逆な方向です。

ソースコードに情報を付加することで、今まで実行するまで分からなかった型チェックによるエラーがコンパイル時に判定できるようになったということです。

ジェネリック型を使わないと警告

Java5 以降では、型パラメータを指定せずに java.util.List などのジェネリック型を使用するとコンパイル時に警告が発生します。

これは、型パラメータを指定しない型(原型といいます)を使用すると、値を取り出すときのキャストがチェックできないので、実行時に例外がでちゃうかもしれないということです。

ジェネリック型と配列との違い

Java 1.4 までであれば、キャストが面倒なので List ではなく配列を使ったということがあったかもしれません。(というか、私はありました。。。)

ジェネリック型とちがい、配列は実行時の型安全性をコンパイラが保証することはできません。

例えば、次のようなコードを見て下さい。

String[] strArray = {"one", "two"};
Object[] objArray = strArray;
objArray[0] = Integer.valueOf(1); // 実行時例外: ArrayStoreException

上記のコードはコンパイルが通りますが、実行時に例外が発生します。

これがコンパイルを通るのは、String[] が Object[] のサブタイプであるためです。この性質を共変(covariant)と言います。

一方、ジェネリック型は共変ではなく不変(invariant)です。List<String> は List<Object> のサブタイプではありません。
List<Object> の変数に List<String> の変数を代入しようとするとコンパイルエラーになります。

List<String> strList = new ArrayList<String>();
List<Object> objList = strList; // コンパイルエラー: 互換性のない型

この性質は少し直感に反するように思うかもしれませんが、この性質により ArrayList<String> のインスタンスが List<Object> の変数に代入されて String 以外の要素を代入されるといった実行時例外を防ぐことができます。

まとめると、キャストが不要な点は配列もジェネリックスも同じですが、ジェネリックスの方がより安全です。

ワイルドカード

List<String> は List<Object> のサブタイプではないということですが、では、要素の型にかかわらず List オブジェクトを受け取るメソッドを定義するときにはどうすればよいのでしょうか？

原型である List を使用すると、コンパイル時に警告が出てしまいますし、List<Object> とするとコンパイルエラーになります。

こういう場合は、型パラメータに ? を使用することができます。? をワイルドカードと呼びます。List<String> や List<Object> は List<?> のサブタイプになります。

void printAll(List<?> list) {
  for (Object o : list) {
    System.out.println(o);
  }
}

上記の printAll メソッドには、List<String> や List<Integer> などを渡すことができます。この List<?> の部分を List<Object> と書いてしまうと、この printAll メソッドには List<Object> 型しか渡せなくなってしまいます。

ワイルドカードには境界型ワイルドカードと非境界型ワイルドカードと呼ばれる2種類のものがあります。上記の例は非境界型ワイルドカードです。境界型ワイルドカードでは要素の型のスーパータイプを指定することができます。

例えば、List<? extends java.util.Date> と宣言した場合、java.util.Date のサブタイプである java.sql.Timestamp などの List を受け取ることができます。

例えば、次のようなメソッド定義が可能です。

void printDateList(List<? extends Date> dateList) {
  for (Date d : dateList) {
    DateFormat format = new SimpleDateFormat("yyyy/MM/dd");
    System.out.println(format.format(d));
  }
}

終わりに

今回紹介したポイントを押さえると Java のジェネリックスをうまく利用できるのではないかと思います。

これからも、勉強会で出てきた話題の中から役立ちそうなものを紹介していきたいと思います。お楽しみに。

本日より「勉強会便り」を開始いたします。
私の所属している部署では若手を中心に週に1回程度定時後に集まって、
技術力の向上を目的とした勉強会を開催しています。

勉強会といっても講師役を決めたり準備をして発表したりというものではなく、
テキストとなる書籍をみんなで決めて、それをみんなで読んでいく、という形式で気楽に行っています。
このカテゴリでは勉強会での話題をピックアップしてお伝えしていきたいと思います。

以上、「勉強会便り」をよろしくお願いいたします。

今回は外回りだけが、営業の仕事ではないということを書きたいと思います。

それでは、Vol.2の始まり～始まり～。

資料をつくるのは、本当に骨が折れます。
見る相手のニーズと、こちらのウリやポイントをまとめ、
相互に共通させながら、「この情報が欲しかった！」「読みたい！」
と思わせるようなインパクトを持たせることが大切です。
それには、文字使い、色使い、そして図の配置などが
複雑に絡み合っています。

パズルを組み立てるイメージで、伝えたいことを画面に表現していく訳ですが、
現時点で、我がグループ直伝、そして自慢のノウハウを注ぎ込んだ
何種類もの資料が存在します。それを目の当たりにし、圧倒されたコマタは、
「現存しているもののイメージを崩してはいけない」
と考えて資料を作成していました。

しかし、目的は「前からあるものを引き伸ばす」ことではありません。
そこに、いかに自分らしさを取り入れ、今あるものを更に良くしていくか、です。

最終的には、「この資料、誰が作ったの？！すごい！」といわせるまでに
成長したいものです。

そんな野望を抱き始めた折、上司からも
「今あるものをそのまま使うことはない。コマタらしくはじけてみろ！」
と助言を頂き、コマタらしさあふれる資料を目指すこととしました。

挿絵の配置を考えるだけでなく、挿絵自体も自分で作成し、
色使いなど、「見たい！」と思ってもらえるよう、力の限りを尽くしました。

そうして出来た、自分らしさ全開の資料。
紙にしてたった２枚の資料ですが、感慨深いものがありました。
ジーンと胸に溢れる達成感を味わい、大満足です。
頑張って作ったし、褒めてもらえるに違いない！
と、うきうきしながら見せた先輩は、まぶしげに資料を眺めています。
してやったり！

しかし、目を細めながら資料を見た先輩の一言は、
別意味で胸にジーンと突き刺さるものでした。

「コマタ。なんだか家電量販店のチラシみたいだぞ。」

やりすぎてしまったのでしょうか。

しかし、コマタはめげません。
外回りの後はデスクに座り、自分らしさいっぱいの資料作成に
手をせかせかと働かせています。

人生初の営業、汗と涙、そしてネタと笑顔の奮闘記を
ついでに過去を振り返りながら書き上げます。

それでは、Vol.1の始まり～始まり～。

以来、快決！シフト君担当のコマタですが、
販促活動以前に、業務の流れも把握せねばなりません。
何もわからない私にとって、
「わかった！」という気持ちが自分を奮い立たせる唯一の材料でした。
今後の自信と、自分づくりのため、当初は呆れるくらいの質問攻めでした。

さらに、シフト君の「単なる製品デモ練習」に緊張し、
社内発表にも関わらず前日はなかなか寝付けない始末。

会社の「顔」として、初めてだろうが何だろうが、
礼儀正しく、分かりやすく、尚且つ受注に繋がるデモを
しなければなりません。

そして、ついにやってきた「初！対お客様デモ。」

初の一人デモデビュー（金曜日）に、月曜日から緊張のコマタでしたが、
金魚のフンのごとく先輩のデモについて回っていたために、
何とかなると気合をためてはいたのですが、
それでも、１人で出張のプレッシャーは容赦なく襲ってきました。

当日は雨。しかし雨も蒸発の勢いで燃えていました。
初が重なると、人は通常より諦めがよくなるみたいです。
現地で販売店の方と待ち合わせし、いざ戦場へ。
そこで待っていたのは。。般若のような形相、、、

とは裏腹に、とても優しいお客様でした。
その雰囲気のおかげで、緊張することなくデモが行えました。

そこはよかったのですが、やはり、一人ではまだまだ頼りないです。。

「たくさんのデモに同行し、先輩を見て勉強した」
と、新人ながらにそう思っていました。
しかしそれは、デモ当日のおろおろぶりを考えると、
「そのつもりだった」のだと苦笑いを隠せません。

しかし、まずは、一人で行って、一人で帰ってくること。
卵の殻がやっとはがれたデモデビューでした。

何かをしようと決めたとき、初めから不安だ嫌だと考えることは得意でした。
しかし、「考えるだけでは何も進まない」と気付いたのは、もう少し後のお話。

快決！シフト君のリンクはこちら

「営業奮闘記」では、新人として営業に配属されたコマタが、
自身の営業活動から生の声をお届けします。ご期待ください。

「営業奮闘記」は今後シリーズ連載として掲載していきます。
お客様と接することで得た知識や経験、社会人の卵としての苦悩や喜びをバネに、
少しずつ成長していくコマタを是非見守って下さい。

新人として泣き、笑い、激走してきた1年間を書き上げます。
お楽しみに！　

以上、「営業奮闘記」をよろしくお願いいたします。

]]> foldl は

    foldl f z [x1,x2,x3,...x_n]
が
    (...(((z `f` x1) `f` x2) `f` x3) `f` ...) `f` x_n

    foldl1 f [x1,x2,x3,...x_n]
が
    (...((x1 `f` x2) `f` x3) `f` ...) `f` x_n

    foldl1 f [x1] = x1
    foldl1 f [] = error "Prelude.foldl1: empty list" -- エラー

maximum xs = foldl1 max xs
minimum xs = foldl1 min xs

    foldr1 f [x1,x2,x3,...x_n]
が
    x1 `f` (x2 `f` (x3 `f` (... `f` x_n)))

次に紹介するのは foldl より年上格の scanl です。
foldl は計算の最終結果だけを返しましたが scanl は計算途中のすべての値をリストにまとめて返します。初期値もこのリストの先頭に入るので要素数 n個のリストに対して scanl が作るリストの要素数は (n+1)個になります。

scanl で (+) を使った例を見てみましょう。

> scanl (+) 0 [1..5]
[0,1,3,6,10,15]     -- [0, 0+1, (0+1)+2, ((0+1)+2)+3, (((0+1)+2)+3)+4, ((((0+1)+2)+3)+4)+5]

> scanl1 (+) [1..5]
[1,3,6,10,15]    -- [1, 1+2, (1+2)+3, ((1+2)+3)+4, (((1+2)+3)+4)+5]

scanl と scanl1 がいるなら scanr と scanr1 もいます。

> scanr (+) 0 [1..5]
[15,14,12,9,5,0]    -- [1+(2+(3+(4+(5+0)))), 2+(3+(4+(5+0))), 3+(4+(5+0)), 4+(5+0), 5+0] 
> scanr1 (+) [1..5]
[15,14,12,9,5]    -- [1+(2+(3+(4+5))), 2+(3+(4+5)), 3+(4+5), 4+5, 5] 

最後に紹介するのは長老格の mapAccumL です。
（mapAccumL と次に紹介する mapAccumR は Preludeモジュールに入っていないので使うときには Data.Listモジュールを import しておく必要があります）
scanl は計算途中の値をリストにまとめましたが mapAccumL は計算していく値とは別の値をリストにまとめることができます。実際に返す値はそのリストと計算の最終結果をタプルにしたものです。
foldl,scanlに比べてインタフェースが複雑なので例を見て確認してみましょう。
初期値 0 に [1..5] を順に加えていきリストとしてまとめるのは計算する値の２倍という例です。

> mapAccumL (\b a -> (b+a,2*b)) 0 [1..5]
(15,[0,2,6,12,20])

> mapAccumR (\b a -> (b+a,2*b)) 0 [1..5]
(15,[28,24,18,10,0])

次回は fold,scan,mapAccum のパワー比較と高階関数の効能について説明します。
]]> tag:www.ndis.co.jp,2009:/blog/tech//1.36 2009-03-17T01:00:00Z 2009-03-17T01:04:52Z