ネタつつき146 - 開発者自身がお客様になる

趣味ではなく商売でしているシステム開発は、お客様の満足度が大事です。しかし実際は、お客様の満足度を、一番に考える事を徹底していない開発者や会社が数多く存在します。売ればいいという考えが根底にあるようで、お客様の事を考えていないと感じる場面に多々遭遇します。お客様を第一に考えるという言葉を知っているのと、実際に理解して実践するのとでは大きな差があります。
例えば、お客様にとって要らない機能を売りつけたり、自分だけの都合で人月単価にて人売りをしたりします。しかしながら、お客様はビジネス上の解決策を望んでいるのであって、意味のないなんだか凄いらしい機能や、解決策ではなく人を売り付けられても満足しません。満足どころか、不快感を覚えるでしょう。
昔から「ドックフードを食べる」と言う言葉があります。この言葉はもちろん、犬が食べる食事のドックフードを、食べると言う意味ではありません。ドックフードと言うのは比喩であり、自分で創ったものを自分で使ってみるという意味です。自分で使ってみれば、自己満足ではなく真実を知るきっかけになります。マイクロソフト社が徹底している事で有名です。
とはいえ、業務系のシステムを販売している者達は、ドックフードを食べただけでは、お客様に満足して頂けるものを作れません。何故ならば、お客様はパソコンの操作すらままならない場合もあるからです。私達開発者の様に、情報機器の使い方に馴れていないので、開発者が良いと思った事が良いとは限らないのです。また、お客様が抱えている問題に対する解決策にはなりません。
真にお客様にとってよいシステムを、知るにはどうすればよいのでしょうか？その答えは自分がお客様になる事です。私がシステム開発で初めにする事は、お客様のビジネスを知る事です。さらにお客様の現場を観察します。私はお客様の職場で働いた事もあります。基礎知識を持ってお客様と共に働けば、お客様が満足する事が分かります。すなわち、お客様を知るために、自分がお客様になるのです。
日本のIT業界は多重下請け構造ですので、常に出来るとは限りませんが、自分がお客様になると言う考え方は非常に有用です。私はこの考えでお客様の信頼を得てきました。お客様から同業者だと思われるに至ったこともあります。自分がお客様になれば、成功は保証されていると言っても過言ではないでしょう。
ただし、この考えは技術力が前提です。技術力が無ければ机上の空論になります。如何なる問題に対しても解決できる、技術力が無ければお話しになりません。その辺を誤解しているから、奇妙な言動をするマネージャクラスの人間が存在するのだと思います。
少し余談になりますが、技術力に関してもどうやら誤解が多いようです。技術力というものは、ただ暗記しているだけではあると言えません。情報技術を体現できなければ、本当の意味で技術力があるとは言えません。私は常日頃、心臓が鼓動するように、呼吸を吸うように、あらゆる情報技術がアウトプットできるように訓練をしています。
生涯学習と訓練を続けて確かな技術力を身につけ、その上でお客様になれればシステム開発で失敗する事はあり得ません。その高みを目指して今日も生きています。それが情報技術のプロと言うものだと私は考えています。

中の人の徒然草421

