ECMサミット2014を無事に終えました

ナビゲーターとして、さも挨拶やらラップアップやらをやりそうなプログラムでしたが、ただの発音が不明瞭な棒立ち司会としての仕事しかやれませんでした。が、とにもかくにもECM委員長としての初のイベントから生還しました。残念ながらOracleさんだけは情報非公開ですがECMポータルのこちらのページから、各スピーカーの方々の発表資料をダウンロードして読むことができます。（OPENTEXTさんは差し替え修正が発生したようなので、公開が少しずれ込む予定です。）

ということで、現地であまり押しつけがましく語り出すのも良くないかと考えて控えさせて頂いた（？）、大まかな感想とまとめについて、ここにメモを残しておきたいと思います。

まず、この競業関係にあるビッグベンダによる競演形式についても、さすがにこれだけの回数繰り返してきていると各社も距離感が掴めてきているのか、テーマに謳われていなくても、必ず（社名の公開有無や国内外などの条件の差違こそあれ）具体的なケースについてのお話を入れてきて下さいました。やはりそういう要素がないとお客様が飽きてしまってあまり高い評価が得られないという傾向は確かにあります。

一方で、明日を語る、最新動向、というテーマですから、（世間一般でも言われているような意味での）デジタル化など新しい社会動向に対応する形でのビジョンやコンセプトについてのお話も、ある種似通った形になりました。コンセプト＋事例、ですね。

ECMは伝統的には「紙情報の電子化」というコンセプトを引き継いでいます。電子情報にすることで得られるコスト削減や利便性を実現する一方でコンプライアンスなどの課題解決にも資する、というのが最初の存在意義。次いで、そこで実現された高い機能や性能が、Born Digital、紙を経由せずに始めから電子的に作られるコンテンツの統一的管理基盤として認められたのが、ECMとしてのアイデンティティでした。さらに、いわゆる業務システム／業務プロセスの枠を超え、世の中全体がデジタル化していっている今、適切に電子化されたプロセスとコンテンツはさらにレバレッジを効いた大きな効果を生み出せるようになってきている... というのが各社がほぼ共通したメッセージとして語っていたところではないかと思います。

主催者の1人としてここで付け加えたいのは、ここで語られた新しいワークスタイル、ワークフロー、現代的なコンテンツの活用法のすべてを、新たなサイロを生むこと無く実現するためには、ECMプラットフォームが必須である、ということです。さらには、そうした実現能力を持つECM製品の技術の大半を、すでに見て頂いているということでもあります。

「デジタル化に対応した（そのメリットを最大化できるような）新しい仕組みを導入したい」と「これ以上の情報（システム）のサイロ化は進行させたくない」を両立させるようなまだ見ぬ銀の弾丸というのは存在しないということです。あるのはECMという（海外では良い意味でそれなりに枯れた）技術の集積のみです。　　　

...あ、弊社aegifだけは別、って話をこの流れでするのは良くないですよね？

他には、ケースマネジメントがある意味で典型的なECMの活用技法として定着しつつあるということ、プラットフォームとしてこそ輝くという点では一致していても、コーディングなしに拘るか標準技術の組合せをアピールするかという点で差が出ている、なんていうのも面白い点でしたね。専業ベンダーさんよりも、ビッグベンダー陣営の方が標準規格の推進に熱心であるような技術構成になっているという傾向なども綺麗にやり方が別れているようでした。目指すところはある程度重なっていても、実現方法はポジションによって結構変わってくるわけですね。その辺りもひっくるめてのアドバイザリー、というのも面白いかな、と思わないでもないんですが、委員としてはともかく本業的には今やうちもベンダーですから、独立した助言にはなり得ないんですよね。

次回は来年2月です。ECMサミットとしての単独イベントで、さらに盛りだくさんの内容になる予定です。是非とも多くの方にご参加頂ければと思います。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014

恒例のECMサミットが近づいてきました。イベントの詳細については、ECMポータルの案内ページをご覧頂いた方がよいと思いますが、JIIMA最大のイベント、eドキュメントJAPANの中の1コマとして実施します。

ECM委員長をやらせて頂くようになって初のECMサミットであるため、緊張しております。

