うちの部署に入れる新しい業務システムの構築の担当になって、昨日から打合せが始まった。今までエクセルで管理してたものが多くて結構表組みで管理したいものがたくさんあったから、そういう要望を業者に伝えたら「いや～、、ハハハ・・（だったら今まで通りエクセルでやれば？）」みたいな反応。例えばフィルターとか超使ってるし、タブをドンドン増やしてハイパーリンクでつないで元データから引っ張ってきて計算して表組みを作成するとかいつもやってるような作業が新システムだと厳しい（＝できないor莫大な時間と金がかかる）らしい・・。帳票は固定になりますね、帳票増やすと増やした分だけ金かかります、みたいな感じ。いちばんビビったのがコピーペーストができないって言われたこと。列ごとコピーしてデータ貼り付けて表作るっていう単純なことが、何百万だか払って作るシステムではできないとか・・。（CSVで保存してアップロードしてください

出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない

株探のミンカブ・ジ・インフォノイド、役員からライブドア買収を聞いちゃった知人がインサイダー取引をしていた件でお詫び

「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな

1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ

この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。（最近のゲームなどは除く）またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を

政府システム調達における失敗の典型例が、特許庁の基幹系システム刷新プロジェクトだ。5年がかりで臨んだが、結局は55億円を無駄にしただけ。新システムは完成しなかった。失敗の最大の要因は、発注者である特許庁にあった（図1）。関係者の証言から、失敗に至る経過を改めてひもとく。 特許庁は2004年、政府が打ち出した「業務・システム最適化計画」に沿って、特許審査や原本保管といった業務を支援する基幹系システムの全面刷新を計画した。システムアーキテクチャーに詳しい情報システム部門のある職員（以下A職員）と、刷新の「可能性調査」を担ったIBMビジネスコンサルティングサービス（現・日本IBM）を中心に、調達仕様書を作成した。 業務プロセスを大幅に見直し、2年かかっていた特許審査を半分の1年で完了することを目指した。度重なる改修によって複雑に入り組んだ記録原本データベース（DB）の一元化に加え、検索や格納など

開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変

人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね？」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 他人を評価する際、第一印象を重視する人としない人がいる。ぼくはこれまでどちらかといえば前者だったし、だいたいのところ、その方法は有効だった。公言したことはないが、人を見る目はそれほど曇ってないんじゃないか、とも思っている。ところが、エースシステム横浜第1開発室システムエンジニア橋本さんと仕事をしていくにつれて、その自信が揺らいでいくことになった。 橋本さんの第一印象は、真面目で仕事熱心な好青年、だった。技術的には不安要素があるものの、単なる経験不足でしかないと思えたのだ。ぼくのカンは、橋本さんを「いい人」リストに追加していた。 橋本さんが誇らしげに出してきた設計書を見るまでは。 東海林さんとぼくは、エースシステム社内に用意された小さな開発室で、数日前から開発作業を開始したところだ

当社のマネジャーミーティングで賛否両論の議題があるので私の意見を聞きたいという。「あるプロジェクトに関わっている技術者が、クライアントから夜間の作業を依頼された。今日、勤務することになっているのだが、作業をさせていいものだろうか」というのだ。 管理部門からは、「契約では就業時間（9～18時）内の勤務となっている。22～8時の夜間に作業するのは、契約違反である。もし何か問題が起きたら、会社としては責任を負えない」と言う。 その心配はよく分かる。実はその技術者はかつて働きすぎが原因で、軽度のうつ病を発症したことがあったのだ。 技術部門は、私の判断に任せるという。「本人に確認したら、このプロジェクトでは断るわけにはいかないので、一番年少の自分が出ると言っています」とのことだった。 営業部門は、作業に行くべきだと考えているようだ。「夜間の作業は他社では普通に行われていることです。日常茶飯事です。こ

先週の水曜日に、IBMのビジネスパートナーの方々が中心となって設立された団体「Open Source協議会 System i」のセミナーで「IT大変革。今、何にどう取り組むべきか！ ～知っておきたい技術動向とキャリアの描き方～」というセッションのスピーカーを、アイティメディアの藤村厚夫取締役と一緒に務めてきました。 藤村さんからはセッションのテーマとして「お互いに、今後5年のあいだにインパクトがあると思われる動向を5つ挙げて説明しよう」という提案をいただいていたので、僕としては少し考えて次のような5項目を挙げることにしました。 セミナーでこの5つについて話したことを、せっかくなのでこのブログでも紹介したいと思います。 業務の定型化の波 1つ目の動向は「非コア業務、�バックオフィス業務の定型化の波」です。これによってこれまで以上に業務のパッケージソフトやサービスへの置き換えが進むと考えていま

『なぜ、コンピュータープログラミングは楽しいのか。なぜ、僕を含めプログラミングに携わる人々は、何度も辛い目に遭いながらも、この職種から遠ざかる事が出来ないのか・・・？』 この問いに対する答えが下記のサイトに載っていました。ここには、プログラミングの本質的な楽しさが書かれています。 Why is programming fun? An extract from Fred Brooks' (Frederick P. Brooks Jr.) book, The Mythical Man-Month http://www.grok2.com/progfun.html この書籍の日本語訳「人月の神話」はこちらです。 人月の神話【新装版】 評価： 4.7点 著者：Jr FrederickP.Brooks,Jr.,Frederick P. Brooks,滝沢 徹,牧野 祐子,富澤 昇 発売日：2014-

はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上