今日は自民党総裁が決まりました。まるでお祭り騒ぎです。でも、何も改善しないと思います。何故ならば、国家システムが何も変わっておらず、あのような非効率的な事を未だにしているからです。あの時間、どれだけのコストがかかっているのか・・・考えただけで恐ろしい無駄です。
誤解が無いように先に言っておきますが、阿部元総理自身は優れた人だと思っています。あのお方は非常に優れた人物なのでしょう。しかしながら、またマスメディアと周りの政治家によって活躍できないでしょう。というのも、マスメディアは無責任に全てを否定するだけだし、あのシステムを考えると、大多数のあまり優れていない政治家が彼の自由にさせないでしょう。なにせ何をするにも多数決なのですから・・・
日本のマスメディアは何かを否定するだけです。小泉元総理の規制緩和についても、タクシードライバーが困っているから失敗だ。規制緩和で市場競争が起こったから悪党だ。などと、風が吹けば桶屋が儲ける理論を言い放ちます。あれは、労働基準法も守らないブラック会社や、それを見逃す行政が悪いのです。常日頃、天下り団体の確保のために、不必要な規制をしていると報道しておきながら、規制緩和をすれば競争が起こってけしからんというのですから、あきれ返るほかありません。規制緩和をしても駄目、規制をしても駄目、ならばどうすればいいのでしょうか？そういった何をしても駄目理論が目立ちます。中国の機嫌を損ねるな、でも尖閣諸島はやるな、とか無茶もいいところです。最近は橋本維新の会に対する異常なネガティブキャンペーンが目立ちます。何も変えるな、でもいままで通りだと嫌だ、まるで子供が駄々をこねているようです。論理に一貫性がありません。この状態では何もせず目立たない人だけが美味しい状態になります。目立たず議員報酬や既得権益だけ貰っておけば一番おいしいです。
何でも多数決の現システムにも根本的な問題があります。全議員が国内で起こる全ての問題に精通し、全ての音大に対して誠実であるなんて事ありえません。従って、既得権益の確保などのよからぬ事を考えていたり、知らないで反対している人なども抱きこまないとならない羽目になります。そんなご機嫌伺いをしていれば、何も変わらないの当たり前です。決められない政治ではなく、もともと生産性が無いシステムなのです。システムを考えずとして、英雄を待っても無駄です。多数決では英雄が活躍できないのは自明です。
誤解されやすいのですが、私個人は政治家や官僚個人に対しては悪く思っていません。バグがあるシステム上で、その様に振舞う事を運命付けられているので、システムに悪い方向へ誘導されているだけです。ただ有権者としては、バグがあるシステム上で、問題があるままその役割を演じているので支持できないのです。システムのバグを戦後60年以上も直さない政治家と官僚もどうかしていると思いますが、だからと言って個人を攻めても意味はありません。システムにバグがあるので、その様に動作するのが当然の状態なのですからそうなって当たり前です。
システムとして考えたとき、法律を生産する機能、問題を捕捉する機能、正常に国家サービスを提供する機能などが余りに考えられておらず、セキュリティがざる状態ですので、少人数でも悪意がある人が居れば、国民に被害を与える結果になります。政治家と官僚全員が善人と言う事はあり得ないので、こうなる事は当たり前です。
この手のバグを直すには、システム上で働く人が素直に障害を報告するのが最善です。しかし日本人は辺に潔癖症で、無謬性が当たり前となっているので、建前に合わせるために事実を隠蔽するんですよね・・・
例えば虐めが起こったら、それは教育サービスとしての正常な状態ではないから、関係者を処罰して二度と同じ事が起こらないようにすると言って行動するだけで、行政と立法府に対するイメージが上がります。でも実際は、隠蔽して加害者の味方をして、何も対策を練らずに同じ問題を発生させ続けます。だから国民から「虐めによる殺人を正常だと考えているのだな」と受け取られて、まるで犯罪組織であるかのように思われるのです。努力して隠蔽をし続けるならば、その問題の発生源を失くしてしまえばよいと思います。その方が簡単だし、普通の国民を苦しめて、犯罪者天国にする意味も意義もありません。民間では当たり前の発想がなぜできないのか非常に不思議です。
きっと何を言ってもメスメディアでバッシングされるから、情報を隠蔽してしまえとなるのでしょう。かといって、問題の隠蔽に対してマスメディアの人が起こるのも当然です。どっちもどっちです。日本はどうも空気で動かされ、冷静に物事を考えない風潮があるようです。非常に嘆かわしいです。

VBオブジェクト指向プログラミング講座 第8回 アクセス修飾子を上手く使って情報を隠蔽しよう