今回は残念ながらEMCさんは欠席（実は早いもの勝ちだったりするので、サミットとしての単独開催ではない今回のようなイベントの一部の場合枠に限りがあるのです）ですが、OPENTEXTさん・Hylandさん・IBMさん・Oracleさんというラインナップです。大雑把なくくりをしてしまえば、専門ベンダ2社、所謂ビッグベンダ2社という構成ですね。

国際展示場は交通の便の良いところではありませんが、お時間のある方は是非いらしてください！

（文責 Ishii Akinori IT-Coordinator）

BPMSはじめました（？）

怠け者の節句働きというか、降れば土砂降りというか（2回でそれは言い過ぎか）、昨日に引き続いて投稿します。

京大情報研の超交流会でもお世話になっているQuestetra クエステトラさんのパートナーシッププログラムに参加することになりました。

取り組みとしては2つのスタイルを考えています。1つは、BPRプロジェクトなどにも参加するいわゆるコンサルティングファームとして、もう1つはECMの専門家集団として、です。

イージフのコンサルティングとBPMS

弊社の技術系ではないコンサルティングのチームは、その多くが「業務改善」のプロジェクトで活躍しています。技術系のチームがOSSという旗印があるのに比べて、今ひとつ対外的にアピールしきれていませんが、こちらのチームに関しても特徴を持ったサービス作りを心がけています。（でないと、大手ファームと比較されると純粋に劣化版に見えてしまいますし、そう見られた状態でのコンサルティングは非常な困難を伴いますし）

具体例を挙げずに説明するのが難しいところではありますが、ビジネス環境の変化（商材や販路の追加・変更）が激しかったり、例外処理が多すぎてキーマンの判断依存の案件が山積みになっているような、IT視点でみて「成熟度が低い」修羅場にあえて踏み込んでいく、という経験は他社と比べても結構豊富なのではないかと思います。

こうしたケースでは、業務を効率化するための検討や判断にもキーマンの参画が必要になりますが、その人達の時間がすでに大幅に不足して限界状態にある、というのがスタート時点の前提条件であったりするわけです。そこで、改善に入る前に、弊社のメンバーが現場に入り込んで業務執行のレベルまで手を動かし、通常業務（とはいえ例外処理は多数含まれますが）の負荷を減らしてスペースを作り、そこから徐々に改善に入る、なんてことをやったりします。

このあたりのノウハウが形成された経緯としては、弊社が起業時点では平均年齢20代の若い会社だったということや、当時は内部統制ブームで各社とも業務執行の現場への負担を増やさざるを得ず、その追加分に関しては抽象化された業務プロセスの知識を持ったメンバーの価値を発揮しやすかった、ということがあると思います。いずれにしても、業務執行のレベルからお手伝いをする、そしてそのことの身の証を立てるために作業品質の向上を可視化してレポートできる状態をキープしていく、というスタイルには自信を持っています。

Questetraはクラウドサービスであり、ユーザ企業側が自発的に使いこなした時にその真価が発揮される、という面は確かにあると思います。コンサルなんかに頼っていては駄目なんじゃないの？ っていうことですね。そういう意味では、単に業務フローのお絵かき代行という意味でのコンサルティングサービスには、あまり大きなビジネスチャンスも無く、やりがいに溢れたお仕事でもなさそうな気がします。

しかし、上記の通り業務改善に関する限り、弊社のサービスは業務執行のレベルまで踏み込んで関与し、徐々に改善に向かっていくというスタイルが基本ですので、単なる代行ではないことができるのではないかと思います。また、我々にとっての生命線である「業務品質の向上分の可視化」についてもBPMSは強力な武器になるのではないかと期待しています。

このあたりは具体的な（公表できる！）事例が出てきた際にまた突っ込んでご紹介させて頂ければと思います。

ECMとBPM

思いの外前段が長くなっちゃいました。どうしよう。

こっちはリクエストがあったらまた日をおいてゆっくり考えることにして、今は考えていることを簡単に箇条書きするだけですませたいと思います。

• 単純なワークフローシステムとBPMSの違いは文書管理ソフトとECMのそれに似ている


• BPMSによるトークン管理の（ある種抽象的な）価値はECMによるコンテンツ単位のアクセス制御のそれに似ている


• CMISにはワークフローの規定がなく、弊社のNemakiWareにも該当機能がないのでQuestetraとの連携に期待している


