win10 uwp 右击浮出窗在点击位置

http://lib.csdn.net/article/csharp/46624

本文主要让MenuFlyout出现在我们右击位置。
我们一般使用的MenuFlyout写在前台，写在Button里面，但是可能我们的MenuFlyout显示的位置和我们想要的不一样。
通过使用后台写ShowAt的方法，我们可以通过e.GetPosition获得鼠标点击位置，需要对函数传入相对的元素，这个元素一般可以用我们点击使用的元素，也可以使用我们的最外层Grid，这样我们就可以获得了鼠标位置，也就可以显示我们的MenuFlyout在点击位置。
我们建一个ListView，然后绑定后台，在我们ListView要右击显示我们的浮出，要求我们的浮出在我们点击位置。
MenuFlyout可以在后台写，当然写在前台也可以。
我们这写在后台，我们可以选择Placement 显示在我们元素的位置，但这不是我们鼠标点击的位置，要显示我们鼠标点击的位置，其实也很简单。我们可以从e.GetPosition(sender as UIElement)获得鼠标位置，把这个给MenuFlyout我们的浮出显示在我们鼠标点击位置

<ListView ItemsSource="{x:Bind View.Str}">

        <ListView.ItemContainerStyle>

            <Style TargetType="ListViewItem">

                <Setter Property="HorizontalContentAlignment"

                                    Value="Stretch" />

                <Setter Property="VerticalContentAlignment" Value="Center"></Setter>

            </Style>

        </ListView.ItemContainerStyle>



        <ListView.ItemTemplate>

            <DataTemplate>

                <Grid Background="#FFda2a5c" RightTapped="GridColection_OnRightTapped">

                    <TextBlock Text="{Binding}"></TextBlock>

                </Grid>

            </DataTemplate>

        </ListView.ItemTemplate>

    </ListView>

