オブジェクト倶楽部イベントがまたやってきます。『プロジェクト・ファシリテーション〜「ものづくり」からチームづくり」へ〜』ワークショップ内容、講演者の情報も随時更新中。申し込みは、もうしばらくお待ちください。JUDEを使ったモデリングセミナーを5月末から開催致します。ワークショップを多く取り込むことでUMLの基礎からモデリングのコツを開発現場に持って帰っていただこうと考えています。講師との円滑なコミュニケーションによる高い学習効果また、モデリングツールにはJUDE/Professional(有償版)を使用する為、この機会に体験してみては如何でしょうか。JUDEとセミナーのセット価格などその他特典も設けています。┗【PF】価値と原則[1]「プロジェクト・ファシリテーション(PF)」の第2回の連載は、「価値と原則」です。「朝会ガイド」を取り上げてきたPFですが、今回は、このPFの価値と原則について、考えていきます。プロジェクトを成功させるために、大切なものはなんでしょう?私自身、ソフトウェア開発のプロジェクトに多く携わってきましたので、その例でお話します。プロジェクトに参加する個人個人に、プロジェクトが扱う問題に関する「ドメインスキル」が必要です。語、デザインパターンやユースケースなどの開発手法の知識とそれを利用した分析、設計、実装のスキルまで、幅広い技術知識とスキルが求められます。扱うビジネス分野ごとの業務知識も求められます。銀行のシステム開発であれば金融業務、病院のシステム開発であれば医療業務の知識です。これらのスキルは、おもに勉強や実習によって、本、現場、先輩から学んでいくものです。次に「ヒューマンスキル」が必要です。力、プレゼンテーション能力などがこれにあたります。ヒューマンスキルがないと、ドメインスキルを持っていてもそれがうまく活かされません。験、参加型のセミナーなどによって成熟していくものです。いったドメインスキルとヒューマンスキルをもった「個人」が集まって「チーム」を組んだプロジェクトでは、もう一つ大切なことがあります。それは、個人と個人をつなぐ場作りです。個人と個人を繋いで100%以上を導く場。このようにチームを機能させ、活性化することにフォーカスした技術・手法を、「ファシリテーション」と言います。ファシリテーションには、机の配置やホワイトボードの使い方、さらに会議やブレインストーミングの運営方法まで幅広い内容が含まれます。ちなみに、ソフトウェア開発に限らず、「ファシリテーション」およびそのスキルをもった実践者である「ファシリテーター」はさまざまな分野で現在注目を集めています。しても、ファシリテーションは有効です。自身は触媒のように働きながらチームとしての価値を最大にします。ファシリテーションとは、スキルを持った個々人の能力を最大限発揮させるチームの場作りなのです。経営幹部の肩書きも現れました。_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。運用が最上流こんにちは、天野勝です。今回のお言葉は「運用が最上流」です。筆者がはじめて聞いたときに、とてつもなく衝撃を受けたこのお言葉を、今回も筆者の独断と偏見で、解釈、解説してみます。開発ばかりしている人からは、運用ってどうやっているか想像はつくものなのでしょうか。筆者は、以前某電機メーカの情報システム部に所属していました。具合修正)を行っていました。それほど大きくないシステムが多く、たいてい一人で開発を行い、運用し、必要に応じて保守していました。人事異動があると、システムの担当が見直されて、他の人のシステムを引き継ぐこともあります。人手が足りない場合は、開発や保守を社外に発注することもありました。運用は自分たちで行います。このような状況で、「システムが動いてなんぼなんだなぁ」と感じていました。プログラムを作っても、動かさなくては意味がありません。作っただけではコストを削減することも、稼ぐこともできないのです。動くためには、ハードも含むシステムが必要なのです。時には開発が最優先され、運用されることをあまり意識していないシステムもあります。恥ずかしながら筆者が最初に作ったシステムも、ほとんどといってよいほど運用が意識されていませんでした。このようなシステムは、日々のバックアップ作業や、マスターのメンテナンスにとてつもない労力を必要としていました。月次処理が、朝になっても終わらないというのも中にはありますし。組織変更があったり、組織長が変わるたびにマスターをメンテナンスすればすむというのではなく、プログラム自体を書き換えなくてはならないのもありました。このようなシステムは動かせば動かすほど、損をしているような気になってきます。そこで、このような状況を打破すべく、プログラムに改良を加えて、運用のコストを抑えるようにしていきます。自分の場合はこのようにして、システムを成長させていきました。用する側からも、使っていく中で新たな要望が出てきます。項目のレイアウトを変更したいだの、新たな項目を増やしたいだの、今まで別々のシステムだったものを連携させたいだの、その要望は小さなものから大きなものまでいろいろとあります。このような要望は、まったくゼロから湧いて出てくるのではなく、日々使っていく中でヒラメキとして出てくるのです。運用して初めて要望が出てくるのです。稼動しているシステムがありますので、要望は具体的ですし、お互いの考えに違いが少ないので、話はとてもスムーズに進みます。レイアウトの変更であれば、すでに稼動しているシステムの画面のハードコピーや、実際の帳票に直接書き込みますし、システム同士の連携も実際のデータを使って話し合いをすることができます。個々のシステムに保守という形で実装されていくのです。ありますが、これに近い状態だと思います。自分が経験した社内情報システムのほとんどは、このような流れで成長していきました。要求分析なんかにあまり時間はかけません。運用されているシステムがあるので、それが基本です。そこに新たな機能を足したり、別の機能に置き換えるだけなのです。運用しているからこそ、開発コストだけではなく、運用と保守を考えたコストを意識することができるのです。どのようなシステムを対象としているかで思いは違うでしょうが、筆者にとって「運用が最上流」という言葉は、まさにそのとおりで、もっと多くの開発者に運用について知ってもらいたいと思っています。_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。ホントのところ今週は「ここ半年くらいの平均残業時間は何時間ですか?」のホントのところ。残業が多いとささやかれるシステム業界。実際はどのくらい残業されているんでしょうか。ほとんど残業してません。