当社では、開発のご依頼をうけたシステムやソフトウェアについて、お客さまのご要望はとことんまでお聞きするようにしています。 それは、お客さまに最終的にご満足頂きたいため・・・というものもちろんありますが、とことんまで要望を出し切って頂いた方が、その後がスムーズだからです。我々にとっても、お客さまにとっても、です。 ただ、システムへのお客さまの要望を全て聞き出す、出し切って頂くというのは、かなり大変な作業になります。 なぜなら、オーダーメイドのシステムの場合、はじめには何もありません。 何もないところから、設計を行い、プログラムを作ってゆくのですから、最初、システムのその姿は、想像するしかない状態なのです。 設計書をいくらリアルに書き、類似のシステムを使用して類推を繰り返しても、やはり想像の範囲を脱しません。 だから、多くのシステム屋は「お客さまには、できあがってみないとわからない部分がある」

先日、当社にお問い合わせ頂いたメーカーさん、その販売代理店さんにわざわざお出向き頂き、打ち合わせをさせていただきました。 当方からは私を含めて４名、打ち合わせに参加しましたが、皆、それぞれ別の会社、別の事業者です。 プログラマ、テクニカルライター、ITコンサル、ITカウンセラという顔ぶれです。その異種混合ぶりに、先方も最初は少し、戸惑われた様子でした。 しかし、こういった協業による「総掛かり力」の意味するところを、理解して頂けたのではないかと思っています。 そして、この総掛かり力の中に加わって頂くことで、このパワーを、共通のお客さまに向けて、発揮することができるということも、垣間見て頂けた気がします。 我々のような中小企業は、資金や人材に限界があります。 しかし、それを負の要素に思う必要はまったくなく、中小だからこそ、特化できた技能やノウハウがあります。 そういったものを持ち寄り、お客さま

・・・と、先日お問い合わせのお電話を下さいましたお客様が嘆いておられました。 得意先や仕入れ先と共同して、受発注のシステム統合をしようということになり、その方の会社に最近出入りするようになった中堅どころシステム会社さんに、アドバイスを求めたのだそうです。 すると、数日後、ぱりっとした細身のスーツを着たシステム会社の社員が５，６名やってきて、プレゼンをしたのだそうです。 プロジェクターとパソコン持参であったものの、スクリーンがなく、仕方なく、売り物のシーツ（この会社さんは、ビジネスホテルなどに寝具関係の物品を販売している会社さんなのです）を倉庫から引っ張り出してきて、それをスクリーンがわりにプレゼンしてもらったとか。 約１時間のプレゼンの中で出てくる横文字を誰も理解できないまま、終わってしまったのだそうです。 もう皆６０歳を超えている経営陣が、倉庫や荷造りの現場と行ったり来たりしながらプレゼ

コンピュータというのは、なんのためにあるのか、といえば、ずばり！ 難しいことを簡単に済ますため というのが、代表格といえるでしょう。 紙の台帳や伝票で管理していたことが、 EXCELで毎月コピペミスを犯しながら管理していたことが、 電話やメールで何度もやりとりしていたことが、 システムを導入すれば、簡単に済ますことができます。 もし、逆に難しくなったなら、そのシステムには全く何の価値もありません。 さっさと頼んだシステム屋に突っ返してしまいましょう。 さて、事務や作業を簡単にするためにあるコンピュータ、そしてシステム。 いろんな実現の方法があります。 なぜなら、「簡単にする仕組み」が様々だからです。 たとえば、マイクロソフト・アクセスというソフト（マイクロソフト・オフィスのプロフェッショナル版以上に付属しているデータベースソフト）を使えば、これまで紙やEXCELでやっていた集計や印刷が簡単

当社のホームページなどをご覧になって問い合わせやお見積もりの依頼をされるお客さまに、 では、ということで見積書を提出させて頂くと、 「高い！」 という反応が返ってくるときがあります。 一方、 「おたくの見積は他社の半額以下だ。なにか裏があるのでは?」 という反応もあります。 前のお客さまは、当社からしか見積をとっていません。 後のお客さまは、複数の会社さんから見積を取っています。 当社の開発コストが、必ずしも他社さんより安いとは言えませんが、やはり、中間マージンや間接コストがかさんでいる見積金額よりは安く、また、セル生産方式、小チーム生産方式と小規模・特化による効率化があるので、削減できる部分が大きいと思われます。 ところが。 見積書を作成している私本人が、 「システム開発費用は高すぎる！」 と感じるときがあります。いえ、ほぼ毎回そう思います。 システムを開発する、という仕事は、すべて手作