　この記事は、第7回 プロパティとメソッドの違いを知る の続きです。前回は、プロパティについて解説しました。今回は、情報の隠蔽とアクセス修飾子について解説します。
　オブジェクト指向プログラミングの概念に情報の隠蔽というものがあります。これは、オブジェクトを使用する人は、実装の詳細を知らなくても使用できる事を意味しています。情報の隠蔽の概念はいたるところにあります。TVや電話だって自分で作れないよね？もし情報の隠蔽がなければ、TVや電話を作る知識が無いと使用できない事になります。オブジェクトも同じです。下手なオブジェクトをプログラミングすると、他のプログラマーや未来の自分が困ってしまいます。情報の隠蔽が有用な概念であると分かって頂けると思います。
　しかし、情報の隠蔽を守るプログラミングは、知らなくても出来るというものではありません。正しい知識が無いと、情報の隠蔽がなされていないオブジェクトを実装してしまいます。具体例を挙げます。前回のサンプルは、Messageプロパティを誰からも書きかえられる状態でした。これは情報の隠蔽に反しています。特に理由がない限り、プロパティの値を自由に書き換えられる状態は好ましくありません。何故ならば、プログラム間の結合度が高まってしまうからです。プロパティは極力リードオンリーにしましょう。
　しかし、プロパティのセッターには、チェックロジックを含められるので、非常に便利です。値は誰から読まれてもいい、だけど書き換えられるのはごめんだと言う場合は、アクセス修飾子を上手く使います。

Public Property Message() As String
    Get
        Return Me.m_message
    End Get
    'セッターにアクセス修飾子を指定
    Private Set(value As String)
        If Me.CheckMessage(value) = False Then
            Throw New ArgumentException(
                "1文字以上の文字列を指定して下さい。")
        End If
        Me.m_message = value
    End Set
End Property

以上の様にアクセス修飾子を自由自在に使いこなしましょう。
　ところで、Messageプロパティは必要とされているのでしょうか？一層の事、Messageプロパティを公開しないほうが得策かもしれません。こうした疑問を持つ事が重要です。オブジェクト指向プログラミングの概念に情報の隠蔽がある事からも分かりますが、基本的に公開する要素は最小限にするのが最善です。どうしても必要な要素（プロパティやメソッドなど）だけ公開しましょう。こういった事があるので、オブジェクト指向設計をしっかりしないと駄目なのです。オブジェクト指向プログラミングは、オブジェクト指向設計をしないと真価を発揮しません。続く。

中の人の徒然草420 人間と科学／技術の進化について

