スポンサーサイト

一定期間更新がないため広告を表示しています


  • 2010.11.01 Monday
  • -
  • -
  • -
  • -
  • by スポンサードリンク

ワークシェアリング

 ここ数日、本職のほうが忙しくてブログを更新していなかった3日坊主です。


もちろん、技術的な勉強もすることができず、
2週間の間、ずっとメンバーの仕事をスムーズに進めるためのサポートをしてきました。


10人もいると、いろいろな性格な人が集まってくるもので、
ずさんな人もいれば、きっちりやる人もいて、話をしていて、本当面白いです。

そういったメンバーのバランスをとるのがリーダーの仕事だと私は思っています。


とはいっても、みんなに平等に接することがなかなかできないのが現実です。
きっと、不満を持っているメンバーもいるとは思うのですが、そこは諦めるしかないところです。


さて、話は変わり今日のテーマはワークシェアリングです。
ここ数カ月、不景気のあおりを受けてIT業界も大変なことになっているようです。
(ずっと忙しい現場なので、まったく影響を受けていませんが・・・)

ワークシェアリングとは、簡単に言うと今まで一人で行ってきた作業を、
分担することで、一人一人の作業時間を削減して、その分ほかの人に作業を分担しましょう。ということです。

全体として、目的を達成するための作業時間は減少しませんが、
その作業にかかわる人数を増やすことで、みんなの生活を守りましょうということです。

ただ、なかなか難しいのがワークシェアリング。
何かのプロジェクトを進めている途中で、ワークシェアリングを導入するのは一筋縄ではいかないと思います。


現場の人間の意見からすれば、作業を分担するということは下手をすると逆に効率が悪くなり、費用がかさんでしまう恐れがあるからです。


では、どうすれば上手く仕事を分担できるのか?

まずは、顧客とSIerがともに仕事を分担して行うということを意識することが大切です。
意識するだけではなく、契約内容に盛り込むことが必要だと思います。

次に、ワークシェアリングを行うことを前提に納期やスケジュールの設定を行う必要があります。

そして最後に一人ひとりの作業者が仕事を分担して行うということを意識して仕事を進めることです。
どうしても、この業界の人たちは自分自身の力を周りにアピールしたがる人が多いと思います。
(その割には、できないことがあると、人のせいにする人がいますが・・・最後まで責任とってくれよ・・)

ただ、最後の内容はこの業界に限ったことではないのかもしれませんね。
そもそも、今の日本の教育制度の責任かもしれません・・・とは言っても別に国のやり方に文句があるわけではありません。

それならそれで、その国で生活している以上、仲良くお付き合いするのが大人ですからね。

「郷に入っては郷に従え」です。

少し話がそれてしまいましたが、ワークシェアリングは上手に実行すれば、みんなが幸せになる要素を持っていると思います。こんなご時世だからこそ、こういったことを実践してみても良いのではないでしょうか。


Erlang 〜第3回〜 モジュール編

 本日は第3回目ということで、モジュールの解説に入っていきたいと思います。
関数型言語ということだけあって、Erlangには常に式という概念がありますので、
今まで記述してきた内容についても、式であったわけです。

今回は、Erlangの中でモジュール(メソッド)を利用する方法を説明したいと思います。
また、今回からソースファイルは基本的にコンパイルして利用する方法をとります。
コンパイル対象のファイルは、拡張子をerlとしてテキストエディタ等で作成を行います。

また、コンパイルの方法は以下のように記述します。

