蟹江文彦

幼少の頃よりProgramingを経験しSystem開発歴は40年近くになる情報処理技術者 最近は開発支援の傍自らの体験を元に小説や技術文書の著作もしている

蟹江文彦

幼少の頃よりProgramingを経験しSystem開発歴は40年近くになる情報処理技術者 最近は開発支援の傍自らの体験を元に小説や技術文書の著作もしている

メンバーシップに加入する

■なにをするサークルか 主にSystem開発における失敗例と要因及び改善についての解説と 新技術における学びの方法についての解説について講義論文を発表する ■活動方針や頻度 主催者は一個人としてMemberはこれを購読するのみ 頻度については月または隔月 ■どんな人に来てほしいか 開発現場で苦しんでいるEngineer及び素人同然のPM ■どのように参加してほしいか System開発に関わるもの達すべて

  • System開発あれこれ

    ¥2,000 / 月

マガジン

最近の記事

要件定義の歩き方(機能拡張編)

はじめに要件定義は本来Serviceを提供する企業が行うものだが必ずしも彼らの全てが情報処理技術に対して知見がある訳ではない。従って多くの企業は企画書を作成しVendorを選定後Vendorと共同して要件定義を行う。Vendor選定では企画書に対して安価な業者になる事がしばしばであるが安価になる要因は要件定義書や設計文書の一部省略にあったりする。それでも要点がまとまっていれば開発を進められるのだがそういう開発案件は大抵暗礁に乗り上げてしまう。暗礁は単体試験から結合試験にかけて

¥500
    • UI/UXの罠

      お客様の案件に開発支援する際に設計工程から参画する事もあるのだがその際に必ず開発手法を伺いAgileであれば快く受けAgile以外であれば要件定義書の有無について伺う事にしている 「大丈夫です要件定義書はあります」という回答には必ず裏切られるので最近は一切信用していないので 「ASIS TOBE差分分析は出来てますか?」と聞くようにしている その時点で???という案件は参画をお断りしするようにしている 過去の失敗例で「要件定義書はあります」で示す文書は画面遷移図だけだった

      • 流れに身を任せるか?堰止めてみるか?

        川の流れに任されて流されてみるのはとても楽な事だ それは行きつく先が思っている方向であれば尚楽しい 何処へ只りつくのか分からないなら冒険心で胸は膨らむかもしれない しかしその行先が大きな滝壺へ進んでいるなら貴方はどうするだろう? 滝壺に突っ込んで天に運を任せるか? 無駄と分かっていても流れを変える様努力をするだろうか? 確かに自分が今いる場所が川の上であれば無力を知りこれも天の定だと諦め滝壺に落ちて身を砕くしかないだろう 結論から言えば川の流れに身を任せるのは行きつく先が楽

        • 出来る・・・でも出来ていない

          Backlogを利用したAgileのProject管理でみられる言葉の中に (〇〇出来る)というものがある これを用いたのか要件定義書の中の要件内容にこれと同じ文面を見かける事がある がしかしこの場合において私的にはこの書き方が違和感そのものであり目障りだったりする 要件定義書ならここは機能区分として整理する方が望ましいと思っているからだ なので小生であればCRUDに特化した機能名と機能区分を明記するだろうか 更に気に触るのは要件定義と称しているのに記載されている内容が

        マガジン

        • 技術思考あれこれ
          2本

        記事

          要件定義の進め方と開発後片付け

          要件定義を始める前に今まで様々なProjectに参画し要件定義を行ってきた そこでまず最初の関門は既存の機能を依頼者全体が把握していない事から生じる これは依頼者側の問題ではあるが前Phaseの開発業者のSystem開発における知見の問題でもある 殆どの開発業者は客先からの要件が全てでありそれに関わらない既存の機能は度外視してしまう 開発業者の調整役が開発工数を削減するための手法と言っているがそれは嘘である 開発業者は既存調査を自身で行う工数を含むと開発費用が嵩張るため発

          ¥100

          要件定義の進め方と開発後片付け

          ¥100

          技術者としての心得 - その5 -

          Object思考で常に作業せよObject思考と聞くと挫折の経験のある方は犬や犬種を思い浮かべるだろう さぞその方達は犬種による例えが派生というものに頭の中で繋がらずもやもやした気持ちを抱いた事だろう しかしそれはやり方を理解しようとしているから迷う事なのだ Object思考の目的を理解していればこんな突飛な例えでも納得できるだろう まずObject思考の目的とは何か? である そしてObjectとは何か? である この何か?に興味を持つところから実はObject思考

          ¥100

          技術者としての心得 - その5 -

          ¥100

          技術者としての心得 - その4 -

          Documentを作成し常に共有すべし

          技術者としての心得 - その4 -

          技術者としての心得 - その3 -

          英語の読み書きを習得する為り

          技術者としての心得 - その3 -

          技術者としての心得 - その2 -

          技術書の購入はべからず

          技術者としての心得 - その2 -

          技術者としての心得 - その1-

          片仮名英語を使うべからず 片仮名は外来語を表現するには便利かもしれない しかしその反面日本語の母音で必ず締め括れれてしまうため結果として音節が乱れてしまう これを回避するには2つのやり方がある

          ¥100

          技術者としての心得 - その1-

          ¥100