知識欲が止まらないインドリです。今日はちょっと、以前日常生活の中で考えた事を書きます。
私は常日頃、情報技術について考えています。情報技術は自然の中にあります。月を見て何かを思いついた事もあります。山や空をふと見たり、風を浴びたりしていると色々な発想が湧きでます。これから述べる事はそのうちの一つです。
人間は五感を拡張する方向で、科学と技術を発展させてきました。これからは、語幹を拡張するだけではなく、新しい感覚を創造する段階にきていると思います。五感だけではこの広大な世界の真理が解明できません。例えば、光よりも速いニュートリノの様なものは、五感で考えてもどうにもならないと思います。人間は五感で物事を考える性質がありますが、人間と言う狭い範囲内でしか発展が望めません。
そこで情報技術の出番です。五感以外のものを考えるとき、情報技術が必要不可欠になります。何故ならば、感覚とは情報の受信以外のなにものでもないからです。ならば、自分が持っている情報を受信する機能に縛られる必然性などありません。どの様な情報を受信して分析したいのか、それを考えて五感以外のものを作り上げればよいのです。いわば感覚の抽象化です。
　感覚の抽象化を実行し、受信した情報は脳で処理するかありません。それは専門分野のコラボレーションとなるでしょう。情報技術でモデル化し、数式で表し、科学で人間の都合がよいようにまとめあげ、倫理を哲学や宗教で考え・・・それら専門家のオーケストラがますます必要となります。この音楽団の発生源は情報技術となるでしょう。人間は全く存在しない情報を作り上げられません。というよりも、対象物を観測した結果でないと意味がありません。
　もうひとつ、社会制度についても情報技術が活躍します。現在政治や行政は情報技術で考えられていません。それ故、無駄や非効率的な出来事が多いのです。政治家は国民の意見を聞いていると言いますが、実際は選挙の時しか民意を反映できません。しかも不完全です。政治家は次の選挙まで国民の意見を聞かなくても報酬が得られます。おまけに、選挙時に嘘をついても支障が無いのですから、民意と政治家の仕事は全く関係がありません。
　行政もまた、官僚の都合により運用されています。国家や国民よりも官僚の利権で動いている事は誰しも知っているでしょう。しかし、日本の国民は自分で考えず、全て誰かがやってくれるものして、お上任せにしているから愚痴る事しか出来ません。その証拠にニュースを見ていると、出演者の「政治家がやってくれない」という愚痴と、「政治家がやってくれ」という願望しか述べていません。そこには、主権者である国民が考えると言う視点がありません。
　誤解されがちですが、私は政治家と官僚を忌避していません。何故ならば、お上任せすればそうなるのは当然だからです。貴方が考えて下さいという言葉は、考える人の利益が先に考えられる事を意味しています。任しているのですから、その人達の都合で動くのは当たり前です。国家システムについて考えた国民が何人いるでしょうか？主権者が考えないのであれば、国家システムが破綻するのは当然です。
　この日本の末期症状と情報技術の関係性は大いにあります。国家システムをどうするのかと言う問題は、情報技術しかないでしょう。国家システム全体を合理的に考えるには、国家を流れる情報をどの様にするのかと等価です。システムの不備があれば、そのう情報が即座つに届けられ、責任者がエラーを直す。経済の正確な情報を把握し、経済を正常化する。そういった事は、正しく情報技術の領分です。
　日本ではなぜか、情報技術者の事を相場師と勘違いしています。おそらく、ライブドア事件がきっかけでしょう。情報技術はそういった胡散臭いものではありません。社会のインフラを支え、社会問題を解決するためのツールです。そういった視点が欠けているから、国家システムの崩壊に対して有効打を打てないのでしょう。
　おもえば日本は正確な情報源を持ちません。マスメディアが歪んでいるのは揺るぎない事実です。しかし、スポンサーがついている以上、そのフィルターを通して情報が発信されるのは当たり前です。先ずは正確な情報源を持つために、日本人は情報機関に投資するべきです。国民の寄付で運営された情報機関が、如何なる情報を発信するのか非常に興味深いです。おそらく、誰もが知りたくなかった、酷い情報が大量に発信されるでしょう。その時、いつものようにお上任せにして現実逃避するのか、自分たちで解決方法を考えるのか、最終的にはそこが問題となります。
　今、尖閣諸島と竹島の問題がクローズアップされていますが、結局国民がどうしたいのか、どんな痛みを受け入れるのかを考えていないと思います。現実を直視する勇気が無いので、日本は崩壊しつつあるのでしょう。政治家が駄目だ、官僚が駄目だ、あれが駄目だと愚痴るのではなく、自分たち国民がどうするのかを考えないと日本は崩壊します。選挙システムが駄目だから何もできないのではなく、お上任せして自分の頭で考えないのが根本的原因です。それを忘れてはなりません。

実践的オブジェクト指向設計入門22

　この記事は、実践的オブジェクト指向設計入門21の続きです。前回は、並列タスクによる制御について解説しました。今回は、制御の実装の次の作業である、継承の調節について解説します。
　オブジェクト指向設計が進んでくると、操作やオブジェクトが複雑化してきます。そこで、継承関係が無いのかチェックします。ある程度の規模のシステムとなると、オブジェクトの数は膨大となります。膨大なオブジェクトは、設計の理解を困難にし、あらゆる作業に悪影響を与えます。従って、継承による設計の簡素化が重要となるのです。
　オブジェクト指向方法論OMTでは、設計を簡素化するために、継承の検討が提唱されていますが、それと同時に 注意もされています。継承はカプセル化の原則を崩します。無理な継承関係は、余計にシステムを複雑化してしまいます。ですから、継承だけではなく、委譲も視野に入れて設計のリファクタリングを行いましょう。
　ただし、継承と言っても実装の継承とインタフェースの継承がある点に注意して下さい。プログラムの量を減らす事だけを考えて設計しても、オブジェクトの構造が複雑化し、余計に実装を困難にします。インタフェースの継承を賢く活用しましょう。

VBオブジェクト指向プログラミング講座 第7回 プロパティとメソッドの違いを知る

　この記事は、第6回 手続き、関数、メソッドの違いを知るの続きです。前回は、操作（メソッド）、関数（ファンクション）、手続き（プロシージャ）の違いについて解説しました。今回は、プロパティとメソッドの違いについて解説します。
　VBの記事らしく、サンプルプログラムを提示した後で解説します。

Imports System
Imports System.Windows
Imports System.Windows.Controls

