Amazon.co.jp: 職業プログラマー入門: システム開発者を目指すあなたへ 設計からC言語コーディング、テストまで: 遠矢行史 (著), レッドフォックス (編集): 本
わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W.
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
＠IT：明日からできるプロジェクト管理（4） - 単体テストの品質をチェックするには
明日からできるプロジェクト管理（4） 単体テストの品質をチェックするには 1page｜2page｜3page 高野敦 2006/1/12 実装・単体テストの品質をうまくチェックするにはどうすればいいのだろうか。本稿ではまず品質の考え方を概観し、その後、チェックを現実化するツールを紹介していく（＠IT編集部） プロジェクトマネージャ（＝PM）の石出さんは今日も悩んでいます。 石出さん談――。 今度のプロジェクトは実装・単体テストを一括発注することになった。でも一括発注だとどのように品質をチェックしたらいいのだろう。いつものように目の前で作業をしてくれれば分かるんだけれど……。 なるほど、石出さんは実装・単体テストの品質に関して悩んでいるようです。 ◆ 品質の考え方 品質には大きく分けて2つの考え方があります。製品（システム）そのものの品質と製品を作成するプロセス（作り方）の品質です。前者は、
強みの上に自らを築け － ＠IT自分戦略研究所
コラム：自分戦略を考えるヒント（26） 強みの上に自らを築け！ 堀内浩二 2006/1/12 堀内です。明けましておめでとうございます。 今回のタイトルである「強みの上に自らを築け」という言葉は、昨年亡くなった「マネジメントの父」、ピーター・ドラッカー教授の言葉として知られています。自分戦略を考えるうえでは「定番」といえる言葉です。 ただ、キャリア相談を受ける中でしばしば気になるのが、「強み」イコール「他人が口出しできないくらいの専門領域を持つこと」だととらえられていること。もちろんそれも強みを構成する要素ですが、それだけではありません。そこで今回は「強み」についてじっくり考えてみたいと思います。 ■強みとは何か （1）強みとは相対的なもの ある力が強みになるかどうかを決めるのは、非常に相対的な基準です。つまり需要と供給のバランスです。 需要＞供給の典型は、「ほかに分かる人がいないから」と
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
ビジネスプロセス・マネジメントのすすめ － ＠IT情報マネジメント
経営環境の変化に応じて、業務プロセスや情報システムを俊敏に変更できるようにする──という提案に異議を唱える人は少ないだろう。しかし、それを実践するのははなはだ困難だ。その理由と解決策としてのBPMについて解説する。（→記事要約<Page 2>へ） 企業経営の進化を継続するために、「BPM（ビジネスプロセス・マネジメント）は有効である」が本論のテーマです。 BPM適用領域についてはいろいろな意見があります。意見の違いはBPMを情報システム構築の手段として見るか、ビジネスプロセス・マネジメントという言葉の持つ意味から見るかによるものです。ここでは後者の立場で全体概要を説明します。 コミュニケーションが成り立たない！ 事業運営に情報システムが欠かせないことは、誰もが納得できるしょう。しかし、事業の推進と情報システムの構築の関係は水と油のごとく遊離しているように思えるのはなぜでしょうか？ 次のよう
ウノウラボ Unoh Labs: 共同開発を効率よく行う方法
尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット
「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育シ
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
意図が伝わる設計書作成の心得【第1回】：行きすぎた技術志向
設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一
新しいタイプのSE、「アクセス解析エンジニア」セミナー開催：CodeZine
日本では馴染みがないが、今後経営を握る新しいWeb系の仕事として注目されるであろう、「アクセス解析エンジニア」を紹介するセミナーが開催される。 セミナーではWebマーケティングの先端を走っているアメリカや、今、大きく成長している中国のマーケットに対して各国のエンジニアが何を目指しているのかといったトレンドから、「アクセス解析」という仕事の内容と重要性、アクセス解析エンジニアの将来性、企業がアクセス解析エンジニアを採用する時のポイントについて紹介する。まだ転職は考えていないが、ITエンジニアとして自分の価値を高めたいと考えている人にとって、ヒントになる内容が盛り込まれるとのこと。 経営を握る新しいWeb系の仕事～アクセス解析エンジニア～ 日時
プログラマの労働価値
プログラマの労働価値は、そのソースコードのクオリティでも、書いた行数の長さでもなくて、成果物がもたらす価値によってのみ決まる。 いくらエレガントなコードを書いたところで、それが1円も生まなければ・・・金銭だけじゃなくブランド価値なども含めて・・・・ビジネス的に価値は全くない。つまり本来は報酬の対象にならない。 受託業務の場合は、受発注する側が成果報酬などのリスクを取らないのであれば利益を先に確定したいのは受託する側も受託に出す側も共通したリスク回避の切り分け手段なので、そこを重視するが故に、不確定な見積もりだけに売り上げを依存させましょう、というトレードオフがあるに過ぎないんじゃないだろうか。 つまりお互い幸せになるための手段が、事前見積もりでいつまでに納品しますよ、という契約をしてしまうこと。 この一番大事なステージを、うまくやれる会社か否かか、という違いが受託ですげー苦労するかそうでも
分裂勘違い君劇場グループ - 劇場管理人のコメント - 有能なプログラマの特徴を思いつくまま列挙してみる
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
町場のＳＥに求められる素養の第一は「技術」ではなく「人柄」 - 木走日記
最近ネットでは、「日本のプログラマの生産性は高いか？」とか、「優秀なＳＥ（システムエンジニア）の条件は？」といったテーマが話題になっているようですね。 今日は、業界歴だけは長い町場の零細ＩＴ企業オヤジの視野の狭い（苦笑）「よいＳＥとは」話をしたいと思います。 ●本来優秀な営業マンたるもの、かかわるすべての人々から好感を持たれるように努めるべき 私の知り合いにマンション業界のトップ・セールスマンであるＹ氏がいます。 Ｙ氏は月に１０件の契約を取ったこともある凄腕営業マンであり、実は私の義理の妹夫婦もＹ氏からマンションを購入しているのであります。 Ｙ氏は言います。 「木走さん、これは誰にもいえない私の本音ですが、私は売れといえば「つけもの石」でも「隅田川の汚水」でも売る自信があります」 ・・・ 彼いわく優秀な製品を売るのは誰でもできます。 オーバーな話、みなが認める素晴らしい商品ならば、営業マン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
javaworld.jp
サービス終了のお知らせ
究極のお仕事 : 404 Blog Not Found