• （ECM上のチェックアウトって該当ユーザが「球を持っている」状態を作ってるよね？ システム的に上手くマッピングされてる例をみたことないけど）

って感じです。

（文責 Ishii Akinori IT-Coordinator）

JIIMAのECM委員会で委員長をやらせて頂くことになりました

2ヶ月以上ぶりです。この所、社長の方が結構頑張ってコンスタントに記事をあげている感じなので、一段と心苦しい限りです。

さて、以前から予告めいたお話はそこかしこでさせて頂いておりましたが、今月から、公益社団法人 日本文書情報マネジメント協会JIIMAのECM委員会の委員長を務めさせて頂くことになりました。中学時代以来の委員長ポジションです。

JIIMAには幾つか委員会があるのですが、ECM委員会はその中でも「ナレッジ系」と言われる系統に属しています。資格試験やセミナーイベントなどの事業運営とは異なる、知識の収集整理と普及啓発を目的とした組織です。

これまで委員会を引っ張ってきた前任の方が初代委員長で（どこまで細かい情報を出していいのか判断が難しいので、少しぼかしますが）、EDMSと呼ばれていたころのECM製品を日本に最初に持ってきた人達の中の1人にあたります。まさに国内のECM市場を作ってきた人達なわけです。JIIMAは元々マイクロフィルムを扱う人達の業界団体で、ついこの間まで日本画像情報マネジメント協会という名前でしたし、マイクロフィルムからスキャナベースのイメージングという「紙の電子化」を経て、その上でECMに取り組んできた経緯があります。

対する2代目の私は、社会人キャリアのほぼ最初の時点からECM製品を取り扱ってきました。言わば、ECMネイティヴな世代と言えるかもしれません。年齢的にも結構な若返り人事ではありますし、伝統的なバックグラウンドに欠ける面があるという不安もあります。しかし、折角のチャンスですし、国内でのECMのさらなる普及とより一層の利活用を目指して頑張っていきたいと思います。

告知 大事なお知らせ

別に委員長になったからということではなく、これまでも委員として積極的にアピールしなければならなかった話ではあるんですが、今月JIIMA最大の恒例イベントであるeドキュメントJAPANが開催されます。我々ECM委員会が絡む企画として、2日目である16日に、これまた恒例のECMサミットを予定しています。皆さん是非お越し下さい！

ECMサミットは、主要ECMベンダさんが呉越同舟的に一堂に会して共通したテーマでプレゼンを行ってくれる珍しいタイプのセミナー企画で、今回で第10回目になります。同一カテゴリのソフトウェア製品のプレゼンを連続聴講するという経験は、他ではなかなかないことだと思います。ECMそのものずばりに関心がなくても、業務アプリケーション分野に携わる方であれば、面白いと感じて頂けるのではないかと思います。（各社が同じ事を言っているように見えるのか、それとも全然異なる戦略を取っているように見えるのか、そしてその印象を有無原因は何なのか、なんていうのは割と一般的な関心時だと思うので）

...本当は、これまでの委員会活動で色々なことを教えて頂いた尊敬すべき諸先輩についてのお話もしたかったんですが、変に湿っぽくなるか、単なるガジェット好き集団だと誤解されるか、のどちらかである気がして仕方が無いので、断腸の思いで割愛したいと思います。

皆様今後ともよろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

文書・コンテンツ・ファイル 半構造データ（XML）とCCMS

最近、自社関連の各Blogが、書き出し部分にスマートに近況報告的な世間話を混ぜ込んでいくスタイルに収斂しつつあることに危機感を感じています。

前回の、補足でもあるのですが、ECMはファイルが基本の管理単位になります。従って、図面管理においても物理的には1ファイルにまとめてある中で「特定のページをめがけたリンクを埋め込みたい」、というニーズがある場合は、そのまま適用するのは難しくなります。（例えば1ページ毎のレンディション（PDF版）を別途作成し、そちらを参照させる、などのテクニックはありますが）

今回は、ファイルが主役である、という特性を改めてご説明した上で、CCMS（Component Content Management System） コンポーネント・コンテンツ・マネジメントシステムというコンセプトについてもご紹介したいと思います。

ECMの基本とする管理単位が「ファイル」であるということ

