京都市が今回失敗したような、自治体のシステム更新について
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/ Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？ A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。 それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。 Q2.なんで新規で作らないの？ A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。 Q3.メインフレーム（汎用機）って何？ A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーご
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか？ | Social Change!
「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積
GitHub製フレームワークHubotの概要とインストール、チャットアプリと連携する基本的な使い方
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
IT現場でも使える「TOC思考プロセス」：ITpro
本連載では、CCPMやDBRを生み出した大本のTOCの問題解決手法にスポットを当てる。多くのTOC関連書籍などで「思考プロセス」として紹介されているものである（本連載では「TOC思考プロセス」と記述する）。これをどのようにIT現場で問題解決に役立てればよいかを、筆者の実践経験を踏まえた知見も交えつつ解説していく。 TOC思考プロセスは、組織・システムにおける問題の根本原因を「制約」と捉え、その制約を解消する方法を考えられるようにする、体系的なアプローチである。組織変革における問題解決を目的に開発されたもので、様々なツール（後述する）が用意されており、本来は体系的に活用することが前提とされており、書籍でもそのように解説されていることが多い。 もちろんIT関連の組織全体で抜本的な生産性向上や品質向上の施策を打ちたいときにも、TOC思考プロセスをフルセットで利用してよい。しかし筆者の活用経験では
ソフトウェア開発委託基本契約書の不備により、未払い200万円の被害を受ける - Moonmile Solutions Blog
フリーで作業をしたり小さな会社で請け負い作業をするときには「ソフトウェア開発委託基本契約書」を結ぶことになると思うのだが、これを結んでしまった後、トラブルが発生したときに「請負側」が被害を蒙っている、という現状です。 本日、弁護士に相談したところ「ソフトウェア開発～」の条項から、「違約金などは取れない」旨の通知を受けたのですが、かなり納得がいかないので、ここにフリーランスという立場の防御のために事案を晒しておきます。 # 上の図は「給与」って書いてあるけど、実際は報酬/委託金です。 今回のソフトウェア開発は、発注元Lから元請けGに製品開発を依頼しています。この中で株式会社Eの仲介があって個人事業主のM（＝私）にところに話が来ている状態です。それぞれの契約は、 発注元Lと元請けGの間の契約 元請けLと株式会社Eの間の契約 株式会社Eと個人事業主Mとの契約 に分かれます。どれも請負契約で、最終
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