Public Class MessageWindow
    Inherits Window

    'インスタンスを識別するための定義
    Private Shared ID As Integer

    'Windowのサイズを指定するための定義
    Private Shared random As Random =
        New Random(DateTime.Now.Ticks Mod Integer.MaxValue)

    '使用するメッセージ
    Private m_message As String
    Private Function CheckMessage(ByVal value As String) As Boolean
        If value Is Nothing OrElse value.Length = 0 Then
            Return False
        Else
            Return True
        End If
    End Function
    Public Property Message() As String
        Get
            Return Me.m_message
        End Get
        Set(value As String)
            If Me.CheckMessage(value) = False Then
                Throw New ArgumentException(
                    "1文字以上の文字列を指定して下さい。")
            End If
            Me.m_message = value
        End Set
    End Property

    '各種コントロール
    Dim input As TextBlock
    Dim text As TextBox

    'メッセージを指定してインスタンスを生成する
    Public Sub New(Optional ByVal msg As String = "Hello World")

        'Windowの設定
        Me.Height = random.Next(100, 1000)
        Me.Width = random.Next(100, 1000)
        Me.Message = msg

        'ボタン上のコントロール
        Me.input = New TextBlock()
        Text = New TextBox()
        Dim panel As New StackPanel()
        Dim createBtn As New Button()
        createBtn.Content = "作成"
        Dim endBtn As New Button()
        endBtn.Content = "終了"
        AddHandler endBtn.Click,
            Sub() Application.Current.Shutdown()
        panel.Children.Add(input)
        panel.Children.Add(text)
        panel.Children.Add(createBtn)
        panel.Children.Add(endBtn)

        'ボタン
        Dim btn = New Button()
        btn.Content = panel
        Me.Content = btn
        AddHandler btn.Click, Sub() Me.CreateWindow()

        'その他の処理
        Me.SetMessages()
        MessageWindow.ID += 1
    End Sub

    '新しいウインドウを作成する
    Private Sub CreateWindow()
        If Me.CheckMessage(Me.text.Text) = False Then
            Call New MessageWindow().Show()
        Else
            Call New MessageWindow(Me.text.Text).Show()
        End If
    End Sub

    '指定されたメッセージを各種要素に反映する
    Private Sub SetMessages()
        Dim str As String =
            Me.Message & "(ID:" & 
            MessageWindow.ID.ToString() & ")"
        Me.Title = str
        input.Text = str
    End Sub

End Class

このサンプルは、自由にメッセージを指定して、ウインドウを作成できるプログラムです。Windowにプロパティを設定している点に注目して下さい。
　プロパティは一見すると関数と手続きです。しかし、それはあくまでも実装上の都合です。プロパティは、オブジェクト指向プログラミングの属性を表しています。属性を簡単に言うとデータの事です。オブジェクトは、インスタンスごとにデータを持つ事があります。それらのデータを表すのが属性であり、プロパティであります。つまりプロパティとメソッドの違いは、データを表すものか、操作を表すものかの違いなのです。
　プロパティとメソッドの違いは大きいです。WPFの様にプロパティを多用するスタイルを採用すると、マークアップ言語の様な宣言型プログラミングになります。例えば、WPFがプロパティを重視しているのは、XAMLとの連携および、宣言型プログラミングにするためです。宣言型プログラミングのサポートはWPFの設計方針であり、プロパティを多用する設計にしています。
　プロパティを使用するのか、メソッドを使用するのかは設計の問題です。しかも、それは大きな違いです。プロパティを多用するスタイルを採用すると、理解しやすい宣言型プログラミングへと進みます。WPFの様な美しい設計にしたいと誰しも思うでしょう。しかし、何事も一長一短があります。プロパティはロックの対象となりがちなので、並列プログラミングでは頭痛の種です。一方メソッドを多用するスタイルは、並列プログラミングで必要とされています。どちらを採るのかよく考えて設計しましょう。
　プログラミング＝文法だと考えている人もいます。しかし実際のところは、文法は概念を表すものであり、概念を知らずとして文法だけを見ていても、プログラミングの腕は上達しません。概念をしっかりマスターしましょう。続く。

中の人の徒然草419