あちこちの講演でも繰り返しご紹介していますが、ECMはかつてはEDMS、電子的文書管理システムといわれたコンセプトの後継にあたります。時期としてはおおよそ2000年あたりにこのキーワードの交代劇が発生しました。なぜ、文書（Document）をコンテンツ（Contents）と読み替えることになったのでしょうか？

1つには、Webに代表されるインターネット技術の台頭があります。HTMLで記述される「ページ」は、その呼び名とは裏腹にあえて再現性の低い印刷工程を通さないと「頁」もなく、文書という従来からある言い回しに収まらないインパクトを持つものでした。また、技術的にも、体裁情報を定義したスタイルシートや画像ファイルなど複数の「ファイル」によって構成されていますし、特定のポイントを指さすリンク構造も持っています。そのため、当時はWebページを管理するためのコンテンツ管理システム、WCM（Web Content Management）の製品が多数出荷されました。このジャンルは後にPHPベースのシンプルで安価な製品群が席巻し、カジュアルにCMS（Content Management System） コンテンツ管理システムと言った場合、一般的にはECMの様な文書管理ではなくこれらのWebコンテンツの管理システムを指すようになっています。

2000年代においては、EDMSから進化したECM製品もWebコンテンツの管理機能を取り込もうとしていましたし、Javaで構築されたような重厚なWCM製品もECM的な文書管理やワークフロー、コラボレーション機能などを製品に取り込む努力をしていました。例えば、2005年に立ち上がったAlfrescoにおいても、WCMモジュールが後から追加されています。この時は、「重厚なWCM製品」の代表格であったInterwovenのチームのエンジニアを引き抜いて、かなり大がかりなフォルダ仮想化技術を実装していました。これは素晴らしい機構でしたが、ここでお話しているようにECMがファイルを基本単位としている一方でWebコンテンツはその枠組みに収まらないというギャップがあり、Alfrescoの内部構造に異なる2つのリポジトリエンジンを抱える構造を余儀なくされていました。結果、数年後彼らはこの重厚な仕組みを放棄して軽量なWebページ作成機能を別途開発します。そしてさらに、現在ではWebサイト側にもそれなりに複雑な要件があるケースではDrupalなどのPHPベースのCMSを別途立ててインテグレーションしたり、Liferayを並立させたりする構造が一般的になっています。

それだけ何を基本の管理単位としてシステムを設計するのか、というのは大きな問題であるということだと思います。

ワンソースマルチユース

全社的にECMが導入された場合、所謂コンテンツ・文書・非構造データについても、ワンファクト・ワンプレイスが実現します。冗長なコピーを作る必要がなく、漏洩の恐れもなく、必要な時に必要な人に必要なコンテンツへのアクセスを提供できます。（かなりの理想論ですが）

一つの文書が、色々な目的で使い回されることになります。

ワンソースマルチユースというキーワードがありますが、これはここでいうような「複数の業務プロセスや部門から横断的に同一のコンテンツが利用可能になる」というのとは少し違うニュアンスを持った言葉です。具体的には、コンテンツの意味内容をXMLなどのプレーンな形式で管理し、体裁情報をスタイルシートとして別管理しておけば、印刷用、Webページ用、ダイジェスト出力用、など同一の内容で体裁が異なる出力結果を得られる、という状態を指しています。これにより、意味内容に変更があった場合は1カ所だけ修正すれば、すべての出力結果にその修正を反映させることができるようになるわけです。

弊社の取り扱い製品のラインナップの中では、Alfresco上にDITAというXML標準を扱う機能を実装したComponizeが、このワンソースマルチユースを実現するための仕組みになります。

DITAの詳細の説明はここでは省きますが、トピックという単位で意味内容を表現した（主にテキストの）部品をなるべく文脈に依存しない形で構成し、マップという単位でそれらのトピックの構造をまとめあげ（目次を定義して、どの順番でトピックを並べるのか、を決めてあげます）、そこにスタイルシートを適用して体裁情報を加えた出力結果を得る、という仕組みです。意味と体裁、ではなく、意味の断片と構造と体裁、を独立したコンポーネントとして管理するわけです。

これらの管理をシステム的にサポートするのが、CCMS コンポーネント・コンテンツ・マネジメントです。この仕組みでは最終的には1つのファイルとして提供されるマニュアルの中の特定の箇所をめがけてリンクをはったり、そこを書き換えたりということも可能になるわけです。