これから書くことは決して「これをしなければいけない」とか「他に手段はない」なんてコトを主張したいのではない。色んな道があるはずだぁ。その中の一つの事例として、自分がやってきたことをフレームワーク化し、色々挙げてみようと思う。 当然、俺の主観が入りまくっているので、突っ込みどころは満載だろうなｗ そもそも「エンジニア」って何？ｗ その辺り、はてブ界隈のミナサマにおかれましてはお手柔らかに願いたいｗｗ さて、いきなりどこかの技術系カンファレンスで1時間喋っちゃえ、とか突然は無理なのは分かる。何を話せばいいのやら、どこに喋るチャンスがあるのやらだ。しかし、そういう所で喋るような自分を将来のビジョンとして持っている人は、以下に挙げることを小さなことからコツコツと実践してみるといいかもしれない。という意図で書いていく。 何事にも興味を持とう 興味は勉強の原動力。興味のない勉強は苦痛でしかない。ここが

システム開発契約についての勉強会の話の続き。 契約交渉は、大体は力関係で決まってしまうところも大きい*1ですが、取引条件の調整の仕方は、押し切る（相手があきらめるまで押し通す）か、交渉をするかの2つですねーという話が出てました。 で、その調整について、たとえば、瑕疵担保を1年取るか、6か月にするかという押しあい圧し合いをしてるときの話ですけど。 委託側だったら1年取りたいし、受託側なら6か月にしてしまいたい。どう調整するって、こっちが受託側なら、民法上の瑕疵担保は1年間だけど、商法上の瑕疵担保は6か月だから、1年も必要ないですよね、商法は「特別法」にあたりますので、商事に関しては、特別法である商法が民法に優先されますしー。と言って大抵は終了です。 でも、1年に1回とか半年に1回しか動かないシステムである場合、瑕疵担保責任期間が6ヵ月では短いですね。が、そうでない場合は、3ヵ月でもいいかもし

システム開発契約についての勉強会に行ってきました。講師は、企業法務についてあれこれの雑記のkataさん（@katax）さんでした。即戦術的なTips話というより、啓蒙的＆根本的な話が中心で、それがなかなかに興味深かったです。 質疑応答というか雑談？で出た話が大事だと思うのでまとめてみるよ システム開発契約の基本契約と個別契約の違い 開発委託契約には、基本契約と個別契約というのがありますが、その違いが分からないという話がでました。 基本契約とは、企業間で、何度も反復・継続して行われる商取引に共通して適用される事項をまとめてあらかじめ定めたものです。この先、何度も契約を交わされるだろうと思われる企業間で、個別の取引全てに適用されるような、共通した約束ごとを先に決めておくための契約書が基本契約書です。 取引ごとに、著作権は・・・とか、いつから所有権が移転されるのか・・・とか、一から、都度都度条件

システムを設計する、というのは非常に難しいことだと、いつも思います。 お客様の要望をそのままシステムに実現するのは簡単です（いえ、一般的な意味で「簡単」ではありませんが）。 お客様の業務とともに、理念やコンセプトを理解し、システム導入によって合理化と効率化を図るための仕事が、「システム設計」です。システム化ありきの設計では、ほんとうのシステム設計とは言えないでしょう。 現場の業務を知るために、自ら現場に立って、レジ打ちしたり棚卸しを手伝ったりしたりすることもあります。そうしないと紙の上だけで業務と現場を知ることは難しいのです。 そうやってようやく、「なにをすべきか」がわかってきます。 そして、その「わかったこと」を、経営者やシステム担当者と話し合います。 まずこれが、業務分析の段階です。 どこが合理的でないのか、効率的でないのかを洗い出します。 ここからが、システム設計の要となります。 第