1> c(ファイル名).
{ok, ファイル名
※ファイル名には拡張子を含めても含めなくても問題ありません。

成功した場合は上記のようなメッセージ{ok, ファイル名}が表示されます。

また、コンパイルするファイルは任意のフォルダに保存しておいて、
保存したフォルダまでパスを移動させた後で上記コマンドを実行します。

■移動方法
1> cd("フォルダパス").
フォルダパス
ok

移動完了後のパスが実行結果に表示されます。
(※間違ったパスを指定しても、コマンドを実行したときのパスの場所に居続けます)

■現在のパスを調べる
また、現在のパスを調べたい場合は、pwd().コマンドで調べます。
(このあたりまでは、UNIX系のコマンドと同様です)

1> pwd().
現在のパス
ok


長くなってしまいましたが、ここから本日の本題です。
まず、以下のようなコードを任意のファイル名(ここではhoge.eal)で保存します。

[ファイル中身]
-module(hoge).
-export([sum/1]).
sum({X,Y}) -> X + Y.

保存が完了したら、コンパイルをして実行内容を確認します。

1> c(hoge).
{ok,hoge}
2> hoge:sum({10,20}).
30

ここで2行目に入力した方法でモジュールにアクセスします。

Javaやその他の多くのオブジェクト指向言語では、.(ピリオド)でアクセスしますが、
erlangでは、:(コロン)を用いてアクセスをしていることがわかると思います。

このあたりは慣れなので、最初は違和感があるかもしれませんが、
いずれ慣れてくると思います。

このモジュールを拡張してみたいと思います。
-module(hoge).
-export([sum/1]).
sum({X,Y}) -> X + Y;
sum({X,Y,Z}) -> X + Y + Z.

これで拡張完了です。3つの配列をすべて加算した値を返してくれるメソッドの作成完了です。

上記のようにリストの数によって加算数を変更しなくてはいけないのは面倒です。
こういった場合は、以下のように変更すれば、リストの数がどれだけあっても計算をしてくれます。

-module(hoge).
-export([sum/1]).
sum([H|T]) -> H + sum(T);
sum([]) -> 0.

このコードはリストのヘッドを取り出し、テールと加算します。
リストは空になった時点で0を返しますので、リストの数まで加算を続けて結果をかえしてくれます。
(この考え方は慣れるまで非常に難しいです。)

1> c(hoge).
{ok,hoge}
2> L = [1,2,3,4,5].
[1,2,3,4,5]
3>hoge:sum(L).
15

モジュールの基本的な考え方は以上です。
次回は、funという無名関数について説明したいと思います。


Erlang 〜第2回〜 基本仕様編

  本日より、Erlangについて解説していこうと思う。

Erlangとは関数型言語のうちの一つである。

以下にあげる要望を満たしたい人の場合に利用すると良いと書かれている。
.泪襯船灰鵐團紂璽拭爾任茲蟾眤に実行できるプログラムを書きたい。
▲機璽咼垢鮖澆瓩困暴だ気任る耐障害アプリケーションを書きたい。
「関数型プログラミング」のことを耳にしたが、そんな手法が実際に有効なのか興味がある。

ということで、第2回はErlangの基本的な仕様から説明していきたいと思います。

アトム
数値以外の様々な不変値を表す場合に利用する。
※C言語で言うところの、#define定数のようなもの。

タプル
様々なデータ構造を表現するために利用する。
※C言語で言うところの、構造体のようなもの。
《例》
1> Point = { point, 10, 45 }.
値の取り出し方法
2> { point, x, y } = Point.
これで、xとyに値を取り出すことが可能

リスト
リストを作成するためには、リストの各要素をカンマで区切って、角括弧で囲む。

1> ThingsToBuy = [ { apple, 10}, {pears, 6}, {milk, 3} ].

値の取り出し方法

2> [ Buy1 | ThingToBuy2] = ThingsToBuy.
[ { apple, 10}, {pears, 6}, {milk, 3} ].

Buy1には、リストのヘッドがThingToBuy2へはリストのテールが設定される。

文字列
Erlangでは文字列は単なる整数のリストで表現される。

1> Name = "Hello".
"Hello"

2> [1, 2, 3].
[1,2,3]
3> [83,117,114,112,114,105,115,101].
"Surprise"
※表示文字列として置換可能な整数の場合、文字列に置換される.



Erlang 〜第1回〜 インストール編

1.ダウンロードサイトより、以下のファイルをダウンロードします。



2.ダウンロードしたファイルをダブルクリックします。


3.以下のダイアログが表示されるので、[Next]を選択します。



4.インストールするディレクトリを設定します。




5.スタートメニューに登録する名称を入力して、installボタンを押下します。



6.インストールが開始されるので、完了するまで待ちます。



7.インストールが完了したら、Closeボタンを押下して完了です。




ひとりはみんなのために・・・

 ひとりはみんなのために みんなはひとりのために

英語で言うと

  "one for all"
     "all for one"

この言葉を聞いたのは、小学校2年のときでしたが、
今でも、本当に大切な言葉なんだと思います。

仕事をしていて、一人でできる作業には限りがあります。
どんなにすごい人でも、1日に24時間しかありませんね。

人一人に与えられた時間は24時間だけです。
でも、人が10人集まれば、それで240時間あることになります。

単純な計算ですが、それを知っていると知っていないとでは、
管理者を目指す人間に大きな違いが出てきます。

この知恵を知っているうえで、どれだけ効率よくみんなで作業を行うか?
行わせることができるか?で、管理者としての能力が問われます。

もちろん、管理者という立場の人ではなくても、
この言葉を意識して作業を行うことで、自然とコミュニケーションが生まれます。

理想論ですが、きっちりと歯車がかみ合った組織は本当によい仕事をします。


ラインの引き方

皆さん!仕事の"やる""やらない"の線引きって、
どういう判断でやってます?

立場的に、断れないけど
断らないといけないケースがよくあります。

みんなで一つのものをつくっているのだから、
そんなわだかまりは作りたくないと思っているんですけど、
政治的な話か絡んでくると、下請けは辛いところです。


ため息つきすぎて、心配されました。



YESまんのススメ

 YESまん。

賛否両論あると思いますが、メリットもあればデメリットもあると思います。

まずは、デメリットのほうから、
なんでもかんでも「はい」と言っていると、
自分の意見のない人間と思われがちです。

そのため、新しい企画の仕事なんかを任せられるケースが少なくなるケースが多いと思う。

逆にメリットは?


メリットと言えば、上からの信用は厚くなります。
(ただし、YESと言ったことをしっかりとやれた場合のみ)
その信用を勝ち取れば、いろいろなチャンスが生まれてくるはずです。

と、ここまで読んでいて感じた人もいると思いますが、
正直、YESまんは一長一短です。
所属する会社や、所属する組織の空気を読んで立場を決めるのが一番良い方法です。

何が正しいのかを主観的に判断するのは非常に危険を伴う行為です。
主観的に判断して、行動に移したい場合は経営者になることを勧めます。

組織に所属する以上は、第一に考えるのは客観的に判断できる能力を身につけることです。
若い頃は、「自分の思ったことを自分の思った通りに無我夢中に行動する」タイプと、
「言われたことに対して、きっちりとこなそうとする」タイプと、「適当にやりくるする」タイプの人がいると思います。この選択は正直非常に難しいです。

なんせ、答えを持っているのは結果が出たときにしかわからないからです。
だから、自分の感じたままに行動するのが、一番後悔が少なくてすむと思います。

もし、失敗したと思ったら、
その行動をただせばいいのです。20代はそんな世代です。
失敗しても、まわりは大目にみてくれます。
それが20代です。30代になったらそうはいきませんからね。

よく言いますが、後悔をするのではなく反省をすることです。

反省をして次に生かせばいいのです。
例え大きな失敗を仕事でしたとしても、次の機会にその失敗を生かせばいいのです。

そんなこと、誰もが思っていて簡単にできるわけないと思われるかもしれません。
その気持ちでいいんです。次の失敗をすればいいのです。

30代、40代になっても失敗はします。
ひとつ違うとすれば、責任の取り方です。

よく政治家が、責任をとって辞職をするという話を耳にすると思います。
当然ですね。それが、そのかたの仕事なんですから。

当然、年齢が上がれば責任は重くなります。
そうなる前(自由にやってよい期間)に思いっきり失敗することです。

そして、反省してください。反省して反省して成長してください。

「反省は成長の糧です」

この事を常に念頭において仕事をしていれば、
必ずいつか報われます。だから若いうちはたくさん失敗してください。

どうしてもダメだったら、その仕事をやめれば済むことです。
今のご時世、仕事がなくなったら生活できないじゃないか!と思われる人もいると思います。
ただ、何もせず会社をやめていく人間ではなく、
いろいろな失敗をした上でやめていく人間では明らかに違う部分があります。

それは、
「失敗している」ということです。
失敗ほど大切なことはないと思います。


リスクマネージメント

 IT業界・・・

常にリスクと隣り合わせで仕事を進めなければいけない業界。

どんな作業にもリスクが存在し、問題が発生すれば即座に対応策を考える。

立場によって、考えることは違うけれど
その場、その場でリスクと上手に付き合っていく必要があります。


そんなリスク管理ですが、
別に難しいことではありません。

要は、
■リスクが発生する要因
→情報収集

■リスクが発生したときの被害
→自分(達)が被る被害

■リスクが発生した後の対策
→どのように対策が行えるのか?また、行えないのか?

こうやって書くと、難しく感じるかもしれませんが、
皆さんが普段何気なく行っているリスク管理だってあると思います。

私の場合ですと、
朝シャワーを浴びるときに、熱いお湯の出る蛇口と冷たい水の出る蛇口があるのですが、皆さんはシャワーを浴び終わった後に、どうやって蛇口をしめますか?

私の場合は、やけどが怖いので、
必ず熱い蛇口をしめてから、冷たい蛇口をしめるようにしています。
(そのとき念のためシャワーの水が出るところは、壁に向けておきます)

これも立派なリスクマネージメントです。

この場合ですと、
■リスクが発生する要因
熱いお湯が体にかかる。

■リスクが発生したときの被害
やけどする。

■リスクが発生した後の対策
軽傷であればそのままにし、
重症であれば病院へいく。

普段何気なく行っているのは、
リスクが発生したときのこと(痛みを伴うこと)がいやだということ。
そして、発生した後に金銭的な無駄が発生するということを無意識のうちにやっているからなんです。

このことは、体が勝手に覚えてますので慢性的に行うことができますが、
仕事の場合はそうではありませんね。

そこが難しく感じられる点なんだと思います。
この問題を解決するには、トレーニングを行うしかありません。
OJTでもOffJTでもよいのですが、こつこつと経験(バリエーション)を増やしていくしかありません。



求心力

新世紀エヴァンゲリオン 序

今日、自宅でゆっくりと一人で見ていました。


テレビ放送版のリメイク?なのかな。

碇 シンジを見ていると、人間的弱さというか、若いころに抱いた反抗心というかを、
すごく上手く表現していると思う。

見ていると、どんどんのめりこんでいくんだけど、
どこか歯痒いシーンも多く、ハッキリしろよ!!!!

とか心の中で突っ込んでいました。

人の事をとやかく言うのは自分の嫌いな一面だからだそうです。
(あらあら、碇くん・・・・私は歯痒いのか・・・)

エヴァみたいな名作に限らず、一気に物語に引き込まれることってよくあると思う。
"求心力"というのだろうか。
どんどん引き込まれていく感じは何とも言えず、集中力も非常に高い状態を維持していると思われる。

この状態を仕事をする上で、自由自在に操れるようにすることで、
業務を円滑にこなすことができると思う。

私の場合は、いつもモチベーションを一気に上がるために、
次のことを意識して仕事をこなすようにしている。

ー分のできる限界を少しこえるくらいの作業スピードでやる。
難しいと思わず、簡単に終わると思う。
Cかの喜ぶところを意識して作業を行う。

と、まずは上述したようなことを意識して、
作業を一気に終わらせるように集中力を高めます。

最後に、終わった後に必ず自身を褒めてあげてくださいね。


ただ、問題が・・・
簡単と思っていた作業が、難しいことがよくある。
この場合、下手をすると一気にモチベーションが下がるケースがあります。

もちろん、この状態を防ぐことは難しいです。
とりあえず、モチベーションを下げるしかないです。

ただ、モチベーションが下がるということを意識して、下げることです。
あらかじめわかっていれば、自分の状態を客観的に見ることができます。

自分自身を客観的に見ると、仕事も違う視点から見ることができ、
結果的に、良い解決策を見つけることができると思います。


どこの本を読んでも書いてあると思いますが、
自分の中で腑に落ちていれば、案外どんな出来事も素直に受け取れると思います。


国語の試験について思うこと!!!

 本日のお買いもの♪

戦国合戦 15のウラ物語(PHP文庫)

もともと、日本史は弱いんだけど、
大阪に来てから、様々な縁で触れる機会ができたので、今回も思い切って買っちゃいました。
(衝動買い大好きです)

ウラ話というところにひかれたんだけど、
本当のグリム童話とかも気になります。
(話それた・・・)

そうそう。
話は変わるだけど、中学校のときに非常に強く疑問として思っていたことがあるので、
ちょっと、そのときの思いを書いてみます。(同意してくれる人はいるのだろうか?)


小学→中学→高校と国語は基本科目?としてずっとお世話になると思うんだけど、
国語の試験で、漢字の読書きや四字熟語の意味などを問う問題は、全然許せるんだけど、
読みとり問題ってあるじゃないですか?

たとえば・・・

「このとき、作者は何を思っていたでしょうか?」
みたいな問題。

まだね。
「ここでいう"それ"とは何を指しますか?」
とかいう問題は許せます。許せるんですよ。
きっと、ソレが指している答えは、問題文から読み取れますからね。
(私には無理でした)


でもね!
「このとき、作者は何を思っていたでしょうか?」
これ、私の中ではかなり悪な問題に思えるのです。
(本当、国語好きはこれ以上読まないほうがよいかもww)


だってですよ。





そのとき作者が思っていたことなんて、誰にもわからない!!!!




んですよ。
というか、と思っていたんですよ。(今でも)


もしかしたら、トイレに行きたかったかもしれない・・・
その日の晩御飯のことを考えていたかもしれない。


何を思っていたのかを第3者に答えさせるのって、
「わかるわけないじゃん!!!」ってのが私の思いです。(ちっちぇ〜かも)


まぁ。問題のニュアンスが少し違っていたかもしれないけど・・・




でも!

私、国語が大の苦手でしたから!!!
小説を真面目に読み始めたのは、25歳くらいからですから!!!


こうやって書いていると、
自分が国語が苦手だった言い訳をしているように思えてくる。




図星ですけど。


関連会社
株式会社ツクル
誠意と創意で技術を社会に活かすIT企業
          
          
時計
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>
Amazon
selected entries
categories
archives
recent comment
recommend
links
profile
search this site.
sponsored links
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM
2008JUGEMキャラコングランプリ
キャラクターデザイン:磯崎洋助/「おしゃれひつじ」