「killする」とは

コンピュータ上で動いているプロセスを強制的に止めること。

Linuxのコマンドの「kill」が語源。動いているプロセスを問答無用で停止させることができる、その名にふさわしいコマンドである。

ソフトウエアを動かしている時に、正規の手段で停止（×ボタンを押すとか、止めるためのコマンドを打つとか）を試みたけどうまくいかなかった場合に、半ば投げやりに「もういいよ、killしてしまえ」のように使用する。

「隠ぺいする」とは

プログラムの、ほかの機能から参照される必要がない部分（クラスの中で内部的に使っているだけのメソッドなど）を、ほかのクラスから呼べないようにするためなどに使用する言葉。主に変数やメソッドの前に「private」という予約語を入れることで実現する。

一般的に「隠ぺい」という言葉は「情報漏えいがあったことを隠ぺいした」のような悪いイメージの言葉として使われるが、プログラムでは必要もないのに外から変数を呼べるようにしておくと、ちゃんと隠ぺいしておくべきと怒られたりする。

まれに進捗が遅れているのに隠ぺいしている人を見かけることがあるが、そちらは決してしてはいけない。

「悲観的」とは

排他制御をする際によく使う言葉。対義語は楽観的。

例えば２つのプログラムが１つのデータベースの同じレコードの値を書き換える時に、同時に値を「取得 → 計算 → 更新」という処理を行うと、ユーザが意図していなかった値に書き換わってしまう場合がある。

そんな時に、１人のユーザが操作している間はほかのユーザにそのデータを絶対に触らせないという意志を込めてロックしてしまうことを指して、「悲観的ロック」という言葉が使われる。

お金にかかわる計算を行う時は、無駄に思えるほど悲観的ロックが行われるケースをよく見かける。

「人柱」とは

【意味１】
アルファ版やベータ版などの正常に動くことを保証されていないソフトや、リリースされた直後で十分な実績を持たないミドルウエアなどに対して、果敢に挑戦する人たちのこと。

実績のないものを採用すれば、当然のように、不具合やら、相性やら、知識不足やらに悩まされて多くの困難が発生するものである。だが、そこで彼らが流した血と汗と涙の分だけそのソフトウエアには「実績」が生まれ、その知識が後世の役に立つことになる。ソフトウエア産業にとって彼らの存在は、まさに欠かせない人々である。

「永遠のベータ版」なんて言葉も使われる昨今においては、ただ単にベータ版をちょっと使ってみたという程度では必ずしも「人柱」と呼ばれるだけの地位が得られるかは分からない。

何億円もの予算が組まれているプロジェクトにまだ実績も大してない新しいミドルウエアを投入したり、私的にアルファ版や、そもそもコンパイルがどうかすら心配なナイトリービルド、製作者が「まだテスト不十分ですが、とりあえず人柱版として公開しときます」なんて公言してるものにまで手を出すような行為は、間違いなく人柱と呼べるだろう。

尚、世の中には製品版を名乗って人柱を募集する企業も多く存在するので、たとえ正式リリースと銘打ってあっても注意が必要だ。

例えば2007に出荷されたとあるOSのような、非常に複雑かつ多くのハードウエアが絡むソフトウエアは、リリース段階ですべてのバグが潰れているはずがないものである。そんな製品を発売日当日に買う行為もまた自らを進んで生贄にささげる人柱的行動の一種として捉えることができる。

【意味２】
誰もがやりたくないけれど、誰かがやらなければならない。そんな作業が目の前にあった時に、それを押し付ける対象を指して人柱と呼ぶことがある。

「この案件、どう考えても赤字にしかならないだろうな」と営業が呟いているような危険な案件を押し付けられてしまったプロマネや、「今回のリリースは月曜日の午前3時〜午前5時に行う予定です。つきましては、開発メンバーの中から2人ほど日曜の23時に出勤していただく必要があります」とかいう訳の分からない状況に付き合う羽目になったプログラマは、まさしく人柱と呼ばれる存在である。

世の中には性格的に人柱になりやすい人と、なりづらい人がいるようである。１度人柱になった経験のある人は、その後もことあるごとに開発現場の神に向かって生贄に捧げられる一方で、１度うまく回避した経験のある人は、その後もうまく人柱になるような事態を避け続けるといった光景を、開発現場では頻繁に目にすることができる。 この人柱になりやすさ、なりづらさを指して人柱ビリティと呼ぶこともある。人柱ビリティが高ければ高いほど生贄になりやすくなる。

自分の人柱ビリティが若干高めだなぁと思っている人は、悪いことは言わないので、早めにそのアビリティを下げる方法を探しておくことをオススメしたい。

「小人」とは

夜、人々が寝静まったころに開発現場に現れて、こっそりソースを書き換えてしまうといわれている伝承上の生物。

前日の帰り際に実行した時はちゃんと動作していたソースが、何も触っていないのに翌日急にエラーになったり、逆に昨日までバグっていたはずのソースが、翌日動かしたらなぜかきちんと動くようになっていたりと、不可思議な現象に遭遇した時に、彼らの名前が口にされる。

うわさに聞いた生態から判断すると、彼らは西洋の伝承などに出てくるブラウニーに近い存在のようだ。

一部の開発現場には、難易度の高いバグにハマって長時間もがいているプログラマに対して「きっと明日になれば小人が直しておいてくれるよ」という優しい言葉をかける風習があるらしい。もちろん、９割９分小人が現れることはなく、翌日もそのプログラマは同じバグと対峙することになるわけだが。

