2013年の仕事が始まって1週間が経つというのに、年を書く時には時々「2012年」と書いてしまうことが多い。ようやく2013年という書き方に慣れた頃にはもう2014年が始まっていたりするわけだが、そんな風に時代の変化に追いついていけなくなってしまったら歳の証拠なのだろう。（たぶん嘘） 最近のかな漢字変換は賢くて「きょう」と入力すると「2013/01/12」と変換してくれるし、「いま」と入力すると「午前11時31分」と変換してくれる。誰が考え出したのか知れないけど便利な仕組みだ。そのうち「ここ」と入力したらGPSから拾った今の住所を入力してくれたり、「いまのきもち」と入力したらユーザの気持ちを読み取って「くたびれている」と変換してくれるようになるのかも知れない。なんせ面倒な作業を賢く片付けるのがコンピュータの役割のはずだ。きっと誰かが作り出してくれるに違いない。（やや期待） メールや文書に日

会社で開発の仕事を続けていると、どうしても知識に偏りが出てしまう。仕事で使うからという理由で専門知識が増えていくのは有り難いことだとは思うけれど、だからと言って専門家として書籍を書ける位に深い知識が身に付くわけでもないし、新しく開発した技術を特許として出せるものでもない。せいぜい、APIをたくさん覚えたので一連の処理は素早く作れるとか、ドメイン知識が深まったので開発対象を容易に理解できるようになったとか、仕事のコツが分かったので素早く回せるとか、その程度であることが多い。 これは確かに大切なことだし、会社から求められる責務を果たしているとは思うけど、この変化の激しい時代に昔の技術にしがみついているのは、技術者として或いは組織としてかなりリスクが高い気もする。例えば、以前なら苦労して自分で作っていた機能が、最近のフレームワークを使えば簡単に実現できるようになっていることが珍しくない。宴会の席

「仕事だから忙しいのは当然のこと。忙しくなかったら会社が潰れてしまうよ」と減らず口を叩きながら仕事に励むものの、忙しさには様々な危険も伴うので注意が必要だ。 優秀な人材が職場を去ってしまう 開発のプロとしてデスマーチを乗り切るものの、そんな環境に嫌気が差して退職届を持ってくるのは何故か優秀な開発者であることが多く、逆に居残るのは「取り柄は長時間労働に耐えうる体力だけ」という体育会系開発者だけだったりする。 技術の進歩に取り残されてしまう 技術的に進歩のある前向きな仕事なら良いのだけど、実際には、どこかの誰かが昔作ったバグの原因調査に時間がかかっていただけ、と言った時間消費型作業が多く、気がつくと技術的な成果が過去1年の間に何も無かったりする。 思考停止に陥ってしまう 物事を考えるには落ち着いた時間と心のゆとりが必要だ。朝から晩まで忙しさが続く状況では良いアイデアは生まれないし、建設的な議論

開発現場にいると時々不思議な言い訳に出会うことがある。 「言われた通りに作業しました。だから自分に落ち度はありません」 「そんな指示は受けていないので、やりませんでした」 「そんな処理は仕様書に記載されていません。だから実装していません」 指示されていないことはやらない。これは正論だ。うかつなことを言い出せばタダで追加作業をやるハメになってしまうし、下手をすれば自分の責任問題に発展してしまう。損する宿題を持ち帰ると上司に怒られるし、面倒ないざこざはご免だから、徹底的に自己弁護の姿勢を貫いているらしい。確かに、言われた通りにやったという顛末は役立つ情報だし、弁明としては悪くないとは思うけど、これがいい歳をした開発者の言うことなのかと呆れてしまうことも多い。 何も指示されていないからこそ、自ら問題を見つけ出すのが本来あるべき姿だと思うし、問題の存在に気づいたのなら知らんぷりせずに率先して持ち出

依頼していた仕事の納期を休み前の金曜日にうっかり設定してしまうと、時々痛い目に会うことがある。 朝会：「予定通り定時までには終わります」 昼前の定例進捗会議：「問題が見つかったので1時間遅れます」 15時の休憩時：「問題の解決に手間取っているので更に2時間遅れます」 定時：「問題が他にも見つかったので、作業完了は21時頃になります」 21時過ぎ：『全ての問題の解決には更に3時間必要です」 修正予定の見積に何度も失敗しているのだから、その経緯から見て「3時間必要」という見込みもかなり甘い方だろう。ホントに3時間で終わるのならギリギリ本日中という約束は果たせるけれど（社内での話。社外の顧客向けならもちろんアウト）、問題の発見と修正を既に何度も繰り返しているのだから、3時間で終わるとは到底思えない。そんな訳で当日の作業は打ち切り、めでたく休日出勤の号令がかかることになる。 工場のラインで決められ

