fc2ブログ

初心者のためのC#プログラミング本格入門53 - 外見から考えよう

 この記事は、初心者のためのC#プログラミング本格入門52の続きです。前回は、オブジェクトのコンポジション(合成)について解説しました。今回は復習を兼ねて、初心者用のオブジェクトの作り方を解説します。
 「 ( 1 + 2 ) / 3 」の様な複数の式を解析するには、新しいオブジェクトを創らねばなりません。ですが、初心者の方はまだ不慣れだと思いますので、新しいオブジェクトを作る過程を丁寧に説明します。
 単一の式ならば解析できますので、先ずは複数の式を区切る方法について考えましょう。式を区切る方法は、前回()記号を使用する事を決定しましたので、「(」記号から「)」記号までの文字列を切出せれば実現できます。早速その方法をプログラムで実現する事を考えましょう。
 初心者がいきなり答えを出そうとしても混乱するので、使用する側のプログラムを作るのがベストです。

static void Main()
{
    //結果をチェック
    System.Tuple<bool, string, string> result =
        CutExpression( " ( + 1 2 3 ) / 3" );
    System.Console.WriteLine( "元となる式:" + result.Item2 );
    System.Console.WriteLine( "式は正しい?:" + result.Item1 );
    System.Console.WriteLine( "取り出した式:" + result.Item3 );

    //エラーの場合もチェック
    System.Console.WriteLine( "" );
    System.Tuple<bool, string, string> error =
       CutExpression( " + 1 2 3 / 3" );
    System.Console.WriteLine( "元となる式:" + error.Item2 );
    System.Console.WriteLine( "式は正しい?:" + error.Item1 );
    System.Console.WriteLine( "取り出した式:" + error.Item3 );
}

static System.Tuple<bool, string, string> CutExpression(
        string expression )
{
    System.Tuple<bool, string, string> error =
            new System.Tuple<bool, string, string>(
                false, expression, "" );
    return error;
}

最低限必要な要素、「式の正しさ」、「元の式」、「取り出した式」を取得する事を考えます。なお、呼び出される側のCutExpression静的メソッドは、ひとまずエラーを表すインスタンスを返すようにしておきます。このプログラムを元にして、徐々にプログラムを完成させます。
 これで完成イメージが湧いたと思います。次はCutExpression静的メソッドの内容を考えましょう。文字列を部分的に取得するメソッドを解説した事がありますが覚えていますか?正解は「Substring」メソッドです。Substringは、開始位置と文字の個数を指定して呼び出します。ということは、開始位置と文字の個数を記憶する変数が必要です。

static System.Tuple<bool, string, string> CutExpression(
        string expression )
{
    int startIndex = -1;
    int count = -1;
    System.Tuple<bool, string, string> error =
            new System.Tuple<bool, string, string>(
                false, expression, "" );
    return error;
}

目的が分かったら後は簡単です。順番に考えていくだけです。開始位置を判定するプログラムを考えてみましょう。

for ( int i = 0; i < expression.Length; i++ )
{
    char tmp = expression[ i ];
    if ( tmp == '(' )
    {
        startIndex = i + 1;
    }
}