ああ、化学と物理に手を出すと小遣いと時間が足りない。好奇心が止まらず困っているインドリです。
私は何時もニュースを見て疑問を感じています。それは、なぜ感想しか述べないのかです。
テレビを見ていると、コメンテーターという人が、社会問題についてあれこれ話しています。しかし、根本的に解決する方法や根本原因を述べず、感想だけに終わっています。感想だけならば要りません。視聴者が勝手に感想を持ちます。
もし、ニュースが事実を述べるだけならば、考えるのは自分自身だと納得がいきます。しかしながら、専門家を呼んできて、キャスター達が持論を述べているスタイルだから疑問に感じるのです。そのスタイルで、感想だけ述べるのは無意味です。いや、先入観を植え込むので有害とさえ言えます。変なフィルターを通して情報を流すのではなく、何の加工もしないで情報を流して欲しいです。
要するに中途半端なんです。事実を流したいのか、専門的知識を付加価値として付けたいのか、それをはっきりして欲しいです。中途半端だから濁った情報しか流れてきません。
虐め問題を例にとります。教育の専門家を名乗るのであれば、虐めを許すシステムについて述べるべきです。被害者が可哀そう、虐めは許せない、そういった言葉はただの感想です。何の意味も持ちません。専門家であるならば、既存のシステムのどこが駄目なのか、どうやってそれを改善するのかの2点を述べるべきです。
ニュースと言う短い時間だからそれが不可能なのかもしれません。しかし、長い放送時間がある報道番組ですら同じです。朝まで話しあっても何の解決策も問題の根本も見えてきません。明らかにバグがあるシステムを指摘しないというのは頂けません。専門家の名が泣きます。
虐め問題については、隠蔽が出来ている時点で、お話しにならないシステムとしか言いようがありません。そして、その状態を放置し、政治劇場を繰り広げる政治家が大問題です。選挙で当選する事以外何も考えていないように見えます。就職活動に専念しているその様子は、多額の報酬と高い権限を持つべき人達に見えません。
立法機関の生産能力が問題発生件数を上回らなければ、そのシステムは役割を果たしていないと考えます。問題が発生しても、それを処理できないシステムはお話しになりません。そういった根本的な事を、TVに出演している専門家が発言しないのが不思議でなりません。
私が思うに、ニュースはバグを報告する役割を果たすべきです。変な感想は要りません。変なフィルターを交えずに、社会システムに発生したバグを詳細に報告するだけでいいのです。そして、専門家を呼ぶのであれば、改善策と根本的な問題を放送して欲しいです。
残念ながら今の日本は問題解決能力と問題発見能力が全くありません。問題を的確に発見し、問題が発生したら正す。その当たり前の事をするだけで、日本は最高に幸せな国になれるのにと思えてなりません。日本は潜在能力はあったのに、今ではそれすらないのかもしれませんね。
非常に嘆かわしいです。天国を自ら破壊し、地獄へと変えようとしているのですから・・・

初心者のためのC#プログラミング本格入門96 - 実装を意識しないテストを行おう

　この記事は、初心者のためのC#プログラミング本格入門95の続きです。前回は、テストファーストでありがちな間違いを通して、プログラミングの心得について解説しました。今回は、前回提示したありがちな間違いを防ぐための方法を解説します。
　前回述べた「分けて考える」をより具体的に言うと、実装を意識してテストを作らない事を意味します。自分が行った実装を意識すると、どうしても先入観が生じ、間違ったテストを作ってしまう恐れがあります。先入観が入らないようにするには、やりたい事をそのままテストして実装しましょう。
　改めて今行おうとしている事を考えると、自分のオブジェクトをforeach対応にする事です。それをテストで表現します。

class SimpleListTest : Test
{
    private SimpleList target;
    public override void ExecuteAllTest()
    {
        this.OneElementAdd();
        this.CurrentTest();
        this.AddElementCheck();
        this.ForeEachTest();
    }