CCMSではファイルが基本単位になっていない？（＝ECMとは相性が悪い？）

DITAはXMLの規格ですから、通常ECMが扱うような文書ファイル、Word Excel Powerpoint PDF、の類いに比べてHTMLやWebページに近い技術です。そう考えると、ECMによるWCMの取り込みが失敗に終わった歴史を振り返るに、Alfresco上にDITAコンテンツの管理機能を実装するというComponizeの取り組みは一見筋が悪いものにも見えてきそうです。

しかし、私はこれは非常に洗練された仕組みだと考えています。つまり、出力結果の1ファイルに主眼を置いてしまうと、その構成要素は複雑に絡み合う複数の部品となり、ECMが苦手とする領域に踏み込んでいるように見えますが、通常直接編集を行う個別のトピックを定義するファイルに注目して考えた場合は、依然として1ファイルが基本の単位になっているからです。

AlfrescoもECM製品として十分な「ファイル同士の」関連付け機能を備えていますので（残念ながら基本のUIからはその機能は見えづらいのですが、内部機構には強力な仕組みがあります）、どのトピックがどの出力結果に利用されているか、などの情報はファイルを基本単位としたまま適切に管理されています。

これらはDITAという標準規格がしっかりと定義されていて、わざわざ関連付けまで含めた管理機構を実装するに足るメリットがあるからこそ実現している仕組みであるとも言えるでしょう。

DITA/CCMSのメリットや必要性

残念ながらこれでワンソースマルチユースの洗練された管理機構を実現できるのはDITAが対象としているようなマニュアルや仕様書などのテクニカルドキュメントだけですが、その導入メリットは非常に高いものであると考えられます。

もちろん、管理の仕組みが大きく変わるだけでなく文書の作成方法も従来通りとは行かないため学習コストは相対的に高くなりますし、いかにDITAが洗練された規格であったとしても、既存の規格を知らずに作成されたコンテンツをその枠組みに押し込むには難しい判断を求められるケースも多くなります。（最近では、規格自体のアップデートなどもあり得るので、その動向に目配せをしながら判断した方がより望ましい、なんていう面もあります）

それでも、最終的なコンテンツの管理コストを下げ、陳腐化したコンテンツが滞留しないようにしていくことのメリットは非常に大きいはずです。未だ多くの企業においてはコンテンツの整備は製品・サービスそのものの提供と比べると副二次的なものであるという扱いを受け、管理人員が十分に提供されない状況があります。製品・サービスそのものと違い、コンテンツは何もしなければ堆積していきます。活用機会を失うだけでなく、誤った情報が残り続けることで、様々な領域で問題を生じる可能性があるわけです。

こうした観点から、広く技術系のコミュニケーションに問題意識を持っている方も徐々に増えているのではないかと思います。Componizeはクラウド上でのトライアルも可能な製品ですので、是非お気軽にお声がけを頂けると幸いです。

あー、また長文ポストになってしまった。一応、営業っぽいメッセージも入れたから許して欲しい、という業務メッセージを追加して、結びの挨拶とさせて頂きます。

（文責 Ishii Akinori IT-Coordinator）

文書管理と図面管理

最近、図面管理についてのご相談を頂くことが増えてきました。がっちりしたPLM（製品ライフサイクル管理）やPDM（製品データ管理）のコンセプトを実装した製品は複雑で高価、顧客にとって不要な機能を包含したものになりがちなため、文書管理ソフトウェアを使って図面を管理できないか、という着眼点からのお問い合わせ、というのがある種のパターンになりつつあります。

非常に大雑把なくくり方をすると、PLMをゴールとした場合のCAD図面の管理体制には以下の様な成熟度が考えられます。（図にするのであれば高い成熟度を上に持ってきたいところですが、Markdownで書いているので、ひとまず項番＝Lvという解釈で下へ行くほど成熟度が高くなります）

1. 図面ファイルを単なるファイルとして管理し、メールやファイルサーバで管理


2. ローカルではCADツール付属の図面管理機能で図面番号などの属性を管理


3. シンプルな図面管理ソフトウェアを使って共有


4. PDMツールを導入し、パーツ品番の管理や各種採番などもシステム化


