先々週に引っ越ししてからネットにつなげてない。 OCNに申し込んだら1週間くらいといわれたものの、 音沙汰全くないのでやめたった。 やめようとしたら、工事の時期とかまったく言われてなかったのですんなりやめれるそうなことを言われた。 なんじゃこりゃ…

理路整然と現実を語ることで多くの人たちには納得していただける。 感情論が優先する人種には理路整然とした言葉に加えて 「これをやることがいかにあなたとついでにみんながハッピーになるか」って要素と 「でもそれにはこんな悔しいことが伴うんだ」って要…

まず断る。 (..´Д｀)＜あの〜こんな機能につけられへんかな？( ´∀｀)＜なぜ今つける必要があるんです？ (,,ﾟДﾟ)＜大変だ！今の機能じゃ足りてないからこんな機能にパワーアップしなきゃ！( ´∀｀)＜なんで今なんです？後回しにできない理由はなんでしょ？ 機…

この単語が嫌いでしかたない。 現実に沿っていない言葉だから。 それはともかく、最近の自分の技術力を持ってして「製造」が出来るようにしてみた。 ドキュメント通りにソースコードを作る。 もちろんそれを成立させるだけの仕組みも作っている。 ここまでし…

むずかしい。とっても難しい。 正確には「みんなの平均値を高めること」がとっても難しい。 ソースコードとモジュールのみを相手にみんなでやいやいやるのは 技術力があればさほど難しくない。 そこにドキュメントが入り込んでくると、難易度がとたんに跳ね…

設計書と言う名の書類が多い。 しかしあれだな。 データの移送表的なものがあればプログラム作りに支障はないし、 要望は文章で箇条書きが望ましいことを踏まえるとシステム化できるよな。 あれ？ 登録データをExcelに出力する仕組みってなんぞなかったっけ…

例えばExcelに項目の移送表を定義して、周辺事情を整えて 代入文っていうかマッピングだけすれば機能を満たすよ！ってお膳立てをしたとする。 それでも人は間違うだろう。 悩むだろう。 そしてなにより時間がかかるだろう。 ツール作って〜 って言えるように…

意外に難しいことなのかなと思った今日この頃。 例えば。 「画面で使用したデータをデータベースに送る」 代入が１回で済むような作りをするようなプログラムのことは無視してよいと思うが、*1 通常は「画面→データオブジェクト→DB」のように行われると思う…

そういや開発時に感じたこと。 業務アプリケーション作りは、答えを用意してから その道筋を作ることだな〜と。 答えありきで挑戦する証明問題みたいな感じ。 答えなかったら証明なんてどうやってやるんだろう

なんで誰も用意しないんだろう。 開発時に。 って思う現場は多い。 最近の現場でも「綺麗なデータを用意してください」といったら(ﾟДﾟ)ﾊｧ?っていわれたし。*1 開発時に「こうあるべき」って姿を用意できないデータ。 作るの難しいから後回しにされるデータ。…

あがんない！！ 最近のプログラムの楽しみの大部分は「量産化」の仕組みづくりにあるおいら。 凝集度も結合度をつきつめて、業務アプリとはこんな感じってのに一つの答えを見出した感を味わうのですよ。 しかし。 しかしだ。 フレームワークをつくり、ライブ…

いざプログラムを作ろうというときに。 ・データの流れがおかしい。 ・データの扱い方がおかしい。 こんなことに直面する。 調べてみると、データベースの構造がおかしい。 なぜか。 ・前任者の遺物を有効活用した。 ・画面からマスタテーブルを作成した。 …

ファクトリー化と聞くと、へたれでもいっちょ前に作業が出来そうなイメージがIT業界にありそうに思われる。 しかしファクトリー化に至るまでの地道な地道な作業は多くの人間が出来ない。 実現できないとか実行できないとか以前に、理解できない人が多いと言…

コンピュータが出来ることは全てコンピュータに任せたらいい。 この怠け心からスタートする。 プログラム作成を自動化するには制約がある。 制約とはある一定の手順が作成されてあることである。 手順とはこれをこうしてこうすればああなるってこった。 手順…

役割決めるのも、手順を考えるのも、 なまじ知識が付いたり、業務を知っていたりする人ほど下手だ。 データや処理のやりくりをしようとしはじめるからだ。 ハマり道への第一歩はこんな考えから↓。 「今がこうなっているからこうすれば結果が合う(･∀･)」 小手…