その昔、上司と出張した時の話。出先での打合せが終わり電車で帰ることになったのだが、切符を買う時になって上司が「特急列車に乗って帰ろう」と言い出した。乗車時間はそれほど長く無く、自分一人の時にはいつも普通電車に乗っており、わざわざ追加料金を出して特急に乗ることは無かったし、そもそも出張に関する旅費規定では特急料金は支給されないので自己負担になるはずだ。自分のお金を出して楽を出来るとはいえ、それは少々贅沢ではないのだろうか。 そんな不審そうな私の表情を読み取ったのか、特急に乗り座席についてから上司はこんな話をしてくれた。 普通列車に乗っても確実に座れるかどうか分からない。立ちっ放しだと、次の日に疲れが残るから仕事の効率も良くない。それなら少しくらいのお金を出してでも確実に座れる特急の方が楽だし、疲れを翌日に引きずることも無い。それに、座席に座って仕事の続きをしたり本を読んだりすることも出来る。

仕事というものは基本的に面白くないものだ。若い頃なら上司から言われた作業を延々とやらなければならないし、少し偉くなると部下と上司との間の調整に気配りしなければならないし、さらに偉くなって部下をたくさん持つと管理の書類をやたらと作る必要が有ったりして、つまらない業務からは決して逃れることが出来ない。個人で自分勝手に働くのなら別かも知れないと思って、独立して働いている知人に尋ねてみたら、税金の計算やら管理業務に忙しくて本業に割く時間が減るばかりだとぼやいていた。 やり甲斐を感じつつ熱意を持って仕事に励むというのは一種の幻想であって、仕事の基本というものはつまらない作業の繰り返しではないかと思う。こんな仕事が誰の役に立つのか、誰も読みもしない資料を作ることに何の意義があるのか、と思うことは甚だ当然であり、そのような疑問を抱くこと自体、真っ当な思考力を持ち合わせている証拠ではないかとさえ思う。（何

組織の中で仕事を進めていると、互いに作業を頼んだり頼まれたりするわけで、多くの人はその通りに確実に片付けてくれるのものの、中には呆れるような仕事のやり方をする人もいたりする。その一例。 自分が終電で帰宅するような時刻になってようやく仕上がった資料を送付して、「期日には間に合った」と豪語する。 人から頼まれた仕事をいつまでも放っておき、「そのうち依頼元の人も忘れるでしょう」とニヤニヤする。 忙しくて出来ません、他の仕事で手一杯です、時間がありませんと、他人からの依頼は徹底的に拒否するのに、自分からは平気で依頼を出してくる。 いずれも相手のことなんか考えていない余りに身勝手な理屈だと思う。元々そんな仕事をする性格なのか、あるいはそのような仕事の進め方をしている組織に入ってしまったのか知らないけれど、そんな人を相手にする度に残念な気持ちにさせられてしまう。作業の結果を返すのなら定時時間内が1つの

寒い気候が続くせいか、周囲では体調を崩して休む人が多い。休む人がいるということは、予定していた作業がそれだけ遅れるということを意味する。もちろん、体調が復帰して出社するようになってから残業で挽回するとか、他の人が肩代わりして進める等の対策は考えられるけど、余裕の無い工程でやっている以上、どうしてもリカバリ出来ないところが出て来てしまうし、そもそも技術的に他の人では手に負えない範囲だって有る。デッドライン直前に体調を崩したメンバがいるため、必要な作業が完成できず、困った状況に陥った経験を持つ人は少なくないだろう。 そんな状況を客観的に見ていると、冬の期間はリソースの変動量が意外に激しくて、工程管理に意外に苦労することが多い気がする。夏の期間も休みをとる人が多く、全体としてのリソース量は他のシーズンより減るものの、その割に工程に影響を及ぼすことが少ないのは、計画的に休みをとる人が多いからだろう

