Archives | Tumblr | Facebook | bullet-feed.pngRSS
TOPソフトウェア開発

誰でもわかるIT用語「再帰」

 「再帰」と言う一見難しい概念を理解するためは、下記のリンク先で実感するのが一番の近道です。

 » Giles Bowkett: Recursion Is Easy To Understand

 訳します。

I got tired of all these blog posts explaining simple concepts in unnecessary detail, so I wrote up the simplest possible explanation of recursion.
 (シンプルに説明できる概念を、不必要な程具体的に書いている全てのブログに飽き飽きしたので、私は再帰について、最も単純だと思われる説明を書き上げました。)

Want to know what recursion is?
 (再帰がなんだか知りたいですか?)

Click here.
 (ここをクリックしてください。)

 なるほど。とても良く分かりました。

 ハイパーリンクがあるHTMLだからこそ成せる技ですね。すばらしい。

このエントリーをはてなブックマークに追加

心に響く、プログラム、コンピューターに関する優れた格言、名言

 何度か紹介している下記の"Stack Overflow"は、エンジニアのためのQ&Aサイトです。

 » Stack Overflow

 このサイトの、人気があるQAの中で、"great programming quotes(凄いプログラミングの格言)"と言うのがありましたので、その中から、特に心に響いたものを抜粋して和訳します。

 » Great programming quotes - Stack Overflow

 <余談>記事を投稿しようとしたら、このQAに掲載されている格言とオーバーラップしている全く別の記事を見つけてしまいました。しかも、すでに和訳されている文章がかなりあります。まぁ、ここまで作って、途中でやめるわけにも行かなかったので、このまま投稿しようと思います。今回掲載する訳文については、一応、自ら訳したオリジナルです。</余談>

Hofstadter's Law:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
 ( ホフスタッターの法則:作業は、いつだって予測以上に時間がかかるものだ。ホフスタッターの法則を計算に入れても。)

 格言が再帰してます。

Walking on water and developing software from a specification are easy if both are frozen.
-- Edward V Berard
 (水の上を歩くのと、仕様からのソフトウエア開発は、簡単だ。・・・両方とも凍っているならの話だが。)

 「凍っちゃってる仕様は、作ってもあまり意味が無い。」って話もあるけども。

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-- Brian Kernighan
 (デバッグ作業は、最初にコードを書くときよりも倍難しい。したがって、自らの知恵を出来る限り振り絞って書いたコードは、その定義上、自分自身でデバック出来ない。)

 何にでも余力は必要。

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-- Rick Osborne
 (コーディングは常にこう、心がけるのだ。出来上がったコードを最後にメンテナンスするのが暴力的な精神病者で、そして、君の住所を知っていると。)

 コードやコメントに、証拠や個性を残すべからず。

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
--Tom Cargill
 (初めの90%のコードは、開発時間の90%を占める。残りの10%のコードは、他の90%の開発時間を占める。)

 足したら180%。

 これは、下記の格言からの変形。

The first 90% of the code accounts for the first 10% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."
-- Jon Bentley
 (初めの90%のコードは、開発時間の10%を占める。残りの10%のコードは、他の90%の開発時間を占める。)

 これでも十分、心に響く。

Java is to JavaScript what Car is to Carpet.
 (JavaScriptにとってのJavaは、「カーペット」にとっての「カー」。)

 格言と言うか、ジョークの類かも。

 追加で、下記のサイトからの格言を、いくつか抜粋して訳します。

 » 101 Great Computer Programming Quotes

There are only two kinds of programming languages: those people always bitch
about and those nobody uses.
-- Bjarne Stroustrup)
 (この世には、2種類のプログラミング言語しかない。皆が常に不平を言う言語と、誰も使わない言語。)

 言語に限らず何にでも当てはまる。

The trouble with programmers is that you can never tell what a programmer is doing until it's too late.
-- Seymour Cray
 (プログラマーの困った点は、手遅れになるまで、何をしているか、けして分からないことだ。)


 ぐさり。

Don't worry if it doesn't work right. If everything did, you'd be out of a job.
-- Mosher's Law of Software Engineering
 (うまく行かなくても気にするな。全部うまく言ったら、君の仕事はなくなるのだから。)

 自分(もしくは、誰か)が掘った穴を自ら埋める。これがすなわち仕事。

First, solve the problem. Then, write the code.
-- John Johnson
 (まずトラブルを解決し、それからコードを書け。)

 理想:コードとは、仕様を書き落とした物。