    //foreachを模倣する
    private void ForeEachTest()
    {
        //準備
        base.Execute();
        this.target = new SimpleList();
        for ( int i = 0 ; i < 10 ; ++i ) {
            this.target.Add( i );
        }
        //1 ～ 9 の数値が格納されているはず
        int x = 0;
        System.Text.StringBuilder error =
            new System.Text.StringBuilder();
        do {
            if ( this.target.Current != x ) {
                string message = "予期せぬ値が返されました。" +
                    "予想値：" + x +
                    " 返された値" + this.target.Current +
                    System.Environment.NewLine;
                error.Append( message );
            }
            ++x;
        } while ( this.target.MoveNext() );
        if ( error.Length != 0 ) {
            base.Error( error.ToString() );
        }
    }

foreachを直接使ってもよいのですが、それだとIEnumerableとIEnumeratorの働きが分かりません。そこで、foreachに近いプログラムにしました。
　テストをパスするには、次の様な実装にします。

//関係のあるプログラムだけ掲載しています
class SimpleList :
    System.Collections.Generic.IEnumerable<int>,
    System.Collections.Generic.IEnumerator<int>
{
    private int readIndex; //読み取り位置
    
    public System.Collections.Generic.IEnumerator<int> GetEnumerator()
    {
        return ( System.Collections.Generic.IEnumerator<int> ) this;
    }

    System.Collections.IEnumerator
        System.Collections.IEnumerable.GetEnumerator()
    {
        return ( System.Collections.IEnumerator ) this;
    }

    public int Current
    {
        get { return this.data[ this.readIndex ]; }
    }    
 
    object System.Collections.IEnumerator.Current
    {
        get { return this.data[ this.readIndex ]; }
    }
    
    public bool MoveNext()
    {
        ++this.readIndex;
        return this.data.Length > this.readIndex;
    }

    public void Reset()
    {
        this.readIndex = 0;
    }

    //保持しているリソースを解放
    public void Dispose()
    {
        this.data = null;
    }
}

まだまだ粗い実装ですが、ひとまずこれでパスを通過できます。
　これでひとまず、foreachループも使用できるようになります。

public void ForeEach()
{
    this.target = new SimpleList();
    foreach ( int value in this.target ) {
        System.Console.WriteLine( value );
    }
}

ただし、これは完全な実装ではありません。次回へ続く...

ネタつつき145 - お客様を羅針盤に開発の荒海を航海する

　開発は荒海を航海するのと似ています。状況は常に変化し、危険にみち溢れています。少しでも舵を誤れば、プロジェクトの船は大破します。一体どうすればよいのでしょうか？今回は、この命題について書きます。
　先に断っておきますが、銀の弾丸は存在しません。あったら誰も苦労しません。現実は常に複雑なのです。人間の能力など高が知れており、神様でもない限り完璧な開発は行えません。しかし諦める必要もありません。事実をありのままに受け入れれば、困難な現実を乗り越えられます。
　システム開発が難しい一番の原因はゴールが定まらない事です。完璧な要求定義など見た事がありません。お客様の要望は時間と共に変化します。従って、スタートした時点でゴールが決まっていないのです。正しく荒海を航海するのと同じです。いえ、漂流するのと等しいと言っても過言ではありません。プロにとって、技術的な事ならば比較的簡単です。しかし、非技術的な問題は解決が困難なのです。
　この難題を解決する方法は一つです。初めから仕様とゴールは変化するものと考えるしかありません。人は自然（世の理）に勝てません。下手に逆らわず、自然に対応する術を身につける方が賢明です。だからと言って、無目的に漂流しろと言っているのではありません。言いたい事はその逆で、常に目標を見失わない事が大事です。
　改めてシステム開発の目的について考えましょう。芸術的なプログラミングをする事でしょうか？完璧な理論で設計を組み事でしょうか？美しいドキュメントを書く事でしょうか？・・・。答えは否です。それらは一要因にしかすぎません。システムを販売している以上、答えは一つしかありません。システム開発の目標はお客様を満足させる事です。厳しいようですが、お客様が満足しないシステムに価値はありません。
　システム開発では一般的に、仕様要求の変更は忌避するべきものと看做されています。しかし前向きに考えれば、むしろ歓迎するべき事だと分かります。常にお客様の満足だけを目標にすれば、開発の荒波で沈没しないことを意味しています。従って、お客様の意思である仕様変更は喜ぶべき事なのです。それさえわかれば、迷うことなどありえません。
　誤解が無いように書きますが、お客様の満足度を考えると言う行為は、盲目的に従う事を意味していません。日本ではその辺が混同されています。お客様は情報に関しては素人です。迷って当然です。ですから私達プロが、お客様の真の要望を引き出しつつ道案内をすればよいのです。そうすれば自ずと、技術軽視、知識軽視、ドキュメント指向などといった奇妙な現象は起きません。
　もちろん、実際にそれを行うのは難しいです。だからと言って、始めから放棄する者は、プロを名乗る資格がありません。必死になって泥臭くやるからこそ、仕事はやりがいがあるのです。お客様の笑顔を糧に、充実した人生を送りましょう。誰かから求められる人生を目指すのか、誰からも必要とされない人生を目指すのか、それを選ぶのは貴方です。

VBオブジェクト指向プログラミング講座 第6回 手続き、関数、メソッドの違いを知る

　この記事は「第5回 インスタンスを見る」の続きです。前回は、インスタンスについて解説しました。今回は、メソッドについて解説します。
　オブジェクト指向プログラミングの基本要素はメソッドです。でも、メソッドを本当に理解していますか？経験者の中にも、理解していない人が結構いるようです。そんなメソッドについてちょっとだけ詳しく学びましょう。
　手続き（プロシージャ）、関数（ファンクション）、操作（メソッド）の違いは、プログラムとして可視化すると分かります。

Structure Point
    'フィールド
    Public X As Integer
    Public Y As Integer

