applesという具合に複数形のsがつくけど、これ、0の時はどうでしたっけ?という話題。pointsで正解です。いわれてみるとそんな気がするけど、不思議不思議。いう時は、Google英語検索の検索結果でどっちが多いかを比べてみます。resultsおお、たしかに複数形の方が多数派です。byte”が混じっている掲示板なども普通に見られるし、0byteと書く人もいっぱいいるみたいだけど、複数形で書くのが多数派なのは間違いなさそう。ちなみに、普通にGoogleで検索すると日本語を優先して検索しますので、日本語ユーザーの英語でどうなっているかを見ることになってしまってあんまり意味がありません。英語でGoogle検索する方法については過去に説明したのでこちらをどうぞ。Google英語検索ブックマークレット-もぎゃろぐGoogle英語検索フォーム-もぎゃろぐおまけ:自分の知り合いがラングリッチという英会話教室を始めました。Skypeで学べるオンライン英会話教室です。興味のある人は見てあげてね。英語コメントする社内公用語を英語にすると何が起こるか派遣プログラマ時代の思い出が反響いただいているようでありがとうございます。一応言っておくと、本当に経験した話です。書いてない話はあるけど書いてあることはだいたい本当。ところで、そのラピュタですが、日本企業と外資がくっついて出来た職場だったので、公用語が英語でした。スタッフの40%近くはインド人で、20%くらいそれ以外の国の人もいて、残りが日本人なので、英語ネイティブを無視して仕事はできない状況です。日本人がほとんどの状態で「公用語を英語にします」と宣言してしまった会社とはだいぶ状況が異なるとは思うのですけど、英語が得意でもない日本人が英語で仕事することを求められたらみんなどうするかというのはやっぱり面白い気がするので、こっちも書いてみようと思います。公用語が英語といっても、別に社内で日本語を口にすることが禁止されているわけではありませんでした。お昼休みは、日本人同士で固まって食事に行くので、そういう場面での会話は日本語です。他の国の人たちも、だいたい同じ国の人が固まることが多かったです。少数派の国の人たちは、余りっ子組みたいなのを作ってましたが。自分、「これってもしかして英語力を上げるチャンスじゃね?」とか思ってインド人のみなさまと食事に行くことを試みたのですけど、相当難しいです。後述するように食べるものが違ってますし、彼らは彼らで食事の時くらい自分たちの言葉で雑談したがるので、居心地が悪くて、結局自分の会社のグループに戻ってきてしまいました。メールについても、日本語と英語が半々くらい。公式な連絡(会議の通知とか)については、すべて英語でした。正確に言うと、元が日本語のメールには必ず英訳がついてくるのに対して、英語のメールに日本語訳がついてくることは原則ない、という感じ。公用語が英語なので、「英語のメールなので読み飛ばしていました」的ないいわけは許されないことになっています。いえ、大学で掲示板を見てなくても友達経由で試験日程を知っている人がいたように、日本人の同僚が助けてくれるからボ~っとしていても何とかなっちゃう人は存在していました。会議について会議は英語で行われます。ルールでそうなっているのもあるけど、会議のメンバーに日本語が分からない人がいるからそうならざるを得ない。会議の進行役の人は、可能な限り英語で議論する場面は減らしたいから、一時間の会議に二時間くらいかけてアジェンダを作ります。半分くらいは使いそうな英語をチェックしておく時間だけど、結果的に議事録ドリブンな会議になったので、これはこれで有益だった気がします。日本人しかいない会議があると、とっとと日本語で片付けてしまうことは普通に行われていました。予定の半分くらいの時間で終わって、日本語で話したのに議事録だけが英語で残ります。あと、会議中に話がややこしくなった場合、「ジャストアモーメントね」と話の流れを止めておいて、日本人同士が日本語で話をまとめてしまって、あとでそれを英語で説明するという裏技が普通に使われていました。職場には、部署に一人か二人、英語のスペシャリストが雇われています。日本語で重要なメールが流れた場合に英語にして再送するのがメインのお仕事ですが、重要な会議の時には通訳みたいな形で入っていただくこともあるし、日本人が書いた英語ドキュメントのレビューをお願いしたりすることも出来ました。100人以上のメンバーを一人で見ていますので、おいそれと仕事は頼めません。下っ端は自分で何とかするしかありませんでした。言い回しとかは教えてもらってた。ドキュメントについてすべて英語で書くことが求められていました。日本語で書かれたものはメモであってドキュメントじゃないみたいな扱いです。そんなこと言われたっていきなり英語のドキュメントなんてほいほい書けないので、みんなどうしていたかというと。1.似たようなドキュメントをコピペする過去のドキュメントは専用のリポジトリがあって、すべてそこから検索することが出来ました。そこで、ここから自分の書きたいのと同じような内容のドキュメントを見つけてきて、コピーして、必要なところだけ直せば英語ドキュメントできあがりです。プログラマ同士、ER図とかクラス構成図は世界共通の概念ですから、案外これで実用的な文書ができあがっていました。2.翻訳サイト大枠はコピペできますけど、ある程度は英語の文章を書く必要がでてきます。英語の文書を読まないといけない場面はもっとたくさんあったので、翻訳サイトへのアクセスは相当多く行われていました。ところが、こうやって翻訳される文書は、本来社外に出してはいけない書類とか、NDAを結んで入手したドキュメントもたくさん存在するので、それを社外の翻訳サイトにパカパカ貼り付けるのはどうなのよ、というのが問題になります。そこで、社内に専用の翻訳ソフトサーバが導入され、今後WEB上にある翻訳ソフトは使わずに社内サーバを使うように、とのお達しが通達されます。これが高いくせに全然使えないんだ・・・ろくな訳ができないことがでないことが知れ渡ると、こっそり社外の翻訳サイトを使う人が続出して、やがて社内サーバはほとんど誰も使わなくなりました。#個人的には、名詞だけ置き換えて使えばそんなに問題にならないと思うんですけどね。「Appleの新商品iMogyaの機能について」をそのままWEBに流すとまずいですけど、「Aの新商品Bの機能について」をWEBで訳して、AとBを元に戻せば、別に情報は流出しないですよね。飲み会この職場、何が大変かというと、飲み会が大変でした。米国では仕事が終わった後に飲み会なんて考えられないのですけど、日本の職場だし、日本に来ているインド人はたいてい独身だったので、打ち上げくらいは開催することが出来ました。インド人の中には菜食主義者の方がたくさんおられます。肉を一切食べない人、ブタが駄目な人ウシが駄目な人、人によって様々。この時点で、ほとんどの飲み屋さんは全滅します。白木屋とかありえない。最初のうちは、菜食主義者の人用メニューを用意してもらったりもしていたのですけど、お店としても出せる料理がほとんどなくて困ったメニューになることが多かったので、やがて、宴会は豆腐料理専門店で行われるようになりました。湯葉をつつきながらビールで乾杯。あ、たまにアルコールも駄目な人がいるので、湯葉を食べながらウーロン茶で乾杯する人たちもいた。飲みながら英語をしゃべるのは、慣れたら出来るんですけど、豆腐で宴会盛り上がるのはたいそう難しかったです。追記ごめん、今更なんだけど、見積もりは「60%と90%」じゃなくて「40%と90%」だったような気がしてきた。本質的には大きく違わないんだけど。この考え方の背景はこちらをご覧ください。システムの納期とは確率分布だ-Publickey(追記終わり)派遣PGとしてひどい目にあった人がいて盛り上がっている。某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。「これ参考にしてください」と言って渡されたフローチャートは双六のようで、最後から一つ手前に「仕様変更で振り出しに戻る」と書いてあっても驚かないような代物だった。Togetter-「派遣PG時代の思い出」で、紅茶屋さんが、そうはいっても、最新技術を追いかけ回す企業が旧態依然とした企業より生産性が高いとは限らないよ?とのご指摘。現場を変えようと取り組んでも結果として何も変わらないことはよくあります。何か新しいものが導入されても最初の目論見からはねじれた形で運用されてしまうこともあります。慣習やしがらみという壁はそれほど厚いものです。オフコンが反対の部屋でいまだ現役でデータをあげてくるのに、自分のまわりだけ新しい体制を導入したのではひっかきまわすだけです。運用教育にまつわるコストは、おそらくWEB系の方々が思われているほど低くはありません。ITドカタを笑ってすましてちゃだめだろ-紅茶屋くいっぱのあれこれ日記それはその通りなんだけど、その筋で考えると結局、一般兵は最新技術なんか追いかけ回さずに軍曹の言うことを素直に聞いてりゃいいんだ、という結論になってしまって、それだったら結局、件のtogeterのエントリを見て笑っておくのが一番精神的に健康が保てるような気がする。したらいいかは自分にも分からないのだけれど、過去に真逆の現場を見たことがあって、これはこれで珍しい話のような気がするから書いてみる。数百人規模のエンジニアが一つのプロダクトを開発しているのに、見通しのいいコードを書こうとする文化が存在していて、プログラマの見積もりがそれなりに当たるようになる魔法のメソッドが存在した現場の話。ラピュタは本当にあったんだ!(注:画像は全部イメージです。ここで述べている会社とは関係ありません。)その製品は、外資系の会社と日本の会社が合併して出来た会社の製品だった。本国にもエンジニアがいっぱいいるし、日本にもエンジニアがいっぱいいて、トータル数千人規模の開発じゃなかったかと思う。全容は把握できなかったけど。過去10機種以上が同じソースコードの上に開発されていて、そこに機能を追加したり、場合によっては既存のコードをいじったり。数機種の開発が並行して進んでいた。あっちの不具合がこっちの開発に影響したりしないために、機種ごとにブランチが切られていた。いうか、実はブランチがプログラマの人数×数倍存在していて、プログラマはそれぞれ自分のブランチ上で開発ができる、すんごい規模のソースコード管理システムが動いていた。機種コードネーム+社員IDみたいなブランチの命名規則があった。この規模になると、自分のコードをマスターにマージしようとしても、そもそもマスターがバグっていて動かないとか言うことは普通にあった。あとで書くけど全体としてスケジュールはゆるかったから、マスターが動かない時は、動くようになるまで一週間くらい放っておくこともあった。せっぱ詰まった人が文句言って、当事者か上級エンジニアが直していたのだと思う。末端のエンジニアからしたら、一週間待てば勝手に直るイメージだった。Q:一週間待つってどういう事?なんでそんな緩いの?A:プログラマが見積もりを出す時は、「90%の確率で実現可能な納期」と「60%の確率で実現可能な納期」というのを見積もる。前者はよほど致命的な問題が見つからない限り実現可能な納期で、後者はたいていの物事がうまくいった場合の納期。マスターブランチにマージするのは、60%と90%の間のバッファの時期にリリースする事になるから、今日中にリリースせねばならない的な圧迫感のある状況に追い込まれることは滅多になかった。チームリーダーも、「○月○日がデッドラインだ!」みたいなことは言わなくて、「今月くらいでできあがる時期のはずだから、タイミングを見てリリースしてね。出来たら報告してね」みたいなノリだった。あと、全体にスケジュールはゆったりしていた。最初、普通に日本の開発現場のつもりでぎりぎりの見積もりを作ったら、「本当にそれで出来る?本当に実現できる数字を聞かせて。見積もりが大きかったら機能を切って調整できるけど、出てきた見積もりが遅れた時はとても困るんだ」と言われた。競合する日本製品と出荷ペースはあんまり変わらなかった。理由は分からないんだけど、プログラマをぎりぎり締め上げてスケジュールを短縮しても、いい加減なソースコードを書いたり、どうしようもないプログラマを入れてしまったりして遅れる分が出てくるから、最終的にできあがるペースは案外変わらないのかも。実際、ドキュメントとかも大量に作られていたし、レビューもしっかり行われていて品質はとても高かった。Q:不具合管理は?A:バグトラッキングシステムが存在して、プログラマと同じ人数くらいのテストエンジニアがいた。そのテストエンジニアが担当のモジュールをテストして、出てきた不具合をバグトラッキングシステムに登録していた。プログラマが自分で見つけた他のモジュールのバグをあげることもあった。