<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>satのブログ</title>
<link>https://ameblo.jp/n-satoko/</link>
<atom:link href="https://rssblog.ameba.jp/n-satoko/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>ブログの説明を入力します。</description>
<language>ja</language>
<item>
<title>改善したいＩＴの現場③</title>
<description>
<![CDATA[ <p>開発現場でよく発生するものの一つが、要件定義のトラブルです。</p><p>要件の、言った・言わないは、議事録などドキュメントを駆使して何とか防ぐように</p><p>頑張る事ができますが、ドキュメントだけではどうにもならないのが、お客様の要件</p><p>決定問題です。</p><br><p>「要件決定問題」と漠然と書いてしまいましたが、つまりは、要件がわからない・</p><p>決まっていない・決められないという状況です。</p><br><p>課題に対して、メリット・デメリット・コスト・それに関わる人的労力など、様々な決定</p><p>要素を提示しても、お客様の本来の目的が曖昧になっていると、方向性が定まり</p><p>ません。</p><br><p>最終的には、「どうしたら良いと思いますか？」と聞かれるので、アドバイスを</p><p>させて頂く事はありますが、でも、基本的にはお客様の業務ですし、お客様に</p><p>意思を持って頂きたいと思っています。</p><br><p>意思決定に向けての材料が不足しているのであれば、何が問題で決定できない</p><p>のかをお話頂ければ、頑張って材料提示をしたいと思っています。</p><br><p>でも・・・</p><p>今までに、何度か要件が決まらない現状に遭遇した事があります。</p><p>その理由が以下があるように感じました。</p><p>　・権限者が明確ではない。</p><p>　・権限者が複数人存在し、それぞれの思惑が異なる。</p><p>　・業務イメージがないまま、ＩＴ導入をトップダウンで命令されている。</p><br><p>このような状態で進めたシステム開発は、兎角、出来上がりのシステムとお客様</p><p>の思惑が異なったものになって、「使えないシステム」になってしまいます。</p><br><p>システム開発は、結構な投資コストが掛かりますから、お客様もそれなりに腹を</p><p>据えて取り組んで頂く必要があると思っています。</p><br><p>その為の一つとして感じている事は、漠然と「ＩＴ化を進めなければならない」という</p><p>のではなく、「自分達の会社のポテンシャルを高める為に、ＩＴをどのように活用した</p><p>らより効果的か」という視点で考えて頂くのが良いのではないかと思っています。</p><br><p>考えた結果、「ＩＴは必要なく、業務改善だけで充分に効果を発揮する」という結論</p><p>に至っても良いと思っています。</p><br><p>無理して導入する必要なんて全くない。</p><p>「自社の可能性を最大限に高める為に、何が必要か。」</p><p>その事を中心に考えて頂いて、その為のＩＴとして有効活用して頂きたいと思って</p><p>います。</p><br><br>
]]>
</description>
<link>https://ameblo.jp/n-satoko/entry-11610434302.html</link>
<pubDate>Mon, 09 Sep 2013 23:24:05 +0900</pubDate>
</item>
<item>
<title>改善したいＩＴの現場②</title>
<description>
<![CDATA[ <p>私は暫く、ＩＴシステムパッケージの開発チームに属していた事があります。</p><br><p>その時思った事は、お客様がパッケージシステムを投資に見合うだけ使いこなす</p><p>のは難しい、という事でした。</p><br><p>パッケージシステムは総じて高価ですが、見方を変えれば、１から顧客個別の</p><p>システムを開発するよりも安価で実績もあり、安心と言えます。</p><br><p>しかし、お客様にとっては不要な機能も多く含まれており、システムとしては無駄な</p><p>ものになります。</p><p>その分のコストがお客様にとっても無駄になります。</p><br><p>その時私が思ったのは、パッケージ機能の切り売りです。</p><p>今ではクラウドを利用した機能の切り売りや、機能を少し細分化したパッケージも</p><p>発売されてはいますが、やはりお客様にとっては無駄な機能が多い。</p><br><p>私の理想として考えているのは、スクラッチ（１から開発する）より安価・安心で、</p><p>かつ、お客様に必要な機能だけを提供できるパッケージの切り売りです。</p><br><p>出来そうですよね。</p><br><p>出来そうなんですが、まだ市場に出てこないのは、開発企業にとっての「投資対</p><p>効果」が出づらい・採算性が低いからなのではないかと思っています。</p><br><p>この点については、私の長期的研究課題であり、一概に回答はでませんが、諦め</p><p>ずに探求してみたいと思っています。</p>
]]>
</description>
<link>https://ameblo.jp/n-satoko/entry-11604656075.html</link>
<pubDate>Sun, 01 Sep 2013 21:14:42 +0900</pubDate>
</item>
<item>
<title>改善したいＩＴの現場①</title>
<description>
<![CDATA[ <p>改善したいＩＴの現場として思っている事。</p><p>それは、ドキュメントの多さです。</p><br><p>今では社内開発はWiki等のWebベースにドキュメントを載せている会社も</p><p>多くあると思いますが、お客様相手には、そうはいかない。</p><br><p>やれレビューポイントだの設計書だのと言って、山ほどのドキュメントを記載します。</p><br><p>勿論、必要な事なのです。</p><br><p>でも、何か効率よくできないかなぁと、いつも思っています。</p><br><p>お客様側も、ドキュメントの量やレビューの多さでプロジェクトの管理体制や</p><p>プロジェクト自体の良し悪しを測る傾向にあるから、さらにややこしい。</p><br><p>お客様にしてみれば、開発現場が見えないから、良し悪しを判断する材料として</p><p>何かの視点が欲しいのは解ります。</p><br><p>特に、大規模システムになると、本当に現場が見えづらくなるのも事実です。</p><br><p>でも、ドキュメントの多さが結局、コスト高に繋がってしまう現状も否めない。</p><br><p>私は、最適なコストで最適なシステムを作る最善の方法は、お客様自身が</p><p>より賢くなって、ＩＴリテラシーを高めるしかないのではないかと思っています。</p><br><p>こんな事を書いてる事をお客様に知られたら、怒られてしまうかもしれません。</p><p>でも、実際、ＩＴの現場では、お客様に理解してもらう為にあえて行っている</p><p>作業がたくさんあるのです。</p><br><p>これについては、また別の機会に深堀します。</p><br>
]]>
</description>
<link>https://ameblo.jp/n-satoko/entry-11603353801.html</link>
<pubDate>Sat, 31 Aug 2013 00:03:55 +0900</pubDate>
</item>
<item>
<title>このブログについて</title>
<description>
<![CDATA[ <p>大学の課題で始まったとは言え、日記も満足に続かない私が、ブログを書くことは難しいのですが、書くとすれば、日頃思っている、</p><p>　　「顧客企業のポテンシャルを最大限に活かす為のＩＴ提案」</p><p>を念頭におきながら、記載したいと思います。</p>
]]>
</description>
<link>https://ameblo.jp/n-satoko/entry-11603341319.html</link>
<pubDate>Fri, 30 Aug 2013 23:55:14 +0900</pubDate>
</item>
</channel>
</rss>