その昔、要求仕様やら画面仕様、シーケンス図、仕様に関する問い合わせのやり取り、バグ票、工程管理のガントチャート、議事録の類を一切合切Excelのファイルで管理している開発プロジェクトを見たことがある。各分類毎にサーバの共有フォルダにズラリと並んだファイルの数はなかなか壮絶なものがあった。しかも、意図通りの順番に並ぶように"00_要求仕様書"という連番をファイル名の先頭に付けたり、更新する度に「履歴」フォルダに日付を付記して移動したり、さらに多すぎるファイルの管理をするための「ファイル管理ファイル」なるものまで存在しており、現場担当者の涙ぐましい努力の跡が伺えた。 管理者が「この方法が良い」と判断した上でやっていることなのか、それとも「他の方法なんか知らない」からやっていることなのかあいにく聞きそびれてしまったけれど、少しばかりの学習と手間をかければ作業をずっと効率化出来るのに、こんな非本質

進捗会議と称する打合せに参加すると、その開発チームの状況がよく分かる。「分かる」と言ってもその報告内容ではない。チームの実情をよく示しているのは、むしろ、その打合せの進め方だったりする。 例えば、状況が宜しくなく、課題山積みのチームで良く見かける光景はこんなものだ。 リーダがチーム全体の状況を把握しておらず、打合せの場で初めて状況を理解している。 やたらと会議の時間が長い割に、発言する人は限られている。 当事者間でしか分からない個々の問題に関する議論が延々と続いてしまう。 問題の事後対応の報告ばかりが続き、事前対策等の前向きな話が全く出てこない。 先週の打合せで出たアクションアイテムをフォローしないし、そもそも誰も覚えていない。 今後の工程、予定、展望についてリーダの発言が無く、チームが進む方向性が見えない。 議事録の記載内容がお粗末なので、参加者以外には内容が全く理解出来ない。 会議が終

開発プロジェクトの実行部隊は当然生身の人間だから、感情もあるし気持ちの問題もある。いつも明るく愉快に仕事が出来れば嬉しいけど、そんな楽しいことばかりではない。忙しい現場は少々殺気立ったり雰囲気があるけれど、むしろ現場の雰囲気を台無しにしてしまうのは、そんな個人の感覚を理解していない開発リーダだったりする。そんな人によく見受けられる作業指示の一例。 他部門から来た作業依頼メールを、「対応をよろしく」と一言書いただけで転送してくる。（多いよね） 定時後に新しい作業依頼を平気で出してくる。（特に金曜日は最低） 担当者が作業に没頭しているのに「至急の作業」と称して次々と作業依頼を出してくる。（あなたの「至急」とは何なのさ？） 現場の士気を上げるのは難しいけれど、逆に低下させるのは簡単なことだ。ほんの少しばかりの気配りで心穏やかに担当者が作業できるはずのことを、手間を惜しむばかりに、或いは自分で横着

開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった（行かなかった）事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは

隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが

ソフトウェアのバグやコンパイルエラーなど、開発作業の進行をブロックする些細な問題はたくさん有って、その度にリファレンスやウェブを検索して解決策を求めるのだけど、そんな類の問題は、実は何度も繰り返し発生することが多い。個人で開発をしていると以前に別の案件で遭遇したものと同じ状態が発生したり、チームで開発をしているのなら、実は各自が同じ問題にぶつかって困っているという状況が珍しくなかったりする。 解決策を見つけ出すのは少々骨の折れる作業だが、問題を片付けただけで終わってしまうのは勿体ない。経験的に言って、いずれまた同種の問題が発生する確率は高いのだ。それなのに、いざ同じような問題発生を前にして「この問題は以前にも見た。でも、その時の対処方法を覚えていない」という悲しい状況が少なくない。 そんな痛い経験に懲りて、何かの問題に対する解決策を見つけた時には、その対処方法を必ずメモに残すようにしている

