社内論文の提出期限は3週間後。どうしよう！：ITアーキテクトが見た、現場のメンタルヘルス（7）（2/2 ページ）
常にコンピュータ並みの正確さを要求されるITエンジニアたち。しかし、ITエンジニアを取り巻く環境自体に、「脳を乱す」原因が隠れているという……。ITアーキテクトが贈る、疲れたITエンジニアへの処方せん。
障害と対策の履歴を集め、論文に組み立てる
1週間後、SEは作業を終えたファイルを持ってきました。でも報告書を切り張りしただけなので、誰もが読んで理解できる文章にはなっていません。
次に私はこの内容に、「誰」が「何」の作業をしたのか、追加する作業を依頼しました。例えば「月次更新処理で異常発生」なら「担当者が確認したところ、月1回のマスターDBの更新作業が失敗していた」、こんな感じです。
さらに私は、SE本人が実施した作業に「筆者が……した」とか「……と思う」という言葉を追加するように依頼しました。例えば「障害の監視体制強化」だったら、「筆者は障害をチェックする仕組みの強化を提案した」、こんな感じです。
SEはいいます、「自分のした作業や工夫を強調するのですね」。そのとおりです。論文や事例報告では、自分の挙げた実績を、誰が読んでも分かりやすいように書く必要があるのです。
さらに1週間後。SEは作業後のファイルを持ってきました。前回私が見た「更新処理の異常」や「監視体制を強化」という内容が、以下のような文章になっていました。
「お客さまへの請求ができない状況になった。原因は月1回のマスターDBの更新作業の失敗である。これは事前に作業結果をチェックできれば防げるトラブルだと思う。筆者は体制を見直してチェック会議をするよう提案した」
何とか読んで理解できる文章になったところで、これを基に体裁を整え、論文の形にしないといけません。全体を見渡して、修正する場所を一緒に考えました。
最後の1週間、SEは頑張って体裁を整え、論文に仕上げました。SEなりに努力して考えた作業の結果が出せたのです。こうしてSEは論文提出を乗り切りました。
論文で、自分のした仕事を振り返る
ITエンジニアにとって、自分の仕事を振り返ることはとても大切な作業です。論文の執筆作業を通して、自分の仕事を「整理し」、悪いところを「見直し」、それを第三者に「理解させる」ことができます。会社が論文の執筆を推奨するのは、これを社員に実行させるのが目的なのです。
なので論文には、一生懸命考えた形跡が残っていないといけません。急いで「やっつけ」で作ってしまうと、何も考えていないことがすぐにばれてしまうのが論文というものです。
プログラムも書く、手順書も書く、そして論文も書く。バランス良くできることが、ITエンジニアのキャリアアップには重要です。
今回の作業を終えたSEはいいました。「こういう作業は、早くから手を付けてないとダメですね。そう感じました」。そのとおりです。優先順位の低い作業でも、必要なことは手を抜かずにやらないといけません。
難しい作業を乗り切るための3つの手順
この作業、ちょっと自分には無理かなあ。仕事をしていると、そんな作業をしなくてはならないことがあります。そんなとき、このSEのように逃げてばかりいると、結果が出せないうえに脳が疲れてきます。
どうせ使う脳だったら、前向きに使った方がよいです。頑張って困難を乗り切るために有効な手順が、今回SEが論文を執筆するのに使った「乗り切るためのパーツ活用3手順」というものです。ここでいうパーツとは「能力」や「手順」や「考え方」のことです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
手順1では、作業に不可欠なパーツを見つけ出します。これを探索作業といいます。特に、いまの自分にないパーツを探してください。スキルや体制、お金、時間、体力などが出てくると思います。
手順2では、見つけたパーツをどうやって手に入れるか考え、実際に手に入れます。これを収集作業といいます。訓練して手に入れるとか、支援を受けるとか、交渉、売買などが出てくるでしょう。
手順3では、もともと持っていたパーツと手に入れたパーツを使って、仕事に組み立てます。これを実行作業といいます。実行すると何らかの結果が出てきます。
手順を進める段階では、すぐに手に入らないパーツを発見することもあります。そういうパーツはないままで実行することが大切です。その結果、屋根のない家や、プロペラのない飛行機が完成するかもしれません。でも時間がたてば、地下室でも住めるとか、風に乗れば飛べるとか、そんなことが分かってきます。ないパーツには固執せず、基礎工事だけでも進めておく、そうすると目に見える形になってきます。
SEはいいます。「あきらめたらアウトなんですね」
そのとおりです。あきらめてしまっては、何もしていないのと同じです。パワーが出ないときがあっても、少しずつでいいので作業を進めるようにしてください。
最初から能力のあるエンジニアはいません。少しずつでも毎日、前に進むことが、マイナスパワー改善の原動力になります。そのためにも、ぜひこの手順を活用してみてください。応援しています！
筆者紹介
樋口節夫
日本アイ･ビー･エムに22年間勤務し、その後独立。アーキテクトとしてメインフレームからオープンシステムまで幅広いシステム構築に携わった経験から、コンピュータシステムの良しあしはそれを使う人間の良しあしによって決まることを発見。人間のパフォーマンスアップツールとしてITコーチング手法を開発し、人材開発およびテクニカルコンサルタントとして活躍中。『ITコーチング入門―SE・ITエンジニアのための問題解決とスキルアップ』（技術評論社刊）をはじめ、技術系や人材系の著書多数。主宰する樋口研究室では、ITエンジニアが危機から身を守るための練習会（ワークショップ）も実施している。
Copyright © ITmedia, Inc. All Rights Reserved.