To iterate is human, to recurse divine.
-- L. Peter Deutsch
 (繰り返し処理は人の技。再帰的呼び出しは神の業。)

 再帰は、時に人智を超える。

There is no programming language--no matter how structured--that will prevent programmers from making bad programs.
-- Larry Flon
 (下手なプログラムの作成を防げるプログラミング言語は存在しない。たとえどんなに構造化されていても。)

 そして、構造化されすぎた言語は、誰も使いこなせない。

Writing in C or C++ is like running a chain saw with all the safety guards removed.
-- Bob Gray
 (C言語やC++で書くと言う事は、まるで、全ての安全装置が取り外されたチェーンソーで作り上げるようなものだ。)

 斧とも言う。サーバーを真っ二つに割るくらい酷くなる事も。

Good code is its own best documentation.
-- Steve McConnell
 (優れたコードは、コード自身が最良のドキュメントとなっている。)

 優れすぎたコードは、凡人には理解できない、という話もある。

You can't have great software without a great team, and most software teams behave like dysfunctional families.
-- Jim McCarthy
 (素晴らしいチームなしに、素晴らしいソフトウェアは生み出せない。そして、大部分の開発チームは機能不全の家族のように振舞う。)

 確かに。酷いと家出とか引きこもりなど、発生するね。

If debugging is the process of removing bugs, then programming must be the process of putting them in.
-- Edsger W. Dijkstra
 (デバッグ作業が、バグを取り除く過程であるならば、プログラミングとは、バグを入れ込む過程でないとおかしい。)

 リリースとは、「バグ」を「仕様」に変化させる工程である。

But what is it good for?
-- Engineer at the Advanced Computing Systems Division of IBM, commenting on the microchip, 1968
 (で、それは何に使えるの?)

 苦労すればするほど、元のコンセプトから外れていく。

2009.5.23追記
 コメントでアドバイスいただいた点を一部直しました。ありがとうございます。

このエントリーをはてなブックマークに追加

『なぜ、プログラミングは楽しいのか?』に対する素晴らしい答え

 『なぜ、コンピュータープログラミングは楽しいのか。なぜ、僕を含めプログラミングに携わる人々は、何度も辛い目に遭いながらも、この職種から遠ざかる事が出来ないのか・・・?』

 この問いに対する答えが下記のサイトに載っていました。ここには、プログラミングの本質的な楽しさが書かれています。

 ? Why is programming fun? An extract from Fred Brooks' (Frederick P. Brooks Jr.) book, The Mythical Man-Month

 この書籍の日本語訳「人月の神話」はこちらです。

 以下、抜粋した引用です。難解な部分もある英語ですが、可能な限り、僕のつたない超意訳も併せて載せます。

Why is programming fun?
 (なぜ、プログラミングは楽しいのか?)

The below is an extract from Fred Brooks' (Frederick P. Brooks, Jr.) book, The Mythical Man-Month. This is one of the best explanations of why programming is so interesting. It touches on all aspects of the mystique of programming.
 (下記は、フレッドブルックス(Frederick P. Brooks, Jr.)の本、題名「人月の神話」から抜粋したものです。これは、「なぜプログラミングがこんなにも面白いのか?」と言う問いに対する理由の中で、最も素晴らしい説明の1つです。それは、プログラミングの神秘的な面、全てに言及しています。)