何事も現状を踏襲せずに考えるほうがスッキリする。 (1) 「何」が「どう」なればいいかを決める ・何をどうすれば ・何がどうなると ・あれこれをこうする ・あれがこんなようになる とかいろいろあるけれどもまず決める (2) (1)を実現するための手順を考え…

(2)で止まっている人たちって結構多いやんね。 っつか(3)以降の手順を踏襲する人たちが珍しい気もする。 仕事が正確かつ早いのは後者なんだがな。 増えていくメソッドと増えていくクラスに萎える人たちがいる。 だからといって巨大なメソッドに巨大なクラス…

単純に手順化してみる (1) 動きを決める ・どんなデータが対象で、どんな結果を得られるとうれしいかってのをなんとなくでいいから決める ・役割を決めるってこったな(2) まずは動くものつくる ・(1)を実現することが大事(3) (2)を見直す ・実現方法は果たし…

プログラムに落としづらい「仕様書」を作るのに時間と労力を割いて 苦労してプログラム作ってバグと戦う姿勢ってマッチポンプだと思う プログラムに落としやすい資料を作って、そこからプログラムと「仕様書」の両方作れば省力化得られて、 その両方にかかる…

・管理という名の下スケジュールをいじくるしか方法がないことがしばしばある。 ・っという人がいる ・現状を把握し、開発の実態を把握し、注力するポイントや改善点を白日の下に晒してから始まるコトがある。 ・でも「がんばってやらなきゃいけない点で同じ…

以下の条件でプロジェクトが達成できる要因を述べよ ・納品時期は決定している ・要員のスケジュールは決定している ・「製造」に取り掛かれるための書類は充実している ・「単体テスト」完了予定は納品時期の2ヶ月前である ・「結合テスト」はシステムテス…

・人数が多いと膠着する ・技術力の平均は普通底辺に合わせるように得体の知れない何かが働く ・高いほうに合わせるには工夫が必須 ・目先にあるスケジュールは未来にくる必然の不安から目をそむけることができる。 ・小さなことの積み重ねが大事 ・そんなこ…

ちなみに。 ・プログラム(機能)の予定工数を決定する ・プログラム(機能)作成工程を10段階ほどに分ける ・各工程に案分の重み付けを行う ・各工程が完了したら案分の分だけ作業が進んだと管理する ってなことをそのときのメンバーの実績値から工程や案分量を…

技術者達にとって ウォーターフォールモデルを押し付けられるくらいなら、 内部進行と外向けのスケジュールの嘘をつかない調整程度は、甘受できる増加作業だ。 ってなことを いろんなところでいろんな技術者達と話したときに感じた。 そんなことをウォーター…

・ウォーターフォールモデルでの開発は至難だ。 ・開発において技術力は必要不可欠な要素だ。 以上2点を考慮してプロジェクトを成功に導くにはどのようなアプローチがよいか？ 答え ・技術力のある開発者を集めて、アジャイル。 現実問題で考慮すべきこと ・…

人数が増えるとコミニュケーションコストがかかると言われてる。 その通りだと思う。 その中でもこれ無駄だよなーと思うことが2つほどある。 ・あのヒトはこう言ったけど望んでいるものはこういうのではないか？ ・口頭だけで該当の担当者と決めたのち、周知…

同じ160時間をすごすなら。 (1)良い現状維持に費やす (2)悪い現状維持に費やす (3)良い循環の継続に費やす (4)悪い循環の継続に費やす どれがうれしさ満杯で、どれが絶望と永久の縁を結ぶことになるのだろうかとふっと思った。 よくないプロジェクトにあたる…

単純に倍(ﾟДﾟ)ｸﾜｯ!!。へらしへらし(;´Д｀)φ

この事例が成功事例であるなら、やはりそこには必然と思えるだけの行動結果があると思った。「アジャイルとウォーターフォール」：文句付けるだけだと無価値エントリなので経験したアジャイル開発の事例を紹介させていただきます。 http://d.hatena.ne.jp/sh…

投資と負債は違うよ(2) http://d.hatena.ne.jp/masayang/20090306/1236351525 高生産性・高品質な開発者に高い金を払う意味 のくだり全部ステキ。 数値の話はなんとなくで受け取るのは常として、*1 「より短期間で付加価値を生み出す仕組みを実現してくれて…