ソフトウェアの開発現場には様々な人がいて、コードをガンガン書き続ける開発者がいる一方で、協力会社向けの仕様書を書き続ける人や、ひたすら打ち合わせを続けて「仕様調整」「工程管理」「障害対策」に励む人もいる。毎年新入社員が入ってくると聞かれるFAQの一つに「ソースコードを書かない開発者は一体何をしているのか？」というものが有るけれど、そんな開発現場の実態も学校の授業ではなかなか教えてくれないことなのだろう。 実際のところ「開発部門に所属しながらソースコードを書いたことがない（書けない）」人も全然珍しくなくて、開発のスキルと管理のスキルは異なったりするから、それはそれで業務分担として構わないのものの、厄介なのはそのような人に限って「自分は技術を分かっていると心の底から信じ込んでいる」点だと思う。 日々、ソースコードを相手に格闘している開発者だと、そもそも「ある環境（プラットフォーム、仕組み）で実

ルンバを買った。ホントは掃除機を買い換えるつもりだったのだけど、電気屋さんに行ってみたらルンバの実物が展示されていて興味を惹かれたし、以前から気になる製品だったのでエイヤッと買ってしまった。 以下、実際に使ってみた所感をまとめてみた。 掃除の手間が激減した スイッチを入れるだけで勝手に掃除をしてくれるのは素晴らしい省力化で、全自動洗濯機の如く利用者の手間がかからないようになった。掃除の前に床のガラクタ類を片付けておくとか、走行の邪魔になる椅子を移動させておく等の前処理が必要とは言え、掃除の本作業にかかる手間と時間は大きく削減できた。これはルンバ導入の最大のメリットだろう。 毎日発生するゴミは想像以上に多い 外出時に掃除開始を指示しておき、帰宅時にルンバ本体に溜まったゴミを捨てているのだけど、毎日驚くほどの量が出ることに気がついた。今まではゴミパック式の掃除機を使っていたので、一回の掃除でど

昔のソフトウェア開発なら、いわゆる業務系、ウェブ系、組み込み系といったカテゴリがあって、開発者はいずれかのカテゴリに属しているのが普通だったし、各々の技術者では前提となる知識が異なっていたので話が通じないことも多かった。同じ開発言語を使っていても作る対象や作り方は大きく異なっていたし、隣のカテゴリの仕組みなんて何も知らなくても全然問題が無かった。 でも、単独の製品やサービスだけでは、生き残ることががだんだんと難しい時代になってきている。ちょっとした組み込み製品でもネットワークに接続出来ることが当たり前だし、単独システムだけではビジネスとして成り立たず他のサービスとの連携が当たり前になりつつある。「ソリューション展開」などと称してシステム一式を商売にしようとしている企業が多い状況を見ていると、ビジネスの重心が変わりつつあるような感覚すらある。 このように、各システムがシームレスに結合すること

携帯電話が暇つぶしに欠かせない存在になったのはいつの頃からだろうか。昔の携帯電話はインターネットに接続する機能が無かったから、本来の目的である電話以外に使い道が無く、持ち歩いていても邪魔なことが多かった。今から考えてみれば本当に単機能な存在で、牧歌的な時代だったと言えるだろう。 しかし、今ではパソコンの如く高機能化した携帯の端末を使って、いつでも何処でもネットに接続出来るし、必要なソフトをインストールしてゲームを楽しんだり本を読むことも出来てしまう。外出先にて手持ちの本を読み終えてしまい、かと言って近所に本屋も見当たらない時に、時間をつぶす上手い方法が見つからずぼんやりと物思いにふけるしかなかった時代は、もう過去のものとなってしまったようだ。 いつでも何処でも、ネットを通じて無限の情報にアクセス出来るようになると、何かを考える前に行動してしまうし、そのような行為しか出来ないようになってしま

仕事の現場では、教科書では教えてくれない様々な状況が発生する。 送られてきた仕様書には書かれていない内容が多い。不明箇所を確認してみたら「開発者なのだから、その位は自分で考えて上手く作れるだろう」とのこと。それが普通かと思っていると、一方で「仕様書に書かれていることは絶対。変更は一切認めない」という人もいる。 報告書という形でレポートを出したら、それを受け取った人から「必要な情報が書かれていないと差し戻し。しかし、同等レベルの情報を書いている隣の人は、何も言われないどころか良い内容だと褒められている。 リーダとして担当者に作業指示をあれこれ出すと、口うるさいと言われる。それを反省して、作業を任せてあまり介入しないように遠慮していると、今度は丸投げと非難されてしまう。 マニュアル本の類を読むと、こんな時にはこうすべき、という指南が事細かに記載されていて、それに従えば上手く行きそうな感じがする