5. PLMツールを導入し、関係各所とも一貫した情報管理を実施

紙図面を脱却し、パーツ情報の共有や生産情報などの基幹系システムとの連動を実現できるようなシステム的にユニークで一貫したIDの管理など、図面情報の高度化が希求されています。

IDの管理や図面全体に割り当てられるような図面番号や顧客名などの属性情報の管理などについては、まさしく文書管理やECMで行われていることと同じ機能が求められています。そのため、高価なPDMなどを導入しなくても当面必要な管理精度や検索の利便性などについては文書管理でもできそうだな、という印象を持たれる方も多いわけです。

しかし、パーツの管理や、パーツそのものに付加された属性まで管理しようとすると、なかなかに複雑になります。ECM製品であれば文書同士の関連情報を保持することも可能なので、サーバ内でパーツの図面と製品全体の図面を結びつけておくこと自体は可能ですが、CADファイルの中身を書き換える機能があるわけではないので、それを持ってパーツ側での仕様変更を製品図面に反映させる、などの機能を実現するのは無理があります。（せいぜい、パーツ図面の更新時に利用してる製品の一覧を表示するくらいでしょうか）

文書管理ソフトウェアやECM製品は、各文書の内部構造に踏み込んだ処理はあまり得意ではありません。

全文検索インデックスをつけるというのがこれらのツールにとって最も内部に踏み込んだ処理、と言っても良いかもしれません。もちろん、文書管理ツールで図面管理を考えておられる方が関心を持っている、プレビューやサムネイル作成の機能などもファイルの中身を使っての処理ですし、Excelの特定セルを読みこんで属性値として割り当てるとかPDFの属性情報を吸い上げるなんていう処理もありえます。しかし、これらの機能も、本体そのものはそのままの形で保持することを前提として、プレビュー用の補助ファイル（レンディションと呼びます）や属性値を周囲に配置することを目的としたもので、図面の内部へ変更を自動反映していくような位置づけのものではありません。

では、図面管理は専用のソフトウェアで行うべきであり、文書管理ソフトウェアやECM製品を無理矢理適用するのは間違っているのでしょうか？　

（例によって議論の幅が拡がり過ぎてしまいそうなので、ここから先は文書管理ソフトウェアというよりはECM製品を前提に続けたいと思います。弊社には文書管理ソフトウェア並に低価格なECM製品もありますし！）

図面管理分野でECMが活躍する局面

上述したPLMを頂点とした図面管理は、製品を設計し、材料を調達、製造して、販売し、（場合によっては）保守をする、というストレートな製品出荷を前提としています。そして、製品の種類が多ければ多いほど、効果が大きいと予想されます。また、どちらかといえば製品のライフサイクルが短く、どんどん新しいものを出荷する、というスタイルに向いているとも言えるのではないでしょうか。

しかし、製造業にも色々なスタイルがあります。例えば、私の実家は天井クレーンの製造販売を行っていますが、基本的には個別受注生産で、どの案件にどのパーツを使ったのかという情報は必要ですが、そのパーツも他社からの購入品であるため個別に図面を管理したりはしていません。では、図面管理の必要が無いかと言えばそんなことはありません。顧客毎、案件毎の管理をロングスパンで行う必要があります。クレーンは何年も使い続ける装置ですので、初期設置時はなかった安全装置を後で取り付けたり、古くなった部品を新しいものと交換する際に従来の部品が手に入らず新しい互換品を採用したり（あるいは互換品がなくて修正工事を行ったり）ということをしていきます。これらの情報が散逸してしまっては都合が悪いわけです。

もっと大きなビジネスをしている製造業でも、標準品の図面管理と、案件毎のカスタマイズによる施工図面を二重に管理せざるを得ないケースはたくさんあると思います。図面の内部に踏み込んでCADの内部で扱えるパーツ間の関係などにフォーカスするのではなく、図面の外にある（あるいは業務的な意味で設計の外にある）情報とのリンクを取り扱いたいのであれば、ECM製品を利用する意味合いが出てきます。

非常に大雑把なまとめ方をすると、製品と部品の関係をメインで取り扱いたいのであれば図面管理、製品と案件（工事）などの関係に着目する必要があるのであればECM製品を検討するのが良いのではないかと思います。

