ツールの使い方に関するノウハウをデザインパターンにまとめる事例 - プログラマの思索
DataSpiderというパッケージ製品の記事を見ていたら、ツールの使い方に関するノウハウをデザインパターンにまとめる事例があったのでメモ。 【参考】DataSpiderデザインパターンβ 序章 「DataSpider デザインパターンβとは」コメントを投稿する DataSpiderデザインパターンβ｜DataSpider Technical Network RedmineのチケットをExcel形式でレポートしてみたコメントを投稿する ｜DataSpider Technical Network あるソフトウェア製品を使いこなしていくと、それに関するノウハウが色々溜まってくる。そのノウハウは、ある利用シーンに対する効果的な使い方もあるし、製品の制約によって、こういう使い方しかできない、という場合もある。そんな時に、製品のノウハウをパターンカタログで表現する、という方法は面白い。 実際、下記の
ERPの落とし穴part2～業務の裏には会計あり - プログラマの思索
ERPの落とし穴part1～SW開発ではない。要求開発だ！の続き。 「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を非常に参考にしているので、全てが僕のオリジナルの考えではないので注意。 【1】業務の裏には会計あり。業務データは必ず仕訳データに連携される。 業務システムの裏には必ず会計システムがある。 Webで作っていても、メインフレームで動く会計システムと連携できなければ、ただの箱に過ぎない。 会計システムと連動できて初めて、業務コストや売上が計算出来るし、更には売掛金管理や請求管理で経理担当者の仕事もサポートできる。 例えば、「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、販売業務では、受注→出荷→売上→請求→入金のような業務フローがあるだろう。 業務データの裏には、仕訳デー
ERPの落とし穴part3～外部システム連携がプロジェクトのボトルネック - プログラマの思索
業務システムを開発したり保守している時に、本番障害が多発したり、想定外の障害で業務が止まったりしたりするのが「外部接続」という名の外部システム連携機能だ。 今までの経験も含めて考えたことをラフなメモ書き。 【参考】 ERPの落とし穴part1～SW開発ではない。要求開発だ！: プログラマの思索 ERPの落とし穴part2～業務の裏には会計あり: プログラマの思索 【1】業務システムは基本は何らかのERPを真似たり、そのまま取り入れることで実現している。 その時、一つのシステムで全ての業務をカバーできるわけではないので、複数のサブシステムを作って各システムを連携することで、ユーザ企業の業務をカバーする方式設計が多い。 例えば、基本的な業務システム(仕入れ・売上・請求・在庫など)の他に、会計システムは別システムで作っておき、業務が発生したら自動仕訳が起きて、会計システムへデータが流れるようにす
「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい - プログラマの思索
「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしいのでリンクをメモ。 【参考】 RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない はてなブックマーク - RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない 【1】IoT企業特有の問題点を読むと、ハード業務はWF型開発、ソフトウェア業務はアジャイル開発なんだよなあ、と改めて思う。 (引用開始) IoT企業特有の問題 1. タスクが複数の開発レイヤーにまたがりまくる 2. お問い合わせ対応も横断的 3. ハードとソフトで開発サイクルが違い過ぎる (引用終了) ハード業務は文字通り、硬くて融通が利かない。 出荷してしまうと、元に戻せないしリセットも出来ないから、前工程で品質を100％くらいの気持ちで作らざるを得なくなる。 ま
AgileMetrics入門がとても分かりやすい - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ITの地殻変動はどこで起きているのか～技術革新の流れはWebから機械学習やデータマイニングへ - プログラマの思索
2015年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 自分の理解が浅いのは承知のうえで、以下は、妄想を含めたラフなメモ書き。 間違っていたら後で直す。 【参考】 機械学習をこれから始める人に押さえておいてほしいこと - Qiita Pythonでデータの分析を出来るようになりたい（その１） - Qiita Pythonでデータの分析を出来るようになりたい（その２） - Qiita Pythonでデータの分析を出来るようになりたい（その３） - Qiita Pythonでデータの分析を出来るようになりたい（その４） - Qiita 「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan Google、脳のシミュレーションで成果……猫を認識 | RBB TODAY データサイエ
レビューをTestLink＋Redmineで管理できないか？ - プログラマの思索
SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。 ＃後でまとめる。 SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。 上流工程の品質UPが鍵を握る。 そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。 しかし、設計レビューそのものの品質が低いように思う。 僕がいつもレビューで問題と思う点は、二つある。 一つは、レビューのプロセスがあいまいできちんと定義されていないこと。 例えば、レビューする際の観点がレビューアによってまちまちだったりする。 レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。 もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。 例えば、レビュー後修正の品質チェックが個人任せで、他人のチ
RedmineをBPMツールとして使うアイデア - プログラマの思索
Redmineを事務処理の申請承認ワークフローシステムとして使うとか、帳票ワークフローシステムとして使うアイデアを考えているうちに、RedmineをBPMツールとして使うアイデアについて考えてみた。 以下、ラフなメモ書き。 【元ネタ】 Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索 Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索 Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索 akipiiさんはTwitterを使っています: "それだ！ @u6k_yu1: チケット管理システム全般に言えることだとは思うけど、中でもRedmineは、ワークフロー制御と項目カスタマイズ性によって完成度が高いと言える/Redmineは帳票ワークフローシステムであるというアイデア
Redmineの「チケット計測のススメ」の記事がすばらしい - プログラマの思索
チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。 次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース＆解析して、各種メトリクスを出力する仕組み。 仕組みは簡単だが、すごく良いアイデアだ。 従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。 アジャイル開発ならば、下記が既に知られている。 詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。 ・累積フロー図：ステータス毎のチケットの枚数を時系列に並べたグラフ ・Velocity：チームの開発規模を表す ・リードタイム：平均のリリース間隔を表す。チケットの平均完了日数。 ・サイクルタイム：ステータスが変更される平均時間を表す。 累積フロー図は、チケットの増減を通じて、チーム
システム設計よりも業務プロセスの設計をやっている - プログラマの思索
業務プロセス設計についてラフなメモ書き。 主張は特に無く、アイデアをメモ。 【1】業務システムを設計・開発していると最近、システムを設計しているという感覚がない。 むしろ、業務を設計しているという感覚に近い。 すると、既存の業務フローを簡素化してシステム化するという仕事になりやすい。 特にERP導入の場合はそうだ。 既存の手作業のフローがどこまでERPの機能に吸収されて効率化されるか、がERP導入の一つの目的だから。 しかし、既存の業務フローを変更するのがとても難しい経験を何度もしている。 現場にとって、長年の業務フローが変わると、担当者の作業が増えたり減ったりするために、組織に影響をおよぼすのはご法度なのだ。 組織構造に関わるBPRの場合、ユーザ企業の責任者に承認を得て、業務フローを変更しなければならない。 既存の業務フローが変わることをきちんと合意しておかないと、せっかく決めた要件はユ
「開発組織のマネジメント」のスライド資料が素晴らしい - プログラマの思索
「開発組織のマネジメント」のスライド資料が素晴らしいのでメモ。 資料の内容を理解したレベルで書く。 【1】問題意識としては、最近15年でWeb開発は従来よりすごく難しくなり、重要度が増している。 付け焼刃で簡単にプロダクトを作れるレベルではなくなった。 その理由はいくつかある。 一つは、開発基盤やシステムがレガシーであるため、ビジネスの変化に追いつけないこと。 2つ目は、企画チーム・開発チーム・運用チームのそれぞれで異なるやり方が根付いており、押し問答の状態になっていること。 サイロ型組織故に、開発組織の行動が局所最適化されてしまい、全体最適になっていない点に問題がある。 本来解決されるべき姿は、レガシー化を防ぐ作業に継続的に取り組むことと、サイロ型組織から自己組織化されたチーム構造へ組織を変化させること。 チームが都合で解散されるようでは、習熟度はいつまで経っても向上しない。 【2】一番
BonitaBPMを動かしてみた感想～BPMツールに必要な必須機能 - プログラマの思索
オープンソースBPMツールBonitaBPMを動かしてみたのでメモ。 【参考】 ProcessSampleKit - オープンソースBPMジャパン株式会社 ProcessLib - オープンソースBPMジャパン株式会社 Bonita BPMの国内Webサイトが公式オープン、BPMN2 サンプル図を一挙公開 | 岩田研究所 オープンソースのBPMツールBonitaのメモ: プログラマの思索 ちょい図解！使って覚える始めてのBonita 【1】インストール方法 BonitaのWebサイトから、Bonitaをインストールするだけ。 Eclipseベースらしいが、ツールのUIは赤色と銀色のメタリックな感じ。 【2】BPMサンプルの動かし方 ProcessSampleKit - オープンソースBPMジャパン株式会社から、サンプル組織マスタとサンプルプロセスをインポートする。 BonitaBPMの画面
第33回関西IT勉強会の感想～製造業の基幹システムのパターンが知りたい - プログラマの思索
第33回関西IT勉強会のメモ。 感想をラフなメモ書き。 【元ネタ】 第３３回 ＩＴ勉強宴会in大阪 : ATND 関西ＩＴ勉強宴会のブログです: 第33回IT勉強宴会in大阪 【「受注生産」のためのシステム開発ライブ】 Twitter / akipii: 渡辺さんの話。受注生産にはロットごとの在庫管理もいらない。下手に経験し過ぎて過去の開発の経験の奴隷になっていた。すごく意味深 Twitter / akipii: 渡辺さんの受注生産の話は単品生産かつ受注後に仕様に基づいて生産する方式。作出属性や評価をデータベースで実現する場合、evalを使うと言う事例。最終的にはDSLに繋がるだろう. Twitter / akipii: 生産管理システムの設計パターンが知りたい。佐野さんの話では四種類あり、それぞれ特徴と課題がある。トヨタのJIT生産方式もその一つに過ぎない。在庫の変動と工場の操業率に課題
「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している - プログラマの思索
@hatsanhatさんから借りた本「受注生産に徹すれば利益はついてくる」を一気に読んだ。 渡辺幸三さんの本「生産管理・原価管理システムのためのデータモデリング」を読んできたものの、腹の底まで理解してなかったけれど、「受注生産に徹すれば利益はついてくる」を読んで、製造業の業務システムのコツが何となく理解できたような気がした。 理解できた内容をラフなメモ書き。 【参考】 書評：「受注生産に徹すれば利益はついてくる！」 本間峰一・著 : タイム・コンサルタントの日誌から 【1】受注生産の会社は下請け業者の意識が強い。 日本の製造業の大半は受注生産。 自動車も顧客ごとの要望を受けて受注生産する。 旧電電ファミリーの家電メーカー(NTT、NEC、富士通、OKI、日立)も、旧電電公社の通信機械を受注生産する所から発展してきた。 重電メーカーの三菱、東芝、日立も同様。 だから、これらの受注生産のメーカ
「採用基準」の感想～日本の根本問題はリーダーシップの総量が不足していること - プログラマの思索
「採用基準」を読んだ。 本の中身は、優れたリーダーシップ論。 自分のキャリアを考えている人、プロジェクトリーダーや経営者のように、リーダーシップの能力を必要とする人にはとてもお勧め。 とても印象的だったので、ラフなメモ書き。 【1】ドラッカーの本ではいつも「マネジメントとリーダーシップの違いは何か。それぞれの本質は何か」という問いに対して、延々と議論されている。 「採用基準」では、マネジメントとリーダーシップの違い、リーダーシップとは何か、を明確に提示している。 マネジメントとは、プロセス管理、予算や人材などのリソース管理、スケジュール管理などの管理業務。 PMBOKがその内容を明確に提示している。 課長職以上になれば、必要なスキル。 リーダーシップとは、問題に対しゴール(課題)を提示し、その課題に対する解決策を導き出す行為。 マネジメントとは全く異なる概念。 リーダーシップは、管理職だけ
出版システムや文書共有システムを作った事例 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
バランススコアカードの例 - プログラマの思索
【1】BSCが必要な背景と問題 超上流工程であるシステム提案では、ビジネスの企画のスキルが問われる。 ITシステムを入れると、業務にどんな利点があるのか、ITシステムを導入した後のビジネスモデルはどのようになるのか、を提示しなくてはいけない。 前者は、ITシステムがどんな問題に対して有効で、導入したらどんな効果が出てくるのか、を定量的に示せればベストだ。 後者は、ITシステムの初期構築費用と保守運用費(いわゆるランニングコスト)がどれだけ発生し、いつになったら損益分岐点に達するのか、を提示する必要がある。 すると、本来の業務のあるべき姿に対し、ITシステムを入れると、どんな問題が解決されて、どのように効果が波及するのか、といった全体像を示さなくてはいけない。 そんな時に、バランススコアカードを使うと、内容をうまく整理できる。 【2】BSCの特徴 【2－1】BSCで最も重要で、最も効果的な成
BABOKの4つの要求 - プログラマの思索
BABOKの4つの要求について考えたことをメモ。 【参考】 BABOKで“超上流”を強化する - Part2 4種類の要求を区別する：ITpro （2/4）BABOKで“超上流”を強化する - Part3 “超上流”の標準化にBABOKを活用する：ITpro 要求の分類方法について｜ザ・プロジェクトマネジャーズ 【プロジェクトマネジメントを成功に導くビジネスアナリシス】（その1、2） BABOKR2.0 知識エリア： 要求アナリシス 【1】発注者がベンダーにシステム開発を依頼する時、RFPにシステムの要求や要件を載せる。 しかし、RFPに何をどこまで書くべきか、あいまいな時が多い。 最悪な発注者は、自分たちが欲しいシステムの要求をRFPに書けない。 その理由は、色んな利用部門の要望を収集するうちに、どんなシステムを作るべきか、「システムのあるべき姿」を想像できないからだ。 たくさんの利用部
Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart - プログラマの思索
Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart Redmineのアドオン製品 Lychee Gantt Chartのデモ画面を触ってみた。 感想をラフなメモ書き。 【参考】 Lychee Enterprise～マネージャのためのRedmine shinagawa.redmine 第6回勉強会に参加してきた - njuntechのブログ 【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索 【1】Lychee Gantt Chart Plugin | Lychee Enterprise Lychee Gantt Chartは、Redmineのガントチャート画面を機能強化
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
