吾唯足知

これは四国時代（2009年）にブログに書いた記事です。
今読み返しても、まだまだだなぁ･･というところですね。

通勤途中のビルの片隅に、写真のような石柱がある。先週、周りのアジサイが見事に咲いていたので携帯電話で撮ろうと近づくと、なにやら四文字の漢字が彫られている。

２ヶ月もこの前を通っているが、まったく気づくことがなく、偶然のことである。疑問におもい、インターネットで調べてみた。

吾唯足知（われ　ただ　たるを　しる）とは、「知足（ちそく）の者は貧しといえども富めり、不知足の者は富めりといえども貧し」という禅の言葉からきているようである。

一言でいうと、「人は欲張らず、今の自分を大切にしなさい」という意味で、「足る事を知る人は不平不満が無く、心豊かな生活を送ることができる」ということでしょうか･･。

何とも意味深く、考えさせられる言葉である。

この言葉は、「石庭」で有名な京都の龍安寺（りょうあんじ）にある蹲（つくばい）に刻まれている言葉で、蹲は４つの漢字に共通している口の部分を中央に配し、そこに水を張るデザインになっている。　水戸光圀（みと みつくに）が寄進したと言い伝えられている。

リーマンブラザーズやＧＭの破綻。テレビや新聞で報道される企業トップや政治家の不祥事･･。また、企業では欧米の仕組みを、何も考えず！に取り込んだ成果主義の失敗･･。

最近の世相を見ると評価尺度が「金」に集約され、高齢者は先行き不安、中年は過労とストレスに押しつぶされ、若者は前途に夢を持てずにいる。

偶然見つけた石柱に書かれた言葉、今の自分に置き換えてみると、反省することが多々ある。　理不尽な左遷人事に対する不満。業績が思うように上がらないことに対するいらだち･･　、等々。

まだまだ、修行の日々である。

カタカナ語で提案しているベンダーは疑ってかかれ！

これは、メルマガ記事のタイトル。記事はこちらから。

確かにＩＴ業界はカタカナ語が氾濫している。
セミナーを聴いていても、やたらとカタカナ語を使う人っていますよね！

国会中継を聞いていてもカタカナ語を使う議員が多いですよね～！
国民に分かるような日本語を使って欲しいです。

毎週、初心者の方にパソコンを教えていますが、言葉の壁にはいつも悩まされます。
カタカナを、無理やり日本語にするのもどうかと･･。

システムの目的･･

システム設計書には、必ず「システムの目的」という項目があります。

企業がシステムを導入する場合は、必ず何らかの経営メリットを求めるはずです。

しかし、中には「これが目的ですか･･??」と思ってしまう内容の物もあったり、内容が抽象的すぎて、目的がぼやけている物もあります。

こんなプロジェクトの中には、崩れて顧客と開発ベンダーとの係争に発展するものもあります･･。

「･･効率アップ」
「･･基盤づくり」
「･･見える経営」
「パッケージありきの文言･･」

こんなキーワードが書かれていたら要注意！ですね。

もう１つ大切なのは、「顧客と目的を共有する」です。

ベンダーが勝手に設定する物でもなく、発注企業だけが思っている物でもありません･･。
お互いが目的を共有し、プロジェクトを進めていくことが重要です。

その機能、本当に必要･･?

ソフトウェアの複雑化・多様化にともない、求められる品質は日に日に高度化しています。

従来の品質は、書かれている仕様書通りの動きをするか?に注力されていました。

最近は、そもそも「この機能は本当に必要なの!?」と云う、『機能の妥当性』をチェックする必要性が言われています。

上流工程で、これを評価する仕組みや、テストエンジニアの育成が重要になってきているように思います。

成果を明確に･･

目的に向かって何かをやろう！と思ったとき、到達するまでの過程を細かく計画すると思います。
ＩＴの世界では、細分化して管理しようとする手法をWBS(Work Breakdown Structure)といいます。

このとき、漠然とした目標を設定する人を時々見かけます･･･。
これでは、目標の到達度合いを測ることが困難となり、次の目標へ向かっての修正もできません。

当たり前のようですが、意外とできていないと思いませんか?

成果を設定できない原因に、作業の塊が大きすぎることが挙げられます。
この様な場合は、具体的成果が設定できるレベルまでに作業を細分化してみてください。

スケープゴート

あまり使いたくない言葉ですが「身代わり」のことです。

プロジェクト崩れが発生すると、スケープゴートを作って自分は逃げようとする自己保身の人間がまれにいます。

この時、スケープゴートにされ易いのはPM（プロジェクトマネージャ）です。

プロジェクト崩れが発見されるのは、試験等の後半に多く手遅れになるケースもあります。

しかし、崩れは急に発生するのではなく徐々に悪化し、あるタイミングで発覚することになります。

実際プロジェクトを担当している人は、実は早い段階から「おかしいぞ･･」と気付いていることが多いのです。

崩れが発生してから騒ぎ立てたり、スケープゴートを仕立てるのは、母体組織の長であることが経験から多いです･･。

よくプロジェクトを機関車に例えます。

スタート段階では、母体組織の長も入って機関車をレールの上に乗せ、走り出すのを見守ることが大切です。

子育てと同じですね！

ソフトウェアの保守性･･

先日、このテーマで社員と少し議論をしました。この手の話しは、暗黙知の世界が多く、範囲を限定して話しをしないと発散してしまいます。
我々は、ソフトウェアを設計し、お客様に納品するまでは、多くのパワーを掛けます。また、管理手法もいろいろな物があります。しかし、開発以上にコストと時間を掛けている「ソフトウェア保守」についてはあまり関心が無いようにも見えます。
納品後に発生する要求に対し、いかに容易に対応できるようにしていくか･･という「保守性」についてはソースコードだけでなく、ドキュメントなども重要になります。
もう一つ重要なのは、ソースコードをいかに読みやすくするかという「可読性」という面も重要です。また、属人的なものをいかに排除していくか･･も大切なポイントとなります。
何か属人的な物ではなく、新たなメトリックス（物差し）が必要な気がしています。

難しい課題です･･。