実際には他にも色々なケースが考えられますし、そういった事例もいくつか持っていますので、ご関心をお持ちの方はお気軽にお声がけ頂けると幸いです！

（文責 Ishii Akinori IT-Coordinator）

エンジニアの仕事環境と『小さな成功』のはなし

パートナーさんとの合宿のために軽井沢に向かっています。新幹線も空いているのでこれ見よがしにMacを広げたところです。

普段ならTwitterに書き散らすようなネタなのですが、うまいこと140文字に収まりそうにないので、こっちの自由記述欄に。

個人的には「ネット」という言い回し自体あまり好きではないのですが、TVや新聞ではなく基本的な情報収集の手段がインターネットになり、アグリゲートされた後の記事をナナメ読むことが多いので、私自身はかなりネット寄りな情報や論調に偏ったポジションにいる、という自覚はあります。その中で、これも嫌らしい単語だと思うのですがリテラシーという面では上級職扱いのIT業界の住人でもあります。自戒を込めて言うのであれば、そういう人種はやはり進歩的であったり、欧米的な価値観に寄り添った立ち場から社会を見ているような印象があります。その例の一つ、「（日本は）もっと失敗を許す社会であるべき」という意見について、少し思い付いたことがあります。

まず、私自身はこの意見に対して、どちらかというと賛成、くらいのスタンスです。言っている内容に妥当性を感じるが、殊更自分が声を上げて現状を否定するほどのものでもないし、なるようになるんじゃないか、という位の温度感です。（現状それなりに恵まれた環境で仕事をさせてもらっていることと、独立だの起業だのというリスクを一応は取っているということのバランス、がこのあたりに落ちてきています）

また前置きが長くなってきています。

（IT業界の）エンジニアは人から見えないところで小さな失敗と成功を繰り返せる環境を持っているので、ある種成熟した視点を会得しやすい

という仮説を考えました。

システム開発、特にコーディング部分に関わることのない人には本当に何を言ってるのかわからないと思うので、少し細かく説明します。（単純に私が注意力散漫とうこともあると思いますが、）通常、最初に書いたプログラムというのは上手く動きません。上手く、どころか、まず動かないことの方が多いくらいかもしれません。で、機械にだめ出しをされ、修正をし、どうにか動いてくれるのを確認、でも結果が想定と違うのでまた修正、そうするとまた動かなくなって、、、というのを本当に細かいレベルで繰り返します。

実際、こんなに頻繁にネガティブなフィードバックに晒される職種は珍しいんじゃないかと思います。ただ、あまりにも些細なものであり、相手が機械であるという点で、心理的なダメージは非常に小さくなっています。（ここに人間味があるネガティブコメントが付加されると一気に耐えきれなくなる、というのは感覚的にはあり得そうな話で、業界にメンタルを損なう人が多いことの数多い原因の一つだったりするのかもしれません）

一方で、そういう作業が上手く意図通りに行った場合の小さな達成感というのも当然あります。顧客に何らかの変革を強いる、いわゆるコンサルティングの仕事では、「小さな成功（win）」を顧客に感じてもらうことがプロジェクト全体の成功を握る鍵である、というような話がよくされるんですが、まさに「小さな成功」です。

つまり、多くの失敗と、そこそこの頻度で訪れる小さな成功、というサイクルで仕事を回しているエンジニアは、「失敗の許容」という冒頭の大人な意見に同調しやすくなってるんじゃないか、と。

Railsのブームの出始めあたりに、生産性に絡む評価として、個々のエンジニアが「俺すげー」って思えるポイントをチラしてある感じが憎い、みたいな視点があったような気がします。（ソースとなる記事がないかなと思いましたが、それらしいものはうまく見つけられませんでした）。最近だとVagrantとかChef/Puppet/AnsibleとかDocker界隈の技術にも似たような受け止められ方をされてる部分があるように思います。

やっぱり思ったより長くなってしまったので、さっさとまとめると、そういう個々人の体感の部分で「小さな成功」や高い生産性を感じさせてくれるツールが受けているということなのだとしたら、それをエンジニアだけでなくナレッジワーカー全体に適用するような工夫ができると楽しそうだな、と。細かいアイディアは幾つかあるので、実現しそうになったらまたご紹介します。

（文責 Ishii Akinori IT-Coordinator）