考え出すといろいろ出てきて、例えば「数字に弱い」（理系なのに……）とか、「あちこち痛い」（まだ30代前半なのに……）とか、いろいろあって困るぐらい。といういか、思わずしょんぼりしてしまったりしてたのですが、いろいろ考えたうえで、結論としてたどり着いたのが、
【経験のないところでも理論的に考えていく力】
これが、ずばりこの先も生き残っていくために必要だと思いました。
■普遍的な技術、ノウハウってなんだろう？
ある日、こんな質問を受けました。
「ＸＸをやりたいんだけど、どう考えていけばいいか？」
これだけだと、具体的に何に困っているかわからないので、わたしが、「何が課題ですか」と聞くと、
「これから検討していくので、まだ課題はわからないので、一般的な考え方を教えてほしい」
というような答えが返ってきました。具体的なシーンが想像できないので、「うーん、例えばここではこんなことをやった、っていうことはいえるけど、“一般的な考え方” かぁ」ということで、困ってしまったことがありました。
この、“一般的には”って、けっこうくせ者だと思っています。経験や事例は話せるけど、“一般的な考え方”を聞かれると困ってしまう、こんなこと、皆さんも経験ありませんか？
その時は、業種違いではありますが、詳しそうな人に来てもらって、いろいろ語ってもらいました。その時感じたのは、「この人はきっとずーっと飯食っていけるなぁ」ということでした。
じゃあ、自分と何が違うのかな、と考えてわたしなりにたどり着いた結論は、
「この人は、自分の中でちゃんと整理できていて、ノウハウが普遍化しているのではないか？」
ということでした。経験だけだと、前提条件が違ってしまうとそこでおしまいですが、いろんな経験を整理・昇華して、前提条件が違っても、「変わらない考え方」として、普遍化？ というか、概念としてちゃんととらえている、ということかな、と思ったわけです。
■モデリング、ということ？
事例は役に立つ、もっとも必要とされる情報ではありますが、その背景（たとえば業務の特性、規模、利用者数／層、性能……）で、実現方式が全然変わってしまって、「ぴったり合う」事例って、なかなか見つからないのが現実です。
経験はもっとも重要ですが、変化の早いこの業界。技術トレンドがどんどん変わっていく中で、経験や事例は数年すれば陳腐化してしまって、使い物にならなくなってしまうような気がしています。一方、自分を振り返ってみると、まさに「経験で勝負」している状況で、数年先のことを考えるとそら恐ろしくなってしまいました。
やっぱり、さまざまな経験を、“概念”として、自分の中で形を作っていく、この辺をしっかり見直さないとなぁ、と思ったわけです。
「概念」といってしまうと、何となく上流工程技術チックですが、たとえば開発言語のスキルでもにたような話かと思います。
言語って、どれか1つちゃんと覚えれば、割と流用効くじゃないですか？ これって、言語特性によらない概念（考え方）としての、「プログラミング技術」とか、「アルゴリズム」の考え方が身についているからではないでしょうか？
それが頭の中に入っていると、あとは、「この言語でどう書く？」「こんなAPIあるかな？」っていう、言語特性だけの話になるわけです。だから、どれか覚えていると、言語が変わっても何となくコード読める、習得も早い、ということですよね（きっと）。
で、「概念でとらえる」、ということで、ふと気づいたのですが、これっていわゆる「モデリング」だよなぁ、と思ったわけです。
■外部刺激とシミュレーション
さて、じゃあ自分の経験をモデル化、っていっても、はっきりいってどうすればいいかさっぱりわからなかった訳で、あの手この手を思いつくままに試している訳ですが、とりあえず効きそうかなと思っていることが2つあります。
◆外部刺激をうける
なにか考えるとき、やっぱり参考が欲しいですよね。ということで、まず1つ目「外部刺激」をうけることから始めました。
その1つが、このコラムのタイトルにもある「社会人大学院」にいってみよう、ということでした。
自分でこつこつできればいいのですが、根がめんどくさがりやなので、強制的にそういう環境に身をおいてみたわけです。改めて、世の中の一般的な考え方やすでにあるメソドロジー、この辺をちゃんと見返して、自分の経験と照らし合わせて、「ああ、この時考えたのはこういうことだったのか」といったところを見返してみる、非常にいい機会だったと思います。
しかし、学校も今年の2月で終わってしまい、そういう環境から離れてしまうとじっくり考える機会が少なくなってきます。で、やっぱり環境作りとして、研修を受けたり、無料セミナーにいったり、自学したり、というところは欠かせなくなります。
◆シミュレーション（妄想？）
2つめ、これはよくやっているのですが「シミュレーション」してみるということです。シミュレーションっていうと大げさですが、例えば、「出身校に呼ばれて、全然知識のないような学生に情報システムとはなんぞやって説明して」って言われた、とか、そういうシーンを想像して、自分がそのことを話すとしたら、どう話すのか、っていうのを脳内シミュレーションしてみる訳です（人はこれを妄想っていうかもしれませんが……）。
これは、脳みその中でできるので、密かにけっこうやっています。時々、セミナーとか研修の間にやりすぎて肝心の話が上の空になってしまうこともありますが、これ、わたし的にはけっこう効くとおもってます。
まあ、余裕があればこれをマインドマップで思いのままに書き連ねてみたりしています。
■まだまだ先が長そうですが…
と、ここまで書いてきて、「例えば」って話を書こうとしたら、ぱっと出てきませんでした。考えたことを忘れてる？？？
うーん、なにかの形で形式知化する、ってことも必要そうです。まだまだ先は長そうですが、地道に「経験のないところでも理論的に考えていく力」を鍛えていこうと思っています。
]]>ここ2、3年、仕事上において、第三者的視点で設計書やソースコードのインスペクションを行う機会が多くなってきています。これを読んでいる方々も、きっとインスペクションを行った経験のある方は大勢いらっしゃると思います。自分がメンバーではないプロジェクトや組織に関するインスペクションって、悩みがありませんか？
インスペクションのやり方や技法という面から見ると、ある程度数をこなしていると、「自分のやり方」「着目点」みたいなものが頭の中にできあがってきて、基本的にアドホック的に行っている事って多くないですか？
もちろん、チェックシートやレビュー記録票のようなツールは、当然利用する、あるいは用意して行います。しかしながら、やはり最終的に解釈、判断するのは人の目とセンス。網羅的かどうか？ 前提条件を掛け違えていないか？ レビュー自体の品質はどうか？ など、わたし自身は毎回悩みながら実施している状況です。
また、技術的な観点とは全く別の側面として、「第三者」というのがくせ者で、インスペクションを受ける側は、「文句つけんじゃねぇ」（言葉悪くてごめんなさい）とか、「第三者に何がわかる」的にとらえられていないかなぁ？ といった不安もあります。
インスペクションやレビューの必要性は、みんなアグリーだと思います（障害をできるだけ前工程で検出した方がいいのは常識ですし）。でも……
などなど、あまり日の目を見ないことが多いですし、初めて見る大量のドキュメントやソースコードをインスペクションするのは、かなり苦しい作業です。
そんな悩みを持っていた最中、7月2日にソフトウェアインスペクション・ワークショップ 2009なるイベントが開催されました。「何かうまくやる方法がつかめるのではないか、また、メソドロジーや技法ってどんなものがあるんだろう」との思いで、さっそく参加してみました。
内容はこちらに掲載されていますが、ざっとこのような内容でした。
非常にたくさんのキーワードや効果的になりそうな話が出たのですが、全部は書けないのでわたしが特に「ピンと来た！」「ちょっとやり方を見直せるかも！」という所をかいつまんで、わたしなりの解釈を踏まえて紹介したいと思います。
■読み取り、解釈した内容を別のレビュー者と交換■
1番難しいのは、「仕様間の関連性の齟齬、間違いを指摘すること」だと感じています。第三者的な立場だと、当然ですが業務知識やバックグラウンドがわからない事が多く、特に関連性に関する齟齬はなかなか見えてきません。「そういうものだ」と思ってしまいませんか？
そこで、記載された仕様をそのままとらえるのではなく、理解した内容を（声を出して）確認して、「捉え方に誤解がないか」「ほかの人間が違う捉え方をしていないか？」という観点で、ほかの人とすりあわせると、そういった齟齬が見えてくるとのことでした（なるほど納得、という感じです）。
■短期間に複数回す■
レビューって、他人の作成物を読み抜いて理解する、ということで、わたし自身は「いかに正確に読み取るか」に非常に力を入れていました。しかし、この方法だと非常に時間がかかるし、正直疲れます。当然人間なので、ずーっと同じ品質で作業できないし、その日のコンディションによっても見方が異なったりする。そこで、じーっくり読み深めるだけでなく、小さく（荒く？）見て、それを複数回見る。すると、見落としたものが見えるし、1度目よりは理解度が上がっていて、見落としたもものも見えてくる。
■事実で指摘する■
これは、レビュー結果の指摘、フィードバックの仕方についてです。「事実で指摘する」とは、「○○が記載されていない」「○○が実装されている」など、ありなしだけを言及する、という意味です。
ものすごく当たり前の事のように思えますが、インスペクションを受ける側のことを考えると、単に欠陥を指摘しただけだと、何となく冷たい印象を与えそうで、つい過去の経験や他の事例などを付け加えたくなってしまいがちです。しかし、これをやると非常に時間がかかるのと、親切心のつもりが的外れ、という事もありがちです。
そんなことになるよりは、欠陥は欠陥として端的に指摘する。一方、アドバイスとしては、指摘内容を全体的に見渡し、より根本的な原因として予想されることを示し、その是正策をサジェスチョンする方がいい、ということです。
例えば、同じような欠陥が多く見受けられるのであれば、標準化不足などの共通的な部分に原因があるのでは？ という予想ができそうです。一方、非常に局所的な欠陥であれば、その原因もおそらく局所的（担当者スキルなど）になるのでは？ といった予測を行う、ということです。
■誇りを持ってインスペクションする！■
1番グッっときた所です。実際の話の中では、いろんな話の中にちりばめられていましたので、そのものズバリの言葉があったわけではないです。ですが、ポイントだけ思い起こすと、講演していただいた方の自信に満ちた言動もから、きっと「もっと誇りを持ってやること、誇りを持てる領域である」ということだととらえました。
こんなことを講師の方は言われていました（記憶だよりな部分もあるので、一部不正確かもしれませんが）。
わたしの解釈ですが、底辺の領域で、ともすれば後ろ向きになりがちだけど、インスペクション技術はこの先もそう変わらない。その中で、1番頼りになるのはインスペクター自身の力であり、すなわち「プロ」としての技である。だからこそ、誇りの持てる技術であり、誇りをもって実施し、よりよりやり方を追求していく、そういうことだと感じました。
そのほか、技術的な面では、構造化ウォークスルー、Guided Checklists、ツールとの組み合わせての効率化、メトリクス計測による複雑度分析によるレビューの重点箇所のの絞り込み、など、いくつかありました。
自分自身のやり方を見返してみると、実際に実行している内容も多々あり、やり方や考え方自体はそんなに間違ってないとの確信を持つことができた反面、まだまだ、意識的にも技術的にも工夫の余地があることを実感した1日でした。
レビューやインスペクションを行っている皆さん、後ろ向きにならずに「俺、わたしだけが見つけた！」という誇りを感じられるように、がんばっていきましょう！！
]]>自分に足りないところを鍛える、といっても、やはり仕事の環境では、ビジネスですから当然、結果が求められます。なんでもかんでもチャレンジするわけにはいきません。
新人のうちはまだしも、やはり現場ではそれぞれの専門領域が仕事の主体になってしまいます。特に、短期間で成果を出さなければいけないところではなおさらで、まったくの素人の分野に手を出すのは、ビジネスや職制上のリスクを考えると、どんどん難しくなっていくのではないでしょうか？
産業技術大学院大学のPBLは、そんなところを何とかできそうな、数少ない場の1つです。
前回からしばらく空いてしまいましたが、しばらくは、産技大のカリキュラムの大きな特徴であるPBLについて書いていきたいと思います。
PBLについては、産技大のサイトにも紹介がありますが、「Project Based Learning」の略です。その名の通り、1年間をすべてプロジェクト形式で進めていく形で、1年次は基本的にすべてをPBLで費やすことになります。
産技大のPBLには、上流技術タイプ、開発技術タイプ、研究タイプとざっくり3種類ぐらいあって、それぞれの専門分野の担当教官が、大まかなテーマ設定を行っています。
学生は、その中で自分がやりたい分野、やりたいことを選択する、という形になっています。
■ビジネスリスクのない環境
先にも書きましたが、やはり仕事の上ではビジネスリスクは回避し得ないところです。とは言っても、スキルアップにおいては、自助努力だけでは、いかんともしがたいところもあります。
例えば上流設計では、メソドロジ的な内容を勉強することはできても、本当の組織や企業の業務分析をそれなりの期間をかけて実施しないと習得は難しいですよね。また、実装技術についても、サンプルは世の中に山ほど転がっていますが、目的意識や着眼点をしっかり見定めていないと、「ちょっとやってみた」で終わってしまって、結局すぐに忘れてしまいがちです。
そこで出てくるのが産技大のPBLです。学校という環境の中ですので当然ですが、ビジネスリスクを考えることなく、未知の分野にしっかりチャレンジすることができるのが、PBLという形式の大きなアドバンテージです。
「所詮学校、シミュレーションじゃないの？」と思われるかもしれませんが、それはある意味、自分次第です。
PBLでは、大まかなテーマの領域は与えられるものの、その後の計画と実行はすべてメンバー主体で行います。また、一部のPBLでは、実際の企業や組織に協力いただきながら行うため、実践的なテーマ選択も可能です。
■ここは当然、未経験分野を！！
わたし自身は、元々アプリケーションの基盤領域が専門で、業務分析や要求分析に関する経験が皆無でした。そういう領域も強化したいと思いつつ、上流設計手法等の研修会などを受けてみたりしたのですが、それを生かす場もなく、結局身についていない状態でした。
PBLテーマ選定の際、そういう領域のPBLがあることを知り、これはチャンスとばかりに、思い切って上流の業務観点でのテーマ選択ができるPBLを選択しました。
実際にPBLを行う上では、いろいろ紆余曲折もあったのですが、某地方公共団体の組織にご協力いただくことができ、そこの業務分析と課題抽出、そして改善提案という内容で1年間過ごしてきました。
次回以降は、このPBLの内容など、順次お話したいと思います。
■実は……
ところで、実は「元社会人大学院生」になってしまいました（そもそも、このコラムを始めたのが2年目の秋からだったのですが）。
2月11日にPBL成果発表会があり、3月14日に学位授与式があって、ついに2年間の大学院生活が終わってしまいました。しばらくPBLについてお話しながら、今後のこと（コラムの題名とか）を考えていきたいと思っています。
いろいろあって、しばらく間が空いてしまいましたが、じょじょに復活していきますので、今後ともどうぞよろしくお願いします。
]]>私自身はコラムタイトルにもあるとおり、仕事に加えて、プラスアルファの大学院で、かつ既婚者な訳ですが、感覚的には「なんとかなるもんだなぁ。でも、油断は禁物」というイメージを持っています。
私自身も、通勤時間や昼休みなどの「隙間時間」をどうやって使うか（このコラムも主に電車の中でシグマリオン3で書いてます）など、できそうな工夫はしているつもりですが、効率的に仕事やスキルアップをやる方法はいろんなところで語られてます。ですので、あえてそこから離れて、既婚者目線で、生活を（できるだけ気持ちよく）進めていくには？ 的な話で行きたいと思います。あんまり赤裸々（笑）な話はできないですけどね。
さて、いざ考えてみると、「あまり特別なことをしていないなぁ」と。で、一旦書くのをやめようかな、と思ったのですが、じっくり考えてみると3つぐらいポイントがありそうです。
並べてみると、実は日々のちょっとしたことの積み重ねなのですが、何となく顧客満足度向上とか、人間系作業の見直しとか、技術的領域以外でITエンジニアが気をつけなければいけない領域、行動規範的な内容とと重なっている気がしています（ちょっと違うかな……）。
■この業界の仕事を奥さんに理解してもらうこと
1つ目は、いかにしてこの業界の仕事を理解して貰うか？ また、どうやって説明するか？ という話です。
設計したアーキテクチャをお客様に説明するシーンがよくあると思います。特に、概要設計、あるいはシステム全体の設計ポリシー的な部分では、お客様に説明する機会が多くあります。設計書というと、ついシステムを作るための観点で書きがちですが、「説明して理解して貰う」観点も加えて書くと、結構悩ましい時がよくあって、「説明力」が必要だと感じています。
私の奥さんは、元ITエンジニアなので普通に考えていたのですが、いろいろ話を聞いているとそうではないみたいです。まあ、普通に考えれば、毎日遅くて休日も仕事、場合によっては2～3日帰ってこない、なんていう状態が続くと、冗談抜きに浮気でもしてるのかと疑われますよね……。
私はたぶん恵まれた環境にいると思いますが、振り返って考えると、やっぱりこの業界の状況とか、仕事とかを理解してもらうことって、凄く重要ではないかと思っています。そのことで、ある程度、自分の動きに自由度が出てくる、そう思っています。
「理解してもらうこと」って、結構難しい気がするのです。例えば私は、「今日こんなことがあった」などの小さな話を、日常会話の中で織り交ぜていくことで少しずつ話をする、そんなことをしているように思います（愚痴にならないように気をつけていますけどね）。
■守るべきところは死守死守！！
2つ目は、守るべき約束はできるだけ守る、というところです。これはすなわちスケジュール管理、という話になると思います。
IT業界の仕事を理解してもらうとはいっても、やっぱり油断は禁物。約束のドタキャンはできる限りないようにしたいものです（結婚当初を思い起こすと結構痛い思い出が……）。
ですので、独身時代と比べて、予定立てを少し早めにしておくようにしています。仕事や大学院の宿題・予定も、そこに向けて調整していく、少し前倒しで仕事を進めていく。仕事や大学院の予定を、家庭目線から立てていくことにしています。例えば、1カ月前をめどに調整しておけば、「どうしようもない」ってことは以外に少ないと感じています。
とはいっても急なトラブル対応や、開発のピークみたいなところでどうしようもない時はありますが、それはもう、「穴埋め」するしかないですね。
■声かけ
最後は、やっぱりコミュニケーションですね。よく「エンジニアは挨拶しない」とかいわれてますが、満足度向上の1stステップはコミュニケーションですね。ということで、「声かけ」。終電で帰ると、疲れてしまっていろいろめんどくさがってしまうのですが、ほんのちょっと気をつけるだけでずいぶん違うのではないかと思います。
当然ITエンジニアには時間がないので、いろいろやってもらうことが多いのですが、洗濯してもらったら「ありがとう」とか、「ご飯うまかった」、とか、そういう一言だけは言えるように気をつけています。
（みなさん、お皿ぐらいは洗いましょうね。あまりにくたびれている時は、「皿割るからやめて」っていわれますけど……）
さて、いざ書いてみると、ITエンジニアだから、という話にはならないみたいですが、所詮は「人対人」の話で、システム開発と同様、「銀の弾丸」はないみたいです。人がやることなので、人の振る舞いや気づきのところ、人間系作業を見直して、そこから対策していく、そういう取り組みが、少しずついい方向に進むのではないでしょうか？
なんだか偉そうに書いてますが、本当に奥さんさまさまです。「いろいろありがとう」って言っておきたいですね。
]]>「働きながら通学できる」とはいうものの、やっぱりこの業界、毎日定時に退社できるとは限りませんし、特に開発プロジェクトとかに関わってしまうと、そもそも帰れるかどうかも怪しくなってくるわけで。
一方で、せっかく授業料を払ってるわけですから、授業がある日はできる限り出席したいですし、1つでも多くの授業をとっていろいろ勉強したいわけです。とはいうものの、逆にそのせいで仕事が滞ってしまっては本末転倒ですよね。2年という長い期間であることを考えると、やはり何らかの形で調整が必要です。今回は、そのあたりで自分がやっていたことを（まだ継続中ですが）書いてみたいと思います。少しでも参考になれば、ということで。
■職場では「最初の仕切りと報告＋日々の雑談から」
職場では、みなさんいろんな担務、あるいはその時々の条件があって、それを前提として調整が必要です。
私の場合、学校を知ったきっかけは、所属の上司ではなく、以前お世話になった方からの紹介でした。私の会社の人材育成部門からその方に声がかかり、「誰かいない？」って話だったようですが、私はその時たまたま2年間の開発プロジェクトから戻ってきたタイミングだったので、声がかかった、という経緯でした。ですので、多少は他の人たちよりも調整は楽だったかもしれません（もちろん、同期を見渡すと遙かに厳しい条件の中で通っている人もいますので、私はかなり恵まれた環境にいるなぁ、と思っているところはあります）。
でもラインの上司の方では、たまたま別の事業所の部隊に配置しようとしていたようで、まずはそこから話を始めました。事業所を移ると、定時前に退社しないと学校に間に合わない状態になってしまいましたので、まずはそこから始めました。
そして、やはり2年間という長い期間、仕事上どんなことがあるかわかりません。例えば、「何カ月か遠地に……」とか言われてしまうと、その時点で単位が取れなくなって、修了できないか、あるいは長期履修生にならざるを得ないです。このような可能性も考えて、学校に行くことについて、上司とはよく相談しておくことが必要です（話しておいたおかげで、遠地常駐を回避できたこともありました）。
また、最初だけではなく、継続的に「大学院に通っていること、メリットがあること」を上司に知っていてもらう必要があると考えていますので、定期的にアピールすることにしています。
具体的には、以下のようなことをやっています。
加えて、やはり日々同じチームの同僚の理解が、たぶん一番重要ではないかと思います。作業分担をお願いする以上、大学院に行っていること、あるいはその負荷の度合いは理解してもらう必要があると実感しています。私は、日々の会話や週1のチーム会などで、学校の活動状況を話すようにしています。
■家族の理解もやっぱり必要
職場の理解以上に、家族の理解も必要ですよね。私の場合は、開発プロジェクトで2年間ぐらいあんまり家にいない日が続いていたので、それが終わってすぐにまた……という状況になるので、そのあたりはいろいろ会話しました。
この辺、理解してもらえるかどうかは、IT系の仕事の様子を知っているか否かで結構変わってくるみたいです。うちの相方（奥さん）は、元IT系の技術者なので理解してもらえましたが、そうでない人たちは結構苦労しているみたいです（うちの両親はいまだに理解できない模様……）。
具体的には、プライバシーにかかわる話なのであまり話せませんが、少しずつ、いろいろ努力しています（内容はご想像にお任せします……笑）。
私がやっていることはこんな所です。何かしらみなさんのご参考になれば幸いです。
これが今年の最後の更新になります。お休みの方、年末年始稼働を控えている方、様々かと思いますが、みなさんよいお年を迎えることをお祈りしております。来年は2年時のPBL（Project Based Learning）のお話をしていきたいと思いますので、またよろしくお願いいたします。
]]>デジタルネイティブという言葉、正直知らなかったのですが、ネットで検索してみると結構でてきますね。デジタルネイティブの定義については、田所さんのコラムで既に紹介されていますので、そちらでご覧いただきたいと思います。
■基幹系システムも変わってきているようです
デジタルネイティブとは直接関係ないところかもしれませんが、やはり「世代」が変わってきているなぁ、と感じていることがあります。
私の仕事は、いわゆる企業の基幹系、またはそれに属するシステムの開発案件に関する仕事が多く、結構堅いシステムが主な領域です。このようなシステムでは、機能が最重要で、デザイン的なところは二の次でした。お客様側でも、慣れ親しんだ操作性をできるだけ変えたくないという要望が強く、デザインや操作性の面では昔のシステムを踏襲するパターンがやはり多かったです。
ところが、ここ2年ぐらいでその流れが変わってきているように感じています。
それは、画面デザインに関して、専門のデザイン部隊がからむ案件が増えてきている、ということです。お客様の要望としても、これから入社してくる新入社員のことを考えて、最近の流行り（というと言葉があんまりよくないですが）に合わせて、デザイン面でも一新したいと考えるお客様が増えてきました。商談の強みの面でも、デザインと操作性を兼ね備えた提案が多くなってきています。
私は2000年に入社したのですが、当時（の画面）を振り返ると、「背景が灰色で、飾り気のない画面」が主流でした。そして、（画面デザインについては）それ以上は求められてませんでした。長年それでやってきている大半のSEは、画面設計をするとそんな画面を作ってしまいがちで、その結果「いつの時代の画面だよ」ということになるわけです。
先日、昔お世話になった部長さんとそのような話をしていて、やっぱり「（私も含めて）SEが作ると画面が古くさくなっちゃうよね～」という話になりました。だんだんとこのような認識が広まってきてることを改めて認識しました。
基幹システムでも、パソコンやインターネット等、仕事の道具ではなく、生活の一部として慣れ親しんだ世代のことを考えないと時代遅れ、といわれるようになってきたなぁ、と実感しています。
■プロダクトアウトに立ち戻ってみては？
さて、デジタルネイティブの記事をいろいろと目を通していて、ふと思ったのですが、「プロダクトアウト」的な観点にすこし立ち戻ってみてはどうか？ と感じています。
ビジネスでやるからには、普通は収益性を考えるわけで、収益性を考えると、自然と「ニーズ」を考えて、それに対するソリューションを提案していくわけです。でも、ただでさえ変化の激しいIT業界、ニーズを読むのってかなり難しいですよね。
デジタルネイティブ世代は、いまあるツールやサービスが、当たり前のようにある状態がベースラインとして、その上で様々な新しい使い方をどんどん出していくわけです。
一方で、我々のように今のIT業界を作っている側の人間とは、ベースラインの意識からして違うと感じています。デジタルネイティブ世代とくらべてずーっと低いところにベースラインがある。先の画面デザインの話もそうですが、自分自身の反省も含めて、考え方が古くさくなってしまっている気がします（もちろん、そうじゃない人も数多くいらっしゃいます）。
こんな状況の中で、先に触れたように、ニーズを読み切るって本当にできるのかな、と思ってしまうわけです。
じゃあ、どうするか、って話ですが、これは極論かもしれませんが、最近、あまりいい意味では使われていない「プロダクトアウト」的な観点に立ち戻って、新しい仕組みやサービスをどんどん出して、デジタルネイティブ世代のような、使う側にサービスの善し悪しをゆだねてみるもの1つの手かな、と思っています。
インターネットビジネスって、1個当たれば大当たり（なんだかITバブル時代みたいでちょっと語感が悪いですが）のいわゆるマスビジネスなわけです。ニーズや収益をまったく考えないのはビジネスとしてはあり得ないのですが、それを「二次的要素」としていったん脇に置いておいて、プロダクトアウトの考え方でともかくどんどん出していく、そういう考え方を復権させてみてもいいんじゃないか、と思っていますが、みなさんいかがでしょうか？ （自分がそういう仕事をしてみたいと思っている裏返しかもしれないですね）
]]>あるお客様から、次期システム開発の技術選択のためにプロトタイプ開発を請け負って、久しぶりにまともな実装をやっていました（Ajax＋Java Servletでした）。とりあえず無事納品が済んで、ちょうど一息ついたところです。
現場にいたころは、自分で設計して自分で実装してやっていたものですが、今の職場では技術検証のためのテストプログラムを作ったり、依頼があったプロジェクトのソースコードチェックを行ったり、という程度で、まともに実装に関わってませんでした。
やっぱり、実装してないと腕が落ちてますね。普段は、「こういうことちゃんとやらないといけないよ」と自分で言っていることも、いざ短期間で実装していると、自分で忘れていたりと、反省しっぱなしでした（もともと大した腕でもないですが……）。
技術をちゃんと把握して、他人に語るには自分で実装して、時々感覚を取り戻しておかないとダメだね、ということで、この勢いのままJPAとかEJB3.0に手を出している最中です。どっちかというと、資料作りベースの作業よりもモノづくりしていた方が楽しいですし（一応Java技術者のつもりですので、たまには技術の話とかもしていきたいと思います）。
さて、話を本筋に戻します。今回は1年次の間の暮らしぶりについて少しお話したいと思います。
前回少し触れましたが、私の通っている大学院は1年間が4つのクォータに分かれていて、1つ1つのクォータは約2カ月間になっています。1つのクォータには、約7～8つの講義が設定されています。
■1.6倍の時間が必要？
すべての講義を取ることは、仕事との兼業を考えるとかなり難しいため、大体4～5つの講義を選択して受講していました。
ほぼすべての講義で、レポートや演習課題などが課されるため、テスト期間中（懐かしい響きかもしれませんね）に限らず、帰宅後や休日なども時間が必要になります。そういうところも含めて考えると、入学後は仕事を含めて、ざっくり1.6倍程度、入学前より時間が必要な感じがしています（数字自体にはあまり根拠はないですが）。
学校のために必要な拘束時間で考えると、仕事で本当に忙しくなった時と比べれば短いと思います。ただし、あくまでも私の感覚では、そんな時よりもちょっと厳しさが異なる様な気がしていました。改めて考えてみると、2つ大きなポイントがあるように思います。
●ポイント1：頭の切り替えが必要
学校に通うようになって一番ストレスに感じていたのは「頭の切り替え」でした。これは、ある意味では仕事が忙しくて、終電徹夜を繰り返していた時期よりも大変だったかもしれません。
開発プロジェクトとかでやっているときでも、もちろんいろんなことが噴出しますが、基本的には1つの同じバックグラウンドがあって、その延長で考えることができます。
一方、学校に行くときには、一度仕事を切り離して、頭の中を「仕事をこなす」モードから「初心にかえって学ぶ」モードに切り替えなくてはいけません。私はこれが結構重かったなぁ、と感じています。
●ポイント2：移動時間
これはポイントというよりは、私自身の精神的な話かもしれません。学校がある日は大体、定時ダッシュで急ぎつつ移動する訳です。そうすると、ちょうど帰宅ラッシュのまっただ中を移動することになります。他の人が帰る中を次の場所へ移動するのは、なんというか、気持ち的にネガティブになってしまうのは私だけでしょうか？ （たまーに、「ああ、このまま電車に乗ってたら家に着くなぁ」とか思ったり）
■私なりのシフトチェンジの仕方
ポイント2とも絡みますが、やっぱり「どうやって気持ちを学校モードにシフトチェンジするか」が一番のネックでした。仕事だと、仕事場の雰囲気を借りて、ずばっと気持ちを切り替えることが出来るのですが、いったん仕事場を出てしまうと、やっぱり気持ちのどこかにゆるみがでてしまいます。
以前、テレビで脳科学者の茂木健一郎博士が、「ある程度むりやり集中することを繰り返して、集中を早めていく」（うろ覚えなので、正確でないかもしれません）といったような話をしていましたが、私はなかなかうまくいきませんでした。ただ単に気持ちが弱いだけでしょうけどね（笑）。
私は、とりあえず移動時間の電車の中で、10分でも15分でもいいので教科書や課題に目を通しておいて、徐々に学校モードに頭を切り替えていくようにしていました。そうすると、学校について授業が始まる頃には、なんとなく気持ちの切り替えができている、という感じで、ある程度時間をかけてゆるゆると切り替えをしていました。
あと、課題などで帰宅してからも継続して作業を進めないといけないときも、いったん帰りの電車に乗ってしまうと気持ちが途切れがちです。そういうときは、帰ってからやるべきことのシナリオやポイントを頭の中で整理しています。そして、自宅に帰ったら間髪いれずに一気に吐き出してしまいます。
今回はこんなところで。次回は、学校に通うに当たっては、やっぱり職場の理解とか、家族の理解が結構大きなポイントだと思います。その辺のお話をしていきたいと思っています。
]]>さて、カリキュラムについて軽くふれておきます。
大学院大学ということで、基本的には2年間のマスターコースになります。授業自体は、平日夜間2コマ＋土曜日4コマという構成で、2カ月単位で4クォーター制をとっています。やはり、基本的には仕事をしながら通うところですので、長期間引きずる形ではなく、できるだけ短期間で完結する形をとっているとのことです。
カリキュラムは大きく2つに分かれており、ざっくり以下のような形態をとっています。
カリキュラム等の正式な情報については、是非産業技術大学院大学のWebサイトをご覧いただきたいと思いますので、ごく簡単に触れておきます。
■現状とスキルアップに対する悩み
さて、前回でも少しふれましたが、この学校に入ろうとしたきっかけは、自分を振り返ってみて、以下の2点に気づいたことです。
◆知識／ノウハウの技術領域が非常に偏っている。
これまで、いくつかの開発プロジェクトの現場でやってきました。やはり、技術やノウハウが自分の血肉になるのは、苦労してやり遂げる開発現場だと思っています。一方で、それぞれの開発プロジェクトでは、特定のお客様の業務があり、それを実現する処理方式を決定し、それを実現するための設計技法や言語を決めて、その中でどう実現していくかを突き詰めていく。必要とされる技術や知識の領域は、限られています。
一方、いまの職種では、180度変わって、ある意味ですべての業種、すべての開発プロジェクトが相手になったわけですが、自分のスキルを振り返ってみると、自分の経験の範囲では強いのですが、そこから一歩外にでると、ぜんぜん太刀打ちできない状態になっていることに気がつきました。これが1点目です。
◆技術の原理原則を知らない（単なる小手先の技術になっている）
これは、先の内容と関連しているのですが、じゃあ、全部の技術や方法論を全部押さえられるかというと、そんなことは神様でもない限りできないことです。神様みたいな人ってたまにいますけどね（笑）
長年、いろんな案件を経験してノウハウを積み上げる、という方法もあるでしょう。ただ、仕事は仕事。現状はそれを許してくれません。じゃあ、どうするか、と考えたときに、（ちょっと表現がむずかしいですが）根底にある原理原則とか、そういう領域の考え方を身につけないといけないのではないか、逆に、そういうところの考えかたを身につけておかないと、様々な技術がどんどん出てくる中で、この先エンジニアとして生きていけないのではないか、と思ったところがあります。
別に、システム開発の問題点を根本的に解決する何かがあるのでは、とかそういう考えではなく（銀の弾丸はやっぱりそうそうないようです）、例えば、何か1つの開発言語でしっかり作れるようになると、プログラムの基本的な考え方が身について、ほかの言語をやるときも、その言語の深いところをおいておくと、「勘所」みたいな部分って一緒の部分があるじゃないですか。そういう感覚を身につけたいな、と思った次第です。
少し固いことを書いてしまいましたが、「そんなん自分で地道に勉強すればいいじゃん」という意見もあるかと思いますが、やっぱり、正直腰が重くって、家に帰ったら結局だらだらしてしまうじゃないですか。なので、自分を強制的にそういう環境においてみよう、というのも正直なところです（ホントにすごい人たちは、その辺が違うのでしょうね）。
■私の考える、うまくやる秘訣
◆選択と集中
この学校では、カリキュラムとしては情報システムにかかわるほぼすべての領域をカバーしており、1つのクォーター当たり結構な数の講義があります（だいたい、6～7つぐらい）。
せっかくこんな学校に入ったし、未経験の分野も、これまでやってきた分野もすべからくきっちり学びなおしたいと思って、最初のクォーターはたくさん講義を取りました。その結果、日々のレポートやクォーター末の試験などが集中して、ちょっとやばい状態でした（ちょっとです。たぶん、おそらく）。
正直なところ、成績はどうでもいいと思っていましたが、やはり「学校」。単位はとらないと先に進めませんので、試験やレポートにも手を抜くわけには行きません（もちろん、試験やレポートを通して考えないと身に付きませんし……）。
しかし、講義を取りすぎると、そのために細かいところや、自分でゆっくり考える所を通り越して、「こなさなければならない」状態になってしまいます。そんな状態では、せっかくの貴重な場も意味がなくなってしまいます。
やっぱり、自分が強化したい領域をきっちり見定めて、それにマッチする講義を選択する、そして、とった講義にじっくり集中するやり方が良いようです。私は、自分で強化したい領域を、アプリケーションアーキテクチャ系、データベース系およびプロジェクト管理系に軸をおいて、それにマッチする所を集中的に選択してやっていました（ですので、単位はぎりぎり＋αぐらいしかとっていません）。
◆振り返り
「正直、講義の内容やレベルってどうなんだろう？」とか、「本当に自分のやりたいところとマッチするのだろうか？」といった不安は必ずあると思います。普通のセミナーなら1回きりなので、「いまいちだったなぁ」で終わるところですが、大学院の場合は、2年間という期間です。期待はずれだったら、残念なことになるわけです。
学校というパブリックな場なので、広くカバーしなければいけませんし、いろんな職種・経験の人たちが入り乱れていますので、講義の内容としてもある程度一般化しなければならない部分はあるでしょう。実際、狙った領域と少し離れていたり、「その先が知りたいんだ」といったところは少なからずありました（ここはその人の経験とか専門とかによるところはあるでしょうが）。加えて、やはり開発方法論とかのやり方は、人や会社で、独特の文化みたいなものがあるので、そういう面でのギャップも結構出てきます。
そういうところで、「期待はずれ」と思ってしまうとそこでやる気がなくなってしまうのですが、私は、自分の経験や自社でのやり方や文化みたいなところを振り返って考えて、その講義で言っている内容と比較して考えながらやっていました。そうすると、入社以来叩き込まれてきたやり方だとかの、良いところと悪いところとが結構見えてきたりするところがだんだんと出てきます。普段当たり前だと思っていたところを改めて考えてみると、「なるほどそういう考えもあるよね」とか、「やっぱり自分たちのやり方って間違ってなかったね」とか、「ここはこうしたほうがよさそう」といった気づきがいろいろと出てきて、より面白くなっていきました。
時々、そんなことをずーっと考えていて、肝心の講義内容が途中から完全に上の空になっていたり、ぜんぜん聞かなくなってしまったりとか（先生すいません）、講義の後の質問時間で、講師の先生とディスカッションしてしまって、授業の終了を引き伸ばしてしまったり（みんなごめん）、といったこともありましたが……。
純粋に知らなかったり、あまり経験していない領域の話を学べるところもいいのですが、やっぱりほかの人（講師や同じ学生同士の会話も含めて）の話や、ほかのやり方、そしていわゆる一般論的なところを聞いて、振り返ってみると、いかに自分がこれまでの経験や慣れ親しんだやり方で凝り固まっていたのか、といったところに結構気づきがありました。こんな観点で自分を一回リセットする場として考えてみると、また違う面白みが出てくる、というところを実感しています。
次回は、もう少しメリット・デメリットみたいなところや、学校に通うようになってからの暮らし方とか、その辺もお話したいと思っています。
]]>改めまして、みなさんはじめまして。阿部と申します。秋田県出身で、現在は東京都内の某SIベンダーに勤めて9年目のSEです。
正直なところ、わたし自身特に取り柄がある訳でもなく、どちらかというとこつこつやってきたタイプなのですが、逆に、普通のSEの生の声といいますか、地道なところでの悩みや取り組みのようなところで、何かしら皆さんの参考になれればと思いますし、逆に同じような悩みを持つ方々からご意見などいただければ、と思っています。
本コラムのタイトルにもあります通り、現在SE職につきながら、産業技術大学院大学という大学院に通っています。といっても、何かを研究して修論を書くような普通の大学院ではなく、いわゆる情報システムに関わる全般を学び、アーキテクトを育成することを目的とした専門職大学院です。このコラムでは、しばらくはその大学院での経験や得られたこと等、お話していきたいと思いますが、まずは初投稿ということで、自己紹介やこれまでの職歴、大学院に行こうと思ったきっかけについてお話したいと思います。
さて、現職は社内の共通技術部門で、方式設計や開発標準化などをメインに、現場の開発プロジェクトの支援や技術整備、社内展開などを行っています。そういう意味では、SIベンダの社内SEとでもいう立場でしょうか（ちょっと違うかもしれません……）。
現職に就く前は、基本的には開発プロジェクトの現場で「共通技術グループ」の一員として、設計開発、技術支援、といったところを行っていました。「共通技術グループ」といっても、具体的に何をするのかイメージしにくいかもしれません。具体的には、主に以下のような役割ととらえていただければと思います。
この中で、主に大規模系のプロジェクトを幾つか経験してきていたのですが、2年ぐらい前、あるプロジェクトのカットオーバーをきっかけに社内に戻って現職に就いた、というのがこれまでの流れです。というわけで、現在は現場から少し離れて、社内でフィールドSEさん達の支援を行っているのですが、この中での悩みが、大学院にチャレンジしよう！ と思ったきっかけになります。
今の仕事内容は、先にもふれましたが、社内の共通技術部門で、開発プロジェクトの現場に対して、技術支援を行っています。それに加えて、過去のプロジェクト経験や支援の内容を元に事例を整理し、ノウハウ化して社内で横展開する、といったような内容も含まれます。
現職に就いてすぐの頃は、これまでそれなり（と自分では思っていたのですが……）に現場でやってきたこともあり、「なんとかなるだろう」とタカをくくっていました。しかし、いざ始めて見ると、大きな問題に突き当たりました。それは、「見なければいけない範囲があまりにも広い」ということでした。
開発プロジェクトでは、当たり前ではありますが、あるお客様のあるシステムがあり、一つの業種、一つの目的の元で仕事をしていくわけです。
一方、現職では、社内で動いているあらゆるプロジェクトが対象になりますので、業種・業務・目的とするシステム形態・開発言語・開発方法等が案件毎に異なっており、さらに、開発フェーズだけでなく商談対応からトラブル対応まで、ということで、システム開発におけるほぼ全ての領域が対象になってしまいました。
例えば、ある日の仕事内容を挙げてみると、
午前：あるプロジェクトの商談フェーズで、どんな開発言語や方式をとるべきかの相談会
午後：トラブルが発生したプロジェクトに駆けつけての原因調査
という具合で、ほぼなんでも屋の状態です。
もちろん、すべてを自分や自部門だけでやるわけではなく、様々な専門部隊と協力してやるわけですが、協力を仰ぐにしても、要件に対して何が問題で何が必要なのかを判断する必要があり、やはり幾ばくかの知識や経験が必要になります。
一方で、自分のスキルを振り返ってみると、特定のプロジェクトで得た知識や経験についてはそれなりかと思いますが、経験したプロジェクトのスコープ外の領域は非常に薄い、つまり、非常に“とんがったスキル”であることに気づきました。しかも、しばらく続けて見てわかったことですが、プロジェクトの現場と現職では、求められる知識が少し違ってきています。プロジェクト現場では、プロジェクト固有の背景や問題をターゲットにした「答え」が必要になります。一方で、現職では、いわゆる“べき論”的な部分も必要になってきます。きちんと基本や方法論を把握し、それを元に現場の事情を加味して、方向性や方針を導き出す力が必要になってきます。というわけで、これまでの自分の引き出しだけでは足りないと思い、「なんらかの形で広い領域に対してのスキルアップをしなければ」という思いでしばらく焦り気味でした。そんな時に、ちょうど先に挙げた専門職大学院の話を耳にし、飛び込んでみたという次第です。
さて、冒頭でも少し触れましたが、現在終業後や土曜日を利用して通っているのが、「産業技術大学院大学」という、2006年に出来たばかりの専門職大学院です。わたしは二期生で、2007年の4月から通っており、本投稿時点では既に4分の3が過ぎています。だいぶ終盤に差し掛かっている状況ですが、次回以降、大学院でのカリキュラム、大学院と会社を両立しての暮らし、その中での気づきや得られたことなどについて、いくつかお話して行きたいと思っております。また、それ以外にも、職務上での気づき等、随時お話して行きたいと思っております。
初回は自己紹介チックになってしまいました。大学院に行ってからというもの、「今の仕事ってどんなことやっているの？」という話をよくするのですが、なかなか人に理解してもらいにくい職域で（わたしの説明が悪いだけ？）、しかも、なかなか同じことをやっている人と巡り会うことがないので、少し詳しく書いてみた次第です。もし同じような職域についている方がいらっしゃいましたら、いろいろとご意見なども伺いたいと思っております。 今後ともよろしくお願いいたします。
]]>