    '関数で使用するコンストラクタ
    Public Sub New(ByVal x As Integer, ByVal y As Integer)
        Me.X = x
        Me.Y = y
    End Sub

    '内容を表示
    Public Sub Print()
        Console.WriteLine("X = {0}, Y = {1}", Me.X, Me.Y)
    End Sub
End Structure

Module Module1
    '加算手続き
    Sub AddSub(
    ByRef p As Point, ByVal x As Integer, ByVal y As Integer)
        p.X += x
        p.Y += y
    End Sub

    '加算関数
    Function AddFunc(
    ByVal p As Point, ByVal x As Integer, ByVal y As Integer)
     As Point
        Dim result As New Point(p.X + x, p.Y + y)
        Return result
    End Function

    Sub Main()
        '手続きは処理順序に依存
        Dim a As New Point()
        Console.WriteLine("処理前の値")
        a.Print()
        AddSub(a, 10, 10)
        Console.WriteLine("処理後の値")
        a.Print()
        Console.WriteLine()

        '関数は処理順序に依存しない
        Dim b As New Point()
        Console.WriteLine("処理前の値")
        b.Print()
        Dim c As Point = AddFunc(b, 10, 10)
        Console.WriteLine("処理後の値")
        b.Print() '値が変わらない
        Console.WriteLine("新しい値")
        c.Print()

        Console.ReadLine()
    End Sub

End Module

プログラムを見ると、手続き、関数、メソッドに明確な違いがある事が分かると思います。これから個別に解説します。
　手続き（プロシージャ）は、引数として渡されたデータ構造の値を変える閉じた操作です。「閉じている」とは、環境に変化を与える操作の事を指しています。手続きを呼び出すと、プログラムの環境（データ構造など）に変化がもたらされます。従って、手続きの処理結果は、処理する順番に依存します。サンプルを例に取り具体的に書くと、Printメソッドの結果はAddSubプロシージャの呼び出し有無で変化しています。
　関数（ファンクション）は、処理結果を返す開いた操作です。「開いている」は、「閉じている」の反対で、プログラムの環境に影響を与えません。余計な事をしない限り、どこで呼び出しても処理結果は変わりません。従って、関数は処理の実行順序に依存しません。
　メソッド（操作）は、オブジェクトが持つ手続もしくは関数です。サンプルで確認できるように、Printメソッドは引数としてPointオブジェクトのインスタンスを受け取りません。オブジェクトが持つとは、この事を表現しています。
　細かい事を言えば他にも色々ありますが、ひとまず今回解説した分だけ押えておきましょう。違いを分かっていれば、オブジェクト設計にそって上手に実装できます。ちなみに私のお勧めは、関数の方のメソッドを多用するスタイルです。並列プログラミングが一般となった今、処理結果が実行順序に依存するのは問題です。また、処理順序に依存しない方が、プログラムを単独で扱えるのでテストがやりやすいです。ただし、関数を多用するスタイルは、インスタンスを大量に発生させるので注意が必要です。