「(」記号そのものは必要ないので次の位置を記録しています。その点さえ注意すれば簡単です。次は取り出す文字の個数を計算するために、終了位置も一緒に割り出しましょう。

for ( int i = 0; i < expression.Length; i++ )
{
    char tmp = expression[ i ];
    if ( tmp == '(' )
    {
        startIndex = i + 1;
        continue;
    }
    if ( tmp == ')' )
    {
        endIndex = i;
        break;
    }
}
int count = endIndex - startIndex;

このプログラムは理解できると思います。後は、エラー処理とSubstringメソッドを呼び出しを付け加えると完成です。

static System.Tuple<bool, string, string> CutExpression(
        string expression )
{
    //()記号の範囲を決定
    int startIndex = -1;
    int endIndex = -1;
    for ( int i = 0; i < expression.Length; i++ )
    {
        char tmp = expression[ i ];
        if ( tmp == '(' )
        {
            startIndex = i + 1;
            continue;
        }
        if ( tmp == ')' )
        {
            endIndex = i;
            break;
        }
    }

    //エラー判定
    if ( startIndex == -1 | endIndex == -1 )
    {
        System.Tuple<bool, string, string> error =
            new System.Tuple<bool, string, string>(
                false, expression, "" );
        return error;
    }

    //()内の式を取り出す
    int count = endIndex - startIndex;
    string cutExpression = expression.Substring(
        startIndex, count );
    System.Tuple<bool, string, string> result =
        new System.Tuple<bool, string, string>(
            true, expression, cutExpression );
    return result;
}

エラー判定の「if ( startIndex == -1 | endIndex == -1 )」というプログラムは、OR論理演算子「|」(Shiftキーを押しながら円記号(¥)のキーを押せば入力できます)を使用しています。
 プログラムの意味は、「startIndex変数が-1もしくは、endIndex変数が-1ならば{}内のプログラムを実行する」です。AND論理演算子(&)と違い、どちらかの条件が満たされれば{}内のプログラムが実行されます。
 以上で括弧内の式を取り出す事が可能となりました。これは複数の式を解析するための重要な一歩です。
スポンサーサイト



テーマ : プログラミング
ジャンル : コンピュータ

ネタつつき119 - お客様の事を考えていない商品は無価値

 最近お客様主義を、精神論と捉える人が増えてきたと感じます。口ではお客様主義を唱えている会社でも、実際はお客様を軽視しているとしか思えない態度を取る事があります。私は技術者であり経営者でもあるので、非理論的な感情論は好みません。しかしながら、お客様主義は精神論的なものではありません。非常に論理的なものです。
 それを知るには、商品の売買について改めて考える必要があります。買い手は何らかの要求を満たすために商品を求めます。一方、売り手は買い手の要求を満たす商品を作りお金と交換します。この誰しも当たり前だと考えている基本が大切です。
 買い手は何らかの要求を満たすために商品を購入するのですから、お客様の事を考えて作っていない商品には何の価値もありません。目的を果たさない商品に対してお金を支払う必要はありません。お客様は欲求を満たす違う商品を買えばいいのです。
 私は目に見えないと言われる情報システムを販売しているので、特にお客様の欲求について深く考えます。私が医学については素人であるのと同様に、お客様は情報技術については素人です。自分の欲求を上手く言葉に出来ません。従って、売り手である私が、お客様の欲求について深い関心を持たねばなりません。
 私がシステムを作る時、お客様を知る事から始めます。そして、ひとまず自分の立場を忘れて、お客様と同じ考え方が出来るようになります。流石にその道のプロであるお客様と同等の見解は得られませんが、考え方の方向性は同一になれます。そうすれば、自ずとお客様の欲求が見え、お客様にとって最適なシステムが導き出せます。
 私にとってシステム開発とは、不自然にあれこれと考えるものではなく、自然に浮かび上がってくるものなのです。むろん、情報技術は深く学んでいますが、情報技術を使ってシステムを作るのではなく、自然に浮かび上がるシステムを情報技術を使って実現します。従って私は、お客様の事を考えていないシステムは無価値であり、商取引をするのに値しないと考えています。
 お客様主義は商取引の基本であり、お客様の事を考えて作っていない商品は商取引の対象になりません。その基本を忘れてはならないのではないでしょうか?

テーマ : ビジネス
ジャンル : ビジネス

アジャイル開発を元に考えるプロジェクトマネージャのあり方22

 この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方21の続きです。前回は、経営資源「情報」とプロジェクトの関係について解説しました。今回は、今までの総括をします。
 今回までの解説で、従来型のウォーターフォール開発モデルで培われた「管理のための管理」をするプロジェクトマネージャは、変化が早い現代に合わない事が分かって頂けると思います。今求められているのは、変化に対して臨機応変に対処できる誰からも頼られる人です。
 変化に対し柔軟かつ迅速に対処するには、物事を厳密にコントロールしようとする管理ではなく、変化を前提とした誘導型管理をする必要があります。開発メンバーを統治するべき部下として捉えるのではなく、プロジェクト成功を共に目指す仲間として捉えます。開発メンバーを統制するのではなく、成功へと導くために「もの」、「情報」、「金」、「時間」を有効に使います。
 もちろん、プロジェクトマネージャは開発メンバーにだけを見ていればいいという事はありません。自社はもちろんのこと、関連会社の利害関係者の事を考えなくてはなりません。そしてなによりも、お客様の事を第一に考えなくてはなりません
 たまにお客様の事を考えない開発者がいますが、お客様の事を考えないで開発したシステムは役に立ちません。プロジェクトマネージャは、お客様にとって実際に使えるシステムなのかをよく考え、開発メンバーが間違った方向へ進まないようにしなくてはなりません。
 従来のプロジェクトマネージャは、「部下を統率する上司」といった色が強く出ていました。変化が遅い時代では、そういったプロジェクトマネージャでも結果を残す事が出来ました。しかしながら、現代は変化が早く、あらかじめ全てを正確に予測し、物事を制御できません。従って、統制ではなく常に誘導をし続けなくてはプロジェクトは失敗します。
 アジャイル開発を採用するかどうかは、会社の体質に関する難しい問題だと思います。しかしながら、求められているプロジェクトマネージャ像は変わりません。この連載を読んで少しでも多くの人が、新しいプロジェクトマネージャ像について考えて頂ければ幸いです。

テーマ : ソフトウェア開発
ジャンル : コンピュータ

システム開発における情報セキュリティ11

 この記事は、システム開発における情報セキュリティ10の続きです。前回は、人災および災害に関するセキュリティ対策を解説しました。今回は、人とセキュリティの関係について解説します。
 システム開発に従事している人達はセキュリティについて、どうしても技術よりの見方をしてしまいますが、セキュリティ対策は人の行動が大きな比重を占めています。セキュリティ対策は、セキュリティに関係する機能を実装するだけでは不十分であり、運用マニュアルの整備およびセキュリティ意識の向上がともなければ意味をなしません。
 セキュリティは情報資産をどのように取り扱うのかを考え、その考えと方針を徹底的に関係者に伝えてこそ効果を発揮します。関係者に対して徹底したセキュリティ意識を持たせるというと、日本の会社は正社員だけを考えがちです。また、警備員、清掃員といった外部の人員も見落としがちです。しかしながら、情報資源はあらゆる経路で漏えいします。セキュリティは一つの弱点が全てを駄目にしてしまうのです。
 ただし、セキュリティを徹底的に実施すると言っても、関係者全員に細かいルールや複雑な手順を強いるのもまた間違いです。人は余りにも細かいルールや、多すぎるルールには従えません。本人にやる気があっても、ルールが多すぎればどうしても抜けが生じます。また、普通の人はたいした悪意もなく、細かすぎて業務を妨害するルールを破ります。
 セキュリティが難しいのはこういった事が原因です。セキュリティ対策は「やらなくては駄目」、「やり過ぎても駄目」、「穴があっても駄目」という非常に難しいものです。セキュリティ対策は基本的に量よりも質です。ただ実施するのではなく、質が高い少数のセキュリティ対策を行います。
 勘違いがないように明記しておきますが、少数とは言ってもそれは人から見ての量です。システムを構築する側は、非常に膨大な量の対策をしなくてはなりません。その辺を勘違いしないように注意して下さい。
 

テーマ : ソフトウェア開発
ジャンル : コンピュータ

初心者のためのC#プログラミング本格入門52 - オブジェクトのコンポジション(合成)

 この記事は、初心者のためのC#プログラミング本格入門51の続きです。前回は、キャストが不要になる、ジェネリックなコレクションオブジェクトについて解説しました。今回は、より高度なオブジェクト指向プログラミングの概念「コンポジション(合成)」を解説します。
 この連載を通じて作成しているサンプルプログラムには、まだ大きな欠点があります。それは、解ける計算式に限りがある事です。今のところ、「+ 1 2 3 」とか「 1 + 2 + 3 」のような計算式を解けますが、「 1 + 2 / 3 」 の様な複数の演算子を使った計算式は解けません。この複数の演算子を持つ式を解く一つの方法は、オブジェクト指向プログラミングのコンポジション(合成)という技を使用する事です。
 コンポジション(合成)を簡潔に表現すると、複数のオブジェクトを組み合わせて、より高機能なオブジェクトを作る事です。今回のケースでは、Analyzerを持つMultiAnalyzerという新しいクラスを作成します。先ずはMultiAnalyzerクラスの仕様を考えてみましょう。複数の演算子を解析/実行するのですから、何からの区切りが必要となります。区切りは大別すると2つ考えられます。
 1つめは、記号を使って式を区切る方法です。例えば、「 ( 1 + 2 ) / 3 」の様に、一つの式を区切る記号を決めておいて式を分解する方法です。式を入力するのがちょっと面倒になりますが、プログラムが作りやすいという利点があります。
 2つめは、演算子の位置に関するルールを決める方法です。例えば、演算子を数値の間と定めて、「 1 + 2 / 3 」は正常と見做し、「 + 1 2 3 / 」はエラーだとする方式が考えられます。この方式は人間にとって自然ですが、演算子の順番を定める必要があります。具体的には、「 1 + 3 / 3 」は2です。これは加算よりも除算の方を優先した計算結果です。この様に、優先する演算子を決めなくてはなりません。
 プログラムの難易度を考慮し、2つの方式のうち今回は1つめの記号を使って式を区切る方法を採用します。次回、この方式をプログラミングで実現する方法を解説します。お楽しみに。

テーマ : プログラミング
ジャンル : コンピュータ

ネタつつき118 - 議論を成立させるにはどうすればいいのか

 今回も議論について考えます。議論の本質を考える為に、議論が成立しない状態を考察します。議論が成立しない状態が分かれば、逆説的に議論の本質が見えてきます。
 議論が成立しない状態は、色々な原因が考えられます。最も多い原因は、マナーを守らない参加者がいる事です。マナーが悪い人がいると、場が乱れて議論になりません。次に多いのは、議論で取り扱う問題について知らない人が参加する事です。マナーが悪い人が原因の場合は自明だと思いますので、問題について知らない人が参加する場合について考察していきます。
 議論とは「問題を解決するために意見を出し合う事」です。ですから、その問題について知っている事が前提となります。問題そのものを知らない人が参加すると、問題について知っている他の参加者が、一から教えなくてはなりません。その問題が簡単な場合、参加者がその場で問題を知って議論を開始する事は可能ですが、問題が複雑な場合は議論が始まりません。議論の成立云々の話ではなく、そもそも始められないのです。
 従って、健全な議論をするには、問題について知らない人の参加を防ぐ必要があります。ここで一つの問題が浮き彫りになります。参加を防ぐと言っても、参加者の知識が事前に分かりません。また、強制的に防ぐのは紳士的な行為だとは言えませんし、防ぐ方法がない場合のほうが多いです。参加者は議論の問題を事前に知る必要があります
 会議の場合は、あらかじめ議論するべき問題を知らせるのがベストです。むろん、参加者は最低限のマナーとして、会議が始まる前に問題について調べておきます。そして、理解できていない部分については、他者の意見をよく聞くのが基本的なマナーです。しかしながら、問題について知らない事を当人が把握していない時があります。それが一番厄介です。
 本人が問題についての知識が不足しているのを把握しておらず、問題を知っている人の意見を否定、もしくは反対の意見を述べる場合、総じてその意見そのものが見当はずれであり、まともに議論が進みません。おまけに、知らずに反対している人を納得させる事は困難です。知っている人が注意し、本人がそれを自覚すれば議論が進むのですが、自覚しない場合は打つ手がありません。特に性格が悪い人の場合は、議論する事をあきらめ無視するしかありません。
 会議で議論を行う場合、議長もしくは進行役が問題を知らずに議論の進行を妨害する人に対して注意し、それでも聞かなければ、退出させるのがベストでしょう。以上で考察を終えます。
 この考察が導き出した答えは、議論は参加者の質と問題の共有化が成功の鍵を握るという事です。議論に参加する時は、マナーをわきまえ、事前に問題についてよく調べておきましょう。そして、議論にふさわしくない人がいれば注意をし、議論の場を整えましょう。そうすれば、有意義な議論ができ、強いては問題解決につながります。

テーマ : ビジネス
ジャンル : ビジネス

初心者のためのC#プログラミング本格入門51 - ジェネリックなコレクションオブジェクトを使用しよう

 この記事は、初心者のためのC#プログラミング本格入門50の続きです。前回は、コレクションオブジェクトについて解説しました。今回は、キャストが不要になる、ジェネリックなコレクションオブジェクトについて解説します。
 コレクションオブジェクトは便利なのですが、キャストが必要になるという弱点がありました。キャストをしなければならないプログラムは、間違いの元なので極力避けなくてはなりません。具体的にいいますと、System.Collections.ArrayListはどんなオブジェクトでも格納できます。この時、間違った型のインスタンスを格納してしまっていても、実行するまで間違いが分かりません。次のコードを実行すると「実行時に」エラーが発生します。

class Program
{
    static void Main()
    {
        System.Collections.ArrayList list = 
                new System.Collections.ArrayList();
        list.Add( "Hello" );
        list.Add( 10 );
        System.Console.WriteLine(
                ( int ) list[ 0 ] +
                ( int ) list[ 1 ] );
    }
}

コンパイル段階でエラーが発生しない点に注意して下さい。この様な短いプログラムだと間違いは一目瞭然ですが、長いプログラムになるとどうしても間違えやすくなります。コンパイル段階で間違いが分かれば、早い段階で間違いを訂正できます。キャストを必要とするプログラムは、極力避けるべきだという事が分かって頂けると思います。
 キャストを減らすには、ジェネリックなコレクションオブジェクトを使用します。System.Collections.ArrayListと同様のオブジェクトとして、System.Collections.Generic.Listが用意されています。System.Collections.Generic.Listを使用すると、キャストをする必要がなくなります。早速このオブジェクトを使用して、サンプルプログラムを改良してみましょう。

System.Collections.Generic.List<float> values;
public System.Collections.Generic.List<float> Values
{
    get { return this.values; }
}

public Analyzer()
{
    this.success = false;
    this.sign = ' ';
    this.values = new System.Collections.Generic.List<float>();
}

System.Collections.Generic.List<float>となっている点に注目して下さい。System.Collections.Generic.List<float>という名の型が用意されているのではなく、System.Collections.Generic.Listだけが用意されており、あらかじめ使用する型が指定できるようになっています。この様なオブジェクトをジェネリックオブジェクトと呼びます。
 ジェネリックオブジェクトは<>内に型を指定して使用します。<>内に型を指定しているので、C#は使用する型が分かっているので、コンパイル段階で不適切な型が使用されないようにチェックできます。従って、サンプルプログラムAnalyzerの「Calculation」メソッド内のプログラムにあるキャストを全て消せます。
 その作業が終わったら、念のために今回提示した短いサンプルプログラムで、間違えた時にエラーが出るか確かめてみましょう。

class Program
{
    static void Main()
    {
        System.Collections.Generic.List<int> list = 
            new System.Collections.Generic.List<int>();
        list.Add( "Hello" );
        list.Add( 10 );
        System.Console.WriteLine( list[ 0 ] + list[ 1 ] );
    }
}

「list.Add( "Hello" );」の部分でエラーが発生します。これで間違いが減ります。
 今回の記事で分かって頂けると思いますが、ジェネリックでないSystem.Collections.○○よりもジェネリックなSystem.Collections.Generic.○○を使用しましょう。そうすれば、間違いを減らす事が出来ます。

テーマ : プログラミング
ジャンル : コンピュータ

ネタつつき117 - 議論をまともにしない人から見える議論のあり方

 今回は、議論をまともにしない人について観察した結果を書きます。結論から書くと、コミュニケーション能力が低く、まともな議論が出来ない人だと思います。反面教師にするために、議論をまともにしない人を分析してみましょう。
 議論をまともにしない人には一つの特徴があります。それは、自己主張しか考えていない事です。この手の人はモラルが低く、自己主張さえできればどのような手段でもとります。正しく自己主張するのであれば、議論が上手な人になるのですが、それをしないという事は出来ないのでしょう。議論を上手に出来ないものの、自己愛が強すぎるので、議論そのものが成立しない状態にしてしまうようです。その理由を探るために、さらに細かく分析してみます。
 議論が上手な人は、自分の我を通す事だけを考えていません。生産性があり有意義な議論を目的としています。一方、議論がまともにできない人は、自分をアピールする事しか考えていません。つまりその差は、主格をどうとらえるのかにあると私は考えております。
 議論が上手な人は、主格を議題だと捉えています。一方、議論がまともに出来ない人は、主格を自分だと捉えています。議論が上手な人は主題からはずれず、他者の論理を取り入れつつ正しい論理が展開できます。しかし、議論がまともにできない人は、自分の事しか考えていないので、客観的にみると議題から脱線している状態になります。
 主格の問題以外に、論理的に考える能力が不足しているのもまともな議論が出来ない要因です。まともに議論できない人は、他者の意見を聞くのが苦手です。また、自分の論理が正しく組めません。
 論理的に考えるという行為は、自分を客観視しつつ他者の論理も正しく把握する必要があります。しかしながら、議論をまともにしない人は、自己愛が強すぎて相手の事を理解する能力が不足しています。それ故、論理的に考える能力が足りない状態になるのでしょう。
 議論がまもとに出来ない人の発言は、前提がおかしい、もしくは前提を忘れている、論理の飛躍がある、論理が首尾一貫してない、嘘やごまかしがある、決めつけが多い、一人で主張できない・・・といった特徴があります。それらを一言で言うと、論理がまっとうでないと言えると思います。
 議論をするという行為は、自己満足するためのものではありません。また、声が大きければいいというものではありません。日本では声が大きいだけの人を、議論が上手いと勘違いする傾向があるので注意が必要です。多弁である必要もなく、議論から新しい知見を生みだす人が、本当に議論が上手い人です。
 広い視野を持ち、礼儀正しく正しい議論が出来る上手な人になりましょう。本当の意味で議論が上手な人になるのは難しいですが、議論の趣旨を忘れなければ、自ずと議論が上手な人になるでしょう。一緒に議論が上手い紳士/淑女を目指しましょう。

テーマ : ビジネス
ジャンル : ビジネス

アジャイル開発を元に考えるプロジェクトマネージャのあり方21

 この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方20の続きです。前回は、経営資源「もの」とプロジェクトの関係について解説しました。今回は、経営資源「情報」とプロジェクトの関係について解説します。
 プロジェクトが始まると、様々な情報が飛び交います。プロジェクトで発生した情報をコントロールし、適切な人に情報を提供するのもまたプロジェクトマネージャの仕事です。情報の管理をおざなりにすると、開発メンバーや利害関係者に余計な負担を掛け、情報の誤差がデスマーチを呼びます。分かり難いと思いますので、具体例を挙げつつ詳しく説明します。
 仕様の変更はほぼ必ず発生します。よほど単純なプロジェクトでない限り、あらかじめ全ての情報を完備し、仕様を完璧にする事は不可能です。仕様の変更に伴い、開発メンバーにその事を伝える必要があります。この際に情報の管理をしないと、仕様の変更を知っているメンバーと、仕様の変更を知らないメンバーとの情報格差が生まれ、その差がシステムにバグを発生させます。
 仕様変更はそれほど頻繁に起こらないと、考える人もいるでしょう。しかしながら、オブジェクトの変更と言った些細な変化も日々発生します。そうした比較的小さな情報の変化でも積み重なると、プロジェクトを混乱させます。
 情報を必要とするのは開発メンバーだけではありません。利害関係者も情報を必要としています。責任者はそのプロジェクトの進歩度や、現在起っている課題/問題に興味がありますし、お客様は自分の要求が正しく解釈されているのかを気にします。開発が終わってから、お客様の要望と違うシステムだと分かっても手遅れです。
 アジャイル開発では、プロジェクトに関する情報の管理もカバーしています。開発メンバー間の情報を共有するための「共同所有」、お客様と開発メンバーの情報を共有するための「オンサイトのユーザ」がありますし、アジャイル開発の一種スクラム開発では情報のコントロールも行う役割「プロダクトオーナー」が設定されています。
 プロジェクトは情報が命です。プロジェクトマネージャは情報を管理し、開発メンバーと利害関係者を満足させなければなりません。大変な仕事ですが成功すれば、内外ともに評価の高いマネージャになれます。

テーマ : ソフトウェア開発
ジャンル : コンピュータ

ネタつつき116 - 議論の上手な人、議論が下手な人、議論をまともにしない人、議論に参加しない人。

 私は色々な会議に参加し、会議で色々な議論が展開されるのを見聞きしました。皆様も会議で色々な議論を見聞きしていると思います。そこで、会議に関するあるある話しとして、会議と議論について書く事にしました。
 会議で繰り広げられる議論には色々な形があり、そこに参加する人も様々なタイプの人間がいます。それらの人を大まかに分けると、議論が上手な人、議論が下手な人、議論をまともにしない人、議論に参加しない人の4つに分けられます。
 議論が下手な人は、今何が議論されているのかを把握していない、もしくは自身の意見を述べるのが苦手な人です。議論をあさっての方向へと展開したり、細かい部分にこだわり過ぎて本題を見失ったりします。その一方で、議論がおかしいのを把握しているものの、その意見を上手に述べられず悔しい思いを味わう人もいます。
 議論が上手な人は、あらかじめ論理展開を正確に把握しています。先を見越して資料をあらかじめ準備し、会議における議論の流れをコントロールします。このタイプの人は大半が仕事もできる人です。言葉の過多は関係なく、議論の流れを変えてしまう凄い人達です。
 議論をまともにしない人は、他者を妨害して議論そのものを成立させません。人の話の腰を折る、論理を無理やり違う方向へ捻じ曲げる、議題とは関係なく演説をする、やじを飛ばすなど一番迷惑な人だと言えます。他のタイプとは違い、性格が悪いと言えるでしょう。
 最後の議論に参加しない人は、日本に一番多いタイプだと思います。議論を好まず、誰かの支持に徹したり(口を開けば「部長の仰るとおりです」)、自らは意見を言わず求められたら無難な返事をしたりします。平和を愛するおとなしい人だと言えると思います。
 これらの人を踏まえると、会議で一番重要なのは適切な議題の決定と場の調節です。議論をまともにしない人が議論の場を壊さないように管理しないと、他のタイプの人は議論に参加できません。議論が上手な人はコントロールしようとするでしょうが、議論をまともにしない人はその場を壊すので、口論になったりして議論そのものが成立しなくなります。また、他のタイプの人は議論に参加そのものが出来なくなります。会議は多くの意見を聞くためのものであり、こうした事態は避けなくてはなりません。
 会議では人間ドラマが繰り広げられます。大半の会議は退屈だと思いますが、人に注目すれば面白く感じられます。ちなみに私は、第5のタイプ「観察者」です。論理展開を見守り、人を観察するとどの会議も楽しめます。念のために書いておきますが、観察者と言っても会議は仕事ですので、ちゃんと意見は述べます。
 今回は以上です。何事も楽しく行うのが一番だと私は考えております。会議を楽しみ、健全な議論を心掛けましょう。

テーマ : ビジネス
ジャンル : ビジネス

プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

QRコード
FC2カウンター