お客様から「こういうシステムを作ってほしい」という依頼を受け、それを作るのがシステム屋の仕事です。 しかし、「システムを作る」という作業自体は、案外とすんなりと進むものです。 大変なのはその先。「検収」、「導入」という工程に入ると、「作る」のとは全く異質の大変さが待ち受けています。 作ったシステムが、お客様が望んだとおりに出来ているか、お客様自身が確認する作業を「検収」といいます。 お客様も大変です。何日もかけて、実際にシステムを使ってみたりして、検収の作業を進めます。 そのあいだ、システム屋は何をしているかというと、ほとんどの場合は、検収作業をしているお客様の横にぴったりくっついています。そして、お客様から出てきた意見、不満、疑問などを整理します。 「思っていたのと違う」という部分が出てきて当然です。「やはり、こうではなく、ああのほうがよかった」というドキッとする意見も当然のごとく出てき

先日お会いした方は、今年起業したばかりの方で、今はお一人で仕事をされています。 誰もがその名を知る大手企業さんにおつとめで、３０人の部下をもつお役職だったとのこと。 な、なぜ、その地位を捨てて起業？？？ と、私などは思うのですが、しかし、人生は一回こっきり。やりたいことをやって、たとえうまくゆかなかったとしても、やりたいことをやらずに悔やんで人生を終えるよりよほどまし。 その方も、そんな思いで、地位も収入も捨て、あえて起業の道を選ばれたのでしょう。 フリーランスや個人企業（ひとり会社）でシステム開発をやる、というのはもはや、エンジニアリングとかプログラミングとか、そんな横書きの世界ではありません。 中小企業の現場にひとりで乗り込み、海千山千の社長と渡り合い、時には言い争いしながらも、信頼を確保してゆく仕事です。この世界の中で求められるのは、技術力でもスピードでも、精度でもありません。何があ

米国企業型の経営によって、日本企業は経営力を高めなければいけないと盛んに言われたのは一昔前。この10年、日本はいろいろと苦しんできたが、今は風向きが変わり、日本独自の新しい経営スタイル「新日本型の経営」が着実に息づいている企業がある。 液晶テレビに欠かせない、真空技術を使った製造装置で世界シェア9割以上を握る、東京証券取引所第1部上場企業アルバック（神奈川県茅ヶ崎市、従業員数1638人）。5期連続の増収増益の立役者、中村久三会長は、会議で経営者の強い意思を直接伝え、社員の当事者意識を高めることが、現場の力をスピーディーかつ最大限に引き出すカギと考え、業績を大きく伸ばした。 アルバックでは“ダラダラ会議”という徹底した議論を通じて全社合意に至り、経営の方向性を決める方法を採用。このユニークな仕組みが、社外からは分かりにくいが、革新を生んでいる源泉となっている。 「会議はダラダラやる方が効果が

ITエンジニアは「製品やサービスのことを語るのが大好きな人種だ」と周りから見られている。 私はビジネス・スキルの研修で「お客様が一番関心を持っているのはプライベート，2番目が人に関すること，そして3番目が仕事に関することだ」と教えている。誰だって，親や子供が病気になれば仕事よりも重大事であるのは間違いないし，息子や娘が大学受験していれば落ち着かないのが親心というものだ。しかしITエンジニアは，飲み屋でも社内でも客先でも，仕事に関する話をしたがる。なぜなのだろう？ 若い技術者は，部門の上司や先輩をお手本として多くのことを学ぶ。自分の会社はどんな会社なのか，社内ではどういう風に振る舞うべきなのか，どうすれば気に入られるのか，評価されるのかといったことを周りから敏感に感じ取って，お手本として真似るものだ。その上司や先輩が仕事の話ばかりしていたら，彼らもそうなってしまうのは当然のことだ。 また，I

「あなたが作る資料は分厚いものですか？それとも，コンパクトなものですか？」という問いにあなたはどう答えるだろうか。ほとんどのITエンジニアの人たちは「情報が盛りだくさんで，とても論理的な資料を作成しています」と答えるはずだ。なぜなら，分厚くて豊富な内容の資料は，自分の知識の豊富さやスキルの高さを証明するものだし，また一生懸命に頑張って作業したことの証になると考えているからである。 エンジニアがこう考えるのには，上司や経営者にも大いに問題がある。分厚い“作品”を見ると，内容を見るより前に「頑張ったね」「すごいね」とねぎらいの声をかけるのが一般的だからだ。「きちんと内容を見てから評価してください」と要求したいところだが，ITエンジニアの仕事内容を評価するのはそう簡単なことではなく，つい成果物の量だけで評価してしまいがちなのだ。 しかし，ユーザーから高く評価される「プロのエンジニア」になるには，