ポジティブな客先常駐システム開発を考える - 勘と経験と読経
株式会社アクシアさんのブログで、常駐開発バッシング(?)記事が最近掲載されている(http://axia.co.jp/2017-08-01)ことについて考えている。指摘されているような「不適切な常駐開発」というのは確かにあるのだろうけれども（ちなみにあまり目撃したことはない）、適切に運用すればポジティブな常駐開発も有りえるはずだし、自分は一応そうやってきたと思っている。じゃあ、注意すべきところは何だろうか。 なれる！SE7 目からウロコの？客先常駐術 (電撃文庫) 作者: 夏海公司,Ixy出版社/メーカー: KADOKAWA / アスキー・メディアワークス発売日: 2012/12/27メディア: Kindle版この商品を含むブログ (43件) を見る 何が問題なのか？ 常駐や多重請負が問題なのではなくて、請負という形態において受注者が「裁量を持っているか」というのが最大の論点だと思っている
Fireタブレットだけでゼロから学ぶDeep Learning - 勘と経験と読経
ちょっと思うことがあって、Amazon Kindle Fire HD8で「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装」(電子版はAmazonではなくOreillyから購入)を読みつつ、Fireタブレット上にPythonの実行環境を作ってコードの実行までやってみた。出来ないことも多いが、意外と戦える。実質的にFire 7980円＋電子書籍2938円で意外と面白い勉強環境を構築することができる。 View this post on Instagram A post shared by Kent Ishizawa (@agnozingdays) Fireタブレットで出来ることと、出来ないこと Fire HD 8 タブレット (8インチHDディスプレイ) (第7世代) 16GB 発売日: 2017/06/06メディア: エレクトロニクス 先に結論から
情報システムの再構築戦略についての現時点の理解整理 - 勘と経験と読経
1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング／リアーキテクティング／リライト／リホスト／リビルド／リプレースなどの各戦略について考えてみたことなど。 システム開発における上流工程の課題を解決するユーザガイドを公開 コードがレガシーになる原因のほとんどは、人間に関係している～『レガシーソフトウェア改善ガイド』より (1/2)：CodeZine（コードジン） レガシーソフトウェア改善ガイド 作者: クリス・バーチャル出版社/メーカー: 翔泳社発売日: 2016/11/14メディア: Kindle版この商品を含むブログ (1件) を見る 再構築戦略の再整理 実際にはこれ以外にも手法があるのかもしれないけれど、「システム再
ソフトウェア開発の分解能 - 勘と経験と読経
ソフトウェアの開発には時間がかかる。技術の進歩はあるし、ビジネス環境の変化のスピードも早いから以前に比べたら短期間にシステムを作れるようになったけど、それでも一朝一夕でソフトウェアは作れない。 例えば、完成するまでに（最初の見込みでは）12ヶ月の作業期間が必要なソフトウェアがあるとする。費用は普通に考えると完成して引き渡されたタイミングで支払われる。しかし、開発が終了するまでの12ヶ月に一度も支払いが行われないと、開発を請け負った会社は少し困ってしまう。なぜなら作業者には月々の給料を払わなければならないからだ。 そこで、適当な作業の区切りで何回かに分けて支払いをしてもらうようにする。そうすれば、資金繰りの問題は解消される。ここまでは特に問題はないのだけれども、中間支払いのことを「分割納品」とか「中間納品」と呼ぶと、悪夢が始まる。 建築の場合 じつは建築とソフトウェアの構築の違いを知りたいと
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