后台写

   private void GridColection_OnRightTapped(object sender, RightTappedRoutedEventArgs e)

    {

        MenuFlyout myFlyout = new MenuFlyout();

        MenuFlyoutItem firstItem = new MenuFlyoutItem { Text = "OneIt" };

        MenuFlyoutItem secondItem = new MenuFlyoutItem { Text = "TwoIt" };

        myFlyout.Items.Add(firstItem);

        myFlyout.Items.Add(secondItem);

        //if you only want to show in left or buttom 

        //myFlyout.Placement = FlyoutPlacementMode.Left;



        FrameworkElement senderElement = sender as FrameworkElement;

        //the code can show the flyout in your mouse click 

        myFlyout.ShowAt(sender as UIElement, e.GetPosition(sender as UIElement));

    }

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。欢迎转载、使用、重新发布，但务必保留文章署名林德熙(包含链接:http://blog.csdn.net/lindexi_gd )，不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我联系。

エンジニアの自己PR例文

http://it.tenchalle.com/pr.html

IT業界、エンジニアの転職に役立つ自己PR例文の見本・サンプルを17パターン紹介。 システムエンジニア、プログラマ、ITコンサルタント、サポートエンジニア、機械設計エンジニア、ネットワークエンジニア、クリエイター、プリセールス、WEBデザイナー等の自己PR例文を一挙ご紹介します。 自己PRの内容は、面接時に人事担当者から質問される項目でもあり、重要な評価基準となりますので十分に内容を吟味して作成してください。

１	SEの自己PR例文　１ SEとして5年経験を積んで参りましたが、SEは私の天職だと自負しております。SEとして最も重要な要素は顧客との信頼関係だと考えておりますが、エンジニアとして顧客との信頼関係を築くために必要な3つの要素を自分は大切にし、培ってきたからです。それは問題意識・責任感・技術力の3つです。例えば、システムを構築するために顧客の要件を細部まで確認し、少しの修正でも他所への影響や運用の問題などを考える癖をつけるなど、仕事の中で3つの能力を意識しながら取り組むよう心がけてきました。今後も顧客とコミュニケーションをとりながら、多くのサービスを提供できるエンジニアとしてスキルアップしていきたいと考えています。
２	SEの自己PR例文　２ ＸＭＬを中心に様々なアプリケーション開発を経験してきました。現在、Java、XML、Visual Basic、C++、HTML、PL/SQL、CORBA、Pealを習得しています。システムインテグレーターの方やコンサルティング会社の方と一緒に仕事をするなかで、折衝なども経験し、コミュニケーション力にも自信があるため、SEへのステップアップを望んでいます。プロジェクト管理についてはサブリーダーとしての経験でメンバー管理に携わったことがあり、予算やスケジュール管理も含めて今後経験を積み、一流のSEになるために努力を惜しみません。
３	SEの自己PR例文　３ 大学卒業後、大手不動産企業のシステム構築分野で社内SEとして5年間勤務してきました。顧客管理、物件管理などの基幹システムの構築および改修という、正確かつ安定性が求められる分野であり、またクライアントや協力会社との円滑なやり取りも求められるため、コミュニケーション能力をも磨いてこれたと自負しております。今後は、得意分野をさらに強め、より専門性の高い挑戦的なプロジェクトに携わりたいと考えています。
４	PGの自己PR例文　１ 未経験ですが、プログラマーとしての職を希望します。現在、地元の住宅メーカーで営業をしておりますが、以前から趣味でCやJavaなどでソフトを自作しており、自分の設計したとおりにシステムが動作することに大きな喜びを感じます。仕事としてこれまでのスキルや経験を活かしてみたいと強く思うようになりました。プログラマーとしては未経験ながら、長年続けてきたプログラミングに対する思いは本物だと自負しております。また、チーム内や顧客との関係性作りの面では、これまでの営業経験を活かして相手の気持ちを察して応対することで、良好な関係が作れる自信があります。
５	PGの自己PR例文　２ 大学卒業後3年間、総務として社内報の作成、社内資料の作成などを行ってきましたが、自社ホームページ更新等に携わるなかで、プログラミングに興味を持つようになりました。昨年よりパソコンスクールに通い、Office2010のマイクロソフトオフィスマスターを取得しました。またプログラム経験はありませんが、独学でJava、C言語、Linuxを習得中です。 ※Word、Excel（エキスパートレベル）、PowerPoint、Access（ベーシックレベル）
６	PGの自己PR例文　３ プログラマーとしてさまざまなソフトウェア開発現場に7年間勤務してきました。現在はCやJava、PHP、Rubyなど数多くの開発言語に対応可能です。特にPHPでのWEBサイト構築に自信があり、昨年は大手クライアントからの依頼により、グルメサイト、求人サイト、不動産検索サイトを制作しました。検索サイト構築では、一流のDBエンジニアと関わることが多くあり、DB設計の善し悪しによってプログラミングの手間が大幅に省けることを発見しました。今後は、様々な角度からプログラミングを見直し、より高機能でレスポンスのよいプログラミングができるよう技術を磨きたいと考えております。
７	ITコンサルタントの自己PR例文 大手SIerからの業務系システム受託開発業務と、ERP導入およびBPRを中心としたコンサルティング業務を主に担当し、メインフレーム、PC、オープン系システムでの設計から導入までを幅広く経験してきました。特にERPに関しては、SAP R/3　FI、CO認定コンサルタントの資格をもち、要求分析から設計・開発、運用・保守までの一貫した業務を経験しました。またSAP導入を複数同時にマネジメントした経験もあります。今後はＥＲＰでのチームマネジメント経験と会計知識をベースに、より難易度の高いプロジェクトに携わりたいと考えており、貴社のプロジェクトに関心を持ちました。
８	サポートエンジニアの自己PR例文 5年間PCのコンシューマサポートに従事し、ネットワーク製品の性能評価・製品マネジメント業務にも幅広く携わり、テスト環境の構築や検証業務、トラブル対応を担当してきました。ネットワーク製品の評価・検証では性能評価、ベンチマークテストだけでなく、テスト結果・報告書作成および顧客への報告会にも携わりました。また管理業務では製品の進捗管理や海外法人・ベンダとの社外交渉およびチームリーダーとしてメンバーの指導・管理も経験しております。コミュニケーション能力、思考・分析能力には自信があり、新しい知識を抵抗なく取り入れる姿勢で業務に取り組んで参りました。
９	機械設計エンジニアの自己PR例文 自動車メーカーで車体の板金プレス部品設計や自動車の構造設計を固めていくプロセス、及び3D-CADでのモデリングを3年間担当しております。車体デザインデータ及びワイヤーデータから構造上成立する形状を作り出し、プレス金型設計担当者や関連部署と協議しながら性能、生産性、コストなどを考慮して詳細設計を行なうなど、四輪自動車外板部品、板金プレス部品の設計を経験しております。201X年には、3次元CAD利用技術者試験1級を取得し、自動車以外のデザイン設計でも十分技術力を活かせると自負しております。特に環境保護分野の機械設計で活躍されている貴社でお役に立ちたいと思いこの度応募させていただきました。
１０	ネットワークエンジニアの自己PR例文 4年間、サーバ・ネットワークに関する提案、設計、構築、保守・運用を行ってきました。ネットワーク監視網の提案・設計では、チームリーダーとして人員計画や予算管理などのプロジェクトの管理も経験しています。またＩＰ－ＶＰＮ、広域イーサ、ＷＡＮ設計においては、機器や設定の検証、設計や導入、トラブル対応など幅広く担当し、ネットワークのスペシャリストとしてより広範な領域を手がけられるよう技術習得に積極的に取組んできました。今後はリーダとしてのスキルや経験を活かせる環境で、より大きく信頼性を求められるネットワーク構築に挑んでいきたいと考えています。
１１	品質管理・品質保証の自己PR例文 前職では電源機器部品に関する品質管理業務全般を経験しており、製造工程における流れについては、一通りの業務知識を網羅しています。特に品質管理手法や分析手法を自ら立案し、標準化した経験から、品質管理工程の確立には自信があります。また昨年は品質管理のリーダーとして他拠点への技術指導を任されており、後進の育成も得意としています。特に管理工程に沿って留意するポイントを他メンバーにも共有することで、現状の問題点を浮き彫りにし一つひとつ見直しました。知識を伝えることの重要性を再確認しました。
１２	クリエイターの自己PR例文 大学在学中から急速に市場を広げているIT業界に将来性を感じ、その分野でのスペシャリストになろうとIT関連企業に就職しました。3年間、クライアント向けWEBサイトの更新やデザイン業務、およびHTMLコーディング業務を行っており、制作工程における幅広い作業経験を積むことができました。デザインは主にPhotoshop、Illustrator、FireWorks（GIF作成等）で行い、CSSによるサイト制作の実務能力もあります。またコーディング作業はDreamweaverを主に利用し、FLASH制作でもActionScriptを修正する程度は可能です。今後はクリエイターとしての幅を広げるため、WEBデザインにとらわれずスマートフォンアプリやゲームデザインなども手がけたいと考えております。
１３	複数業務担当の自己PR例文 これまで様々なアプリケーションソフトウェアおよびシステムの開発、設計、テスト、保守サポートに広く関わってきました。その都度新しい技術に取り組み、製品の品質アップに力を入れてきました。また、お客様の要望をヒアリングして提案をまとめ、開発から納品までの一連の業務にも携わってきました。昨年は、中堅メーカーの基幹システム開発のプロジェクトリーダーを任され、顧客との折衝、20名のプロジェクトチームの構築、メンバーの教育、予算管理、スケジュール管理などトータルで任され、システム構築を無事成功に導きました。こうした経験は今後、さらに大きなシステム開発に携わっていくために必ず役立てられるものと確信しております。
１４	プリセールスの自己PR例文　１（管理職経験あり） 前職ではインフラ基盤構築プロジェクトの全体管理を担当しており、プロジェクトの規模、収益性、人数、工数など、プロジェクト全体を見据えた見積書の作成と、プロジェクトマネジメント業務を任されておりました。インフラ基盤構築を一手に担うプロジェクトをまとめ、業務効率化および売り上げの拡大に貢献してきた自負がありあます。また手掛けたプロジェクトの質の高さには定評があり、取引した大手企業の多くから、実績に対する高い評価も頂いています。
１５	プリセールスの自己PR例文　２（未経験） 前職ではシステム導入コンサルティングをしておりました。具体的には顧客の業務分析・ソリューション提案・導入コンサルティングを主体とし、システム導入時の業務要件定義・システム化要件定義、システム構築に関するシステムアーキテクチャ設計を担っておりました。そのためプリセールスとして最初にお客様と向き合い、お客様自身も気づかない潜在的なニーズを丁寧に掘り起こし、課題の抽出・解決に向けて正確な青写真を描くことには長けていると自負しています。
１６	WEBデザイナーの自己PR例文　１ インターネットというツールの魅力を最大限に活かし、クライアントのビジネスを成功へと導くサイトをつくりあげるプロとして、WEBデザインを手がけてきました。もちろんデザインだけでなく、企画・ディレクション・コーディング等、WEBサイト制作のすべての工程を経験しています。トレンドを活かし、シンプルかつクールでユーザーが使いやすいデザインを意識したWEBサイトづくりを得意としており、大手アパレル業界に多くの取引実績と人脈があります。特に若者のPC離れを踏まえて顧客からの要望も増えている、スマートフォンやタブレットとの連携を考慮したレスポンシブ対応も得意です。
１７	WEBデザイナーの自己PR例文　２ スマートフォン向けアプリケーションのコンテンツデザインを中心に、コンテンツのコンセプトメイキングから開発までトータルで携わりながら、デザインセンスや発想力を発揮しています。特にアプリケーションのUI・UXのデザイン・設計においてクライアントからの評価が高く、絶対の自信を持っています。これまでのアプリデザインは小規模なECサイトから大規模な大手通信企業の消費者向けアプリまで約40件の案件を手がけております。

★職種別の志望動機例文はこちらから確認できます。

履歴書の書き方と注意点

履歴書とは経歴とアピールポイントをわかりやすくまとめたＰＲツールです。 履歴書とはあなたの経歴を簡素に紹介する基本データであり、自分のアピールポイントをわかりやすくまとめたＰＲツールです。 履歴書と職務経歴書は一緒に提出するため、職務経歴書でどれだけ誇れる経験やスキルを記入しても履歴書に魅力がないために職務経歴書に目を通してもらえず、不採用となるケースがあります。 IT業界、エンジニアの転職の場合、特に職務経歴書を読まずにはいられなくなるような、興味を引く履歴書を作成しましょう。 履歴書の書き方と注意点についてはこちらから確認できます。 履歴書テンプレートの無料ダウンロードはこちらから

スキルシートの作成方法と注意点

スキルシートは、転職を成功させるために作成する最も重要な応募書類です。 IT、Web系の転職の場合、応募先企業から履歴書に加えてスキルシート（職務経歴書）の提出を求められます。これは応募先の企業が、応募者のスキル、経験、実績などをスキルシートから判断し、即戦力となりえる人材かを判断するためです。 スキルシートは、企業に情報提出するために作成するのではなく、キャリアや能力を効果的にアピールし、転職を成功させるために作成する、最も重要な応募書類です。 スキルシートの作成方法と注意点は「スキルシート必勝法」から確認できます。

スキルシート（職務経歴書）の見本・サンプル15種

スキルシートは、転職を成功させるために作成する最も重要な応募書類です。 エンジニア、プログラマ―、Webデザイナー、ITコンサル・プリセールスなど、職種別にスキルシート（職務経歴書）の見本・サンプルを紹介。 書き方のポイント、チェック項目を確認できます。 15職種の見本・サンプルから自分が希望する職種、経歴に合ったものを選び、スキルシート（職務経歴書）の作成に役立ててください。 スキルシート（職務経歴書）の見本・サンプル15種はこちらから確認できます。

Andriod

第一次使用Android Studio时你应该知道的一切配置（二）：新建一个属于自己的工程并安装Genymotion模拟器

http://www.cnblogs.com/smyhvae/p/4392611.html

基本設計のドキュメント構成と作成手順

基本設計のドキュメント構成と作成手順

第1回で「業務フロー」、第2回で「機能一覧表とI/O関連図」について説明しました。今回は残りのアウトプットを取り上げて、基本設計フェーズのドキュメント標準を完了させることにします。「DUNGEON」の標準で定義されている基本設計工程のアウトプットは、表1の通りです。

工程 ドキュメント成果物 内容 範囲 媒体 基本設計 （外部設計） 業務フロー 全体 Excel システム構成図 全体 Excel ER図 全体 OBER テーブル定義書 全体 OBER 機能一覧表 全体 Excel 設計書記述様式 全体 Excel 基本設計書 （外部設計書） 概要 I/O関連図 画面/帳票レイアウト 個別 Excel

表1：基本設計工程のドキュメント構成    基本設計書は機能ごとに表紙、I/O関連図、画面レイアウトまたは帳票レイアウトで構成されます（図1）。この例では説明の便宜上、画面レイアウトと帳票レイアウトを一緒にしていますが、実際はプロスペクト一覧（画面）とプロスペクト一覧表（帳票）は別々の設計書として起こします。 図1：基本設計書 （画像をクリックするとExcelファイルをダウンロードできます。/58.0KB）    基本設計フェーズの作業をおおまかに言えば次のような手順で行います。 業務フロー作成 機能一覧表作成 基本設計書（表紙＋I/O関連図＋画面/帳票レイアウト）作成 テーブル定義（ER図＋テーブル定義書）作成 表2：基本設計フェースの作業手順    最初にユーザ業務のヒアリングを行いながら「業務フロー」を作成し、その中にシステム化対象となる画面や帳票を位置づけます。次にそれらの画面や帳票をサブシステム単位に整理して、「機能一覧表」を作成します。そして1つずつの機能に対して「基本設計書」を作成します。    基本設計書ではどのデータを使ってどう処理するかをI/O関連図で定義し、具体的な画面・帳票イメージを「画面レイアウト」や「帳票レイアウト」で表します。ユーザが理解しやすいように実際の画面・帳票に近いものを作成して、項目などの確認を行ってもらいます。そして、それらの画面・帳票に表示するデータを考慮したテーブル設計を行い、「ER図」と「テーブル定義書」を作成します。 画面レイアウトと帳票レイアウト    図1の画面レイアウトの目的はユーザにイメージを見てもらって仕様を確認することです。それと同時に、この後の詳細設計にも流用して使用しますので、作る観点での記述様式も取り入れています。具体的には、表示項目なのか入力項目なのか、数値表示なのか文字表示なのか、半角文字か全角文字か、データ表示の桁数、金額などのカンマ編集、日付の表示パターン、リンクの有無、ラジオボタンやチェックボックスやプルダウンリストなどの使用、スクロールバーの有無、ボタンの配置や表示文字などです。    図2は表1に含まれている「設計書記述様式」の中から、画面・帳票レイアウトの記述方法の説明箇所を取り出したものです。「設計書記述様式」は設計書の記述ルールを説明するためのもので、第1回で「業務フロー記述様式」、第2回で「I/O関連図の記述様式」を紹介しています。 図2：画面/帳票レイアウトの書式文字 （画像をクリックすると別ウィンドウに拡大図を表示します）    一般の画面レイアウトではデータ部分の表記文字に「X」を使い、「XXXXXX」と表す例が多いと思います。しかし、「X」だけだと情報量が不足するので、DUNGEONでは図2の例のように「6、9、Z、O、B」などの文字を使うようにしています。文字の桁数や全角半角の区別も原則的には設計書に記述した文字通りに記述するルールとなっています。例えば、「ＯＯＯ」なら全角3文字の表示、「Z,ZZZ,ZZ9.99」ならゼロサプレス付で9百万までの半角数値を小数点2桁で入力できることになります。    図1の帳票レイアウトの方では入力しないので「9」や「B」は使いませんが、記述書式は画面と統一しています。改行条件、改ページ条件、データの表示順などにつきましては、詳細設計時に追記しますので、ここではイメージだけに留めます。 Web画面の設計サイズは枠を超えてしまう    これまでの画面設計は図1の画面レイアウトのような縦横の固定枠でOKでしたが、Webベースの画面の場合は縦がずっと長くなる可能性があります。そのためDUNGEONではExcelの画面レイアウトだけでなく、HTMLで画面を作成したものを設計書に貼り付けるという処理も許可しています。    なお、ここではExcelを使用していますがExcelには重大な欠点があります。それは、デザインモードで文字が枠内に入っていても、印刷した場合にはみ出てしまう場合があることです。そのためExcelで画面設計を作成する際は、プレビューを確認しながら枠幅を調整する必要があります。DUNGEONはExcelで統一というのが基本構想なのですが、仕方がないので、ここはWordで仕様書を作成することも許可しています。

ER図とテーブル定義書

画面・帳票レイアウトを作成したら、次はER図とテーブル定義書の作成です。ER図とはEntity Relationship Diagramの略で、データ中心設計（DOA：Data Oriented Approach）に向いたモデリング記法です。ER図はデータベース設計に広く使われており、E（エンティティ）はテーブル、R（リレーション）はテーブルの関係に相当します。図4のようにエンティティを四角、リレーションを線で表わし、リレーショナルデータベースのデータの関連性をわかりやすく示すことができます。 図3：データモデリングツールでER図を作成 （画像をクリックすると別ウィンドウに拡大図を表示します）    実は弊社では、データモデリングを簡単に行うツールを自社開発しており、「SI Object Browser ER」という商品名で販売しています。当然ながら、DUNGEONでもこのツールを使ってデータベース設計を行うことにしており、本ツールから「ER図」や図4のような「テーブル定義書」も出力することができます。 図4：テーブル定義書の例（SI Object Browser ERから出力） （画像をクリックすると別ウィンドウに拡大図を表示します）

まとめ

今回は、基本設計フェーズにおけるドキュメントの中から、「画面レイアウト」「帳票レイアウト」の記述様式について説明しました。また、データモデリングツールを使ったER図の作成、テーブル定義書の出力なども紹介しました。これで基本設計フェーズで作成する各ドキュメントのテンプレートとその作成手順の説明は終了です。次回からは詳細設計フェーズに入っていきます。 リンク： https://thinkit.co.jp/free/project/4/3/1.html

SEとPG、どっちが頭がいい？

ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。

●SEとは何か、PGとは何か

　まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ（PG）とはどういう仕事をする人たちでしょうか。

　いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。

　一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア？ システムの技術者？ ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です。

　それではなぜ日本ではこんな言葉が使われ始めたのでしょう。これは思いっきり個人的意見なのですが、SEは日本にソフトウェア産業が勃興したとき、終身雇用と年功序列型のキャリアパスという企業風土の特色から生まれた日本独特の職種だったのだとわたしは考えています。

●わたしが受けた新人研修

　ちょっと昔のことをお話ししましょう。わたしのIT業界歴は1980年代後半、大学を卒業して、さる金融機関系のソフトウェアハウスに就職したことに始まります。銀行系の子会社のそのまた子会社でした。当時は銀行の第3次オンライン開発というのがあって、ソフトウェア業界は大量に人手を必要としていました。このことを世間では「ソフトウェア危機」と呼んでいました。わたしはそのとき大量に採用されたSE要員の1人です。

　同期の約6割は2カ月のCOBOL研修を受けて現場に配属されましたが、残りの4割はさらに2カ月間のSE講習を受けました。このSE講習、内容はどういうことかというと、一言でいうなら、主に各プログラムをどのように組み合わせて1つの流れにするかという技術です。すなわちこのとき教えられたSEの仕事とは、処理全体の機能を考えて、各ステップの機能を設計し、仕様書に書くことでした。PGはその仕様書をもとにプログラムを作るという分担です。簡潔で一見何の問題もないように見えました。

●いざ現場では

　しかし実際はこの分業は十分に機能していませんでした。SE講習が終わって現場に配属されると、現場のSEはPGをぜんぜん信用していませんでした。PGに仕事をまかせず、全部自分でコーディングしていました。そうした方が早いし確実だというのです。派遣されてきたSEほどその傾向が強かった。おそらく派遣SEさんたちはプロパー社員以上に作業効率を求められるので、プロパー社員の新米PGなど頼むに値しなかったのでしょう。

　当時わたしたちの会社ではプログラミング作業を集中管理して効率を上げようという目的から、「ソフトウェアセンター」という部署を設け、社内のPGを一カ所に集めて作業させる試みを始めていました。ところがSEさんたちはそこに仕事を注文しないで自分たちで作ってしまうのですから、部長は当然渋い顔です。しかし実際問題、そうやってソフトウェアセンターに集められたPGは、仕様書がよくわからないと文句は言うし、テストはいい加減だし、少しも効率は上がりません。よく考えてみれば、このソフトウェアセンターという組織は、企業の中でオフショア開発を始めてしまったようなもので、うまくいくわけがないのです。2年もたたないうちにこの組織は取りやめになりました。

●技術革新は職制を変える

　どうしてこのようなギャップが生まれたのでしょう。わたしが考えるところはこうです。

　わたしが最初に受けたCOBOL講習では、コーディング用紙を使って手書きでプログラムの作成を行っていました。まず原稿用紙のようなマス目の並んだコーディング用紙に鉛筆でソースコードを書き込むのです。それを外部の業者がパンチカードに打ち込み、上がってきたカードをPGが原稿と1行ずつ照合します。打ち間違いがないことを確認すると、データカードと合わせてカードリーダーにかけて機械に読ませ、テストを実行する。バグがあったらカードを抜き取り、自分で打ったカードと差し替える。このような作業環境では、プログラミングとはかなり手間のかかる根気の要る作業でした（このような環境でどうやってデバッグしていたのでしょう？）。

　このような作業をしなければならないのだとしたら、PGとはそれなりに意味のある職分だったでしょう。しかしわたしが実際に現場に配属されてみると、誰もこんな作業はしていませんでした。当時はすでにタイムシェアリング端末によって、SEもPGもエディタが自由に使えるようになっていました。みんなライブラリにアップロードしたソースを自分で手直ししています。そもそも誰も一からプログラムを書いたりしません。みなどこかから似たようなロジックのプログラムを探してきて、部分的に手直しして作ってしまいます。それが一番手早くてバグの起こらない方法だからです。

●形骸化したSE/PG分業

　タイムシェアリング端末という新しい道具がSE/PG分業を時代遅れなものにしてしまっていたのです。コーディングはSEが自分で行っても何の負担にもならないし、むしろPGに依頼すると、仕様を理解させる過程でコストとリスクが発生します。自分でしてしまった方がはるかに生産性が高く確実でした。設計と実装を区別することは現場では事実上、形だけのものになっていたのです。わたしの会社はソフトウェアセンターを廃止すると同時にSE/PG分業を廃止すべきでした。

　ところがそうはなりませんでした。SEという職種は頑強に残り続け、SEを技術的にPGの上位に置く考え方はなおも業界の常識として残っています。これには単にSEとPGの間の関係だけではない複雑な背景があると、わたしは考えています。

●アメリカではPGはえらい

　アメリカではプログラムを実装する人も設計する人もprogrammerと呼ばれます。そもそもPGの社会的地位が高い。プログラミングは大学ではアカデミックな研究の対象です。大学の先生が書いた優れた学術書が何冊もあります。

　COBOLの開発者グレース・マレー・ホッパーは、女性で、軍人で、最後には准将になって、彼女の名前がミサイル巡洋艦に付けられるまでになりました。PGの扱いは日本と外国とでは天と地ほども違うのです。これは、コンピュータ技術の発祥地アメリカではハードウェアとソフトウェアの重要性が同等に評価されて、コンピュータが総合技術として発展してきたことが背景になっているのでしょう。PGを単純労働だなどと誤解する余地などなかったのです。

●産業界とSE/PG

　日本でコンピュータが商業利用され始めたのはIBMの360が普及した1960年代だと思われます。当時日本ではソフトウェアに対する理解が薄く、 OSから言語処理系から基本ソフトウェアを全部アメリカに依存していました（これは今も同じですね）。ソフトウェア製造については学術的な蓄積はなく、ビジネスソフトウェアの作成は企業主導で行われました。そのとき企業の管理者には、コーディング用紙とにらめっこしながらパンチカードの束と格闘しているPGが知的労働者には見えなかったことでしょう。COBOLのプログラムはいくつかのパターンが決まっていて、それを適用して量産することもできました。これゆえ日本の産業界ではPGは「単純労働者」と位置づけられてしまったのだと思います。

　日本の企業は最近まで終身雇用制だったといわれます。それが崩壊して今日さまざまな雇用問題を引き起こしているわけですが、しかし終身雇用制が健在だった時代も、すべての雇用者が定年まで働くことができたわけではありません。業務形態によりますが、単純作業労働を大量に必要とする産業では、比較的賃金の安い労働者を雇用して働かせる必要がありました。そのため企業は、若年者の賃金を低く抑え、一部の従業員には勤続年数が上がって給料が増える前に辞めてもらうようにしていました。

　この雇用形態にぴったりはまっていたのが女性労働者です。女性は雇用されても男性と同じキャリアコースに乗ることはなく、 30歳前には結婚して退職することが暗黙の了解となっていました（いまだにそのような風土を残す企業もあるかもしれません）。企業は「結婚＝女性の幸せ」という価値観を利用して一部の単純作業労働者を辞めさせることで、終身雇用という建前を守っていたのです。

　かつてはソフトウェア開発もこのような形態をとっていました。わたしが就職したときには、PGとして働いていた社員の半数以上は女性でした。今では考えられないことです。彼女たちは非能率なパンチカードによるコーディング作業を黙々とこなし、5年も勤めると誰かに見初められ、結婚し、仕事を辞めていったのです。今でも古くから使われているシステムには、彼女たちが作ったプログラムが現役で動いているかもしれません。時にそのソースコードはよくレイアウトされた印刷物のように美しく整えられていたりして、彼女たちの「意地」を感じさせられます。

●「スキル目標」としてのSE

　その一方で男子従業員は会社に残って技術の中核を担っていくことを求められました。彼らにがんばってもらうには、彼らを単純労働者としてのPGとは差別化する必要がありました。SE（システムエンジニア）というあいまいな言葉は、このようにして社員に技術の向上を促すキャリアステップという意味で使われ出したのではないかと思います。

　以上のことをまとめていうと次のようになります。本来ソフトウェア作成の高度な技術の担い手であったPGは、日本ではその現実的な作業形態から「単純労働者」と考えられてしまった、そのためソフト作成の知的性格を表現する言葉として「SE」という言葉が使われるようになったのです。

　これだけならば「システムエンジニア」という言葉は別に害になるものでもなく、たんに上級PGという意味を表す日本独特の業界用語ということに収まったでしょう。ところが実際にはこれによって生まれるSE/PGの区別が厄介な問題を引き起こすことになりました。

●1990年代に起こった変化

　1990年代になってCOBOL開発に呼ばれたことがあります。その頃にはもう開発現場に女性の姿はなく、男ばかりの世界になっていましたが、当時は気にもとめませんでした。ゆっくりした変化はなかなか気付きにくいものです。このときは気付かなかったもう1つの重要な変化がありました。それは設計作業をしているのは元請会社の社員で、実装作業をしているのはもっぱらよそから派遣されてきた外注PGだったことです。

　このときの開発のエンドユーザーは旅館業です。テレビCMでも聞いたことがある伊豆の有名旅館の客室管理システムをOAで作ろうとしていました。実装している外注PGには、十分にスキルのある中堅どころがそろっていました。それに対して設計しているのはプロパーの若手社員。設計力のレベルに不満があったのでしょう、元請の先輩社員がしきりに後輩を叱咤していたのが印象に残っています。

　ソフトウェア開発では早くから派遣労働が普及していました。これは作業の専門性からいって仕方のないことですし、少なくともこの頃のCOBOLの開発現場では、派遣労働を正当に評価してもらっていましたから不利になったという感じはありませんでした。むしろプロパー社員のがんばりに感心していたくらいです。しかし今から考えるとそんなことより、その元請がスキルに不安のある自社社員をあえて設計に起用していたことに疑問を持つべきでした。この会社では設計とプログラミングを分け、後者をアウトソーシングしていたのです。

●アウトソーシングとSE/PG

　ここでソフトウェア開発でなぜアウトソーシングが増えるのか考えてみましょう。製造作業の一部を外注することのメリットを理解するには、損益分岐点分析というちょっと面倒な原価計算の理屈が必要になるのですが、かいつまんで説明すると、固定費である労務費を変動費である外注費に切り替えたほうが、利益が出るようになる売上高、「損益分岐点」が低くなるのです（注）。

　売上高を急激に伸ばすことが期待できないソフトウェア開発では、固定費を少なくする方が有利です。日本のIT産業は、かつては女性の結婚退職を隠れ蓑に、ひそかに高齢になった労働者の一部を排除することで非効率な部門の固定費を削減していたわけですが、男女雇用機会均等法の制定などでそのようなことができなくなり、その代わりに固定費をアウトソーシングという形で変動費に変える道を選んだのです。

　まあ、以上のようなことは本当はきちんとしたデータをもとにして主張しなければならないことで、その意味ではこれはまったくのわたしの仮説にすぎません。しかし今日、日本のSIerの多くが企業利益のためにアウトソーシングを積極的に行い、その外部委託作業を切り分けるためにSE/PG分業を境目にしていることは、だれもが認めることでしょう。

　このアウトソーシングによる利益設計、すなわちビジネスモデルは、プログラミング作業に対するある先入見――プログラミングは単純作業であるという思い込みにもとづいています。PGは使い捨てにしても構わないが、SEは設計という「高度な」作業をして、顧客の業務知識を蓄積していってくれると。日本のIT企業のトップはどうしてこの誤った認識を改めることができないのでしょう。それが事実に見えた時代が一時はあったにせよ、少しでも現場に目を向けていればその誤りを容易に理解できることでしょうに。まるきり古い時代の、実質的に意味のなくなった分業区分をいつまでも有効であると信じている。間違った区分で外部委託の範囲を決めたことが、どれほどの問題を引き起こしていることか。

　その実態については、長くなりますので次回に述べたいと思います。

●PGは単純作業ではない

　これはわたしの持論ですが、プログラミングとは究極の「手仕事」です。どんなに技術が進んでもプログラミングという作業は残る。それは絶対にコンピュータにはできないことなのです。なぜならそれはコンピュータがすることを前もって考えることなのですから。この手仕事は職人仕事の性格を持っています。品質が製作者個人のスキルに大きく依存しています。しかもそのスキルはパターン化することができず、訓練では身につかない。PG個人の強い自発性がなければスキルアップしない。

　プログラムは、どんなものでも個人の技術の力量が問われる知的著作物です。上手な人が書いたプログラムは、まるで物理学の方程式のように美しい。そんなプログラムは当然バグも少ない。あっても見つけやすいのです。それがまるで大量生産品のように思われているのは、そういう作り方をすればできてしまうからです。困ったことにそれでもシステムは動いてしまうのです。

　経営者の方はこういうかもしれません。「なるほど、たしかにプログラミングは職人仕事かもしれない。優秀なPGを使えば品質の高いプログラムを作ることができるだろう。しかし優秀なPGを探すのは大変なことだ。安い労働力を使った大量生産方式でも、動くプログラムができるならそれでいいじゃないか」と。

　しかし考えてみてください。プログラムのほんの小さなバグがシステム全体に影響を与えるのです。1箱に不良品が3％以下なら許容できるというような話ではないのです。最近銀行のシステム統合で頻発した不具合のことを思い起こせば、その影響が理解できるでしょう。

　プログラマを粗末にしたらバチがあたりますよ。