不可思議な現象は大抵の場合、本人は何も変えていないつもりだけれど、疲労困憊（こんぱい）した脳が無意識のうちに何かをやっていたとか、データ量が一定量を超えたり一定時間以上が経過すると発生するような時限式バグ（2000年問題もその一種）とかが原因だったりする。

それでも、開発をやっているとどれだけ調べても原因が分からず「これ、絶対に小人のせいだ」と思ってしまうような不可解な事象と遭遇することが、けっこうあるもの。

「レガシー」とは

車の名前ではない。そちらはレガシィと表記するようである。

古き良きシステム、もしくは古き悪しきシステムを指す言葉。

エンジニアにシステムの改修を依頼する時に「ちょっとレガシーなシステムなんですけど」と付け加えると、苦笑されたりする（体験談）ところを見ると、どうやら古き悪しきものというイメージのほうが若干先行しているような気がするもの。どれくらい前のシステムをレガシーと呼ぶか、その線引きは主観に任されるところが多い。

また、ごくまれに見かけることがある冷蔵庫より大きいサイズの汎用機などは、中身がどうかは別として、昨今の省スペースなブレードサーバなどと比べると見た目がレガシーという感想を抱いてしまったりするもの。

ただし、古い時代から動いている分、データの整合性や安定運用といった実績面については、十分な信頼性を持っているため、ただ古いからという理由でないがしろにしてよいわけでもない。

普段、新しいシステムとばかり触れ合っている人が、うっかりこれらのシステムとかかわることになると、異国の地に放り出されたような感覚を味わうことができるかもしれない。

「冗長」とは

一般的には、余分とか、余計とか、無駄といったちょっとマイナスなイメージがある言葉。

プログラムの世界でも、例えば「冗長なソース」と言うと、同じようなことを何度も書いているような「無駄が多い」、「余分な記述が多い」ものといった意味合いで受け取られる。

実際にシステム開発の現場では、ちょっとした機能追加があるたびに、コピー＆ペーストでソースが展開されて3,000行ずつステップ数が増えていくといった、ダイナミックに冗長なコードを見かけることがよくある。

ところが、この「冗長」という言葉に、たった１文字「化」という言葉を後ろに付けると、急にプラスの意味として使われるあたりがこの言葉の不思議なところである。

代表的な使い方として、ストレージの冗長化（同一のデータを複数のディスクに重複して持たせ、データの破損に備え……　えーと、つまりRAID）が挙げられる。

また、DBで頻繁に結合が発生するテーブルを、データの重複が発生することを認識したうえで、あえて１つのテーブルにまとめてしまうといった冗長化も見かけることがある。

「強力な」とは

ソフトウエアやプログラミング言語の紹介などをする際によく使われる言葉。

「この言語の最大の特徴は強力な正規表現機能を有していることです」とか、「このソフトウエアは強力なメモリ回収機能により長時間の安定した動作が可能です」といった使われ方をする。

この言葉は「便利」という言葉とも少し違うし、「簡易に実現できる」というのとも違う場面で使われる。どういった機能を「強力」と呼べばいいのか、明確な線引きは難しい。

ただ、Perlの正規表現を使っている時にふと「Perlはこの辺が強いなぁ」と思ったり、C++のテンプレートを使いこなしたコードを見た時に「さすがC++は強い」といった気持ちを抱くことがある（筆者主観）ことから、きっと人の心に「強い」という感覚を抱かせる何かがプログラミング言語の中には存在するのだと思われる。

ソフトウエアハウスやベンダーの宣伝文句の中にも、よくこの「強力な」という文字を見かける。それらの機能はデモを見た時には「確かに強そうだなぁ」と思えることが多いが、実際に使ってみても強いと思えるかについては未知数である。デモの優秀さには誤魔化されないように気を付けたいところである。 

「柔軟な」とは

フレームワークやパッケージソフトの売り文句によく使われる言葉。

「柔軟な拡張が可能」とか、「柔軟な設定で多彩な動作を実現できる」といった使われ方をする。

フレームワークの基本機能を継承して、さらっと新しい記述を足しただけで望みの機能を実現できたりしたら、「このフレームワークは柔軟だなぁ」と思えたりする。逆に継承したい情報が「private」に設定されていて、望みの機能を実現するために結局元のソースをコピペして拡張しなければいけなかったりすると、「あまり柔軟じゃないなぁ」と思えるもの。

パッケージソフトでも、設定ファイルを少し変更するだけで望みの機能が実現できると、「柔軟な良いソフトだなぁ」と思えるもの。逆に設定項目はたくさんあるのに、どう設定してもなぜか欲しい機能に一歩届かないようなソフトだと、「硬い」という心証を抱いたりするもの。

「あちらを立てればこちらが立たぬ」とは

仕様を考える時によくぶつかるシチュエーション。

よくある例としては「ユーザの利便性を立てればセキュリティが立たぬ」とか、「IEを立てればFirefoxが立たぬ」などがある。

限られた予算と限られた期間の中で行われる開発は、頻繁にこの種の問題にぶつかり、何かを切り捨てなければいけないという選択が必要となる。何を切るべきかを検討するために頭を使うというのは、少し寂しい作業である。

お客さんを立て過ぎると自社の利益が立たず、自社を立て過ぎるとお客さんとの関係が険悪になるなどのシチュエーションも頻繁に見られるもの。