The book was first published in 1974 and then republished in 1995. What Fred Brooks had to say then based on his experiences with the development of the OS/360 system is still relevant today.
 (この本は、1974年に初版が出版されて、それから1995年に再版されました。OS/360システムの開発に接したフレッドブルックスが、その当時彼の経験から言った事は、今日でもそのまま適応できます。)

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.
 (第一に、プログラミングには、物を作る本当の喜びがあります。子供が泥のパイ作りに喜びを得るように、大人が、物作りを楽しむように、特別な物を、自分自身の設計で作り出す事が出来ます。)

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."
 (第二に、プログラミングには、他の人にとって有益であるものを作り出す楽しみがあります。心の奥底で、私達は、自分達が作った物を他の人に使ってもらい、それが役に立つとわかって欲しいと思っています。この点でプログラミングシステムは、子どもが始めて作る「パパのオフィスの為」の粘土製鉛筆ホルダーと、基本的に同じです。)

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
 (第三に、プログラミングは、可動部分を連結し、それらが微妙なサイクルで動くのを見る事、つまり、複雑なパズルのような対象を形作る魅力があります。原則によってもたらされる結果の展開を初めから組み立てられます。プログラムされたコンピュータには、ピンボールマシンやジュークボックス機構が惹き付ける魅力の全てがあります。そして、最後までやり通せます。

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
 (第四に、プログラミングには、常に学ぶ喜びがあります。問題は常に新しいものです。そして、問題を解く人は常に何かを学びます、時には、実地で。時には、論理的に。そして、時々は両方から。)

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (...)
 (最後に、プログラミングには、とても扱いやすく加工しやすい媒体で動かせる楽しみがあります。クリエイティブなほとんどメディアはこれほど柔軟でありません。そして、磨き、調整するのがとても簡単で、すぐに、壮大な概念構造を形作る事が出来ます。)

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
 (それでも、それが動き、実際に作用するという点で、プログラム構成要素(それは、詩人の言葉とは明らかに異なる)はリアルです。そして、目に見えるアウトプットを構成された概念そのものから作り出します。それは結果を印刷したり、絵を描いたり、音を出したり、機械の手を動かします。「神話と伝説の魔法」は、我々の生きている今、この時代に実現しました。人々はキーボードで的確な呪文を入力します、そして、表示スクリーンは生き生きと反応します。そして、今まで無かった、存在することも出来なかったものを見せてくれます。)

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
 (全ての人々が同じように持っている喜びの感情と、我々の奥深くに眠っている創造的な欲望を満足させるので、プログラミングは楽しいのです。)

 ...残りの記事を読む

このエントリーをはてなブックマークに追加

英語とプログラミング言語はかなり似ていると思う

 今読んでいる本。

 これまで、簡単な英文法の本と単語だけで英文を読もうと思っていたのですが、いよいよ限界を感じ始めてきたので、この本を手に取ってみました。

英語リーディングの秘密英語リーディングの秘密
薬袋 善郎

研究社出版 1996-10
売り上げランキング : 37724
おすすめ平均

Amazonで詳しく見る
by G-Tools

 この本は英語の構文を品詞ごとに細かく分類して、理論的に英語を読み進める手伝いをしてくれる本です。普段からプログラミング言語に慣れ親しんでいる、理屈っぽい...いや、理論的思考を持った、IT業界の方々にぴったりだと思います。

 英語と言うものが、文系だけではなく、いわゆる「理系」と言われる方々にも興味を持っていただけるような、論理的に考えるコツと言うものが書いてあります。少なくとも僕は、「この発想は今まで無かった」、と面白く感じています。

 中には、構文解析の為に記号が山の様に出てきますが、これがなんともプログラミング言語的な雰囲気を感じさせます。

 で、まだ半分ほどしか読めていませんが、この本を読み進めていくうちに、英語の記述方法と、プログラミング言語の共通点がなんとなく見えてきました。

 僕が、こんな共通点を無理やりでも見つけようとする原因の一つは、「プログラミング言語と似てるなら、英語も時間さえ掛ければ理解出来るだろう」と言う考え方を持って、やる気を少しでも高めたいからです。

 今のところ、僕が「英語」と「プログラミング言語」で似ていると思う共通点を列挙してみます。

  • 英語は、曖昧さが非常に少ない言語。きっちりしたルールで記述しないと文法的におかしくなったり、全く別の意味になってしまう。
  • プログラミング言語の命令で使用するパラメータが、いわゆる英語の5文型に良く似ている。
  • 不定詞や分詞構文が、プログラミング言語で言う、「関数のポインタ」の考え方に良く似ている。
  • 文の主従関係が、プログラミング言語で言う、「ネスト」の考え方に良く似ている。
  • プログラミング言語のコメントは、英語の形容詞や副詞。無くても通じるけど、無いと無機質だし、いろんな人に受け入れてもらえない。
  • プログラミング言語で最も重要なのは、命令文。英語では動詞が最も重要。

 だんだんとこじつけっぽくなって来たので、この辺でやめますが、よくよく考えてみれば、プログラミング言語のそもそもの成り立ちは、英語的な考え方を持った欧米人が作成した言語なので、似通うのは当然かなと思いました。

 でも、今までプログラミング言語と戯れてきた、IT技術者の考え方として、「英語 ≒ プログラミング言語」だと思う思考法は、下記の2つの点でよいことだと思いました。

  • 「英語がプログラミング言語に似ているなら、英語も頑張れば出来るんじゃないか」と言う希望を持てる。
  • 「プログラミング言語が英語に似ているなら、プログラミング言語なんて英語に比べれば簡単じゃないか。」と言う楽観的な希望を持てる。
このエントリーをはてなブックマークに追加

社運を賭けていた「大作」がどうやらうまく行かなかった件

 以前、この件について書きましたが、『社運を賭けていると言われる「大作」』は、どうやら本当に発売延期となってしまったようです。

 以前書いた記事。

 ? 社運を賭けていると言われる「大作」や「大規模システム開発」は大概成功しない法則

 ニュース。

 ? 「ドラクエIX」発売延期の理由は 「油断していた」と和田社長 - ITmedia News

 延期した理由について、記事では下記の様に書かれています。

 実装が済み、本格的なデバッグに入った段階で「手強いバグがいくつもあることが判明した」という。バグの量は「とてもお客様に出せる状態ではない」ほど大量。「もう少しチューニングしようというレベルではなく、今出すべきでないことは明らかと判断した」

 延期に対する理由になってませんね。延期に至る要因と言うのは、必ずデバッグ中に発生します。実装中に遅れが発覚するようなケースは通常考えられません。もし実装中に何か起こった場合は、コンセプトや方針自体が変えられていくはずです。ですから、下記の発言に繋がっているわけですね。

 その上で「ドラクエやスク・エニに固有の問題が起きているわけではない」と釈明。

 しかし、「大作」とそうでないシステムでは、明らかに違う点があります。

 以前書いた僕の記事から引用しますが。

 「社運を賭けてる」と言われているシステムは、大概期限がきっちり定められています。それは、社運を賭けているがゆえ、業務計画としてある程度外向けに情報を公開しなければならないからです。それは株主に影響を及ぼすため、一度決めた計画を簡単には変更できません。

 つまりは、普通のシステム開発よりもはるかに計画変更がしづらいのです。この計画変更のしづらさにより、そもそも期間が変更されるリスクがとても高い大規模なシステム開発とは、性質が合わなくなります。

 どうも、上記の発言からして、『製品固有』の問題とは思ってない節があります。これではまた遅れるのではないでしょうか。そんな予感がしてなりません。

 実際、この発売延期によって、発売が期を跨いだため、業績予想を下降修正することになってしまいました。これにより、さらに計画変更がしづらいと言う、プレッシャーが圧し掛かってきています。

 延期された『4ヶ月』と言う期間についても、延期後の発売日が「7月11日」と言う事ですので、どうも夏休み前のタイミングにずらしただけと言う感じがします。

 社運を賭けるべき主力製品がある事は、とてもすばらしいですが、大作であるが故の難しさもあるのだなぁと感じます。必ずしも、定期的に発売する必要がない、連作物のゲームについては、前宣伝を極力せず、不定期に発売するなど、別の方向性からアプローチした方が良いのかもしれません。

 そう考えてみると、Nintendoは、狙ってるのか知りませんが、こういう事しませんね。さすがと言うべきなのか。

このエントリーをはてなブックマークに追加

現場のSE, PGが思いつかないデスマーチになる根本的条件とは

≫ 現場のSE, PGが考えるデスマる条件とは:アルファルファモザイク

1 仕様書無しさん :2008/06/03(火) 22:07:26

当方1年目の新人です。"デスマ"と言うのを最近知りました。
勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。

答え
 現場の手が決して届かない上層の政治的な部分から来る、長期的な観点から見て、会社が存続するためにやむをえない事情がある場合に起こりやすい。その辺りがそもそもの根本原因。

 ・・・だと思う。現場が思いつく条件なんてのは、所詮事前に逃げる為の参考にしかならないのだと思う。悲しいのだけど、これが現実。

 現場が思いついた条件はいくらでも出せるのだけど、いくら並べても解決にならないのがデスマの難しい所。

 たとえば・・・。

  • 予算が決まっている。
  • 納期が決まっている。
  • 仕様書が固まらない。

 などなど、良く言われるデスマーチの条件は、その会社が存続する為にはそうする必要があるからそうなってるのだと思われます。

 もし逆に、

  • 臨機応変に予算が変更できる。
  • 納期がコロコロ変えられる。
  • 常に仕様書がきっちり固まってから始まる。

 と言う会社だと、さっぱり仕事が取って来れず、デスマ以前に会社が存続出来ない可能性があります。そういったやむをえない事情から、必然的にデスマになりやすい風土が作られていくのだと思いますよ。

 結局デスマを生む会社の存続が更なるデスマーチを生んでるって事ですかねー。結果、そのような会社が一掃されないと無くならないって結論だと、お先真っ暗になってしまいますね。困りました。

参考になる
≫ 「現場のSE, PGが考えるデスマる条件とは」 - カレーなる辛口Javaな転職日記

 もう、現場レベルではこれが全てです。

このエントリーをはてなブックマークに追加

社運を賭けていると言われる「大作」や「大規模システム開発」は大概成功しない法則

 下記のはてな匿名ダイアリーを読んで。

 「大作」と言われるゲーム開発を始め、IT業界における大規模システム開発は、その事例自体、元々失敗するファクターを多くはらんでいると思います。大規模であればあるほど、原因は特定の人間でない事が多いです。

 現場にやる気がないのだけは真実らしくて、それは一番偉いクリエイターが気まぐれすぎて下請け会社の作業がストップしたことがあるからだと言っていた。

 これは非常に良くあるケースです。

 大作を作るための下地や準備期間があまり無く、見切り発射すると、方向性を決める権限が特定の人物に集中しがちです。決められたコンセプトだけが一人歩きして、伝達する手段がなく、それを具現化するチームも存在しないため、下請けまで砕かれた仕様が伝わらないのでしょう。

 「社運を賭けてる」と言われているシステムは、大概期限がきっちり定められています。それは、社運を賭けているがゆえ、業務計画としてある程度外向けに情報を公開しなければならないからです。それは株主に影響を及ぼすため、一度決めた計画を簡単には変更できません。

 つまりは、普通のシステム開発よりもはるかに計画変更がしづらいのです。この計画変更のしづらさにより、そもそも期間が変更されるリスクがとても高い大規模なシステム開発とは、性質が合わなくなります。

 「大作」と言われるゲームの場合、オリジナル(パート1)はそのようなプレッシャーや明確な期限が引かれていない為、比較的自由に開発を行うことが出来ます。しかし、そのゲームが当たってしまい、大作と呼ばれるようになると、上記の様な金銭が大いに絡むプレッシャーが乗っかってきて、パート1では普通に出来ていた自由度のある開発が束縛され、どんどんやりにくくなります。

 これは、銀行やガス、電気などのインフラのシステムでも同じことが言えます。絶対に止めてはいけないと言われる業種では、そもそも大規模システム開発と言う物自体、相性が良くないです。

 このような状況で開発を始めると、現場サイドと上層部の意識に必ず隔たりが生まれます。プレシャーをまともに受ける上層部と、遅れを取り戻せない現場サイドでは意識的ギャップが大きすぎて、上手く意思疎通が図れません。

 「気まぐれ」と言われてしまったクリエーターも、上層的な意識に取り込まれている為、現場サイドから見ると気まぐれに見えるのかも。

 一旦このような状況になるともう手が付けられません。根本的な原因が分からない限りは、どのような応急対策を行っても永遠に遅れを取り戻せません。大作と名が付き、続編となってしまった時点で、そのゲーム開発の性質が変わってしまったのです。

 まぁ、だからと言って、大規模システムを成功させる秘訣なんてものは僕には分からないのですが。

 少なくとも、特定の個人を非難するのはおかしいと思いますよ。

関連記事

 まぁ、言わずもがな、ですけど、一応。

このエントリーをはてなブックマークに追加

「仕事は燃えてこそなんぼ」全てのマネージメントに関わる人々が読むべき素晴らしい記事

≫ 成果主義が失敗したいまだからこそ、社員が仕事に燃える理由を探す:NBonline(日経ビジネス オンライン)

 文頭から文末まで、全編に渡って同意出来る、素晴らしい記事です。全てのマネージメントに関わる人々が読むべき文章だと思います。僕は基本的に全て激同意なので、自分の意見は入れられないかも知れませんが、注釈を入れながら紹介していきます。

 ここに書かれている事が、まさに僕の身近な所で起きています。

しかし、2000年代初頭に入り、成果主義の流れは行き詰まってきた。「成果に応じて給与が上がる」と言われても魅力を感じなくなってきているのである。1990年代以前は年功序列的な処遇が定着しており不公平感があったため意味があったと考えられるが、年功序列的な処遇が多くの企業で崩壊している現在では、社員に成果主義は魅力的に映らない。

 元々、成果主義には懐疑的でした。結局、管理される側からすれば、成果主義といわれても、制度的な置き換えと言う観点でしか見ていません。「なーんだ、給与体系がちょっと変化しただけか・・・。」なんてすぐ見透かされてしまいます。そして、形だけの成果主義が未だ続いている状態です。

 成果主義が導入された当初は、「仕事してる分、せめて給料が上がらないとやってられないよ。」と言う考え方にある程度マッチしていましたが、最近そんな言葉さえも聞かなくなりました。一時的に潤うカンフル剤のようなアメでは、効果が出なくなってきたのだと思います。

 そして、下記の6つの背景。誰もが感じている事だと思います。近年における労働の6大傾向と言っても良いのではないでしょうか。

  1. 上昇を求めない社員が多い(または増加した)
  2. サービス業の感情労働という特性
  3. 仕事の難度の高まり
  4. 職員の志向の複雑化
  5. 権威の喪失
  6. 成果主義制度に対する慣れと諦め

 僕も全てに思い当たる節があります。全てが、仕事への動機付けはお金で解決できないと言う方向を示唆しています。全てのバックグラウンドは、職が確保されれば、いくら不況とは言え金銭面で必死になる機会がほぼなくなったと言う事じゃないかと思います。

 このような背景から、「内発的動機付け」が無ければ、社員はすすんで仕事をしないと言う事に繋がっていきます。その手法として6つの手法を提案しています。

(1)自己認知支援 (2)安心できる環境づくり (3)成長機会提供 (4)哲学形成 (5)使命感の創出 (6)コミュニケーション

 「知識労働者」と言われる職種の動機付けは、この6つの手法に則って仕組みを作ってやれば上手くいきそうな気がします。たとえばIT業界の場合、マネージメントの立場から出来るのは、下記のような事ですかね。

(1)自己認知支援
 職務的権限をまずハッキリさせる。決裁権限など金額的な線引きはきっちり行って、迷いが無いようにする。個人の出来る出来ないを切り分けやすくするため、チーム内メンバーの役割を明確化する。

(2)安心できる環境づくり
 ベースは安定した給料。また、サービス残業をなくし、残業に対する報酬は必ず支払われるようにする。休日や夜間呼び出しなどを出来る限り無くす仕組みを作る。(保守と開発の線引きを明確化する)特定の社員に負荷が集中しない体制を作る。

(3)成長機会提供
 成長を促進する為、業務時間内でチャレンジ出来る体制とその発表機会を作る。教育制度を確立させ、体系化した社員教育を行う。可能であれば、転職したときでも役に立つような知識と資格を取れるような制度にする。

(4)哲学形成
 最初は絵に描いた餅でも良いので、企業理念やビジョン、経営方針などを掲げる。その理念等が利益だけでなく、社会的価値へと繋がっている事が望ましい。

(5)使命感の創出
 企業理念に則って、実現可能なレベルの目標を設定する。それらの目標はいくつかに分けて、個々のグループでそれがクリア出来る様に仕向ける。

(6)コミュニケーション
 複数の部署に渡って横断的な作業チームを作り、全体で考えなければいけない課題を与えるか、飲み会を開くでも良いと思う。今は少なくなったけど、社員旅行とかを見直して、定期的に行うのも良いかもしれない。

 1以外は、もはや平の1社員が出来ることでは無いのですが。6はまぁ出来なくもない。たとえ部下が数人だったとしても、その中でやれることはあると思います。

 どちらにしても社員一人ひとりが「腑に落ちた」という状態まで話し合わなければ意味がないと記事では書かれています。そういう意味で、このピラミッドの最も下の層では、「直属の上司と部下の間での意思疎通」と言うのがあるのかもしれません。

 僕自身もモヤモヤしていた事が、この記事を読んでだいぶ「腑に落ち」ました。しばらくこれをテンプレートにして仕事していきたいと思います。

このエントリーをはてなブックマークに追加

『プログラマの慢心。IT業界の現状。』を読んで

はてな匿名ダイアリー

 ...残りの記事を読む

このエントリーをはてなブックマークに追加

プロジェクトの遅れを取り戻せない方法10選

projectイメージ

 ...残りの記事を読む

このエントリーをはてなブックマークに追加